Add more tests for the Indexed_pool

Explain your changes:
These tests were written to investigate the infamous nonce gap issue, that is a situation where some transactions are being lost in the network and are never being applied (see #8331 ). This was reported numerous times by block producers, who issue large numbers of transactions to pay a fraction of their block rewards to their delegators for the delegated stake. It is believed that the issue sits in the mempool, which sometimes discards valid (or potentially valid) transactions. While sometimes this cannot be helped, as the max size of the pool must be capped to protect nodes from consuming all of their machines' memory, the problem is so severe that something must change in how the mempool operates to mitigate it.
These tests exclude a few potential points of failure by proving that:

the mempool returns each account's transactions for application ordered by nonce (thus never skipping valid transactions this way);
the mempool always correctly invalidates applied transactions and does not invalidate anything in addition.

The final potential point of failure, which  cannot reliably be tested with unit tests is admission of transactions to the mempool. Checking that properly requires integration testing which will be added separately.
Explain how you tested your changes:

dune runtest src/lib/network_pool/test

Checklist:

[x] Dependency versions are unchanged

Notify Velocity team if dependencies must change in CI

n/a Modified the current draft of release notes with details on what is completed or incomplete within this project
[x] Document code purpose, how to use it

Mention expected invariants, implicit constraints

[x] Tests were added for the new behavior

Document test purpose, significance of failures
Test names should reflect their purpose

[x] All tests pass (CI will check this if you didn't)
[x] Serialized types are in stable-versioned modules
n/a Does this close issues? List them

!ci-build-me

!ci-build-me

!ci-build-me

!ci-build-me

!ci-build-me

!ci-build-me

!ci-build-me

!ci-build-me

!approved-for-mainnet


[SPARK-11314] [build] [hotfix] Add exclusion for moved YARN classes.

@JoshRosen

Test build #47205 has started for PR 10147 at commit beae35f.

LGTM. Thanks for fixing this.

Test build #47205 has finished for PR 10147 at commit beae35f.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/47205/
Test PASSed.

Merged build finished. Test PASSed.

Merging this now.


ITMS-90809: Deprecated API Usage UIWebView

React Native version: 0.60.5
Issue Description
ITMS-90809: Deprecated API Usage - Apple will stop accepting submissions of apps that use UIWebView APIs . See https://developer.apple.com/documentation/uikit/uiwebview for more information.

If you're using react-native-webview @imbudhiraja, take a look at:
https://github.com/react-native-community/react-native-webview/issues/312

We've received the same warning and are not using any webview

I've made the same mistake. Is there a solution? I didn't use react-native-webview

Just got the same email, I'm guessing it might be expo related? Because I'm otherwise doing pretty vanilla stuff on top of expo

more information here: https://github.com/react-native-community/react-native-webview/issues/819

@maxwell2022 @Yathousen no I'm not using react-native-webview

@Maxwell2022 @Yathousen no I'm not using react-native-webview

In the referenced issue they are also talking about other possible sources for this warning.

using RN 0.59.x
using modules that depend on react-native-webview

To fix this you need to update to RN0.60+,this is when WebView was extracted and use react-native-webview (if you need it) 7.0.1+

(OR dirty fix but if you really can't upgrade remove the RTCUIWebView files with a postinstall/patch)

How to check libary using Webview Deprecated API,
I upgraded react-native-webview to version 7.0.1 android react-native 0.59.10.
I can't pushlish my app to TestFlight. Please help me!

@ATranDev Maybe try grep -r UIWebView node_modules/*

To fix this you need to update to RN0.60+,this is when WebView was extracted and use react-native-webview (if you need it) 7.0.1+

(OR dirty fix but if you really can't upgrade remove the RTCUIWebView.* from react-native deps files with a postinstall/patch)

Do you have any sample for patch ? I am very new to react native and facing this issue and at this stage i can't take a risk to upgrade react native ?
Please help!

@HiralBarot1512
Do you use cocoapods? We put something like that in our Podfile's post_install
react_project = Xcodeproj::Project.open("../node_modules/react-native/React/React.xcodeproj")
    react_project.main_group["React/Views"].files.each do |file|
      if file.path.match(/^RCTWebView/)
        file.remove_from_project
      end
    end
react_project.save

We also removed or upgraded all packages that were using this deprecated Webview (like for example react-native-device-info.

In my case.
Long time i used HockeySDK in Podfile.
Solved : Remove HockySDK in Podfile -> Delete Podfile folder and Podfile.log in ios path -> Pod install.
Worked for me.

@mptorz I love you man! Those lines were a life saver :D

We tried @mptorz's post_install script, but we're still receiving the same warning, any updates on this?

hi try grepping pods folder
check

@bbturtle, @mikehardy I'm getting the similar one as @bbturtle. Here people have had UIwebview issues in a different forms and came up with a solution. Gr8 to c that. But from my side, I thought of upgrading the following libraries with the version mentioned below would fix the issue as one of the members suggested. But it still didn't fix it.
react-native-web-view: 7.0.1
react-native-device-info: 5.2.1
My existing react-native version: 0.59.10
After upgrading the above-mentioned web-view and device-info, when I did
grep -r UIWebView node_modules/*
I c the following.

I believe that I might have to upgrade react-native-threatmetrix. But other than that,
Can I understand what is this
node_modules/create-react-class/node_modules/fbjs/lib/UserAgent.js.flow:   * - UIWebView node_modules/create-react-class/node_modules/fbjs/lib/UserAgent.js:   * - UIWebView node_modules/create-react-context/node_modules/fbjs/lib/UserAgent.js.flow:   * - UIWebView node_modules/create-react-context/node_modules/fbjs/lib/UserAgent.js:   * - UIWebView node_modules/fbjs/lib/UserAgent.js.flow:   * - UIWebView node_modules/fbjs/lib/UserAgent.js:   * - UIWebView
Do I need to do anything on this or Can i ignore?
In here, one of them has suggested including post-install scripts in Podfile. Is that the only solution or can we do anything without touching the scripts?
Thanks in advance

Images are hard to decipher, text is preferred.
1- yes
2- Those all appear to be comments.
3- if you are fully upgraded, no? but each project has it's own priorities and needs

@mikehardy
Thanks for your immediate response. Apologies for the image sent as i thought it won't occupy more space. But if you need text, I can send it as well.
My actions after your response

Upon investigating a bit, I found that there is no upgrade for react-native-threatmetrix releases for long time. And what I found is that the default usage of webView in our app which is set to false upon initializing the ReactNativeThreatMetix call. Please note that react-native-threatmetrix is used as a dev dependency only. So, not sure if I have to do something about this. If yes, Pls, advise

I'm ignoring the following as suggested by you
node_modules/create-react-class/node_modules/fbjs/lib/UserAgent.js.flow:   * - UIWebView node_modules/create-react-class/node_modules/fbjs/lib/UserAgent.js:   * - UIWebView node_modules/create-react-context/node_modules/fbjs/lib/UserAgent.js.flow:   * - UIWebView node_modules/create-react-context/node_modules/fbjs/lib/UserAgent.js:   * - UIWebView node_modules/fbjs/lib/UserAgent.js.flow:   * - UIWebView node_modules/fbjs/lib/UserAgent.js:   * - UIWebView

At the moment I'm sticking on with react-native - 0.59.10 and not fully upgrading except for react-native-webview and reaft-native-device-info as I mentioned earlier. So, in that case, is the only solution available is to remove its usage via post_install scripts? Pls, advise.

I suppose I can ignore the react-native-charts-wrapper as I see this as a comment

The rest are all related to the usages of Webview under the node_modules/react-native/React/Views/RCTWebView.m: for which I've upgraded the react-native-web-view to 7.0.1. I suppose it should take care of the issue. Unsure if I need to upgrade to the latest or something. Please advise

Also, I noticed this while calling the WebView, there is no explicit use {useWebKit=true}. Do I need to inject {useWebkit=true} to opt into WKWebview. Pls, advise.

Hi @Brad19 . I can answer some of your questions:

The post script suggested by @mptorz was the only thing that worked for me (using react native 0.59)

react_project = Xcodeproj::Project.open("../node_modules/react-native/React/React.xcodeproj")
react_project.main_group["React/Views"].files.each do |file|
if file.path.match(/^RCTWebView/)
file.remove_from_project
end
end
react_project.save

I didn't write {useWebkit=true} anywhere in my code

react-native-web-view to 7.0.1 was enough for me

Thanks @lgenzelis . I'll try including the scripts in podfile and build it again to create a TestFlight build. Hope it works!!!

@Brad19  Can you make it work?
@mptorz Can you share some example of your pod file? Thank you.

@ducpt2 The solution that worked finally was removing the RCTWebView. It's not only important to upgrade the ReactNative Webview version, but also remove the old file where it has its reference. Just follow this - https://medium.com/@NumberShapes/uiwebview-app-store-submission-kickback-issue-bb07d77a902. I suppose it should work. If not, Pls check your references.

I have tried everything I can find on the web.
I have ran the
grep -r UIWebView node_modules/*
I currently get the following output
Binary file node_modules/react-native-device-info/RNDeviceInfo.xcodeproj/project.xcworkspace/xcuserdata/fahadhaque.xcuserdatad/UserInterfaceState.xcuserstate matches

node_modules/fbjs/lib/UserAgent.js:   * - UIWebView

node_modules/fbjs/lib/UserAgent.js.flow:   * - UIWebView

node_modules/react-native-webview/README.md:- [7.0.1](https://github.com/react-native-community/react-native-webview/releases/tag/v7.0.1) - Removed UIWebView

node_modules/ua-parser-js/test/browser-test.json:        "ua"      : "Mozilla/5.0 (iPhone; CPU iPhone OS 10_0_2 like Mac OS X) AppleWebKit/602.1.50 (KHTML, like Gecko) Mobile/14A456 QQ/<IP_ADDRESS>0 V1_IPH_SQ_6.5.3_1_APP_A Pixel/1080 Core/UIWebView NetType/WIFI Mem/26",

I am still getting the deprecated warning error when I upload to  itunesconnect.
Can some one please help. Thanks in advance.

@HiralBarot1512
Do you use cocoapods? We put something like that in our Podfile's post_install
react_project = Xcodeproj::Project.open("../node_modules/react-native/React/React.xcodeproj")
    react_project.main_group["React/Views"].files.each do |file|
      if file.path.match(/^RCTWebView/)
        file.remove_from_project
      end
    end
react_project.save

We also removed or upgraded all packages that were using this deprecated Webview (like for example react-native-device-info.

i am not able to find React.xcodeproj, may be because of higher react-native version(0.61). Any solution that might help?

@fahadhaquni
Pls use the following in post_install in podfile and i'm sure it should work as this will delete the old files which had deprecated references.
react_project = Xcodeproj::Project.open("../node_modules/react-native/React/React.xcodeproj")
react_project.main_group["React/Views"].files.each do |file|
if file.path.match(/^RCTWebView/)
file.remove_from_project
end
end
react_project.save

I'm unfortunately seeing this on 0.61.5, I'm not using WebView at all, and I've grepped for UIWebView and RCTWebView to no success. I have no idea where this warning is coming from.

Following instructions above, I looked into adding a post_install step to my Pods file. When I looked at the path in the given code, I couldn't find React.xcodeproj. I assume it went away as part of the refactoring that went into react-native 0.61.X + (maybe even earlier).
Next I tried searching my node_modules for the string UIWebView:
grep -r UIWebView node_modules/* but the on closer inspection most of them were comments or lines in changelogs.
I expanded my search to the entire project, and came up with some hits in my Pods directory:
[redacted]$ grep -r UIWebView ./*
# (comments/changelogs/android code removed)...
Binary file ./ios/Pods/FirebaseMLCommon/Frameworks/FirebaseMLCommon.framework/FirebaseMLCommon matches
Binary file ./ios/Pods/Crashlytics/iOS/Crashlytics.framework/Crashlytics matches
Binary file ./ios/Pods/Fabric/upload-symbols matches
# ...

This pointed strongly towards our firebase dependencies being the culprit (Fabric is used by firebase). I googled for firebase+UIWebView and found a GH Issue suggesting it was a known/fixed issue. I upgraded the three firebase dependencies we have using:
yarn upgrade @react-native-firebase/app @react-native-firebase/analytics @react-native-firebase/crashlytics

cd ios

rm -rf Pods # probably not needed
pod install

Built my project, tested everything was still working and submitted to Apple. This time there was no message about using a depreciated API.

For those who can't update above RN 0.60 i run this command and it's solve the problem in react native package:
local dir="${BASE_DIR}/node_modules/react-native/React";
sed -i'.bak' '/RCTWebView/d' "${dir}/React.xcodeproj/project.pbxproj"
rm -f "${dir}/React.xcodeproj/project.pbxproj.bak"
rm -f "${dir}/Views/RCTWebView.m"
rm -f "${dir}/Views/RCTWebView.h"
rm -f "${dir}/Views/RCTWebViewManager.m"
rm -f "${dir}/Views/RCTWebViewManager.h"

Credit To -
https://medium.com/@ivanpagac_5657/how-to-solve-itms-90809-deprecated-api-usage-with-reactnative-0-60-in-ci-pipeline-132ca60dcf60

@barak109 that's a good catch. This is a dirty way but it works 👍
small description to make it easy to implement

create removeWebView.sh file in your root folder
inside  removeWebView.sh past this code:

#!/bin/bash
BASE_DIR=`pwd`;
function remove_rctwebview(){

    local dir="${BASE_DIR}/node_modules/react-native/React";

    sed -i'.bak' '/RCTWebView/d' "${dir}/React.xcodeproj/project.pbxproj"
    rm -f "${dir}/React.xcodeproj/project.pbxproj.bak"
    rm -f "${dir}/Views/RCTWebView.m"
    rm -f "${dir}/Views/RCTWebView.h"
    rm -f "${dir}/Views/RCTWebViewManager.m"
    rm -f "${dir}/Views/RCTWebViewManager.h"
}

remove_rctwebview;

in your terminal execute chmod 777 removeWebView.sh
and then sudo ./removeWebView.sh
check if files have been removed from  /node_modules/react-native/React

Does anybody has resolved this issue? specially @fahadhaquni

@AtranDev Maybe try grep -r UIWebView node_modules/*

Try this where exactly?

my app not accepting by testflight.
By this reson.
plz help. i am stuck from 10 days.
i have tried all soolutions.

@Biplovkumar
What is the error do you get. Could you please explain what did you try and what do you get now?

Did you check grep -r UIWebView node_modules/*
Did you use react-native-gesture-handler or reaft-native-device-info or any other
Any other peer dependencies?
Please explain to get more clarity for others.

same problem.react native 0.62

I solved my problem, after upgrading from 0.59.10 to 0.61.3.. which even after upgrading react-native-fbsdk i was not able to publish the app.
The steps i have followed in order to solve it:
1)  Upgrade the package to react-native-fbsdk": "^2.0.0",
2) Added to pod:

pod 'FBSDKCoreKit'
pod 'FBSDKLoginKit'
pod 'FBSDKShareKit'
pod 'FBSDKPlacesKit'

3) Removed from framework folder the old facebook frameworks:

ios/Frameworks/FBSDKCoreKit.framework/Headers/FBSDKAccessToken.h
ios/Frameworks/FBSDKCoreKit.framework/FBSDKCoreKit
... all FBSDKXXXX

4) Removed also from Xcode in frameworks folder
5) cd ios - pod install
6) Archive and uploaded to apple.

I am facing the same issue, while using react-native-fbsdk: 2.0.0,
Can you help me to fix this issue?

Just got the same email, I'm guessing it might be expo related? Because I'm otherwise doing pretty vanilla stuff on top of expo

@rcchen This reply is a bit late, but ExpoSDK > 36.0.0 uses UIWebView which will cause the bug. Upgrading to 36.0.0 or higher should fix it.

I was also facing the same issue, the trick was to upgrade react-native-gesture-handler and removing the Facebook SDK and bolts framework references from ios/Frameworks as Pod installs them in the Pods anyway.

killed my hours ,
in xcode searched uiwebview then made the changes below on FIRAuth* files
//webView.webView.delegate = self; UIWEBView -> WKWebView UIWebViewDelegate -> WKNavigationDelegate

@rakeshostwal I'm having the same issue, I have updated the react-native-gesture-handler, can you explain more to delete the fbsdk and bolts framework ?

@kemalony did you just comment the line? and how did you find the FIRAuth* files. I'm having the same issue.

same issue but i'm using both WebView from react-native and from react-native-webview.
"react-native": "0.60.5",
"react-native-webview": "^9.4.0"
"react-native-fbsdk": "^1.0.4",

For those who can't update above RN 0.60 i run this command and it's solve the problem in react native package:
local dir="${BASE_DIR}/node_modules/react-native/React";
sed -i'.bak' '/RCTWebView/d' "${dir}/React.xcodeproj/project.pbxproj"
rm -f "${dir}/React.xcodeproj/project.pbxproj.bak"
rm -f "${dir}/Views/RCTWebView.m"
rm -f "${dir}/Views/RCTWebView.h"
rm -f "${dir}/Views/RCTWebViewManager.m"
rm -f "${dir}/Views/RCTWebViewManager.h"

Credit To -
https://medium.com/@ivanpagac_5657/how-to-solve-itms-90809-deprecated-api-usage-with-reactnative-0-60-in-ci-pipeline-132ca60dcf60

Using CocoaPods (in 0.59.10), as well as running the above I also had to:

Remove the following lines from ios/Pods/Target Support Files/React/React-umbrella.h:

#import "RCTWebView.h"
#import "RCTWebViewManager.h"

Go to the React target of the Pods project and remove references to RCTWebView and RCTWebViewManager in Build Phases -> Headers (Public & Private).

In my particular case on an application that is using react-native 0.59.10 I made the following steps to solve the issue:
Steps to fix the issue on React-Native 0.59.X
Upgrade dependencies
Make sure all the dependencies are not using UIWebView. If you find a dependency that is using UIWebView find the update that removes it.
To check this you'll have to look on node_modules and ios project folder with the following commands:
$ grep -r UIWebView node_modules/*

$ cd ios/ && grep -r UIWebView .

Ignore the UIWebView references from node_modules/react-native because I'm going to explain later how to remove those references. Make sure that both commands does not returns real code that is using UIWebView. You may find matches on comments but those doesn't matter.
:warning:  In case you're using react-native-webview you'll find that on<EMAIL_ADDRESS>you are not able to use the release that contains the removal of this component because it requires react-native version bigger than 0.60.x (due to AndroidX support).
You should use jettifier on reverse mode to patch the dependency and convert it to Android Support Library on install time. After that you'll be able to upgrade this dependency and make it work on Android build.
Remove UIWebView references from react-native core
Ensure that all the WebViews you're using on your react codebase are imported from react-native-webview and not react-native.
Once you don't have any dependency that is using UIWebView internally. Now you need to remove the UIWebView from the react-native core. Why ? You might wonder, because this removal was done on the 0.60 release. To do that I implemented the following solution https://github.com/facebook/react-nareacttive/issues/26255#issuecomment-528275747 as an npm postinstall script since I'm not using CocoaPods for the moment.
ios/removeUIWebView.rb
require 'xcodeproj'

# This script removes UIWebView from React project.
# We should remove this script once we upgrade react-native to 0.60.x
react_project = Xcodeproj::Project.open("./node_modules/react-native/React/React.xcodeproj")

react_project.main_group["React/Views"].files.each do |file|
  if file.path.match(/^RCTWebView/)
    file.remove_from_project
  end
end

react_project.save

puts '> ✅ UIWebView removed successfully from React.xcodeproj'

package.json
"scripts": {
  "postinstall": "npx jetifier -r && ruby ios/removeUIWebView.rb
}

This step is not required once you upgrade to react-native > 0.60. Because this is already done on the native iOS library.
Upgrading to react-native 0.6X does not solves the problem if there are dependencies using UIWebView
This is an important concept. If you still have dependencies that are using the deprecated WebView you'll find the same warning even though you upgraded your react-native version.
List of conflicting libraries
From all my dependencies these ones had a UIWebView reference to it:

react-native-fbsdk: I had a Bolts.framework linked from the first time I was using the library and it's not needed anymore on fbsdk-ios v5. Also starting from v5 UIWebView has been removed from the SDK. Reference from the maintainer

react-native-firebase-sdk: Upgrade the firebase-ios-sdk to the latest version 6.28. If you are below 6.8.1 you should upgrade at least to 6.9.0. Reference from the release notes.

After doing this I'm not receiving anymore the following warning:
ITMS-90809: Deprecated API Usage - App updates that use UIWebView will no longer be accepted as of December 2020. Instead, use WKWebView for improved security and reliability. Learn more (https://developer.apple.com/documentation/uikit/uiwebview).

💪🏼  Thanks to everyone on this issue for helping, I hope this comment could help someone ❤  👏🏼

@barak109 that's a good catch. This is a dirty way but it works 👍
small description to make it easy to implement

create removeWebView.sh file in your root folder
inside  removeWebView.sh past this code:

#!/bin/bash
BASE_DIR=`pwd`;
function remove_rctwebview(){

    local dir="${BASE_DIR}/node_modules/react-native/React";

    sed -i'.bak' '/RCTWebView/d' "${dir}/React.xcodeproj/project.pbxproj"
    rm -f "${dir}/React.xcodeproj/project.pbxproj.bak"
    rm -f "${dir}/Views/RCTWebView.m"
    rm -f "${dir}/Views/RCTWebView.h"
    rm -f "${dir}/Views/RCTWebViewManager.m"
    rm -f "${dir}/Views/RCTWebViewManager.h"
}

remove_rctwebview;

in your terminal execute chmod 777 removeWebView.sh
and then sudo ./removeWebView.sh
check if files have been removed from  /node_modules/react-native/React

It worked fine. When I execute command "grep -r UIWebView ." inside node module path nothing exists, but inside the project I found too many binary files inside ./ios/Build matches . Finally got the same mail from app store " UIWebView are no longer accepted".
Any solution, please ?

Still got the same error. Apple no longer accept builds with UIWebView reference.
I tried adding post install script to remove references to UIWebView, RCTWebView. I also upgraded react-native-webview to 7.5.2 (also tried 10.0.0) but nothing worked for me. The project I'm working on currently using RN 0.59.8.
Also ran: grep -r UIWebView node_modules/* and here's what I got:

Tried to removing the ff:

react-native-instagram-login
react-native-reanimated
react-native-web

Nothing worked as well.
We are also attempting to upgrade to higher SDK version but having errors and it's kinda complicated to do so.
Is there anything else we need to do? Please help. Thanks.

Hello everyone, I looked at this issue but I couldn't solve my problem.
My problem is the same as reported above -> ITMS-90809: Deprecated API Usage - New apps that use UIWebView are no longer accepted. Instead, use WKWebView for improved security and reliability. Learn more (https://developer.apple.com/documentation/uikit/uiwebview).
Package.json from my current project
{
  "name": "app1",
  "version": "0.0.1",
  "dependencies": {
    "axios": "^0.18.0",
    "axios-extensions": "^3.0.5",
    "babel-eslint": "^10.0.1",
    "boleto-validator": "^1.0.2",
    "color": "^3.1.2",
    "graceful-fs": "^4.2.4",
    "lodash": "^4.17.11",
    "moment": "^2.24.0",
    "react": "16.8.3",
    "react-native": "0.59.10",
    "react-native-android-open-settings": "^1.2.0",
    "react-native-animatable": "^1.3.0",
    "react-native-camera": "^1.6.4",
    "react-native-carousel-control": "^2.0.1",
    "react-native-circular-progress": "^1.1.0",
    "react-native-contacts": "^3.1.4",
    "react-native-custom-qr-codes": "^2.0.0",
    "react-native-datepicker": "^1.7.2",
    "react-native-device-info": "^7.1.0",
    "react-native-elements": "^0.19.1",
    "react-native-elevated-view": "0.0.6",
    "react-native-fast-image": "^5.1.2",
    "react-native-fingerprint-scanner": "^2.5.0",
    "react-native-firebase": "^5.2.3",
    "react-native-flexi-radio-button": "^0.2.2",
    "react-native-gesture-handler": "^1.2.1",
    "react-native-image-resizer": "^1.0.0",
    "react-native-keychain": "^3.0.0",
    "react-native-masked-text": "^1.9.2",
    "react-native-modal": "^7.0.2",
    "react-native-modal-datetime-picker": "^6.0.0",
    "react-native-motion": "^0.2.0",
    "react-native-navbar": "^2.1.0",
    "react-native-orientation": "^3.1.3",
    "react-native-orientation-locker": "^1.1.1",
    "react-native-pdf": "^5.0.11",
    "react-native-permissions": "^1.1.1",
    "react-native-picker-select": "^5.2.4",
    "react-native-progress": "^3.5.0",
    "react-native-public-ip": "^1.0.1",
    "react-native-push-notification": "^3.1.2",
    "react-native-qrcode-scanner": "^1.1.2",
    "react-native-qrcode-svg": "^5.1.1",
    "react-native-responsive-screen": "^1.2.0",
    "react-native-router-flux": "^4.0.6",
    "react-native-search-filter": "^0.1.4",
    "react-native-shadow": "^1.2.2",
    "react-native-share": "^1.1.3",
    "react-native-snap-carousel": "^3.7.5",
    "react-native-svg": "^9.3.3",
    "react-native-svg-uri": "^1.2.3",
    "react-native-swipe-gestures": "^1.0.3",
    "react-native-transition": "^1.1.8",
    "react-native-ui-xg": "0.0.6",
    "react-native-vector-icons": "^6.1.0",
    "react-native-voice": "^0.2.6",
    "react-native-webview": "^10.10.2",
    "react-number-format": "^4.0.6",
    "react-redux": "^6.0.0",
    "redux": "^4.0.1",
    "redux-thunk": "^2.3.0",
    "reselect": "^4.0.0",
    "rn-fetch-blob": "0.10.15",
    "rn-viewpager": "^1.2.9",
    "standard": "^12.0.1"
  },
  "devDependencies": {
    "@babel/core": "^7.4.5",
    "@babel/runtime": "^7.4.5",
    "babel-jest": "^24.8.0",
    "jest": "^24.8.0",
    "metro-react-native-babel-preset": "^0.54.1",
    "react-test-renderer": "16.8.3",
    "reactotron-react-native": "^3.2.1",
    "reactotron-redux": "^3.1.0"
  },
  "jest": {
    "preset": "react-native"
  },
  "private": true,
  "rnpm": {
    "assets": [
      "./src/assets/fonts/"
    ]
  },
  "scripts": {
    "android": "react-native run-android",
    "port:kill": "kill -9 $(lsof -t -i:8081)",
    "android:apk": "cd android && ./gradlew assembleRelease && cd .. && yarn copy:apk",
    "copy:apk": "cp android/app/build/outputs/apk/release/app-x86-release.apk se-wallet.apk",
    "clean-cache": "react-native start --reset-cache",
    "emulate": "cd %USERPROFILE%/AppData/Local/Android/Sdk/emulator && emulator @Nexus",
    "maxUserWatches": "echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p",
    "start": "node node_modules/react-native/local-cli/cli.js start",
    "test": "standard"
  },
  "standard": {
    "parser": "babel-eslint",
    "globals": [
      "describe",
      "test",
      "jest",
      "expect",
      "fetch",
      "navigator",
      "__DEV__",
      "XMLHttpRequest",
      "FormData",
      "React$Element"
    ]
  }
}

I did the process of running the script below
#!/bin/bash
BASE_DIR=`pwd`;
function remove_rctwebview(){

    local dir="${BASE_DIR}/node_modules/react-native/React";

    sed -i'.bak' '/RCTWebView/d' "${dir}/React.xcodeproj/project.pbxproj"
    rm -f "${dir}/React.xcodeproj/project.pbxproj.bak"
    rm -f "${dir}/Views/RCTWebView.m"
    rm -f "${dir}/Views/RCTWebView.h"
    rm -f "${dir}/Views/RCTWebViewManager.m"
    rm -f "${dir}/Views/RCTWebViewManager.h"
}

remove_rctwebview;

I also run the following command on the terminal
❯ grep -r UIWebView node_modules/*
node_modules/fbjs/lib/UserAgent.js:   * - UIWebView
node_modules/fbjs/lib/UserAgent.js.flow:   * - UIWebView
node_modules/jsc-android/dist/include/JSContextPrivate.h:/*! @abstract The delegate the context will use when trying to load a module. Note, this delegate will be ignored for contexts returned by UIWebView. */
node_modules/metro/node_modules/fbjs/lib/UserAgent.js:   * - UIWebView
node_modules/metro/node_modules/fbjs/lib/UserAgent.js.flow:   * - UIWebView
node_modules/react-native/node_modules/fbjs/lib/UserAgent.js:   * - UIWebView
node_modules/react-native/node_modules/fbjs/lib/UserAgent.js.flow:   * - UIWebView
node_modules/react-native-webview/README.md:- [7.0.1](https://github.com/react-native-community/react-native-webview/releases/tag/v7.0.1) - Removed UIWebView
node_modules/ua-parser-js/test/browser-test.json:        "ua"      : "Mozilla/5.0 (iPhone; CPU iPhone OS 10_0_2 like Mac OS X) AppleWebKit/602.1.50 (KHTML, like Gecko) Mobile/14A456 QQ/<IP_ADDRESS>0 V1_IPH_SQ_6.5.3_1_APP_A Pixel/1080 Core/UIWebView NetType/WIFI Mem/26",

But even after doing all the processes I still can't publish in the store. Has anyone managed to solve or have a tip? Remembering that I have already placed all WebViews in react-native-webview and also with useWebKit = {true}

Still got the same error. Apple no longer accept builds with UIWebView reference.
I tried adding post install script to remove references to UIWebView, RCTWebView. I also upgraded react-native-webview to 7.5.2 (also tried 10.0.0) but nothing worked for me. The project I'm working on is currently using RN 0.59.8.
Also ran: grep -r UIWebView node_modules/* and here's what I got:

Tried to removing the ff:

react-native-instagram-login
react-native-reanimated
react-native-web

Nothing worked as well.
We are also attempting to upgrade to higher SDK version but having errors and it's kinda complicated to do so.
Is there anything else we need to do? Please help. Thanks.

Updates:
We did check the Pods and UIWebView still exists in Crashlytics and FBAudienceNetwork as part of/dependencies of ExpoKit 2.13.0.
Aside from doing the post install script, what we did is to upgrade Crashlytics from 3.13.4 to 3.14.0 and FBAudienceNetwork to 5.5.0 to 5.6.0.
I did fork Expo repository and upgraded the versions for Crashlytics and FBAudienceNetwork. Check it [here].(https://github.com/jeremiahlachica/expo/commit/f5cd4bc2bc785dcfddd676db1c0c31eafcb0bb64)
Solution for my case:

If you're using ExpoKit 2.13.0, replace this block:

pod 'ExpoKit',
    :git => "http://github.com/expo/expo.git",
    :tag => "ios/2.13.0",
    :subspecs => [
      "Core"
    ],
    :inhibit_warnings => true

To
pod 'ExpoKit',
    :git => "http://github.com/jeremiahlachica/expo.git",
    :tag => "ios/<IP_ADDRESS>",
    :subspecs => [
      "Core"
    ],
    :inhibit_warnings => true

Delete Podfile.lock
Delete Pods folder
In the terminal: pod install

I hope this will help someone.

ITMS-90809: Deprecated API Usage** - New apps that use UIWebView are no longer accepted. Instead, use WKWebView for improved security and reliability. Learn more (Apple Developer Documentation).
Package.json
“dependencies”: {
“@angular/common”: “~8.1.2”,
“@angular/compiler”: “~8.1.2”,
“@angular/core”: “~8.1.2”,
“@angular/forms”: “~8.1.2”,
“@angular/platform-browser”: “~8.1.2”,
“@angular/platform-browser-dynamic”: “~8.1.2”,
“@angular/router”: “~8.1.2”,
“@ionic-native/app-version”: “^5.27.0”,
“@ionic-native/core”: “^5.14.0”,
“@ionic-native/geolocation”: “^5.14.0”,
“@ionic-native/ionic-webview”: “^5.34.0”,
“@ionic-native/native-geocoder”: “^5.14.0”,
“@ionic-native/onesignal”: “^5.18.0”,
“@ionic-native/paypal”: “^5.28.0”,
“@ionic-native/photo-viewer”: “^5.29.0”,
“@ionic-native/sms-retriever”: “^5.27.0”,
“@ionic-native/splash-screen”: “^5.0.0”,
“@ionic-native/status-bar”: “^5.0.0”,
“@ionic-native/stripe”: “^5.28.0”,
“@ionic/angular”: “^4.7.1”,
“card.io.cordova.mobilesdk”: “^2.1.0”,
“com.paypal.cordova.mobilesdk”: “^3.5.0”,
“com.razorpay.cordova”: “^1.4.9”,
“cordova-browser”: “^5.0.4”,
“cordova-plugin-add-swift-support”: “2.0.2”,
“cordova-plugin-app-version”: “^0.1.9”,
“cordova-plugin-cocoapod-support”: “^1.6.2”,
“cordova-plugin-device”: “^2.0.2”,
“cordova-plugin-geolocation”: “^4.0.2”,
“cordova-plugin-ionic-keyboard”: “^2.2.0”,
“cordova-plugin-nativegeocoder”: “^3.2.2”,
“cordova-plugin-sms-retriever-manager”: “^1.0.2”,
“cordova-plugin-splashscreen”: “^5.0.2”,
“cordova-plugin-statusbar”: “^2.4.2”,
“cordova-plugin-stripe”: “^1.5.3”,
“cordova-plugin-whitelist”: “^1.3.3”,
“core-js”: “^2.5.4”,
“onesignal-cordova-plugin”: “2.8.0”,
“rxjs”: “~6.5.1”,
“rxjs-compat”: “^6.5.4”,
“tslib”: “^1.9.0”,
“zone.js”: “~0.9.1”
},
“devDependencies”: {
“@angular-devkit/architect”: “~0.801.2”,
“@angular-devkit/build-angular”: “~0.801.2”,
“@angular-devkit/core”: “~8.1.2”,
“@angular-devkit/schematics”: “~8.1.2”,
“@angular/cli”: “~8.1.2”,
“@angular/compiler”: “~8.1.2”,
“@angular/compiler-cli”: “~8.1.2”,
“@angular/language-service”: “~8.1.2”,
“@ionic/angular-toolkit”: “~2.0.0”,
“@ionic/lab”: “2.0.11”,
“@types/jasmine”: “~3.3.8”,
“@types/jasminewd2”: “~2.0.3”,
“@types/node”: “~8.9.4”,
“codelyzer”: “^5.0.0”,
“com-sarriaroman-photoviewer”: “^1.2.5”,
“cordova-android”: “^7.1.4”,
“cordova-ios”: “^5.1.1”,
“cordova-plugin-ionic-webview”: “^5.0.0”,
“jasmine-core”: “~3.4.0”,
“jasmine-spec-reporter”: “~4.2.1”,
“karma”: “~4.1.0”,
“karma-chrome-launcher”: “~2.2.0”,
“karma-coverage-istanbul-reporter”: “~2.0.1”,
“karma-jasmine”: “~2.0.1”,
“karma-jasmine-html-reporter”: “^1.4.0”,
“protractor”: “~5.4.0”,
“ts-node”: “~7.0.0”,
“tslint”: “~5.15.0”,
“typescript”: “~3.4.3”
},
“description”: “An Ionic project”,
“cordova”: {
“plugins”: {
“cordova-plugin-whitelist”: {},
“cordova-plugin-statusbar”: {},
“cordova-plugin-device”: {},
“cordova-plugin-splashscreen”: {},
“cordova-plugin-ionic-keyboard”: {},
“cordova-plugin-nativegeocoder”: {
“LOCATION_WHEN_IN_USE_DESCRIPTION”: “Use geocoder service”
},
“cordova-plugin-sms-retriever-manager”: {
“PLAY_SERVICES_VERSION”: “15.0.1”
},
“cordova-plugin-ionic-webview”: {},
“cordova-plugin-app-version”: {},
“cordova-plugin-geolocation”: {
“GEOLOCATION_USAGE_DESCRIPTION”: “We need your location for display nearest store.”,
“GPS_REQUIRED”: “true”
},
“com.razorpay.cordova”: {},
“com.paypal.cordova.mobilesdk”: {},
“cordova-plugin-stripe”: {},
“com-sarriaroman-photoviewer”: {}
},
“platforms”: [
“android”,
“browser”,
“ios”
]
Config.xml
We use your location for full functionality of certain app features.
Please help me out. I’m looking for 1 month but not a get solution.
Thanks.


Add LZO compression in Snap

After installing the headset snap, I checked that compression isn't mentioned there. Mention compression: lzo in the snapcraft.yaml file and the startup speed will increase a lot. I didn't get the snapcraft.yaml in your repo, else I'd have pushed that.

Hey, I just updated the app, the startup speed is 1 sec, compared to 4.99 sec. What about you? Can u check it?

That is great news! I only use the .deb for my own, so I'm going to need to spin a virtual machine so I can test it.
I was reading more about LZO compression and indeed, it can offer 2-3 times speed improvement, so it makes sense to see such a big change. Just make sure you test the startup times on a freshly rebooted system because after the first time opened, data is cached in memory and subsequent starts are always fast no matter the compression algorithm.


[Request] Multi-screen/monitor

Great job so far!
Long shot, but is there any chance of getting multi-screen/monitor support down the line?
Cheers

Technically there already is. Let's say you had two 1080p screens next to each other. If they are both aligned in display settings to have their corners lined up, you just need to set a game position at X: 1920, Y:0. Windows should be treating this as one huge canvas, with 0-1919 being monitor one, and 1920-3839 being monitor two. Good idea though, I'll make this easier down the line.
On Apr 22, 2018 at 12:00 PM<EMAIL_ADDRESS>wrote:
Great job so far!
Long shot, but is there any chance of getting multi-screen/monitor support down the line?
Cheers
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/pkillboredom/ElDewritoSimpleSplitScreen/issues/2, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AEN53jCRQX7bCLJT3DIYQJ4m9XiZDtZNks5trKkwgaJpZM4Te60h.

Wow,
That does indeed work! Requires some maths as I've got 4 monitors running different resolutions.
Great,
Thanks!


replace redux-elm on prism

ping

Thanks for the ping. I need to refactor Devarchy before replacing redux-elm with redux-prim. This could take a while as I'm currently busy with https://github.com/brillout/reframe.


Incorrection documentation about "cmd login"

On the doc https://github.com/Ericsson/codechecker/blob/master/docs/authentication.md
we can read:

The user can log in onto the server by issuing the command CodeChecker cmd login -h host -p port -u username -pw passphrase.

which is incorrect according to the code https://github.com/Ericsson/codechecker/blob/7a518174df70de3b2d6acba8f8914dc9551e8807/tests/libtest/codechecker.py#L39

Thanks!


Add JSUT VITS model

Codecov Report

Merging #47 (58ae4cc) into master (01f38f8) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #47   +/-   ##
=======================================
  Coverage   49.46%   49.46%
=======================================
  Files           2        2
  Lines         372      372
=======================================
  Hits          184      184
  Misses        188      188

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 01f38f8...58ae4cc. Read the comment docs.


add a configuration to control columns visibility and width

This is an alternative to #370 which adds support for configuring pg_activity from a file. The JSON format is to be discussed.
What do you think @blogh?

The JSON format is to be discussed.

We can also use an INI format, if we anticipate that we'll never need nested options (or sub-sections).

At first, I was not fond of the idea of  a json file, but it's not that bad. I think we can keep this format.
Do we remove these options from the cli ?
Process table display options:
  These options may be used hide some columns from the processes table.

  --no-pid              Disable PID.
  --no-database         Disable DATABASE.
  --no-user             Disable USER.
  --no-client           Disable CLIENT.
  --no-cpu              Disable CPU%.
  --no-mem              Disable MEM%.
  --no-read             Disable READ/s.
  --no-write            Disable WRITE/s.
  --no-time             Disable TIME+.
  --no-wait             Disable W.
  --no-app-name         Disable App.

At first, I was not fond of the idea of a |json| file, but it's not that
bad. I think we can keep this format.

Not very happy with JSON either; it's just the simplest solution.
But will think about other options and try to see how it works.

Do we remove these options from the cli ?

I don't think it's needed for a breaking change. As is, command-line
options take precedence over the configuration file so this is properly
handled. Also, from a user point of view, I suspect people would want to
sometime hide a specific column one-shot through the --no-xxx option,
but probably won't change columns width so often.

That makes sens, yes.

Changed to INI format; now ready for testing and review @blogh.

How would it work if we add a panel with different columns (I suppose it
would we already have mem/cpu/read/write)?

It works the same as before: if a column is configured to be hidden, it
will be hidden in all panels.

Does it make sense to hide columns in some panels but not in others? (eg
displaying client only for blocking queries)

I don't know, maybe... but maybe not...
Yet, if we want a way to configure per-panel visibility, we'd need a way
to select the panel name from the configuration file. Since there is no
possibility to nest options in INI format, the nesting should be in the
section mame, i.e. something like [running.client]. Or we should
rather go with a file format supporting nested data structures: but is
it worth?

I'm in favor of the INI format. It's certainly simpler for the user and
the complexity on our side, arguably a bit more important than JSON (but
without the need for a third-party dependency), is acceptable.

Ok, let commit to this then. Thanks !


cachix miss on stable

I'm trying to upgrade my system today (on stable), but it's trying to rebuild cosmic from source (which I've never been able to do even with reduced core count and it takes a long time). Is the cache not updated yet? Or is there something wrong with my flake? I've had the cache hit before so it's a bit confusing. I also tried disabling cosmic, doing nixos-rebuild test, and then re-enabling cosmic but it still tries to compile.

See https://github.com/lilyinstarlight/nixos-cosmic/issues/507#issuecomment-2556010230, we've been having some CI troubles that have exacerbated the cache situation
We should have cache populated again once #524 finishes building

Didn't realize you could see the status of the cache build in GitHub actions. It's rebuilding now so my timing must have been a bit unlucky!

I do plan on setting up storepath pinning for cachix at some point to help the problem of repeatedly failing intermediate builds filling up the cache and evicting old storepaths when updates get stalled for a few days :)

Pinning was easier than I anticipated, so I've actually gone ahead and implemented that locally and will push once #524 merges (so that it doesn't start parallel CI runs, which we still aren't able to do yet for a few more days until CI is finished being reworked and cloud quotas get upped)


Bedrock doesn't work with Claude 3

Checked other resources

[X] I added a very descriptive title to this issue.
[X] I searched the LangChain documentation with the integrated search.
[X] I used the GitHub search to find a similar question and didn't find it.
[X] I am sure that this is a bug in LangChain rather than my code.
[X] The bug is not resolved by updating to the latest stable version of LangChain (or the specific integration package).

Example Code
import streamlit as st
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.runnables import RunnablePassthrough
from langchain_core.output_parsers import StrOutputParser
from langchain_community.llms.bedrock import Bedrock
from langchain_community.retrievers.bedrock import AmazonKnowledgeBasesRetriever

retriever = AmazonKnowledgeBasesRetriever(
  knowledge_base_id="XXXXXXXXXX", # Input KB ID here
  retrieval_config={
    "vectorSearchConfiguration": {
      "numberOfResults": 10,
      "overrideSearchType": "HYBRID"
    }})

prompt = ChatPromptTemplate.from_template("Answer questions based on the context below: {context} / Question: {question}")

model = Bedrock(model_id="anthropic.claude-3-sonnet-20240229-v1:0", model_kwargs={"max_tokens_to_sample": 1000})
chain = ({"context": retriever, "question": RunnablePassthrough()} | prompt | model | StrOutputParser())

st.title("Ask Bedrock")
question = st.text_input("Input your question")
button = st.button("Ask!")

if button:
  st.write(chain.invoke(question))

Error Message and Stack Trace (if applicable)
ValidationError: 1 validation error for Bedrock root Claude v3 models are not supported by this LLM.Please use from langchain_community.chat_models import BedrockChat instead. (type=value_error)
Traceback:
File "/home/ec2-user/.local/lib/python3.9/site-packages/streamlit/runtime/scriptrunner/script_runner.py", line 535, in _run_script
exec(code, module.dict)
File "/home/ec2-user/environment/rag.py", line 22, in
model = Bedrock(model_id="anthropic.claude-3-sonnet-20240229-v1:0", model_kwargs={"max_tokens_to_sample": 1000})
File "/home/ec2-user/.local/lib/python3.9/site-packages/langchain_core/load/serializable.py", line 120, in init
super().init(**kwargs)
File "/home/ec2-user/.local/lib/python3.9/site-packages/pydantic/v1/main.py", line 341, in init
raise validation_error
Description
To use claude 3 (Sonnet) on Amazon Bedrock, langchain_community seems to be updated.
System Info
langchain==0.1.11
langchain-community==0.0.27
langchain-core==0.1.30
langchain-text-splitters==0.0.1
macOS 14.2.1（23C71）
Python 3.9.16

Claude 3 cannot use for  generate responses after retrieving information from knowledge bases
https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base-supported.html

Changes have been merged to work with it. Awaiting a new build
https://github.com/langchain-ai/langchain/pull/18630

I think you should use "BedrockChat" ,  it's work .
langchain==0.1.11
langchain-anthropic==0.1.4
langchain-community==0.0.27
langchain-core==0.1.30
langchain-openai==0.0.5
langchain-text-splitters==0.0.1
import boto3
from langchain_core.output_parsers import StrOutputParser
from langchain_core.prompts import ChatPromptTemplate
from langchain_community.chat_models import BedrockChat

bedrock_runtime = boto3.client(
    service_name="bedrock-runtime",
    region_name="us-west-2",
)

model_id = "anthropic.claude-3-sonnet-20240229-v1:0"

model_kwargs =  {
    "max_tokens": 2048,
    "temperature": 0.0,
    "top_k": 250,
    "top_p": 1,
    "stop_sequences": ["\n\nHuman"],
}

model = BedrockChat(
    client=bedrock_runtime,
    model_id=model_id,
    model_kwargs=model_kwargs,
)

# Invoke Example
messages = [
    ("system", "You are a helpful assistant."),
    ("human", "{question}"),
]

prompt = ChatPromptTemplate.from_messages(messages)

chain = prompt | model | StrOutputParser()

# Chain Invoke
response = chain.invoke({"question": "tell me a joke"})
print(response)


Updated kaldi_io can not read from pipe (python3)

Hi Karel,
It's nice to support python3, I tested the new kaldi_io script, however, though it works fine for directly reading  "feats.ark",  it will fail when reading from the stream "ark:apply-cmvn-sliding --center=true ark:feats.ark ark:- |",  line 49 will throw an error as
`fd = os.popen(file[:-1], 'rb')
File "/cm/shared/apps/python/3.6/lib/python3.6/os.py", line 970, in popen
raise ValueError("invalid mode %r" % mode)'
This may be caused by the difference of stdin/out between python2 and python3.

Hi, thanks for letting me know... After looking closer into it,
it seems that this will not be trivial to resolve...
In python3, the os.popen() supports only the transfers of utf-8 strings
(i.e. it does not accept the 'wb' mode of file opening only the 'r' mode,
which cannot be used to write the byte-strings b'...').
In python2, there was no such problem as the 'string' and 'byte-string' is the same type.
Do you know any clean solution? Or would it be fine to support pipe-ing just for python 2.x ?

Hi, finally I found a way how to support pipes both for pyhon2 and python3. Let me know, if there are some more problems... K.

Great! Thanks~


Unable to do a fresh install Today's (Feb 12) Nightly build on the Andriod Mobile.

Description:
Unable to do a fresh install Today's (Feb 12) Nightly build on the Andriod Mobile.
Getting the below error message.

Seems like it is upload issue. The build is restarted.

Nightly is updated with valid apk package

Verified, hence closing this ticket.


Spec for MainDispatcher#todoItemCreate

Hi there!
We're trying to unit test MainDispatcher in isolation with minimal stubbing.  We're a bit confused about the best practices around interacting with p-flux.  We have a passing spec, but there's a lot of setup, and testing works in all but one case.
Specifically, when we try to call Dispatcher.dispatch as recommended in https://github.com/pivotal-cf/p-flux#recommended-practices, we're not seeing the spec pass: https://github.com/pivotal-cf/react-starter/commit/698aff7efd2a9c5a3e6d10d0a8ded31f5aad12e9#diff-a37d4214a47390971b58f52ddb19c77aR13
We're wondering which path to pursue:

const self = this or .bind() scope hackery like the old days
Learn how to properly use Dispatcher.dispatch :wink:

Thanks!

I adjusted your example in the following ways which can be seen in this branch:
https://github.com/pivotal-cf/react-starter/commit/53cf13b01b6b80fe4d1002d14007e8850a578290
Basically you'll want to use the Dispatcher object supplied globally from spec_helper. You also can rely on it's initialization from the Application.reset function which is already called in spec_helper.
Also, I don't tend to like including my actual store when unit testing actions. Instead it is easier to make your store exactly the way you need it in test and verify that it works with that.
Lastly I reorganized the action method names. We tend to follow the standard of  which makes it easier to group actions in the spec.
As for some of your questions:

You can pretty much avoid needing self = this or bind, just use fat arrow as much as possible. It is rare to actually need bind unless you are doing partial application. One interesting note is that using fat arrow puts the function on the instance and not the prototype when using a class so it makes it harder to mock in the way that you might be used to.

Ryan's example spec looks good. I added an example main_dispatcher_spec to help in the future. Let me know if you have more questions.


[Test] import/named should support export = assignment of object in TS

This pattern is valid typescript, but import/named can't find resolve the imports. Relevant issue: #1984
Here's a demo showing that it should work in TS
This test currently does not run, as no TS tests in named.js are currently running: waiting for #2427
Once the test is wired up, it fails with:
  1) TypeScript named [TypeScript] valid import { FooBar } from './typescript-export-assign-object':

      AssertionError [ERR_ASSERTION] [ERR_ASSERTION]: Should have no errors but had 1: [
  {
    ruleId: 'named [TypeScript]',
    severity: 1,
    message: "FooBar not found in './typescript-export-assign-object'",
    line: 1,
    column: 10,
    nodeType: 'Identifier',
    endLine: 1,
    endColumn: 16
  }
]
      + expected - actual

      -1
      +0

You got it, thanks for taking a look at these @ljharb! Reopened at #2432


case test_sql_block_rule may affect other cases

Proposed changes
Issue Number: close #xxx

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall


 In general, all methods on a given type should have either value or pointer receivers, but not a mixture of both.(from https://go.dev/tour/methods/8)

Thanks!

Thanks for the PR, but next time please put the explanation in the commit message.


Added generic Identity validator support using IIdentityValidator and…

… Identity<,>

formalize Identity validation and create a reusable foundation using IIdentityValidator
makes use of SingleValueObject and IIdentity
Identity<,> matches behavior of Identity<>
Identity<,> expects identifiers to be strings from an IO perspective in the same way as Identity<>

@JC008 Good idea to cleanup identity validation. I think you should rework the existing Identity<> so that it uses the new Identity<,> class and putting the current validation into e.g. DefaultIndentityValidator.
Regarding the ordering of static members, I think your suggestion of moving all initializers into static constructors is best. I'll go though the code this week and do just that.
After this is completed I'll move the identity related classes to the EventFlow.Core namespace, as an identity can be used for other entities that need an identity. Specifically commands and events.
Also, I'm considering using deterministic GUIDs for events using a combination of aggregate name, aggregate ID and the event aggregate sequence number (version) and to create the ID.

Oi - I pushed to many files not related to the change yesterday - please close / discard - I will do a clean branch and pull request with a title matching your style.


[MM-20209] Update current channel header when a guest user is deactivated/promoted

Summary
PR fixes a problem with current channel header not getting updated (until channel reload) when a guest user is deactivated/activated/demoted/promoted.
Ticket Link
https://mattermost.atlassian.net/browse/MM-20209
Related Pull Requests
https://github.com/mattermost/mattermost-server/pull/13180

@streamer45 If this is for 5.18 this should be cherry-picked

@streamer45 If this is for 5.18 this should be cherry-picked

yes, I merged before checking for the label. Will cherry-pick this manually.


Add proper support for :not()

The code avoided generating invalid CSS when a rule included :not(), but it did not provide correct support for the pseudo-*-all classes. For example, :not(:hover) would be transformed to .pseudo-hover-all :not(), but we would skip writing that rule, because of the invalid :not(). The correct rewriting of that rule is :not(.pseudo-hover-all *), i.e. "Not a descendant of an element with class .pseudo-hover-all". Similarly, for shadow DOM styles, we need special logic to turn the example rule into :not(:host(.pseudo-hover-all) *).
In general, the approach is:

Replace :not(...<pseudo-state>...) with :not(.pseudo-<state>-all ...) (or :not(:host(.pseudo-<state>-all) ...) if for shadow DOM)
Extract remaining pseudo-states and move them to an ancestor selector: ...<pseudo-state>... -> .pseudo-<state>-all ...

Additionally, the refactoring I did allowed the removal of special logic related to ::slotted() and :has().

@ghengeveld after this PR, I also have a change that adds support for :host-context(). After that, it should be time for a release. 🚀

@ghengeveld seems like this stalled out. Anything I can do to help?

@m-akinc We had a company retreat last week so I was preoccupied. I'll take a look soon.

 Could you check it out @m-akinc? Perhaps address it in that follow-up PR?

 Could you check it out @m-akinc? Perhaps address it in that follow-up PR?

Sorry for that! Fix is up in #117. Another PR adding support for :host-context() will be following shortly.


Implemented specialized serialization of errors

This change makes use of the new slog feature which allows
specializing error types. When an error type is encountered, it can be
inspected to check if it contains an errno. If it does, the standard
ERRNO= field will be added. This however requires a newer version of
Rust (1.30+), so it's an opt-in feature.
Further, logging of error sources separately is supported. This is also
behind a feature flag as some users might find it redundant. Making it
runtime configurable would be nicer, but such would be a breaking change
because the JournaldDrain struct was not future-proofed. It should be
quite easy to make a new breaking release with this option though. This
feature calls cause() so it does not require a new version of Rust. To
aid log analyzers, it also logs the depth of the error chain.
Finally each error is logged as in the case of the default
implementation. The features described above do not interfere with this.
It could be also configurable but I'm not sure how to best achieve it.
The displaying code was copy-pasted from the slog crate because it's
not public. It's a good question whether it should be made public, or
even moved to a different crate.
This is a draft because the new slog version was not released yet. @dpc what exactly is your policy on releases? Perhaps a crate attempting to actually use the new feature could be a good opportunity for a release?
But maybe only after we separate-out the code for default error formatting?

At an initial look, this looks fine to me. I'm not sure whether this should be merged before the core slog crate is released though.

@dpc what exactly is your policy on releases?

My policy is that if someone keeps bothering me to do it, I eventually do it. :)

slog 2.7.0 has been released; I have a more free week ahead, so good to to potentially deal with any post-release fires.

I'm not sure whether this should be merged before the core slog crate is released though.

That's why I originally marked it as draft. :)
@dpc great, thanks!
I've bumped the version added some docs and I think it could be merged now.

Rebased, can this be merged?

It looks like it is failing the format check.

Fixed.


Exceptions on bulk connect to AWS ActiveMQ Broker

Describe your question
I'm craeting application with 500-1000 mqtt connections to AWS ActiveMQ Broker.
After 10-20 connections I have:
"A task was canceled"
"An existing connection was forcibly closed by the remote host."
"Received packet 'PubAck: [PacketIdentifier=21584] [ReasonCode=]' at an unexpected time."
Exceptions
Which project is your question related to?

ManagedClient

I've collected every troubleshooting tips under https://github.com/chkr1011/MQTTnet/wiki/Client#connecting-with-amazon-aws now. There is a discussion available under https://github.com/chkr1011/MQTTnet/discussions/1225 where I'm trying to collect all issues with AWS, you can have a look at these resources (Although, ActiveMQ on AWS might have some different issues...)

Closing this due to inactivity.


Question about updateOverlay

hi:
The updateOverlay method updates other DOM elements, but does not update the SVG view position in openSeadragon-SVG-overlay.
exp：
const newSvg = document.createElementNS('http://www.w3.org/2000/svg', 'circle')
newSvg.setAttributeNS(null, 'cx', 100)
newSvg.setAttributeNS(null, 'cy', 100)
newSvg.setAttributeNS(null, 'r', 100)
newSvg.setAttributeNS(null, 'fill', 'red')
newSvg.setAttributeNS(null, 'stroke-width', 2)
newSvg.setAttributeNS(null, 'id', 'test')
svgG.append(newSvg)
this.viewer.updateOverlay('test', new OpenSeadragon.Point(100, 100), OpenSeadragon.Placement.CENTER)

You're referring to this plugin, right? https://github.com/openseadragon/svg-overlay
That plugin does not utilize the built-in OSD overlay methods, so yes, updateOverlay will have no effect. Instead, to move your SVG elements around, change their attributes directly.

You're referring to this plugin, right? https://github.com/openseadragon/svg-overlay
That plugin does not utilize the built-in OSD overlay methods, so yes, updateOverlay will have no effect. Instead, to move your SVG elements around, change their attributes directly.

thanks,


Documentation on how to mount volumes

Hello,
I have been playing around with this and it is great. But I was not able to figure out how to properly mount volumes onto the generated containers.
Would you be able to add an example on how mount a folder (or file) from the host machine as a volume.
Thank you.

I just look through the closed issues and found this:
https://github.com/docker-php/docker-php/issues/199


Put "Add obsidian__" as Title

NOTE: Each discrete (stand-alone) request should be in its own issue.
Put "Add obsidian__" as Title
[ ] Done
Provide a link to the proposed addition.
Place link here.

markdown免费产品，跨平台，丰富的插件系统，双联笔记的top级别选手
A clear and concise description of why it should be added to this list.
Additional context
Add any other context or screenshots about the feature request here.
Issue Checklist
Put an x in the boxes once you've completed each step. You can also fill these out after creating the issue. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before responding to the issue.

[ ] I have checked for other similar issues
[ ] I have explained why this change is important
[ ] I have added necessary documentation (if appropriate)

@jaywcjlove This issue has been resolved. Could you please close it?
Thanks!


How to add dynamic meta data (Page wise) using React Helmet for Client Side Rendering App(using CRA)?

Hello,
I am using ReactJS for my front-end pages (public pages) using Create React Application (CRA) method.
To have SEO-Friendly web app, I would like to have a meta title and description page wise. To achieve this, I have already installed below NPM (react-helmet) which makes console data dynamic BUT the dynamic data is NOT displaying as expected for source code.
NPM : https://www.npmjs.com/package/react-helmet
Question: Is there any way to have a dynamic meta title and description (page-wise) using a react-helmet and CSR based ReactJS app?
NOTE: At the moment, I am not looking to convert into SSR using expressJS or NextJS.

You should use it with https://github.com/stereobooster/react-snap ;)

You should use it with https://github.com/stereobooster/react-snap ;)
@Lucas-Geitner Thanks for your response. I will review the same.
Do you know any website which is developed using "react-snap"?

Explain a 'real' case, I use it in a Layout with dynamic data without problems.
Like a:
<Layout title = "Homepage" description = "Blah, blah" keywords= "seo, tags, for, current, page">
   <AllPageComponent />
</Layout>

@krupalox Your issue is solved?

@TrejoCode Thanks for your response. I am still looking for concrete solution.
By integrating react-helmet library, I can update page title and meta data successfully. That's fine.
At the moment, my concern is, due to some reason, it is showing main page data (title and meta details) in the source code for all the internal page. Having said that, Google Bot is NOT able to fetch page-wise data (title and meta details) so our SEO rank is very low a crawling of inner pages is not working.
I am not sure, if I missed anything in configuration. Glad to have your input for this.

@krupalox, I understand you, @Lucas-Geitner has the answer, remember it is not for all use cases.
By default in CRA it is not the best option for SEO, the SEO you will get will be low with respect to the SSR approach, even using tools such as 'react-snap' and 'react-helmet'.
A tip for the future: If you need to continue with React, I recommend that you migrate to Next.js, it has everything we like about React + SSR with minimal configuration.

@krupalox @TrejoCode any solution to the issue that Krupal is facing? i.e. can we use CSR and achieve SEO ? Also @krupalox did you find any alternative solution apart from switching to next.js or SSR a create react app using node express ? I even tried node-express server and  run the code using SSR but there react-router-dom doesn't loads meta dynamically it's just when we use hrefs for changing routes on our client side code then it works !

@vaibhav-systango As a permanent solution, we have used NextJS to have SSR which is working fine for us.


pitr: do not set safe-point when pause task in TiKV endpoint

What is changed and how it works?

Issue Number: Close https://github.com/tikv/tikv/issues/12536
What's Changed:

do not set/remove safe point at tikv endpoint when pause/resume.

Related changes

PR to update pingcap/docs/pingcap/docs-cn:
Need to cherry-pick to the release branch

Check List
Tests

Unit test
Integration test
Manual test (add detailed scripts or steps below)
No code

Side effects

Performance regression

Consumes more CPU
Consumes more MEM

Breaking backward compatibility

Release note
Please add a release note.

Please refer to [Release Notes Language Style Guide](https://pingcap.github.io/tidb-dev-guide/contribute-to-tidb/release-notes-style-guide.html) to write a quality release note.

If you don't think this PR needs a release note then fill it with None.
If this PR will be picked to release branch, then a release note is probably required.

/cc @YuJuncen @3pointer @kennytm PTAL

/run-tests

/run-test

/run-all-tests

/run-all-tests

/run-all-tests

/run-all-tests

/merge

/run-test

/run-test

/test

/run-test

/merge

/test

/test

/run-tests

/run-tests

/run-tests

/run-test

/run-test

/run-test


Filter keys of a dict based on their value

Hello.
I would like to have a new filter which take a single dict and output a list of its key/value depending of the value, which could be complex:
{%- set bigdict = {'top1': {'enabled': true, 'descr': 'this is a top level1 item},
                   'top2': {'enabled': false, 'descr': 'this is a top level2 item}} %}
{{ bigdict | NewFilter('enabled') | join(', ') }}

Or maybe it could be an extention of selectattr.
I need actually to calculate things with quite a huge amount of jinja:
{%- set bigdict = {'top1': {'enabled': false, 'descr': 'this is a top level1 item'},
                   'top2': {'enabled': true, 'descr': 'this is a top level2 item'}} %}
{%- set filtered = [] %}
{%- for k, v in bigdict.items() %}
{%-   if v.get('enabled', False) %}
{%-     do filtered.append(k) %}
{%-  endif %}
{%- endfor %}
{{ filtered | join(',') }}

Regards.

Thanks for the suggestion. If this is something you need, you can already register custom filters in your project. I don't plan to add more filters to core at this time.


car state: use class car_fingerprint

These kinds of mass changes aren't great for a couple reasons. It's not clear why self.car_fingeprrint is preferable over self.CP.carFingerprint; I happen to prefer the latter. When it's not clear which pattern is preferable, the one you're trying to remove is gonna naturally pop up again over time. I would leave this as-is until there's a clearly preferable pattern to replace it with. There's more obvious cleanups to do in the car abstraction layer, such as cleaning up the CANParser signal/check convention.


Unable to compile abseil-hello on MacOS Sequoia due to missing C++ standard libraries

I am unable to compile abseil-hello on MacOS Sequoia
`
bazel run //:hello_main
INFO: Analyzed target //:hello_main (0 packages loaded, 0 targets configured).
ERROR: /Users/popurir/abseil-hello/bazel-hello/BUILD.bazel:33:10: Compiling hello_main.cc failed: (Exit 1): cc_wrapper.sh failed: error executing CppCompile command (from target //:hello_main) external/bazel_tools~cc_configure_extension~local_config_cc/cc_wrapper.sh -U_FORTIFY_SOURCE -fstack-protector -Wall -Wthread-safety -Wself-assign -Wunused-but-set-parameter -Wno-free-nonheap-object ... (remaining 29 arguments skipped)
Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
In file included from hello_main.cc:15:
./hello.h:15:10: fatal error: 'string' file not found
15 | #include
|          ^~~~~~~~
1 error generated.
Target //:hello_main failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 1.155s, Critical Path: 0.92s
INFO: 18 processes: 18 internal.
ERROR: Build did NOT complete successfully
ERROR: Build failed. Not running target
`
Below is Mac compilation setup details

/usr/bin/gcc --version
Apple clang version 16.0.0 (clang-16<IP_ADDRESS>)
Target: x86_64-apple-darwin24.1.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

softwareupdate -l
Software Update Tool
Finding available software
No new software available.

xcode-select -v
xcode-select version 2409.

xcode-select -v
xcode-select version 2409.
C02FL3VCMD6R:SDKs popurir$ xcode-select -p
/Library/Developer/CommandLineTools
C02FL3VCMD6R:SDKs popurir$ cd /Library/Developer/CommandLineTools/
C02FL3VCMD6R:CommandLineTools popurir$ ls
Library	SDKs	usr
C02FL3VCMD6R:CommandLineTools popurir$ cd SDKs/
C02FL3VCMD6R:SDKs popurir$ ls -lh
total 0
lrwxr-xr-x  1 root  wheel    14B Nov 14 12:49 MacOSX.sdk -> MacOSX13.1.sdk
drwxr-xr-x  7 root  wheel   224B Nov 12  2022 MacOSX13.1.sdk
drwxr-xr-x  8 root  wheel   256B Nov 14 12:48 MacOSX14.5.sdk
lrwxr-xr-x  1 root  wheel    14B Nov 13 15:39 MacOSX14.sdk -> MacOSX14.5.sdk
drwxr-xr-x  8 root  wheel   256B Nov 14 12:49 MacOSX15.1.sdk
lrwxr-xr-x  1 root  wheel    14B Nov 13 15:37 MacOSX15.sdk -> MacOSX15.1.sdk
lrwxr-xr-x  1 root  wheel    14B Nov 13 15:40 MacOSX_old.sdk -> MacOSX15.1.sdk

Uninstalling and reinstalling  Command Line Tools as described below seems to have fixed the issue.
bazel run //:hello_main  --sandbox_debug
INFO: Analyzed target //:hello_main (0 packages loaded, 0 targets configured).
INFO: From Linking external/abseil-cpp~/absl/base/libbase.a:
/Library/Developer/CommandLineTools/usr/bin/libtool: file: bazel-out/darwin_x86_64-fastbuild/bin/external/abseil-cpp~/absl/base/_objs/base/unscaledcycleclock.o has no symbols
INFO: Found 1 target...
Target //:hello_main up-to-date:
bazel-bin/hello_main
INFO: Elapsed time: 14.434s, Critical Path: 10.66s
INFO: 42 processes: 1 internal, 41 darwin-sandbox.
INFO: Build completed successfully, 42 total actions
INFO: Running command line: bazel-bin/hello_main
Hello world
However not sure what changed because the reinstalled version seems to be the same as the previous version
/usr/bin/gcc --version
Apple clang version 16.0.0 (clang-16<IP_ADDRESS>)
Target: x86_64-apple-darwin24.1.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
C02FL3VCMD6R:~ popurir$ xcode-select --version
xcode-select version 2409.


[Feature Request] Example of MLLM using MLX

With ml-ferret out, it would be great to include an MLLM example in this repo, namely with ml-ferret or just LlaVA itself.  Being LLAMA based, I think this would primarily require just implementing the image encoding step.

Agreed, that would be super cool. If anyone is interested in contributing it let us know!

Agreed, that would be super cool. If anyone is interested in contributing it let us know!

I would like to contribute to this example soon (perhaps this weekend). Some time ago, I proposed implementing ViT (CLIP) https://github.com/ml-explore/mlx-examples/issues/143. Thus, I think it is cool to have an implementation of ViT (CLIP) that perfectly matches the one used in ferret. This enables us to quickly implement ferret. According to ferret implementation, the image encoder just wraps CLIP.
However, it is not the case that implementing ferret is just implementing image encoding. This is because ferret also uses bilinear interpolation using torch.functional.grid_sample. We do not have this in MLX currently. However, I recently implemented bilinear interpolation for Upsample2d(https://github.com/ml-explore/mlx/pull/414).

LLava might be easier to start with as v1.5 is literally just a fine tuned LLama model + CLIP + a small projector layer.

That would be awesome! At a bare minimum an image CLIP encoder will be really helpful.  I saw that the Stable Diffusion example has a text CLIP encoder so the image half should just be a few small changes.
I was semi looking at this just to see how hard it is.  For reference implementation, the original LLaVA implementation is likely to be easier to work with. The transformers v4.35 rewrite made quite a few changes.

Hey, posting in here since I'm interested in multi-modal. I'm currently trying to convert bakLlava. The model doesn't matter too much to me, but this one worked out of the box for me so went with it.
I'm trying to understand what's the best strategy for converting a model you want to MLX? Is there a guide somewhere?
Right now I'm currently looking at the model's config from HF https://github.com/huggingface/transformers/blob/bc72b4e2cdcbc80d5f56731f35dbc9c18b4c8de6/src/transformers/models/llava/modeling_llava.py#L237, and trying to build versions of these modules in MLX. Just started, but the idea is to make modules that look like the following, right?

class VisionTower(nn.Module):
    # TODO

class MultiModalProjector(nn.Module):
    # TODO

class LanguageModel(nn.Module):
    # TODO

class Model(nn.Module):
    def __init__(self, args: ModelArgs):

        self.vision_tower = VisionTower(args)
        self.multi_modal_projector = MultiModalProjector(args)

        self.language_model = LanguageModel(args)

        self.pad_token_id = args.pad_token_id

        self.vocab_size = args.vocab_size

    def __call__():
        # TODO

(This is all I've done so far)
Curious if you all had a different strategy in mind?

Hey, posting in here since I'm interested in multi-modal. I'm currently trying to convert bakLlava. The model doesn't matter too much to me, but this one worked out of the box for me so went with it.
I'm trying to understand what's the best strategy for converting a model you want to MLX? Is there a guide somewhere?
Right now I'm currently looking at the model's config from HF https://github.com/huggingface/transformers/blob/bc72b4e2cdcbc80d5f56731f35dbc9c18b4c8de6/src/transformers/models/llava/modeling_llava.py#L237, and trying to build versions of these modules in MLX. Just started, but the idea is to make modules that look like the following, right?

class VisionTower(nn.Module):
    # TODO

class MultiModalProjector(nn.Module):
    # TODO

class LanguageModel(nn.Module):
    # TODO

class Model(nn.Module):
    def __init__(self, args: ModelArgs):

        self.vision_tower = VisionTower(args)
        self.multi_modal_projector = MultiModalProjector(args)

        self.language_model = LanguageModel(args)

        self.pad_token_id = args.pad_token_id

        self.vocab_size = args.vocab_size

    def __call__():
        # TODO

(This is all I've done so far)
Curious if you all had a different strategy in mind? Seems like starting with CLIP is the best approach, so I'm also going to keep an eye on how that's going / let me know if you need any help.

Hi @nkasmanoff :) I am also very interested in porting multimodal models. My end goal is to implement ferret in MLX and I will probably need some help. Here is my (draft) pull request for CLIP (https://github.com/ml-explore/mlx-examples/pull/315). I think it is going well and I am confident that it will be done soon. After we have CLIP, it is relatively simple to port LLaVA to MLX.
In terms of the general approach, I think that a good starting point is to design model structure (e.g. your Python class hierarchy) such that it closely follows  transformers implementations and HuggingFace weights. The next step is to write a script that converts HuggingFace weights to your weights. This resource is useful https://github.com/ml-explore/mlx-examples/issues/155.  Here is how I did it in https://github.com/ml-explore/mlx-examples/pull/315. I based my work on the StableDiffusion example (https://github.com/ml-explore/mlx-examples/tree/main/stable_diffusion).

@gboduljak Thank you this is a lot of great info! Will try to catch myself up and help :-)

@gboduljak Thank you this is a lot of great info! Will try to catch myself up and help :-)

Thank you :)
Here are some concrete things were I need some help:

Verifying whether the initialization of CLIP (https://github.com/ml-explore/mlx-examples/pull/315) is correct (i.e. matches the method implemented in https://github.com/huggingface/transformers/blob/v4.36.1/src/transformers/models/clip/)
Complete implementation of CLIPTokenizer (the implementation in PR should work for most of the cases, but it is not complete)
An implementation of CLIP image input pre-processing (we are now using transformers CLIPProcessor)
Removing the dependency on ```transformers``

@gboduljak No problem, but after looking it over, not sure I can be extraordinarily helpful beyond some simpler tasks. This is a lot lower level coding than I'm used to :-). With that being said I can help with 3, 5, and a general review. Don't the tests you have already verify that 1. is complete?
I'm also considering making a demo train.py file, have you considered something like this? If I come up with something that looks like it works using the code you have here, I'll submit a PR to the branch you already made.

@gboduljak No problem, but after looking it over, not sure I can be extraordinarily helpful beyond some simpler tasks. This is a lot lower level coding than I'm used to :-). With that being said I can help with 3, 5, and a general review. Don't the tests you have already verify that 1. is complete?
I'm also considering making a demo train.py file, have you considered something like this? If I come up with something that looks like it works using the code you have here, I'll submit a PR to the branch you already made.

Thank you for taking a look at my code. The tests unfortunately do not verify that our model initialization is correct. They verify whether our model inference is correct. In other words, we test whether our implementation with pretrained weights produces the same output as the transformers implementation initialized with the same pretrained weights.
Porting CLIPProcessor would be very useful, because then we can eliminate the dependency on transformers.
train.py would also be very interesting. However, we likely cannot run the full training :)

Closing as we added #461.


nixos-rebuild, switch-to-configuration: document and protect against cross compilation subtlety

Description of changes

This should resolve #166838 by

documenting the expected behavior better
protecting against accidental misinterpretation in case of a platform mismatch

Things done

Built on platform(s)

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

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

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

This looks interesting. Don't feel qualified to review this, but nice to try and make the error cleaner. Documentation looks ok.


isInternalLink: Clarify, fix bugs, add tests, move to use URL object

After studying closely the URL Standard and its definition of the syntax and parsing algorithm for URLs in order to write some small predicates like isUrlAbsolute for #4345, I took a fresh look yesterday at some of our URL-processing code that we've been wanting to fix for a while, i.e. #4146.
Here's a branch fixing one tangly part of that code: the isInternalLink function, used for deciding whether a link the user tries to follow in a message is one we should try to interpret within the app to navigate to some other conversation, or is one we should instead handle more generically, with a download or going out to the browser.
We make the changes in a series of very small steps, so that we can spot exactly where the behavior changes. After a long string of those, including a couple of bugfixes, we have a version that's pretty reasonable and is still in explicit string/regexp terms... and then in the final commit, we switch it to using new URL. The effect of this is that we start accepting a wide range of URLs we didn't before -- for example it turns out that the URL parser produces exactly the same result for https://example/#narrow as for

https://example/.#narrow
https://example/foo/bar/../../../baz/.././#narrow
https://%65%78%61%6d%70%6c%65/#narrow
https://example:/#narrow
https://example:0000443/#narrow
... and further kinds of variation are possible for domains with non-ASCII characters and for IP addresses instead of domains
... and that's just among "valid URL strings", which aren't all the inputs the URL parser accepts.

So in that final commit we also add a wide variety of test cases to illustrate this variation. These are perhaps overkill for this particular function; but as we revise or write other URL-handling functions, they can serve as a helpful source of material for tests.

Thanks for the review! New revision pushed.

Great, thanks!
I'm seeing lots of instances of the following, just after the commit that has us using the URL polyfill in Jest tests:
ReferenceError: You are trying to `import` a file after the Jest environment has been torn down.

      at node_modules/react-native-url-polyfill/index.js:11:69
      at Object.getValue [as URL] (node_modules/react-native/Libraries/Utilities/defineLazyObjectProperty.js:43:16)
          at Array.forEach (<anonymous>)

I'm seeing lots of instances of the following at the commit that has us using the URL polyfill in Jest tests:

Hmm! Indeed I reproduce. Thanks for the catch.
I think before sending the revised version I might have been running only the one test file for internalLinks -- which does show the same symptom, but it's at the top above a ton of other output and I apparently didn't notice.
... Ah, aha, I think I might understand. The offending code is here:
$ nl -ba node_modules/react-native-url-polyfill/index.js
…
     8	export function setupURLPolyfill() {
     9	  global.REACT_NATIVE_URL_POLYFILL = `${name}@${version}`;
    10
    11	  polyfillGlobal('URL', () => require('./js/URL').URL);
    12	  polyfillGlobal(
    13	    'URLSearchParams',
    14	    () => require('./js/URLSearchParams').URLSearchParams,
    15	  );
    16	}

So lines 11 and 14, the ones Jest is complaining about, are require calls.
They're require calls inside a getter it's passing to polyfillGlobal. Reading the latter function, it's intended to polyfill the given properties with lazy getters -- I think the point is to do exactly what react-native-url-polyfill is doing here, by making the require lazy, so that if the polyfill is in something you don't necessarily use or don't immediately use, you don't pay the cost at startup.
But that means that then when some code in Jest tries to use URL, or URLSearchParams, it goes through this lazy getter, which calls require. I think this might even be code in Jest proper, outside any of our test code -- e.g. I've noticed that when it prints test results:
 PASS  src/topics/__tests__/topicsReducer-test.js

the filenames have dotted underlines and are actually links, in my terminal, to file: URLs. Presumably Jest is spitting out some terminal magic to do that, and it'd be very sensible for it to use URL to construct the URLs to put there.
In which case, it tries to get URL, it goes through that getter -- and there it is, trying to import a file after the Jest environment has been torn down.
I'll change it to skip the laziness and do the import up front as an import statement.

New revision pushed with that fix!

Great, thanks! Pushed.


ARROW-4712: [C++][CI] fix build (sum.cc) has warnings in clang

AppVeyor build:
https://ci.appveyor.com/project/pitrou/arrow/builds/22715266

could these have been caught in CI?

It's weird because I build with clang-7, is it a different WARN_LEVEL?

I've found that the warnings can depend on which base gcc toolchain you have

Oh I think the issue is that the Mean patch introduced these issues but that was tested before the clang-7 fix yesterday https://github.com/apache/arrow/commit/e648a762586d1af3a294dd96054a78b90f6e71ec


[2517] Fix issues with erroring confirm pages

Context

Add Error: prefix to page titles:
Fix non-working anchors in the error/info summaries
Add visually hidden Error: against each error inset
Add govuk-grid-column-two-thirds-from-desktop for
error summaries

Changes proposed in this pull request
Guidance to review

 Snags with validated confirm pages


Doesn't explain Switch add-on installation

Document doesn't explain how to install add-ons for the Switch version of Minecraft.  (At https://help.minecraft.net/hc/en-us/articles/4409140076813-Minecraft-Add-Ons-for-Bedrock-Versions-FAQ   it says "Add-Ons will work on any platform that runs the Bedrock Edition").

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: a8a88ce5-d418-c1bf-0edc-cc1836d68ee4
Version Independent ID: 50d65cea-41e6-8478-048b-cf192b12503a
Content: Installing Add-Ons in Minecraft: Bedrock Edition
Content Source: creator/Documents/AddonPackInstallation.md
Product: gaming
GitHub Login: @v-josjones
Microsoft Alias: v-josjones

(Note to self - also put Realm add-on instructions)

I added an update about how to use Realms to play a particular world on a console. That was the way I could get it to work consistently.


LDT support for SHA

Hi,
Any plans to support Large Data Test (LDT) for SHA? https://pages.nist.gov/ACVP/draft-celi-acvp-sha.html#name-test-types-and-test-coverag
Thanks!
Pablo

At present there there are no plans, however I will put it on our backlog. Lot's of other tasks with higher priority at this point for our team.
Regards,
Barry

Thanks @bfussell!


Compatible with Open AI's new API

It's the same as the one I pulled request before. Because it wasn't going well.

Hi @f6844710 ,
Thank you for your PR✨

Set proper title that explains what this PR does🙏
Maybe the dependencies configured in setup.py also to be updated.
Consider closing client instance after http session.

I tried the suggested improvements.

Hi @f6844710 ,
Thank you again🙏

Please ensure that the client is always guaranteed to be closed.
The title is not appropriate. Based on the original content of the pull request, I believe you intended to address compatibility with OpenAI's new client library. However, it doesn't seem like the API itself is utilizing anything new.
The version of the API client library is too old. If there's a reason you chose this version, please share your insights.
Please do not mix multiple themes in one pull request. Supporting the latest model of ChatGPT is a good idea, but it's unrelated to changes in the client library. Also, it would be appreciated if you could clarify why you're choosing an old client library while opting for the latest model (compatible with the latest API).
Do not make changes to the code style. Adapting line breaks and other aspects to PEP standards is a good idea, but please refrain from modifying parts of the style that are irrelevant to the theme of this pull request.


Adding additional template variable scopes

This is a follow up to #2924.  It addresses the issue of exposing session variables to template engines using a more general approach.  Note that unlike #2924, this request does not involve exposing scopes explicitly using certain names.
Each response (potentially) has a stack of template variable scopes.  Each scope is an object whose properties define the variables to be exposed.  A method was added to the response object named addTmplVars.  The parameter to this method is a scope to be pushed on the scope stack.  Here is an example:
res.addTmplVars({ name: 'gfoust', count: 3 });

The scope is stored directly on the scope stack.  Therefore, any changes made to that scope will be visible to the template engine.  For example, the following code listing has the same effect as the previous one.
var obj = {};
res.addTmplVars(obj);
obj.name = 'gfoust';
obj.count = 3;

When a template is rendered, the objects on the scope stack are "flattened" into a single object.  This "flattening" does not alter the scopes in any way; it merely copies their properties to a new object.  In the case of conflicts, variables from scopes higher up in the stack will replace those from scopes lower in the stack.
Prior to this "flattening", the variables of app.locals are effectively added to the bottom of the stack, and variables from res.locals are added to the top of the stack, followed by variables passed to res.render.  This augmented stack may be represented as follows:
variables passed to res.render -> res.locals -> scope stack (high to low) -> app.locals
The arrows here represent precedence:  variables from scopes on the left of the arrow will override variables from scopes on the right should a conflict occur.
The idea here is that any middleware can expose a scope to the template engine.  For example, when using express-session, it could push the session object onto the scope stack, allowing session variables to be directly accessed by the template.  Should multiple middlewares push scopes to the stack, the order in which they execute will define precedence.
I used the tmplVars property of the response object to hold the scope stack.  I would expect this to be considered a private variable.  The property is not created until the first time addTmplVars is called.

This is awesome :)! There are a couple nits in there, but my main question, of course, would be how this would work with features of modules like express-session has the regenerate functionality, which generates a branch new req.session object. For example, if express-session does res.addTmplVars(req.session), but then a user calls regenerate, then how can that module remove the old object from the stack and get the new one added (ideally in the same location?).
Or, would the idea be that express-session and other modules would not be calling res.addTmplVars and instead the user would be responsible for setting up this link (and then they can manage when to add it to account for their use of regenerate)?

I personally was expecting that modules would automatically add variable scopes to the response, thereby lessening programmer burden.  I have two thoughts regarding the issue you raised.
The first is that a module could make it configurable as to whether or not they exposed variables to the template.  This would mean a programmer could prevent the default exposure doing something like this:
app.use(session({ tmplVars: false }));

Then the programmer could manually add variable scopes whenever appropriate---e.g., after regenerating a session.
The second thought is that we could allow modules to "tag" their scopes by providing an id (e.g., the module name).  This id could be an optional parameter, maybe something like this:
res.addTmplVars('myId', scopeObj);

If there were two calls using the same id, the later call would replace the earlier call.  In this way a session module could automatically update its scope whenever the session was regenerated.  As an added bonus, if you ever decided to expose scopes using variable names (as discussed in #2924) you could use the identifiers as the variable names.  Thus, I could be sure I was using variable x from my scope by writing myId.x.

I like the idea of naming scopes. Could lead to a nice api like res.scope('session').myVariable = val where res.scope(]name], [object]) (optional name, optional object) returns the scope from the stack, adding it to the stack if it doesn't already exist. Although, that does raise the issue of name clashes.

I like that idea, @tunniclm.  It does create a potential for name clashes, but (I would say) not unreasonably so.  It should be easy enough for modules to allow the programmer to modify the scope name used by the module if necessary.
Questions that occur to me:  Is it required that all scopes have a name?  What about app.local, res.local, and variables passed directly to res.render()---do those scopes have names?  And, if they have names, should they be accessible via res.scope()?
For my part, I would suggest that you all scopes should be required to have a name, and that you choose and reserve names for app.local, res.local, and variables passed to res.render().  I would think those three scopes should be considered special, and therefore not accessible via res.scope().  For example, you should not be able to set a different scope in place of app.local.

I have taken @tunniclm's suggestion and renamed the addTmplVars function to scope.  It has three signatures.
res.scope(name)

If no scope with name name exists, it creates a new one with that name and adds it to the end of the scope stack.  Returns the scope with name name.
res.scope(name, scope)

If scope with name name already exists, it is removed from the scope stack.  The scope scope is added to the end of the scope stack with name name.
res.scope(name, scope, replace)

If replace is truthy and if a scope named name already exists, then scope scope takes the place of the existing scope in the scope stack.  If replace is not truthy or if no scope named name exists then behavior is the same as the previous signature.
I use properties res.scopeStack and res.scopeIndex to respectively store the scope stack and to name the scopes.  These properties are not created until the first time res.scope() is called.
The scope stack is completely unrelated to both app.locals and res.locals; it is not possible to access these variables through res.scope().
To support the new behavior, I have added another signature for app.render.
app.render(view, localsStack, callback)

This has the usual behavior of app.render(), but the options object passed to the template engine is created by flattening the locals stack on top of app.locals (i.e., the scopes in localsStack are given higher precedence than app.locals).  The function res.render() uses this signature, creating localsStack by copying res.scopeStack then appending res.locals and the scope passed to res.render().
The other signatures of app.render() remain unchanged, with one small exception.  Previously, calling app.render(view, locals, callback) would look for locals.locals and, if it existed, merge it into the options object to be passed into the template engine.  This was used by res.render() to pass in res.locals.  It has been removed since it is no longer necessary.  If desired, it could be added back in; however, it is not part of the official API, so I was assuming no one would be relying on it.

I'm not really sure of your process here, so I wanted to check in on this.  Is this being considered for possible inclusion in a future release?  If so, is there anything I can do to help it be approved?  Thanks.

Great effort and implementation. However, my opinion is that the functionality should be implemented at the application level; we should keep Express as simple as possible.
@expressjs/express-tc

Alright, this is definitely a stale pull request. Not sure why we didn't close it, but above is our thoughts, ultimately.


hash/adler32: optimize on 64-bit architectures

What version of Go are you using (go version)?
go version go1.7 darwin/amd64
What operating system and processor architecture are you using (go env)?
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/dev/gocode"
GORACE=""
GOROOT="/opt/local/lib/go"
GOTOOLDIR="/opt/local/lib/go/pkg/tool/darwin_amd64"
CC="/usr/bin/clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"
What did you do?
$ cd /opt/local/lib/go/src/hash/adler32
$ go test -bench .
BenchmarkAdler32KB-8   	 3000000	       519 ns/op	1971.24 MB/s
PASS
What did you expect to see?
64bit version written in C easily delivers >4GB/s on this machine
Solution
Use 64bit arithmetics via unsafe.Pointer casting.
NOTE: usage of C style indexing instead of slices in the inner loop also gives a small ~5-10% boost.
Result
~1.8x improvement if implemented with 64bit arithmetics.
$ go test -bench .
BenchmarkAdler32KB-8   	 5000000	       289 ns/op	3531.85 MB/s
PASS

Just for future reference, what's the distribution of sizes on adler32 inputs?  For sufficiently large inputs it can be computed in parallel (I have done this myself) which is another way of improving performance.  The same can be done with somewhat more hair for CRC calculations.

There are really cases when inputs are GBs/sec. So parallelism is great, but hey, you want everything to be slow just because modern CPUs have 8+ cores typically?

adler32 is used in the zlib format and in many other places (see imports: https://godoc.org/hash/adler32?importers). The size of the inputs probably varies very widely, so I don't think it is appropriate to make the adler32 implementation parallel by default. That said, I personally would be interested in seeing Combine functions added to the various hash packages. I tried pushing for that in #12297.

Divide-and-conquer parallelism usually has a minimum chunk size, so "not by default" is hardwired into the algorithm.  I recall the minimum chunk size for adler32 was measured in megabytes, but that was using heavier-weight threads, not goroutines.  The question is really more one of whether it is worth the programming effort.

@rsc, @ianlancetaylor, @griesemer, @randall77: decision needed: does adler32 warrant unsafe to get a 1.8x speedup?

I'm not convinced unsafe is needed in that optimization. Why can't it just use the wide integer load technique that binary.LittleEndian.Uint64 uses?

I'm not against unsafe per se here, but @dsnet's suggestion should be considered first.

Decision: try to do without unsafe first.

I have send a CL about it
https://go-review.googlesource.com/c/48270/


Getters and setters support

https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Functions/get
https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Functions/set

Fixed with #56


Vigy Form Page is modified

Fixes Issue
Fix Issue: #1864
Closes: #1864

Changes proposed

Screenshots

Note to reviewers

Summary by CodeRabbit

New Features

Added dynamic form management in the Admin panel with input validation and prompt for unsaved changes.
Introduced checkboxes for terms and conditions agreement in the Admin form.

Enhancements

Updated FileInput, InputField, and SelectField components to support additional props for better flexibility and validation.
Added a list of Indian banks for selection in the Admin form.

Dependency Updates

Downgraded @emailjs/browser to version 4.3.3.
Updated emailjs to version 4.0.3.
Introduced react-confetti version 6.1.0.
Added react-use version 17.5.0.

All changes Applied by coderabbit the outdated changes are dangerous to do so i had havnet done that or else the same vercel issue will ocme