Update request money header title

Details

App displays 'Split' in title on back from scan request money
App displays 'Split' in title on back from manual request money

Fixed Issues

$ https://github.com/Expensify/App/issues/28751
PROPOSAL: https://github.com/Expensify/App/issues/28751#issuecomment-1746280710
Tests

Part 1:

Open the app
Click on plus and click request money->scan
Select any file
Observe now it displays 'Scan' in header, select any user
Click on back and verify that now it displays 'Scan' in header

Part 2:

Click manual tap
Enter amount and select any user
Click back button and verify that header message is 'Manual'
Click split button and verify that header message is changed to 'Split'

[x] Verify that no errors appear in the JS console

Offline tests

QA Steps

Part 1:

Open the app
Click on plus and click request money->scan
Select any file
Observe now it displays 'Scan' in header, select any user
Click on back and verify that now it displays 'Scan' in header

Part 2:

Click manual tap
Enter amount and select any user
Click back button and verify that header message is 'Manual'
Click split button and verify that header message is changed to 'Split'

[x] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] If we are not using the full Onyx data that we loaded, I've added the proper selector in order to ensure the component only re-renders when the data it is using changes
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[x] I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: Native

https://github.com/Expensify/App/assets/141406735/a3c71625-c056-4a1c-af10-89ec82390060

Android: mWeb Chrome

https://github.com/Expensify/App/assets/141406735/785b7bf2-858a-45d3-9b5e-42a0d4d29c83

iOS: Native

https://github.com/Expensify/App/assets/141406735/a42afd67-5355-492f-819a-e2efe95dd40d

iOS: mWeb Safari

https://github.com/Expensify/App/assets/141406735/4110ec79-05f6-46c1-b44f-dc24525abe44

MacOS: Chrome / Safari

https://github.com/Expensify/App/assets/141406735/9bfcfc23-d516-4b9c-84ca-ab055a849645

MacOS: Desktop

https://github.com/Expensify/App/assets/141406735/69c9fb63-0c6d-459f-a77f-dc83399991c6

@fedirjh Could you help to take a look at this PR? Thanks

@fedirjh Could you help to check this comment? https://github.com/Expensify/App/pull/29936#discussion_r1368774468

@fedirjh I am trying your suggestion, i will give some response asap

@fedirjh I just updated code according to your logic, please check again

@DylanDylann We should reset the isSplitRequest to false inside IOU.resetMoneyRequestInfo to fix this issue.

Thanks for your suggestion, I updated

@fedirjh Thanks for your suggestion, I updated. Please check again

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by https://github.com/amyevans in version: 1.3.93-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/Beamanator in version: 1.3.93-1 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to staging by https://github.com/amyevans in version: 1.3.94-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅

🚀 Deployed to staging by https://github.com/amyevans in version: 1.3.94-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/Beamanator in version: 1.3.94-2 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


Use database to keep track of session cleaning

Description

Use database to keep track of when ReactPy last performs a clean.

Previously done via a cache entry for performance. But realistically we should assume the user is either utilizing a performant DB, or doesn't care about performance to begin with.

Store web module file contents in cache, instead of the HTTP Response
Add a timeout to the web module cached files to allow old entries to be deleted.

Checklist:
Please update this checklist as you complete each item:

[x] Tests have been included for all bug fixes or added functionality.
[x] The changelog has been updated with any significant changes, if necessary.
[x] GitHub Issues which may be closed by this PR have been linked.

Merging so I can create a v3.3.0 release. Will handle review comments in a follow up PR if needed.


android studio added directly error

java.lang.ClassNotFoundException: Didn't find class "com.wangjie.androidbucket.utils.ABTextUtil" on path:

Its a class from a missing library. Add this line to your gradle file.
compile 'com.github.wangjiegulu:AndroidBucket:1.0.4'


[Removal]: PLEASE CONSIDER ALSO THE REQUESTS OF REMOVAL

Hotspot Name
Damaged cedar cat
Hotspot b58 Address
11HvFsxMkAd8RswZvucnYQ3jc6dj9ucMzz1ULkuiheBaSK8B9v4
Discord Handle
No response
Hotspot Manufacturer
KERKLINK
Removal Reason
—-
Modifications
No
Extra forwarders
No
Extra antennas
No
Additional Information
Can anyone do anything about the requests for removal as well? On discord the chat is clogged and numerous people have been scammed by buying second-hand hotspots in the denylist.  They have shown that they put the hotspots in real locations but their requests have gone unheeded. It's already a bad time for the value of hnt, can we speed up for verified requests for removal as well? Thanks
Please Abghay, 6cornerdefender do something

This HS is linked to a pull request to be removed from denylist
https://github.com/helium/denylist/issues/4716

Thanks.. the owner of the hs is one month that is waiting .. anyway ok.. 👌

KXI1 and eddi933 , much appreciated


gitea: 1.9.2 -> 1.9.3

Motivation for this change
Changelog: https://github.com/go-gitea/gitea/releases/tag/v1.9.3
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[x] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Determined the impact on package closure size (by running nix path-info -S before and after)
[x] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Notify maintainers
cc @

@GrahamcOfBorg build nixosTests.gitea

@etu thanks!


Client doesn't care about certificate change

I am confused how clients authenticate tokens. I will explain my setup, how I thought it worked and then my current issue.
I have Identity Server as one website and a client mvc application as a seperate app. The client is defined with HybridAndClientCredentials, AllowOfflineAccess and AccessTokenType.Jwt. It uses AddOpenIdConnect with the correct client configuration and SignInSchema = Cookies. Identity Server uses windows authentication (automatic - true, forward client cert = true) and uses a certificate from the certificate store to do it's magic. The clients, app resources and API definitions are all in a database.
How I thought it worked: The two applications load up, once the mvc app has loaded it requests a public key from identity server. On first user authentication request fail, you are redirected to identity server. IS  creates your token goodness once you log in, using the certificate it is provided in .AddSigningCredential. Finally you are redirected back to the mvc app. For the lifetime of the token, when you do any request requiring authentication, the MVC app will use the public key it grabbed from Identity Server and check the signature is valid. If so, you can continue and any claims information inside the cookie can be considered correct.
Now, I wanted to test what happens if I didn't use AddValidationKey to let clients know old tokens using the previous certificate signature are still valid. I assumed either the client app would bomb out saying invalid token, or hopefully, it would get destroyed and automatically redirected to IS login.
I cleared my cookies, set Identity Server to use the "IIS Express Development Certificate" certificate and started up the apps. I then went onto the mvc app, got redirected to IS, logged in and returned authenticated. I kept that tab open with the cookie in the chrome resources tab visible. I now stopped my apps, changed AddSigningCredential to now use the "DEV" certificate I created and started the applications again. I don't get sent to IS and the mvc app seems to be quite happy with my old cookies... is this right? I have both tabs's chrome resource tabs open to double check it is definitely the same cookie and it is.

Once you log into the MVC app, you will be authenticated with that app until the cookie expires.  AFAIK, MVC doesn't use Identity Server configuration settings to validate its cookies.  It only validates the tokens during the initial sign-in process from Identity Server.  This means that if you make any sort of Identity Server configuration changes they will not be detected by the application until the cookie expires and the user is sent through the sign-in process again.

Then how does it know the token is actually signed correctly?

In a less brief response - If the mvc app doesnt grab the public key from Identity Server to validate the cookie, how does it validate it?

It's been awhile since I deployed my implementation of IdSrv4, so maybe @leastprivilege or @brockallen can confirm or deny my understanding below:
MVC validates its cookies the same way it would whether or not you are using Identity Server, which I believe by default is using the DPAPI.  Cookie validation is a completely separate process from token validation.  Token validation DOES use the IdSrv public key, but only during the initial sign in process.  Once MVC validates the token and authenticates the user, the app makes the assumption that it does not need to keep checking whether the original token signature is valid.  In most cases that would be a huge waste of time.
However one thing to keep in mind when you're changing certificates is that you may invalidate the access token for use with downstream APIs.  Unlike client apps, APIs will frequently fetch the latest public key info from IdSrv to validate the access token it's being provided.  So if a client app was providing a token signed CertA and IdSrv was updated to use CertB, it's quite likely that downstream APIs would quickly start rejecting any tokens signed with CertA.

The client loads the discovery document and key information at startup time - and refreshes it every 24h (by default). At least that is the behavior of the Microsoft MVC client lib.


accessing parent component in source function

Hi!
I am using the aupac-typeahead component in my project. In my usecase, the functionality of the source function depends on some properties of the parent component (or controller). However, I can't use this inside the source function to access my component, instead the source function seems to be bound to the jQuery typeahead component. Here is a demonstration twiddle:
https://ember-twiddle.com/6807d81cbaeb475cdb115ed16b8890d1?openFiles=controllers.application.js%2C
Do you have a suggestion how I could solve this problem?
Best,
Matthias

Thanks to camonz from the ember slack channel, I have the answer. The solution is to convert the source function to an action and call it via source=(action "sourceFn"). For an updated twiddle see:
https://ember-twiddle.com/6807d81cbaeb475cdb115ed16b8890d1?openFiles=templates.application.hbs%2C


HMR connected but not hot-reloading with Vanilla JS

OS Details
   Static hostname: mmaza
         Icon name: computer-laptop
           Chassis: laptop
        Machine ID: 8c2121faff414af1af9606b89cd3e6cb
           Boot ID: be3bbe6a599b4d91be2deea016c167cd
  Operating System: Debian GNU/Linux buster/sid
            Kernel: Linux 4.16.0-1-amd64
      Architecture: x86-64

Node, npm and packages versions
$ node --version
v8.11.2

$ npm --version
6.0.1

$ npm list --depth=0
<EMAIL_ADDRESS>/home/mmaza/www/personal/projects/hmr
├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>└──<EMAIL_ADDRESS>
Scenario
I'm setting up a bare-bones example for Express + Webpack-Dev-Middleware + Webpack-Hot-Middleware + Vanilla JS (I'll add React later), but it's not working properly.
When I start my server with node server I see the server listening to 3000 and webpack compiles successfully:
$ node server
clean-webpack-plugin: /home/mmaza/www/personal/projects/hmr/public has been removed.
clean-webpack-plugin: /home/mmaza/www/personal/projects/hmr/public has been removed.
Example app listening on port 3000!
ℹ ｢wdm｣: Hash: 21775a3b93d90235225b
Version: webpack 4.9.1
Time: 807ms
Built at: 2018-05-28 11:33:35
     Asset       Size  Chunks             Chunk Names
 bundle.js   1.67 MiB    main  [emitted]  main
index.html  189 bytes          [emitted]
Entrypoint main = bundle.js
[./client/assets/project01.png] 595 KiB {main} [built]
[./client/index.js] 386 bytes {main} [built]
[./client/index.scss] 1.17 KiB {main} [built]
[./node_modules/ansi-html/index.js] 4.16 KiB {main} [built]
[./node_modules/css-loader/index.js!./node_modules/sass-loader/lib/loader.js!./client/index.scss] ./node_modules/css-loader!./node_modules/sass-loader/lib/loader.js!./client/index.scss 450 bytes {main} [built]
[./node_modules/html-entities/index.js] 231 bytes {main} [built]
[./node_modules/querystring-es3/decode.js] 2.45 KiB {main} [built]
[./node_modules/querystring-es3/index.js] 127 bytes {main} [built]
[./node_modules/style-loader/lib/addStyles.js] 9.77 KiB {main} [built]
[./node_modules/webpack-hot-middleware/client-overlay.js] (webpack)-hot-middleware/client-overlay.js 2.16 KiB {main} [built]
[0] multi ./client/index.js webpack-hot-middleware/client?http://localhost:3000 40 bytes {main} [built]
[./node_modules/webpack-hot-middleware/client.js?http://localhost:3000] (webpack)-hot-middleware/client.js?http://localhost:3000 7.59 KiB {main} [built]
[./node_modules/webpack-hot-middleware/node_modules/strip-ansi/index.js] (webpack)-hot-middleware/node_modules/strip-ansi/index.js 161 bytes {main} [built]
[./node_modules/webpack-hot-middleware/process-update.js] (webpack)-hot-middleware/process-update.js 4.23 KiB {main} [built]
[./node_modules/webpack/buildin/module.js] (webpack)/buildin/module.js 519 bytes {main} [built]
    + 7 hidden modules
Child html-webpack-plugin for "index.html":
         Asset     Size  Chunks  Chunk Names
    index.html  556 KiB       0
    Entrypoint undefined = index.html
    [./node_modules/html-webpack-plugin/lib/loader.js!./node_modules/html-webpack-plugin/default_index.ejs] 376 bytes {0} [built]
    [./node_modules/lodash/lodash.js] 527 KiB {0} [built]
    [./node_modules/webpack/buildin/global.js] (webpack)/buildin/global.js 509 bytes {0} [built]
    [./node_modules/webpack/buildin/module.js] (webpack)/buildin/module.js 519 bytes {0} [built]
ℹ ｢wdm｣: Compiled successfully.

And in the browser I have this:
[HMR] connected client.js?5835:92
Expected behavior
When I update the file client/index.js (I just modify a string), I have this in the console:
$ node server
clean-webpack-plugin: /home/mmaza/www/personal/projects/hmr/public has been removed.
clean-webpack-plugin: /home/mmaza/www/personal/projects/hmr/public has been removed.
Example app listening on port 3000!
ℹ ｢wdm｣: Hash: 21775a3b93d90235225b
Version: webpack 4.9.1
Time: 807ms
Built at: 2018-05-28 11:33:35
     Asset       Size  Chunks             Chunk Names
 bundle.js   1.67 MiB    main  [emitted]  main
index.html  189 bytes          [emitted]
Entrypoint main = bundle.js
[./client/assets/project01.png] 595 KiB {main} [built]
[./client/index.js] 386 bytes {main} [built]
[./client/index.scss] 1.17 KiB {main} [built]
[./node_modules/ansi-html/index.js] 4.16 KiB {main} [built]
[./node_modules/css-loader/index.js!./node_modules/sass-loader/lib/loader.js!./client/index.scss] ./node_modules/css-loader!./node_modules/sass-loader/lib/loader.js!./client/index.scss 450 bytes {main} [built]
[./node_modules/html-entities/index.js] 231 bytes {main} [built]
[./node_modules/querystring-es3/decode.js] 2.45 KiB {main} [built]
[./node_modules/querystring-es3/index.js] 127 bytes {main} [built]
[./node_modules/style-loader/lib/addStyles.js] 9.77 KiB {main} [built]
[./node_modules/webpack-hot-middleware/client-overlay.js] (webpack)-hot-middleware/client-overlay.js 2.16 KiB {main} [built]
[0] multi ./client/index.js webpack-hot-middleware/client?http://localhost:3000 40 bytes {main} [built]
[./node_modules/webpack-hot-middleware/client.js?http://localhost:3000] (webpack)-hot-middleware/client.js?http://localhost:3000 7.59 KiB {main} [built]
[./node_modules/webpack-hot-middleware/node_modules/strip-ansi/index.js] (webpack)-hot-middleware/node_modules/strip-ansi/index.js 161 bytes {main} [built]
[./node_modules/webpack-hot-middleware/process-update.js] (webpack)-hot-middleware/process-update.js 4.23 KiB {main} [built]
[./node_modules/webpack/buildin/module.js] (webpack)/buildin/module.js 519 bytes {main} [built]
    + 7 hidden modules
Child html-webpack-plugin for "index.html":
         Asset     Size  Chunks  Chunk Names
    index.html  556 KiB       0
    Entrypoint undefined = index.html
    [./node_modules/html-webpack-plugin/lib/loader.js!./node_modules/html-webpack-plugin/default_index.ejs] 376 bytes {0} [built]
    [./node_modules/lodash/lodash.js] 527 KiB {0} [built]
    [./node_modules/webpack/buildin/global.js] (webpack)/buildin/global.js 509 bytes {0} [built]
    [./node_modules/webpack/buildin/module.js] (webpack)/buildin/module.js 519 bytes {0} [built]
ℹ ｢wdm｣: Compiled successfully.
ℹ ｢wdm｣: Compiling...
ℹ ｢wdm｣: Hash: 9c5d661564500b568426
Version: webpack 4.9.1
Time: 243ms
Built at: 2018-05-28 11:41:49
                                  Asset       Size  Chunks             Chunk Names
   b9ca870352211d7772a9.hot-update.json   44 bytes          [emitted]
                              bundle.js   1.67 MiB    main  [emitted]  main
main.21775a3b93d90235225b.hot-update.js   2.17 KiB    main  [emitted]  main
   21775a3b93d90235225b.hot-update.json   46 bytes          [emitted]
                             index.html  189 bytes          [emitted]
Entrypoint main = bundle.js main.21775a3b93d90235225b.hot-update.js
[./client/assets/project01.png] 595 KiB {main}
[./client/index.js] 388 bytes {main} [built]
[./client/index.scss] 1.17 KiB {main}
[./node_modules/ansi-html/index.js] 4.16 KiB {main}
[./node_modules/css-loader/index.js!./node_modules/sass-loader/lib/loader.js!./client/index.scss] ./node_modules/css-loader!./node_modules/sass-loader/lib/loader.js!./client/index.scss 450 bytes {main}
[./node_modules/html-entities/index.js] 231 bytes {main}
[./node_modules/querystring-es3/decode.js] 2.45 KiB {main}
[./node_modules/querystring-es3/index.js] 127 bytes {main}
[./node_modules/style-loader/lib/addStyles.js] 9.77 KiB {main}
[./node_modules/webpack-hot-middleware/client-overlay.js] (webpack)-hot-middleware/client-overlay.js 2.16 KiB {main}
[0] multi ./client/index.js webpack-hot-middleware/client?http://localhost:3000 40 bytes {main}
[./node_modules/webpack-hot-middleware/client.js?http://localhost:3000] (webpack)-hot-middleware/client.js?http://localhost:3000 7.59 KiB {main}
[./node_modules/webpack-hot-middleware/node_modules/strip-ansi/index.js] (webpack)-hot-middleware/node_modules/strip-ansi/index.js 161 bytes {main}
[./node_modules/webpack-hot-middleware/process-update.js] (webpack)-hot-middleware/process-update.js 4.23 KiB {main}
[./node_modules/webpack/buildin/module.js] (webpack)/buildin/module.js 519 bytes {main}
    + 7 hidden modules
Child html-webpack-plugin for "index.html":
                                   Asset      Size  Chunks             Chunk Names
                              index.html   556 KiB       1
    b9ca870352211d7772a9.hot-update.json  44 bytes          [emitted]
    Entrypoint undefined = index.html
    [./node_modules/html-webpack-plugin/lib/loader.js!./node_modules/html-webpack-plugin/default_index.ejs] 376 bytes {1}
    [./node_modules/lodash/lodash.js] 527 KiB {1}
    [./node_modules/webpack/buildin/global.js] (webpack)/buildin/global.js 509 bytes {1}
    [./node_modules/webpack/buildin/module.js] (webpack)/buildin/module.js 519 bytes {1}
ℹ ｢wdm｣: Compiled successfully.

After that, HMR should reflect the changes in the browser's console.
Actual behavior
When I update the file client/index.js (I just modify a string), I have this in the console:
$ node server
clean-webpack-plugin: /home/mmaza/www/personal/projects/hmr/public has been removed.
clean-webpack-plugin: /home/mmaza/www/personal/projects/hmr/public has been removed.
Example app listening on port 3000!
ℹ ｢wdm｣: Hash: 21775a3b93d90235225b
Version: webpack 4.9.1
Time: 807ms
Built at: 2018-05-28 11:33:35
     Asset       Size  Chunks             Chunk Names
 bundle.js   1.67 MiB    main  [emitted]  main
index.html  189 bytes          [emitted]
Entrypoint main = bundle.js
[./client/assets/project01.png] 595 KiB {main} [built]
[./client/index.js] 386 bytes {main} [built]
[./client/index.scss] 1.17 KiB {main} [built]
[./node_modules/ansi-html/index.js] 4.16 KiB {main} [built]
[./node_modules/css-loader/index.js!./node_modules/sass-loader/lib/loader.js!./client/index.scss] ./node_modules/css-loader!./node_modules/sass-loader/lib/loader.js!./client/index.scss 450 bytes {main} [built]
[./node_modules/html-entities/index.js] 231 bytes {main} [built]
[./node_modules/querystring-es3/decode.js] 2.45 KiB {main} [built]
[./node_modules/querystring-es3/index.js] 127 bytes {main} [built]
[./node_modules/style-loader/lib/addStyles.js] 9.77 KiB {main} [built]
[./node_modules/webpack-hot-middleware/client-overlay.js] (webpack)-hot-middleware/client-overlay.js 2.16 KiB {main} [built]
[0] multi ./client/index.js webpack-hot-middleware/client?http://localhost:3000 40 bytes {main} [built]
[./node_modules/webpack-hot-middleware/client.js?http://localhost:3000] (webpack)-hot-middleware/client.js?http://localhost:3000 7.59 KiB {main} [built]
[./node_modules/webpack-hot-middleware/node_modules/strip-ansi/index.js] (webpack)-hot-middleware/node_modules/strip-ansi/index.js 161 bytes {main} [built]
[./node_modules/webpack-hot-middleware/process-update.js] (webpack)-hot-middleware/process-update.js 4.23 KiB {main} [built]
[./node_modules/webpack/buildin/module.js] (webpack)/buildin/module.js 519 bytes {main} [built]
    + 7 hidden modules
Child html-webpack-plugin for "index.html":
         Asset     Size  Chunks  Chunk Names
    index.html  556 KiB       0
    Entrypoint undefined = index.html
    [./node_modules/html-webpack-plugin/lib/loader.js!./node_modules/html-webpack-plugin/default_index.ejs] 376 bytes {0} [built]
    [./node_modules/lodash/lodash.js] 527 KiB {0} [built]
    [./node_modules/webpack/buildin/global.js] (webpack)/buildin/global.js 509 bytes {0} [built]
    [./node_modules/webpack/buildin/module.js] (webpack)/buildin/module.js 519 bytes {0} [built]
ℹ ｢wdm｣: Compiled successfully.
ℹ ｢wdm｣: Compiling...
ℹ ｢wdm｣: Hash: 9c5d661564500b568426
Version: webpack 4.9.1
Time: 243ms
Built at: 2018-05-28 11:41:49
                                  Asset       Size  Chunks             Chunk Names
   b9ca870352211d7772a9.hot-update.json   44 bytes          [emitted]
                              bundle.js   1.67 MiB    main  [emitted]  main
main.21775a3b93d90235225b.hot-update.js   2.17 KiB    main  [emitted]  main
   21775a3b93d90235225b.hot-update.json   46 bytes          [emitted]
                             index.html  189 bytes          [emitted]
Entrypoint main = bundle.js main.21775a3b93d90235225b.hot-update.js
[./client/assets/project01.png] 595 KiB {main}
[./client/index.js] 388 bytes {main} [built]
[./client/index.scss] 1.17 KiB {main}
[./node_modules/ansi-html/index.js] 4.16 KiB {main}
[./node_modules/css-loader/index.js!./node_modules/sass-loader/lib/loader.js!./client/index.scss] ./node_modules/css-loader!./node_modules/sass-loader/lib/loader.js!./client/index.scss 450 bytes {main}
[./node_modules/html-entities/index.js] 231 bytes {main}
[./node_modules/querystring-es3/decode.js] 2.45 KiB {main}
[./node_modules/querystring-es3/index.js] 127 bytes {main}
[./node_modules/style-loader/lib/addStyles.js] 9.77 KiB {main}
[./node_modules/webpack-hot-middleware/client-overlay.js] (webpack)-hot-middleware/client-overlay.js 2.16 KiB {main}
[0] multi ./client/index.js webpack-hot-middleware/client?http://localhost:3000 40 bytes {main}
[./node_modules/webpack-hot-middleware/client.js?http://localhost:3000] (webpack)-hot-middleware/client.js?http://localhost:3000 7.59 KiB {main}
[./node_modules/webpack-hot-middleware/node_modules/strip-ansi/index.js] (webpack)-hot-middleware/node_modules/strip-ansi/index.js 161 bytes {main}
[./node_modules/webpack-hot-middleware/process-update.js] (webpack)-hot-middleware/process-update.js 4.23 KiB {main}
[./node_modules/webpack/buildin/module.js] (webpack)/buildin/module.js 519 bytes {main}
    + 7 hidden modules
Child html-webpack-plugin for "index.html":
                                   Asset      Size  Chunks             Chunk Names
                              index.html   556 KiB       1
    b9ca870352211d7772a9.hot-update.json  44 bytes          [emitted]
    Entrypoint undefined = index.html
    [./node_modules/html-webpack-plugin/lib/loader.js!./node_modules/html-webpack-plugin/default_index.ejs] 376 bytes {1}
    [./node_modules/lodash/lodash.js] 527 KiB {1}
    [./node_modules/webpack/buildin/global.js] (webpack)/buildin/global.js 509 bytes {1}
    [./node_modules/webpack/buildin/module.js] (webpack)/buildin/module.js 519 bytes {1}
ℹ ｢wdm｣: Compiled successfully.

But in the browser nothing happens:
[HMR] connected client.js?5835:92
Files
Here are the most important files handy:
client/index.js:
import projectImage from './assets/project01.png';
import './index.scss';

function component() {
    var element = document.createElement('div');
    element.innerHTML = "Hello world with middleware with hot reload!!!";

    var testImage = new Image();
    testImage.src = projectImage;
    element.appendChild(testImage);

    return element;
}
document.body.appendChild(component());

server/index.js:
const express = require('express');
const webpack = require('webpack');
const webpackConfig = require('../webpack.config');
const webpackMiddleware = require("webpack-dev-middleware");
const webpackHotMiddleware = require("webpack-hot-middleware");
const app = express();

// Static files
app.use(express.static('public'));

// Webpack Middleware
app.use(webpackMiddleware(webpack(webpackConfig),{
  publicPath: webpackConfig.output.publicPath
}));

// Webpack Hot Middleware
app.use(webpackHotMiddleware(webpack(webpackConfig),{
  path: webpackConfig.output.publicPath
}));

// Start up
app.listen(3000, () => {
  console.log('Example app listening on port 3000!')
});

webpack.config.js:
const path = require('path');
const webpack = require('webpack');
const HtmlWebpackPlugin = require('html-webpack-plugin');
const CleanWebpackPlugin = require('clean-webpack-plugin');
const public = path.resolve(__dirname, 'public');

module.exports = {
    entry: [
      './client/index.js',
      'webpack-hot-middleware/client?http://localhost:3000',
    ],
    mode: 'development',
    devtool: 'inline-source-map',
    output: {
        filename: 'bundle.js',
        path: path.resolve(__dirname, public),
    },
    module: {
      rules: [
        {
          test: /\.(css|scss|sass)$/,
          use: [
            'style-loader',
            'css-loader',
            'sass-loader'
          ]
        },
        {
          test: /\.(woff|woff2|ttf|eot|svg|jpg|png|gif)$/,
          use: [
            {
              loader: 'url-loader'
            }
          ]
        }
      ]
    },
    plugins: [
        new CleanWebpackPlugin([public]),
        new HtmlWebpackPlugin({
            title: 'React from scratch'
        }),
        new webpack.HotModuleReplacementPlugin(),
        new webpack.NoEmitOnErrorsPlugin()
    ]
};

package.json:
{
  "name": "hmr",
  "version": "1.0.0",
  "description": "HMR-React-Sass",
  "main": "index.js",
  "scripts": {
    "dev": "node server",
    "build": "webpack --mode production",
    "lint": "./node_modules/.bin/eslint --init",
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [
    "HMR-React-Sass"
  ],
  "author": "Marco Maza",
  "license": "MIT",
  "devDependencies": {
    "clean-webpack-plugin": "^0.1.19",
    "css-loader": "^0.28.11",
    "express": "^4.16.3",
    "html-webpack-plugin": "^3.2.0",
    "node-sass": "^4.9.0",
    "sass-loader": "^7.0.1",
    "style-loader": "^0.21.0",
    "url-loader": "^1.0.1",
    "webpack": "^4.9.1",
    "webpack-cli": "^2.1.4",
    "webpack-dev-middleware": "^3.1.3",
    "webpack-hot-middleware": "^2.22.2"
  }
}

Test case
Here you can find the test case I'm working on: https://gitlab.com/marcomaza92/playground
Thank you in advance

You’re passing different instances of the webpack compiler to Dev middleware and hot middleware
They need to share the same instance.

That was super fast.
How come?, I'm passing webpack(webpackConfig) to both webpackMiddleware and webpackHotMiddleware.
Thanks!

Nevermind, I just saw the error (so dumb btw).
Thanks a lot!

@marcomaza92  hello, I have same issue with you ,  I wonder how you solve it?

@marcomaza92 Nevermind, I should pass same compiler to  Dev middleware and Hot middleware, rather than use webpack(webpackConfig).


Forwarding wrangler port host -> guest doesn't seem to work using Docker

🐛 Bug report
Describe the bug
I'm not 100% sure if it's a bug, but this is the first time port forwarding doesn't work for me using docker.
Reproduce the bug
Setup Docker with the following config:
 node:
    image: node
    ports:
      - '8787:8787'
    command: sh -cx 'npm install @cloudflare/wrangler -g'

Start wrangler dev.
Now try to access http://localhost:8787 from your host, which doesn't seem to work. I've also tried it with - '<IP_ADDRESS>:8787:8787' in the ports config, but it doesn't help.
It only works when I add a user forwarded port with the vscode remote dev extension.
Expected behavior
http://localhost:8787 should be accessible from the host.
Environment and versions

operating system: MacOS (host)
output of wrangler -V: 1.16.0
output of node -v: v15.11.0
content of wrangler.toml:

name = "example"
type = "webpack"
webpack_config = "webpack.config.js"
account_id = "1234"
workers_dev = true

Fixed it by myself after I figured out that there is a network config for wrangler, this is required when using wrangler inside a docker container:
[dev]
ip = "<IP_ADDRESS>"
port = 8787
local_protocol="http"
upstream_protocol="https"


invalid sha1

Heyllo !
Looks like the sha1 on https://repo1.maven.org/maven2/com/badlogicgames/box2dlights/box2dlights/1.4/ is invalid.
I compute<PHONE_NUMBER>bb809fef9df8989cb24a1ce08645e8  box2dlights-1.4.pom where it's expected to be eefc40a640a45eeabe749ab9c980fd94c9e529e3
Thanks for your work :+1:

I compute the<PHONE_NUMBER>bb809fef9df8989cb24a1ce08645e8 also... Seems something gone wrong.
Does this have any impact, or you just found out this occasionally?)

Well I use sbt and it verifies the hash by default. I have turned it off

1.5 is the latest, so I'll close this one


[feature request] Support accounts in the Blockrelay config section

Rewriting proposer_config in the blockrelay section based on accounts from the accountmanager section, not based on a single validator.
In my case, I have different accounts with multi keys(about 200 for each).
For each account I need to specify a different fee_ recipient.
And current config is a bit messy now with a lot of copypaste.

This feature should now be available in the https://github.com/attestantio/vouch/tree/execution-config-v2 branch.  If possible, please compile this branch and run it in your test environment to confirm that it meets your requirement.  If not, please read https://github.com/attestantio/vouch/blob/execution-config-v2/docs/executionconfig.md for the same.

ty, gonna test next week or so

Any feedback on this PR?  I'm looking to merge it in the coming week so any information you may have on it would be appreciated.


Increase tolerance when validating gmm and hello.

The tolerances here are somewhat arbitrarily set to allow validation with an implementation based on finite differencing. There is room to bikeshed them, but I suggest not doing so, for the following reasons:

Even with the very generous gmm tolerance, it is unlikely that a
buggy implementation will have a validating Jacobian.

Although a loose tolerance allows implementations to play
mixed-precision games for performance, Gradbench is not a
competition, and so we can assume "good faith" on behalf of the
tools.

Options for configuring the tolerance can always be added later.

The finite differences implementation in #136 doesn't validate without these relaxed tolerances. I expect finite differences will be the numerically worst of any tool for all benchmarks (unless someone is doing something seriously funky), so I don't expect and endless churn of fiddling with tolerances.


combo_beta.json is loaded twice

The file combo_beta.json is loaded twice. If anyone can help make this file load only once I would appreciate the help.

Refactoring to remove jQuery fixed this! See you later 280 KB.


⚠ ClamAV has degraded performance

In 01c0cb0, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 585 ms

Resolved: ClamAV performance has improved in a6a929e.


Try to fix the bugs in MPI parallel sub tasks

Things seem to work now for openmpi but they do not work for mpich or msmpi.


V1.4 bug fixes

Display error message for tag+ and tag- (issue #167)

Update sample data's tags
Included sample tag list upon start-up (to match sample data)

Issue:

#156
#121
#96
Bug fix: Sample and tags mismatch & edit error due to it

Add message when no tags are found with ls -t

Issue: #122

refer to latest pr by shun jie


[NFC] Add additional documentation to patterns

The descriptions of patterns weren't very descriptive. I've added a lot more information
about where patterns show up in the language, as well as adding more examples.

@swift-ci please smoke test

The windows failure is unrelated. I've only made changes to comments.


feat: simplify and generalise get_image()

get_image function in image_utils.py had a hardcoded list of image names and code to modify these for use with a local target registry. It fails an assertion if an unexpected image name is passed in.
This commit simplifies the code and has default functionality for any image not explicitly handled, so that
old_registry/path/image_name
is converted to
new_registry/image_name
which will work in almost all cases.

I apologize this has taken a hot minute to review, I've been meaning to create unit tests to try and make sure we don't regress in those, since to be honest we don't really have a test that uses a container_infra_prefix...

@mnaser could you please take a quick look at https://github.com/bbc/magnum-cluster-api/commits/external-manifest/
This should be much lower risk and if it looks basically OK I can create another PR with that different approach.


Issue #1 typescript migration

Off topic change: making wrapper in node module.

Closing request and deleting branch - after some more research a safer approach is to create a js module then add TS support.

Closing request and deleting branch - after some more research a safer approach is to create a js module then add TS support.


What is wrong about my go runtime of image

I completed my step of Setting up the development environment. But I am confusing the step of go build in Building the project in VM. When I run command go, the error message below come out. I am confusing what is wrong about my Golang runtime of the image of VM.
The program 'go' is currently not installed. To run 'go' please ask your administrator to install the package 'gccgo-go'
Could you Please kindly help?

And could you please help to explain about the shared folder about VM as the image attached?

Here is my fix method, to install guest additions of virtualbox.
http://docs-v1.vagrantup.com/v1/docs/base_boxes.html
First, build the necessary packages. You may have to look these up for your system, but they should be fairly similar. On Ubuntu and Debian based systems they are as follows:
$ sudo apt-get install linux-headers-$(uname -r) build-essential
Next, make sure to insert the guest additions image by using the GUI and clicking on “Devices” followed by “Install Guest Additions.”. Then run the following to mount the CD Rom:
$ sudo mount /dev/cdrom /media/cdrom


Hollow 2.6.2 does not appear to be in maven central

For some reason Hollow 2.6.2 does not appear to be in maven central so upgrading to version 2.6.3 which is there.

Was upgraded in this commit


Make the 'getting-started' document clearer

We found it is confused for new hands in this part from https://open-cluster-management.io/getting-started/register-cluster/:

Can we use lable to print only the csr we want?

Solved


Implement support for respecting upgrade graph semantics

Goal: Ensure the defined upgrade graph semantics are respected during upgrades. The current implementation always chooses the highest semver bundle in the desired package name without inspecting the upgrade graph semantics.
Needs Clarification on Scope:

Ensuring cross-catalog upgrades are handled properly
Ensuring cross-channel upgrades are handled properly
Accommodating catalogs that define multiple bundle formats (as this doesn't exist today)

Open Questions:

Do we need to leverage the OperatorConditions API to determine whether an Operator cannot be upgraded?
How do we avoid blasting through the upgrade graph if there's no support at the rukpak layer for inspecting the runtime state of managed workloads?

cc @joelanford in case you have any thoughts on those open questions. It seems like having runtime checks in rukpak's plain bundle format would be needed here to avoid blasting through the defined upgrade graph semantics to avoid the following scenario:

v0.1.0 is currently installed, and there's a v0.2.0 and v0.3.0 versions present in the catalog
v0.2.0 is replaced by v0.1.0, and v0.3.0 replaces v0.2.0

Any implementation that simply looks at the replaces chain here would pivot to v0.2.0 once it's available, then the controller would catch the BD event and requeue, and then select the v0.3.0 as it's the highest semver available and there's no logic that can inspect the state of something like a deployment.

We'll also need to be able to delineate between "my operator cannot be upgraded right now as performing migration logic" and "my operator was able to successfully be applied to the cluster but it's failing at runtime" to have a more robust story about upgrades that doesn't exist in the current implementation.

I imagine this will be in scope for an integration with deppy, where the operator controller has a way to tell deppy:

Here's what's installed
Here's what's upgradable (based on OperatorConditions and/or BD Health objects)


Error: not a valid NativeScript plugin

When I am trying to install a plugin it gives me an error:
@nativescript-community/texttospeech is not a valid NativeScript plugin. Verify that the plugin package.json file contains a nativescript key and try again.
I am using latest NS:
Component nativescript has 8.0.2 version and is up to date.
Component @nativescript/core has 8.0.8 version and is up to date

I experience the same issue, doesn't seem with the plugin itself but rather an ENV issue
I installed it using npm and continued working fine ..
npm i --save nativescript-texttospeech


Updated Admin table based on the UX design

Updated Admin table based on the UX design. Added Create Provider button to the empty state. Alert.
Signed-off-by: Olga Lavtar<EMAIL_ADDRESS>

Closing in favor of https://github.com/RHEcosystemAppEng/dbaas-dynamic-plugin/pull/60


Fix warning Django 1.9

Fix deprecation warning for django.utils.importlib in Django 1.9

Thanks for the PR. Could you change the code as follow?

Fix the syntax errors. It seems that you forgot to add ':' after else
Move the code into compat.py and use it while the change is related to a compatibility.

#36


Two node with same device eui will cause payload data abnormal

Hi,
I found a strange problem today.
When I use node device eui which is "0x4786e6ed00380057", payload parse ok. But if I use another node with same device eui, the first node still can receive data, but payload parse abnormal. Please refer log below:

gateway/aa555a0000000101/rx {"rxInfo":{"mac":"aa555a0000000101","time":"0001-01-01T00:00:00Z","timestamp":3705995188,"frequency":471500000,"channel":4,"rfChain":0,"crcStatus":1,"codeRate":"4/5","rssi":-4,"loRaSNR":10.5,"size":25,"dataRate":{"modulation":"LORA","spreadFactor":12,"bandwidth":125}},"phyPayload":"gNURwgaAAAACHscuvo2mQjcY6eDmRsMaRQ=="}
Mar 27 19:53:01 iZbp13xpaqt4mvtq1tt73nZ node[27584]: application/70b3d57ed000140d/node/4786e6ed00380057/rx {"devEUI":"4786e6ed00380057","rxInfo":[{"mac":"aa555a0000000101","rssi":-4,"loRaSNR":10.5}],"txInfo":{"frequency":471500000,"dataRate":{"modulation":"LORA","bandwidth":125,"spreadFactor":12},"adr":true,"codeRate":"4/5"},"fCnt":0,"fPort":2,"data":"AAAAAAAA//8AAAAA"}
Mar 27 19:53:02 iZbp13xpaqt4mvtq1tt73nZ node[27584]: gateway/aa555a0000000101/tx {"txInfo":{"mac":"aa555a0000000101","immediately":false,"timestamp":3706995188,"frequency":471500000,"power":14,"dataRate":{"modulation":"LORA","spreadFactor":12,"bandwidth":125},"codeRate":"4/5","iPol":null},"phyPayload":"YNURwgYgAADklLFd"}

Mar 27 19:53:10 iZbp13xpaqt4mvtq1tt73nZ node[27584]: gateway/aa555a0000000101/rx {"rxInfo":{"mac":"aa555a0000000101","time":"0001-01-01T00:00:00Z","timestamp":3714762692,"frequency":471700000,"channel":5,"rfChain":0,"crcStatus":1,"codeRate":"4/5","rssi":-49,"loRaSNR":2.8,"size":25,"dataRate":{"modulation":"LORA","spreadFactor":12,"bandwidth":125}},"phyPayload":"gE0GbAeAAwACDqV+7FQX9I3yzt4aKKJvvQ=="}
Mar 27 19:53:10 iZbp13xpaqt4mvtq1tt73nZ node[27584]: application/70b3d57ed000140d/node/4786e6ed00380057/rx {"devEUI":"4786e6ed00380057","rxInfo":[{"mac":"aa555a0000000101","rssi":-49,"loRaSNR":2.8}],"txInfo":{"frequency":471700000,"dataRate":{"modulation":"LORA","bandwidth":125,"spreadFactor":12},"adr":true,"codeRate":"4/5"},"fCnt":3,"fPort":2,"data":"SyvbZEbu1bFrVKQ5"}
Mar 27 19:53:10 iZbp13xpaqt4mvtq1tt73nZ node[27584]: gateway/aa555a0000000101/tx {"txInfo":{"mac":"aa555a0000000101","immediately":false,"timestamp":3715762692,"frequency":471700000,"power":14,"dataRate":{"modulation":"LORA","spreadFactor":12,"bandwidth":125},"codeRate":"4/5","iPol":null},"phyPayload":"YE0GbAcgAwBPaVAI"}

You can see two packet from different node which use same device eui. Second packet  joined at first, and first packet joined at next.
The Most strange things is that verification about MIC value has no problem. And two node will receive different ACK which devaddr is same as they got before.
Did I miss something?
Thanks for your reply!

Could you share how you activated your nodes?

Hi @brocaar , thanks for your reply!
I first power on node A which is "4786e6ed00380057". After join, every thing is fine, and data parse ok.
Then I power on node B which also use "4786e6ed00380057". It will trigger server accpect node B and I can see device address, network session key, application session key has been changed.
I thought packet from node A will reject then. But actually not.... It still get ACK, and server still decrypt packet, but use new application session key, so it's wrong. Because MIC verify and ACK is ok, I think device address and network session key is still use old for node A.

Could you share which version of LoRa Server you're using? In the meanwhile, I'll see if I can reproduce this behaviour.

I'm not able to reproduce your issue.
What I tried:

Added node<PHONE_NUMBER>010101 to LoRa App Server
Provisioned two nodes (node1, node2) with the same DevEUI / AppEUI / AppKey as for node<PHONE_NUMBER>010101
Activated node1 using OTAA
Activated node2 using OTAA
Now when node1 sends data, I get the (expected) error ERRO[0755] processing rx packet error: get node-session error: node-session does not exist or invalid fcnt or mic  data_base64="QGEsFgeABAACuXLiq4BlZ+hKprcHrOsfSz2p78w="

Hi @brocaar ,
Would you please tell me how long you wait between step 3 and step 4 ? For me, I wait about one minute.

Sorry @brocaar , it maybe code version's problem. After I update my code, this problem disappear.
But another problem appear... Please check log below:

application/1/node/4786e6ed00380057/join {"applicationID":"1","applicationName":"70b3d57ed000140d","nodeName":"4786e6ed00380057","devEUI":"4786e6ed00380057","devAddr":"07662e52"}
gateway/b827ebfffe6c9ff7/tx {"txInfo":{"mac":"b827ebfffe6c9ff7","immediately":false,"timestamp":3675438499,"frequency":475500000,"power":14,"dataRate":{"modulation":"LORA","spreadFactor":7,"bandwidth":125},"codeRate":"4/5","iPol":null},"phyPayload":"IIiloMTT95ewJxMRrsPC8dURtz33t8Abemq5BRBRurEU"}
application/1/node/4786e6ed00380057/rx {"applicationID":"1","applicationName":"70b3d57ed000140d","nodeName":"4786e6ed00380057","devEUI":"4786e6ed00380057","rxInfo":[{"mac":"b827ebfffe6c9ff7","rssi":-95,"loRaSNR":3.2}],"txInfo":{"frequency":475700000,"dataRate":{"modulation":"LORA","bandwidth":125,"spreadFactor":12},"adr":true,"codeRate":"4/5"},"fCnt":3,"fPort":2,"data":"xStAvgOiEMo7kvg4"}

Decryption of old node data still have problem. But it happened only once and at new node join. Test step same as before.
Now I give my suspect below:

node1 send new data to server.
node1 data pass loraserver's mic verify.
node2 join and session renewed.
node1 data send to lora-app-server
lora-app-server decryption it with new App session key.
bad data appear....
So the result is loraserver and lora-app-server has different session at some critical region.
Do you think it is make sense? Thanks!

Could you define "bad data"? Note that xStAvgOiEMo7kvg4 is already decrypted, you only have to base64 decode it (e.g. https://play.golang.org/p/_1sEX3j8xX).

Sorry for confusion.
"Bad data" means use wrong Application session key to decrypt payload. It will cause sensor data seems abnormal, like -105℃.....

It seems that I can't replicate your issue. When node1 sends data again after node2 joins (with the same deveui), I get an (expected) error in the LoRa Server logs ERRO[0755] processing rx packet error: get node-session error: node-session does not exist or invalid fcnt or mic data_base64="QGEsFgeABAACuXLiq4BlZ+hKprcHrOsfSz2p78w=".
That error is expected since the node-session for the deveui has been overwritten by the activation of node2. So the MIC of node1 is no longer valid because the NwkSKey changed.

Hi @brocaar ,
As I said it is a critical region problem, I reproduce it only once.
Maybe you should check if my suspect is available at first.

Theoretically what could have happened (as the MIC is validated in LoRa Server) and the payload is decrypted in LoRa App Server is that the activation of the second node wasn't fully processed yet. Thus the AppSKey was written to the PostgreSQL db in LoRa App Server, but LoRa App Server didn't reply yet to LoRa Server with the join-accept. Because of this, there was a small time in which LoRa Server still accepted data from "node1".
If that was the case, I'm not sure if anything can be done about it, as we're dealing with two data-stores that each do their separate commit.

Hi @brocaar ,
Maybe we can tag every packet between LoRa App Server and LoRa Server with version number. Once node join accept, LoRa App Server will reject this EUI's packet which version is older than join request packet.

Don't think that will make it any cleaner. Honestly, I don't think it is an issue, as long there is no real security issue. In this case both nodes share both the DevEUI and the AppKey (else you would not be able to activate the second node). Also LoRa Server doesn't support multiple nodes using the same DevEUI (as the DevEUI is used as unique ID).

En... I just post some suggestion. Maybe it's not critical like you say.


Include info about the pools which donate to LBRY.Community

:)

Maybe remove the "<- Support the community with this pool" or is this all right?

@real-rouse removed the note at the bottom, think the arrows get the point across.

okay, i'll get it updated


Need to ignore incompatible nodes.

Hi, I've noticed a problem that qualifies as a bug. I describe it here: https://forum.safenetwork.io/t/community1-test-network-is-alive-join-us/9337/77?u=bluebird The community1 network is running safe_vault 0.8.1
I'm not sure but I understand that newer versions of the software will ignore older versions, and not have any problems as a result of older, incompatible binaries trying to connect. However, it appears that in the opposite situation, of newer binaries (launchers or vaults) trying to connect to a network where an older version is the default, that the older binaries are not ignoring these attempts to connect, and the result is instability on the network. Is there at least a workaround for this until a patch can be applied?

This shouldn't really be any different between old connecting to new or new connecting to old. It's just a hash check of the field from the crust config file and if the network_name field doesn't match then the incoming connection is dropped with the message Incompatible protocol version
As you mentioned a few posts later in the forum thread, vault binaries weren't released on Thursday and this error isnt limited to vaults. This is just a handshake check done while bootstrapping for both vaults and clients(launcher).
This could have occurred if someone ran Launcher released Thursday against the community network which uses a different crust version or if someone just did not pass the correct network_name and just updated the hard_coded_contacts in the config file.
Is the issue here just that the log file is getting spammed with this message? you can maybe just disable logging from crust in that case which should keep the log files smaller but not sure if this was the only isse here.

The log file is getting spammed, grows to huge size, gets truncated (so i see only a few hours worth) and vault restarting. I'm not sure whether the restarts are connected to the log spamming.
How would you suggest to disable the messages?

yeh the restarts are what I'm wondering about. That would happen if the Routing table collapses(goes below size 8). You want to aim to keep network size at a minimum of > GROUP_SIZE

How would you suggest to disable the messages?

for this since its an error message from crust, to disable it we'd prolly need to disable crust logging pretty much. You will have a log.toml file next to safe_vault binary which if you update to:
[appender.async_console]
kind = "async_console"
pattern = "%l %d{%H:%M:%S.%f} [%M #FS#%f#FE#:%L] %m"

[[appender.async_console.filter]]
kind = "threshold"
level = "info"

[appender.async_file]
kind = "async_file"
path = "Node.log"
pattern = "%l %d{%H:%M:%S.%f} [%M #FS#%f#FE#:%L] %m"
append = false

[root]
level = "error"

[[logger]]
name = "routing"
level = "debug"
appenders = ["async_console", "async_file"]

[[logger]]
name = "safe_vault"
level = "debug"
appenders = ["async_console", "async_file"]

should have logs from crust ignored in both the console logs and file.

This is something that i am unclear on:#
The launcher presumably connects to the hard-coded vault on port 5483. If I block port 5483 at the firewall, the error messages keep coming. Why is that, and is it really a launcher that is to blame?

The solution that you propose suppresses all crust messages, which ruins my statistical collection. Is there a way to turn off that particular message only?

I just ran a compile of the master branch of safe_vault and I see thousands of these "Incompatible protocol" messages in Node.log, and I know there is only one other vault on the test network (community1 and both machines are hard-coded contacts), which happens to be running the testnet3 binary. What is worth reporting is that: 1. the problem affects the current binary when an older binary is trying to connect to it, and 2. this appears to be the same bug as originally reported above.

This crate had a major re-write/re-design. Please raise an issue again if required as almost everything in the library and the way it handled things have changed. Closing this.


Asynchronous SEGV when running in Flink job

Description
When using an instance created from a Flink job in docker, the taskmanagers (= things that execute the stream processing) die with a SEGV shortly after calling a wasm function.
Steps to reproduce
Requires a bit of setup, I've created a docker-compose based test case:
https://github.com/jcaesar/wasmer-in-flink-segv
You should be able to run it with
docker-compose -p asdf kill \
&& docker-compose -p asdf rm -vf \
&& docker-compose -p asdf up  --build --abort-on-container-exit

Actual behavior
taskmanager1_1  | *** Aborted
taskmanager1_1  | Register dump:
taskmanager1_1  |
taskmanager1_1  |  RAX:<PHONE_NUMBER>000000   RBX:<PHONE_NUMBER>000006   RCX: 00007f86f91367bb
taskmanager1_1  |  RDX:<PHONE_NUMBER>000000   RSI: 00007f8660967f10   RDI:<PHONE_NUMBER>000002
taskmanager1_1  |  RBP: 00007f86609681e0   R8 :<PHONE_NUMBER>000000   R9 : 00007f8660967f10
taskmanager1_1  |  R10:<PHONE_NUMBER>000008   R11:<PHONE_NUMBER>000246   R12: 00007f86609689b0
taskmanager1_1  |  R13: 00007f865005f070   R14:<PHONE_NUMBER>00000b   R15: 00007f85fc00e610
taskmanager1_1  |  RSP: 00007f8660967f10
taskmanager1_1  |
taskmanager1_1  |  RIP: 00007f86f91367bb   EFLAGS: 00000246
taskmanager1_1  |
taskmanager1_1  |  CS: 0033   FS: 0000   GS: 0000
taskmanager1_1  |
taskmanager1_1  |  Trap: 0000000e   Error: 00000007   OldMask: 00000404   CR2: f94ffe80
taskmanager1_1  |
taskmanager1_1  |  FPUCW: 0000037f   FPUSW: 00000000   TAG: 00000000
taskmanager1_1  |  RIP: 00000000   RDP: 00000000
taskmanager1_1  |
taskmanager1_1  |  ST(0) 0000<PHONE_NUMBER>000000   ST(1) 0000<PHONE_NUMBER>000000
taskmanager1_1  |  ST(2) 0000<PHONE_NUMBER>000000   ST(3) 0000<PHONE_NUMBER>000000
taskmanager1_1  |  ST(4) 0000<PHONE_NUMBER>000000   ST(5) 0000<PHONE_NUMBER>000000
taskmanager1_1  |  ST(6) 0000<PHONE_NUMBER>000000   ST(7) 0000<PHONE_NUMBER>000000
taskmanager1_1  |  mxcsr: 1f80
taskmanager1_1  |  XMM0:<PHONE_NUMBER>00000000000000ffffffff XMM1:<PHONE_NUMBER>00000000000000ffffffff
taskmanager1_1  |  XMM2:<PHONE_NUMBER>00000000000000ffffffff XMM3:<PHONE_NUMBER>00000000000000ffffffff
taskmanager1_1  |  XMM4:<PHONE_NUMBER>00000000000000ffffffff XMM5:<PHONE_NUMBER>00000000000000ffffffff
taskmanager1_1  |  XMM6:<PHONE_NUMBER>00000000000000ffffffff XMM7:<PHONE_NUMBER>00000000000000ffffffff
taskmanager1_1  |  XMM8:<PHONE_NUMBER>00000000000000ffffffff XMM9:<PHONE_NUMBER>00000000000000ffffffff
taskmanager1_1  |  XMM10:<PHONE_NUMBER>00000000000000ffffffff XMM11:<PHONE_NUMBER>00000000000000ffffffff
taskmanager1_1  |  XMM12:<PHONE_NUMBER>00000000000000ffffffff XMM13:<PHONE_NUMBER>00000000000000ffffffff
taskmanager1_1  |  XMM14:<PHONE_NUMBER>00000000000000ffffffff XMM15:<PHONE_NUMBER>00000000000000ffffffff
taskmanager1_1  |
taskmanager1_1  | Backtrace:
taskmanager1_1  | /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x10b)[0x7f86f91367bb]
taskmanager1_1  | /lib/x86_64-linux-gnu/libc.so.6(abort+0x121)[0x7f86f9121535]
taskmanager1_1  | /tmp/wasmer_jni7073396356486144275.lib(+0x250f07)[0x7f85d6d3cf07]
taskmanager1_1  | /tmp/wasmer_jni7073396356486144275.lib(+0x24bb46)[0x7f85d6d37b46]
taskmanager1_1  | /tmp/wasmer_jni7073396356486144275.lib(+0x9fad0)[0x7f85d6b8bad0]
taskmanager1_1  | /tmp/wasmer_jni7073396356486144275.lib(+0x9f156)[0x7f85d6b8b156]
taskmanager1_1  | /lib/x86_64-linux-gnu/libpthread.so.0(+0x12730)[0x7f86f94ee730]
taskmanager1_1  | /usr/local/openjdk-8/lib/amd64/server/libjvm.so(+0x6647a0)[0x7f86f87f47a0]
taskmanager1_1  | /usr/local/openjdk-8/lib/amd64/server/libjvm.so(+0x665744)[0x7f86f87f5744]
taskmanager1_1  | /usr/local/openjdk-8/lib/amd64/server/libjvm.so(JVM_DoPrivileged+0x2c6)[0x7f86f8855e96]
taskmanager1_1  | [0x7f86e11d0af5]

Sorry for the late reply, I missed the notification. I'm going to take a look at it.

Ah, yay! I was afraid this repository was dead from the start...
It seems this problem can even be triggered before starting the Flink job (by e.g. moving the wasmer calls to the beginning of main). Any chance it's related to the horribly outdated version of Java?

I finally wanted to know what's going on a bit better and made myself a debug build of libwasmer_jni.so to translate the symbols in the backtrace. They just came down to
/rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4//library/std/src/sys/unix/mod.rs:231
/rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4//library/std/src/process.rs:1773
/usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/wasmer-clif-backend-0.17.0/src/signal/unix.rs:147
/usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/wasmer-clif-backend-0.17.0/src/signal/unix.rs:30

this just seems to be an avverage signal handler, so I guess there is no relevant wasmer code running at the time the segv happens. Phew, looks like whoever wants to solve this is in for some rather fun debugging.

So, I tried disabling the signal handlers to get to see the "real segv".
Turns out that fixed the problem... Not sure what to make of that.
Incidentally, wasmer 1.0 doesn't have the signal handlers anymore. Wonder how this plays out when upgrading versions...

So, I tried disabling the signal handlers to get to see the "real segv".
Turns out that fixed the problem... Not sure what to make of that.
Incidentally, wasmer 1.0 doesn't have the signal handlers anymore. Wonder how this plays out when upgrading versions...

Hm, doesn't seem like migrating wasmer-java to 1.0 will be easy.
Memory wants to own the Memory, but Exports doesn't hand that over. Guess I'll stop here, before I vanish in the rabbit hole.
Y'all got this planned out?

@jcaesar Memory is clonable in Wasmer 1.0, so it should be doable I believe!

Oh, I would have assumed that would create a new copy of the actual memory area. Guess I haven't really understood the semantics. Nevertheless, I was able to construct a patch that makes wasmer-java use a current-ish wasmer master. The problem I report here disappears.
I'd throw a PR, but some of the gradle tests fail. Not sure if I'll work on that.
A serious adaptation of wasmer 1.0.0 would have to chage the Java API anyway, I guess?

Fixed in 0.3.0. (Though testing that out was a bit annoying because 0.3.0 is somehow not properly released. empty folder? wat?)

Fixed in 0.3.0. (Though testing that out was a bit annoying because 0.3.0 is somehow not properly released. empty folder? wat?)


Upgrade to Go 1.22

Upgrading to 1.22 will allow us to apply various simplificactions throughout the code, many have comments, search for /Go.*1\.22/.
It's not obvious that all of these are hard requirements, as Go binaries such as sacctd are statically linked and can be copied somewhat freely; one could build for Betzy and Fram on Fox or some other rhel9 system and copy the binary over.  (Plus sacctd should be integrated into Sonar anyway.)  The tough one is naic-monitor.  Here we could do a local install instead.

[x] Fox (has 1.22.1)
[x] Saga (has 1.22.1)
[ ] Betzy (doesn't have Go at all)
[ ] Fram (has 1.20.4 as of 28 Oct and can't compile Jobanalyzer even now)
[x] naic-monitor (rhel9, at 1.21.13 as of 28 Oct)
[x] bling (has 1.23.2)
[x] deathstar (fairly sure this has 1.23 at this point)

I think we're good, naic-monitor got an upgrade this morning (it broke logins, but at least it upgraded Go...)


Capital letters on Linux

There is a problem receiving capital letters on linux.  With shift key and  caps lock.

I just tested this under Ubuntu

is this still a problem?

@FloVanGH friendly ping on this

I will check it tomorrow.

Thanks!

Still the same issue on minifb = "0.18".


Add distinct keyword

Problem
Original issue for this is: https://github.com/noir-lang/noir/issues/1183
Happy Case
We want to add this into the new SSA code
Alternatives Considered
No response
Additional Context
No response
Would you like to submit a PR for this Issue?
No
Support Needs
No response

Just curious, why a keyword and not an ABI passed when running Noir?

why a keyword and not an ABI passed when running Noir?

What would that look like ser?

Will non-main functions use this keyword?

Good question, this will only have effect on the entry point function(s) -- I use plural here because contracts have multiple entry point functions

Closing as the distinct keyword has been merged


Issue calling possible undefined value even after test.

Why is this failing validation?  Seems like an error:
Type:
type Column = {|
    aggregator?: Array<Row> => Value
|}

Code:
columns.map(column => {
  if (!column.aggregator)
    return;
  const summaryValue = column.aggregator(map(rows, column.columnName));
  // ...
})

I get call of method aggregator`. Function cannot be called on possibly undefined value.  I can't seem to get around this unless I make the type non-optional, but it is optional.

Annoyingly, this works:
const aggregator = column.aggregator;
const summaryValue = aggregator(map(rows, column.columnName));

I believe this is due to refinement invalidation when calling the inner-most map() function. Since that is evaluated before the call to column.aggregator(), flow doesn't know if the map() function sets column.aggregator to undefined so it invalidates your prior null-check.

Thanks.  That keeps biting me.

Actually, taking a closer look at this, how could the map update column.aggregator?  It doesn't receive column as a parameter.

It’s not that the map could update it, but that for all flow knows, the closure passed to map may be called asynchronously later. When that happens arbitrarily in the future, other code may have changed the variable’s value. This is definitely kinda lame since in practice that may not happen, but it is necessary for flow to guarantee correctness when closures capture a variable. I know there is a proposal for a way to mark certain common functions that receive closures, like map, as special and always called synchronously.

I have another example of this:
      if (this.onSessionChange) {
        this.onSessionChange(privateToPublicSessionInfo(info));
      }

which results in:
 36:         this.onSessionChange(privateToPublicSessionInfo(info));
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ call of method `onSessionChange`. Function cannot be called on possibly null value
 36:         this.onSessionChange(privateToPublicSessionInfo(info));
             ^^^^^^^^^^^^^^^^^^^^ null

Using an extra assignment inside the if does not work:
      if (this.onSessionChange) {
        const d = privateToPublicSessionInfo(info);
        this.onSessionChange(d);
      }

That still generates the same error. Moving the inside before the if does work:
      const d = privateToPublicSessionInfo(info);
      if (this.onSessionChange) {
        this.onSessionChange(d);
      }


Kubelet sometimes slow to delete pods

Spinoff from a conversation on https://github.com/GoogleCloudPlatform/kubernetes/pull/9165, I haven't had the time to dig into this yet. Tl;dr version is that graceful deletion is sometimes sluggish with simple ubuntu echo pods on a lightly loaded system. https://github.com/GoogleCloudPlatform/kubernetes/pull/9165#issuecomment-108186294 indicates a possible race. Also discussed on https://github.com/GoogleCloudPlatform/kubernetes/issues/6764.

The potential cause of the slow pod deletion has been identified in #9165, and it is not related to race conditions. Once the PR is fixed and verified, we can close this issue.

Should this be closed now?

Sure.


Error in loading pre-trained models for minigames

Hi just wanted to reproduce the results reported by downloading the zip files from releases
I ran into two issues:

In the unzipped folders, there seems to be missing the config.gin files
In an attempt to resolve the first issue, I started the training for the corresponding minigame and interrupted to get the config.gin file. But loading the model checkpoints seems to give another problem, giving the error message:
Restoring from checkpoint failed. This is most likely due to a Variable name or other graph key that is missing from the checkpoint.
Could it be due to the version of tensorflow?

Thanks again!

Hello,

A dedicated config shouldn't be necessary as the model weights were trained with the provided configs (although that might have changed, will need to double check).
This is indeed probably due to updates to TF version and I will have to re-train the models from scratch. In the meantime you can use the same version of code and deps as the one used when weights were released.

Got it. Was just wondering if there would be a hack or workaround of the error. Thanks for the response.


Adds base wifi command and tests

@MrNice could you review?

@johnnyman727 I'll get it early tmw morning, sorry. Just finished a reversi app that I was assigned for a job process. https://arcane-lake-3833.herokuapp.com/ Probably the second largest job application piece I've had to do.

@MrNice I don't really know how reversi works but the premise seems to be that you can never beat the computer.

@johnnyman727 It looks good to me, but I'm not 100% clear on what the errors were. There's a few ugly things like the double catch that should be looked into.
Is there a Wiki Page on best practices for writing tests for the CLI? This PR opened my eyes to a few of the oddities therein.

@MrNice The root cause appears to be that process.exit wasn't properly being stubbed out so the actual process.exit was being called which killed the test. I'm not sure why that is the case.
Where is the double catch that you are referring to?
We don't have documentation up for CLI tests yet. I've mostly been going off of nodeunit and sinon documentation.


[OFFICIAL] Generated Issue: ConnectException

Please fill out the details below.
Summary:
Steps to reproduce:
Additional Details
Jikan Parser Version: v2.18.14@de723b4648eae7de3cf351e5c1f28992135e9223
PHP: 7.4.23
Redis: Connected
Exception: GuzzleHttp\Exception\ConnectException
Code: 0
Message: cURL error 52: Empty reply from server (see https://curl.haxx.se/libcurl/c/libcurl-errors.html)
Trace: /var/www/jikan/vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php on line 200
Request: GET /v3/search/anime?q=bungaku

Resolved.


Update test/SILGen/keypaths_objc_optional.swift for SDK availability change.

Relax the CHECK: line here to tolerate an [available] attribute on the convertObjCBoolToBool operation that was added in recent Apple SDKs. rdar://129894685

@swift-ci Please test


add messageStore, messages and conversation module to integration test phone.js

add messageStore, messages and conversation module to integration test phone.js

Coverage remained the same at 47.247% when pulling 286ea47138b1e2b5144fc64422bc3f69cfecd22c on embbnux:feature-messages-integration-test into a43bcdedc7bf9aff42283f5e4d3c733a228fea18 on ringcentral:master.

rerun

Coverage remained the same at 47.247% when pulling d2e37186375338127261bcf3452c3810429739b6 on embbnux:feature-messages-integration-test into a43bcdedc7bf9aff42283f5e4d3c733a228fea18 on ringcentral:master.

rerun

rerun

rerun

Coverage decreased (-4.2%) to 43.089% when pulling 24e5cfe70cd380455476dd91487b4da25ebef139 on embbnux:feature-messages-integration-test into a43bcdedc7bf9aff42283f5e4d3c733a228fea18 on ringcentral:master.

rerun

Coverage decreased (-4.2%) to 43.089% when pulling 1578d8e53a838164020dda4ef6042548bd3dbdc2 on embbnux:feature-messages-integration-test into a43bcdedc7bf9aff42283f5e4d3c733a228fea18 on ringcentral:master.


Zero Allocation Networking

I'm currently working on adding a Mirror+Ignorance network backend to Dissonance Voice Chat. Dissonance itself has been written to write into preallocated and recycled byte[] buffers to ensure that it doesn't allocate anything per packet (voice packets happen at a fairly high rate, so this is important).
However I'm having some difficulty actually sending these byte buffers through Mirror without allocating something somewhere!

NetworkClient:Send(short msgType, MessageBase msg) requires me to allocate a MessageBase object.
Using NetworkConnection:TransportSend(int channelId, byte[] bytes, out byte error) is also no good, I can't specify the length without copying my packet into another array of the exact size.

I also tried to pack my data into a byte[] array formatted correctly for TransportSend and this requires more allocations:

byte[] PackMessage(ushort msgType, byte[] content) requires me to pass in a byte array of precisely the right size (one allocation+copy) and then it internally allocates a NetworkWriter containing a BinaryWriter around a MemoryStream!

would you be interested in a PR which added the following:
NetworkClient:Send(short msgType, ArraySegment<byte> data) & NetworkConnection:Send(int channelId, ArraySegment<byte> data, out byte error)
This will insert the protocol bytes into the segment if there is space available. May involve a copy to shift the offset a sufficient amount, or an allocation if there is insufficient space.
NetworkConnection:TransportSend(int channelId, ArraySegment<byte> data, out byte error)
This will call the new ServerSend or ClientSend with these arguments. Exactly the same logic as the current TransportSend, just with new types.
Transport:ServerSend(int connectionId, int channelId, ArraySegment<byte>) & Transport:ClientSend(int connectionId, int channelId, ArraySegment<byte>)
These would be implemented as virtual methods which call the normal ServerSend/ClientSend, this involves a single allocation and a copy. Implementing them as virtual ensures this does not break everything which extends Transport. Network transports can override these new send methods to do the sending with zero copies if they support it - I've already submitted a PR to ignorance which shows what this would look like: https://github.com/SoftwareGuy/Ignorance/pull/16/files

are you running into serious bottlenecks because of those allocations?
original UNET tried very hard to be allocation free, which was one of their internal requirements when writing code. original UNET was able to handle around 20-50 CCU on a good day.
with Mirror we focused on simple code (we have half the LOC than UNET had), and high level / big O optimizations instead. Mirror isn't allocation free. Mirror can handle 500+ CCU.

I must admit haven't profiled it as causing problems - I'm writing this for release to all Dissonance customers, so I can't profile it on all possible devices and I'd like to make sure I don't cause any problems in the first place! The whole of Dissonance is written with zero allocations as a main design goal so it's just kind of my default way of doing things.
If you'd rather keep Mirror simple that's fair enough, that's why I asked ahead instead of submitting a PR out of the blue. If you don't want me to make the PR for these changes go ahead and close this issue :)

Hey @vis2k, we're making a product using Mirror for Android and we'd like to avoid allocations where possible.  If we can overload the API to avoid allocations and keep simplicity, that would make this far more useful on Android.  Right now it allocates too much for our particular app since we're very very frame rate sensitive in VR.

We dont have a goal of being allocations free.  We gave a goal of simplicity and performance.
When I say performance, I mean profile it and show a problem. If something does not show in the profiler it is not worth optimizing.
The way to go about this is to open a pull request, and show the profiler with a before and after for a realistic scenario.

It should be fairly trivial to show what a GC spike looks like when these allocations add up. Someone invested in this with a real implementation should do so, as opposed to a more contrived example I would create. I know what GC does at a low level (your entire app will be basically paused during collection) but I am interested to see the effects in real world apps.
Buuuut ... I'm not a big fan of slapping an ArraySegment over this as proposed. It's been discussed before, and it's not the worst idea, but in the end it's just trading one concrete implementation for another. And I'm not just dreaming of abstract perfection, I mean that neither Array nor ArraySegment will work with my transport without forcing copies (and thus allocations) between the native and managed heap.
IMHO the right long term move is an interface, so we are no longer limited to a specific implementation and also do not break the API down the road with implementation switches. A default implementation could be provided using whatever is felt to be the general case, and could support Array and ArraySegment.
Also, I know this is asking a lot from a potential PR, but it would be very helpful to have tests in place before switching something as core as this. There is a lot of code pinned on these read/write ops and it would be nice, especially for long term maintainers, to have some level of certainly it's not getting blown up. There are already some tests, and more wouldn't hurt. Especially nice would be a test that network message binary compat hasn't been broken with older Mirror versions (unsure if that exists yet)
Also also ... I think the referenced PR is glossing over a huge part of the problem, which doesn't exist at all at the transport layer. For example when reading messages (unless I'm mistaken) the NetworkReader gets the incoming messages as byte[] and constructs a new BinaryReader and MemoryStream. In fact, entire NetworkReader/Writers are allocated and left to GC. Serious love and collaboration with existing maintainers will have to go into any potential solution which aims for zero allocation.
Just my 2 cents

@GabeBigBoxVR did you try unity's new incremental garbage collector yet? that might solve your problem.

I'm not a big fan of slapping an ArraySegment over this as proposed. It's been discussed before

Interesting, could you link to any previous discussion on it? I couldn't find any with a quick search in this repo.

neither Array nor ArraySegment will work with my transport without forcing copies (and thus allocations) between the native and managed heap.

I don't agree. If a transport wants to implement sending by directly copying the contents of an ArraySegment into a socket without any allocations that's perfectly possible. Even if the transport does copy onto the native heap I don't think it's much of a problem - a single native heap allocation is often slower than a managed allocation, but you never incur the huge GC collection delay down the line. That's all besides the point though - the point of this PR is reducing allocations before it gets into the transport layer.
For a concrete example of this I already have this very simple PR open with Ignorance which directly used the data inside the array segment and passes a pointer to it down into ENet - I tracked the execution of that all the way down to the ENet FFI call and as far as I can see there isn't a single GC allocation.

I'm not just dreaming of abstract perfection

Span<byte> 🤤

IMHO the right long term move is an interface ... switching something as core as this

That's possible I guess but it vastly expands the scope of the changes. My proposal here is to add 3 new methods which would be very simple to implement (basically s/byte[].Length/ArraySegment.Count), it wouldn't involve a breaking change the public API for users of Mirror or implementors of transport layers.

glossing over a huge part of the problem

I can only fix one thing at a time in a single PR ;)
If this gets merged in and I still have time to work on the problem I will probably move on to trying to clean up receiving allocations where possible.

I've submitted #404 to clarify exactly what API changes I'm proposing here :)

Span<byte> 🤤
Not to get too sidetracked, but I only recently started with C#. To be clear you are referring to the ref struct implementation that only exists in .NET Framework as a port from .Net Core 2.1 where it was introduced. The portable version is not the same as the one in System.Private.CoreLib, and if you look into it you will find its performance characteristics considerably poorer. I find it about 4-5x slower than an array once you need to index into it.  Even if in some miracle world Unity was using .NET Core it still doesn't get me anywhere to use Span<>. There's an assumption here somewhere about where and why my memcpys are being forced, and that all network messages will always arrive and be sent through the transport in contiguous memory. But these are not everyone's or even most people's problems, I suppose. I see them only as hurdles to more tightly integrating with lower level networking libraries.

That's possible I guess but it vastly expands the scope of the changes
Totally, I get it. Hard work is hard and there are more exciting things to do. So say we all. I don't wanna make an interface in there either, man. It's way easier to just expose more API surface to handle more apt concrete implementations. And it's better than nothing.

 Something is always better than nothing, and if they reduce allocation and they are helpful for others then that is great.

I don't think we should reject this PR as from what I'm reading it's more so a case of both sides of the table have equal pros and cons, is there any killer feature or reason that would satisfy both parties?.
I do agree we need some benchmarks and/or test results, even if we use the Pong example from Mirror.

The only real con is that it increases the API surface.  A good plan today is better than a great plan tomorrow, and I agree this is a good plan today

I do agree we need some benchmarks and/or test results, even if we use the Pong example from Mirror.

I'll be happy to put together a benchmark, but what exactly do you want it to demonstrate? Would you be happy with a benchmark which shows a reduction in total allocations-per-second, or perhaps an increased time-between-collections?
Demonstrating an actual speedup in the collection pass itself will be quite difficult because there are two factors at play here - collections take a certain amount of time (based on heap complexity) and happen at a certain frequency (based on allocation rate). The point of these changes is to reduce frequency of collections, not duration of collections when they do eventually happen.

I guess in case anyone isn't entirely sure of my motivations for worrying about GC, here's an overview: every allocation pushes you closer to an inevitable GC collection which will happen eventually (unless your entire game is truly zero GC alloc, basically impossible in Unity), when it does happen there are two possibilities:

Your game is quite simple, it does not need anything close to the frame time budget (15ms for 60FPS, 11ms for 90FPS). The GC collection causes no problem because the extra time it adds to the frame isn't a problem. This is going to be any simple benchmark game.
The game is quite complex, it needs close to the frame time budget. The GC collections pushes you just over that edge and you drop one or more frames.

The reason this makes me worry (and it's hard to profile) is that I could profile the demo scene (e.g. ping pong) all day as it made heavy allocations and not see any problems, the collection passes would take under a millisecond and the game itself doesn't need even close to the remaining 15ms to render the frame. However once you move into a real game scenario the heap is much more complex (collections take longer), there are many more allocations happening in the game itself (collections happen more frequently) and the game needs more time to render a frame (spare time budget per frame is smaller). So a library such as Dissonance or Mirror allocating lots could push GC over the edge of causing problems even though it's never caused an issue in a simple benchmark scene. Even worse the problems would not be easy to track down to the library in the profiler because the large obvious delay (GC.Alloc) happens on whichever random allocation triggered the collection pass.
Hopefully this answers a few questions people have alluded to in various comments:

Why am I not worried about stack allocations (e.g. new ArraySegment)? It doesn't involve the GC.
Why am I not worried about unmanaged/native heap allocations? A single one is slower to allocate, but it never triggers a GC so amortised cost is similar (but more predictable).
What about extra copying? Copying is crazy fast, I would gladly trade in ~10 extra copies of every packet for a single reduced GC allocation.
What problem does excessive GC allocation cause? No problem at all until you get close to the frame time limit, and then it causes random frame skips (possibly multiple frames dropped at once).

Span<byte> ... to be clear you are referring to the ref struct implementation that only exists in .NET Framework as a port from .Net Core 2.1

Getting wildly off track here, but yes I'm referring to the new memory primitives introduced in dotnet Core mostly for aspcore perf (Span<> and Memory<>). Read about them here and here if you're unfamiliar with the details. I've no idea about the details of how it was ported into System.Private.CoreLib for Unity or the performance characteristics of that.

TL;DR If I put together a PR including a benchmark showing increased time between allocations will that (likely) be accepted?

Is it possible to get a new demo game for testing that can have configurable scale? 1 non player AI that is walking/turning/syncing at a known rate. then at the press of a button that can be increased to 10/100/200. That could be used as the standard for stress testing?
If done correctly that might also fit in the CI pipeline?

Read about them here and here if you're unfamiliar with the details

I am familiar with it, and the links are welcome as everyone should know about the awesome stuff in Core. AFAIK it's only available at this time by using portable assemblies dropped into Unity (System.Memory package), even though I know they have an older Corelib assembly hiding inside the Editor. But I suspect that before long we will see Unity shift off the Mono track over to Core (which other major projects are also doing). JB Evain is even working at MS right now on Unity tools. And even with performance characteristics outside Core such as they are it's quite often a win to use Span/Memory to eliminate memory copying. Also a generic buffer pool is available in MemoryPool, which is very handy in avoiding allocations.
Sadly, none of these solve my issues, but that's another story. The library should cater to broader needs and let people like me fend for themselves :D
Personally re: performance metrics I feel this is a simple, non-theoretical issue. Regardless of system specs, the GC is inevitable. The question is merely how often and how long will it run. I'd still love to see a profile of someone getting murdered by a GC spike, but it's not necessary to prove to me the issue is real. I handle IO outside managed, but for everyone who doesn't (and who is considering high concurrency or even just high throughput) this should be of particular concern. Even for myself it's not much good to send/receive IO at high speeds, but pay a latency penalty waiting for managed to read/respond.

@martindevans about GC: at the moment we are more worried about the stuff on the issue tracker, dealing with source based weaver, and so on so that we can actually release our indie games without bugs.
paul's game won't fail because of a few GC spikes here and there, neither will uMMORPG. but they both might fail if there are critical bugs that users encounter that makes the game unplayable / or the server hackable.
there is a hierarchy. for example, if you teleport back 10k years and ask a cavement if he'd like a faster computer, he'd probably ask you if you were nuts and shove you out of his way so he can find some food and not starve to death tonight.
GC matters, but stability comes first. if we transition everything to arraysegments and buffer caching again then odds are we introduce new bugs. that would a huge problem right now.

they also might fail if Paul and I have to track down strange buffer sharing bugs for the next month.

I guess you didn't actually look at the changes in the related PR? 😕
It's very simple and doesn't introduce any new buffer recycling mechanics or anything complicated/buggy like that. It's just a new public method for sending a packet that doesn't force allocations (by leaving it up to the user to supply a correctly sized buffer in the first place).

@martindevans in the very least, transport maintainers can implement this PR code directly inside their own classes that inherit from Mirror.Transport. The irony of the fact that at first I didn't want this, and then ended up arguing for it is not lost on me. You especially couldn't have known that Mirror.Transport was functioning as an interface disguised as an abstract base because of Unity weirdness (which honestly I'm still puzzling over myself). This was a good fix that addressed a real issue, and I hope its exclusion doesn't sour you on the project. This code will still be just as good a fix inside the individual transports, who would have needed to implement these API calls anyway.

in the very least, transport maintainers can implement this PR code directly inside their own classes

Yep, I've actually already submitted (and merged) a PR that does exactly this for Ignorance. Once that releases I will just have to cast the underlying transport into an instance of Ignorance and use it directly in Dissonance.

I hope its exclusion doesn't sour you on the project

It's a simple difference of opinion over priorities and I can totally understand a position of keeping things as simple as possible :)

@martindevans   I did see the PR,   I agree it is not earth shattering,  but it seems pointless without any sort of benchmark

Responding to the comment by @paulpach on related PR in Ignorance repo.

it is easy to reopen a PR, but we need to see numbers.

As I said a few comments up what kind of numbers do you want to see? I guess I can demonstrate longer times between GC collections relatively easily, but demonstrating a quicker GC collection will be quite hard (for the reasons outlined in the same comment). Are you happy with a demonstration of less frequent collections?

@martindevans  set up a server where you synchronize 1000 objects with a few network components each,  connect a few clients to it.  Connect the profiler to your server and show how long it takes to synchronize them.
See for example this: https://github.com/vis2k/Mirror/pull/299#issuecomment-459745122
Obviously your PR is not going to help per se, as by itself it does not get rid of any allocation,  but you can make a POC branch where you do the changes you have in mind and profile it.

Here's the scene/setup I used for those if you want it aswell: StressTest.zip
Can just be dropped into the Mirror/Examples folder, object visibility is only updated when you touch the slider/spawn objects
It's not 100% optimal (you probably want something more regular, less spiky for fine tuning), but it should work fine for showing significant differences


build-uki: --overlay flag  adds content to rootfs rather than the ISO

Is your feature request related to a problem? Please describe.
In order to do automated install and carry over files from the ISO we want to able to add arbitrary content to the ISO (and not the rootfs content, which would be lost between upgrades).
Describe the solution you'd like
We want this: https://github.com/kairos-io/enki/blob/be3be58a1b7cbd5c24ddd79f9384984925f9f0b2/cmd/build-iso.go#L79 in build-uki as --overlay-iso and map the current --overlay arg as --overlay-rootfs to keep compatibility
Describe alternatives you've considered

Additional context

https://github.com/kairos-io/enki/releases/tag/v0.019 contains this


Cannot find XRoadRequestHandler

Hi
I wont to try use this lib & I follow this guide http://janno-p.github.io/XRoadLib/tutorial-dotnetcore.html
but on step Service request handler creation, I have a problem. Can't find XRoadLib.Handler.

Hi,
It seems that the tutorial is a bit outdated. The missing parts that are specific to AspNetCore environment are now located in separate assembly XRoadLib.Extensions.AspNetCore. That dependency should be added via command line dotnet add package XRoadLib.Extensions.AspNetCore.
After that you should use namespace using XRoadLib.Extensions.AspNetCore instead of XRoadLib.Handlers.
I'll have to update the tutorials in some time.

Tutorial updated to match latest version of the library: http://janno-p.github.io/XRoadLib/articles/tutorials/aspnetcore.html


Implement Ability to Extract Q-factors from Eigenmode Simulations

What are the issues this pull addresses (issue numbers / links)?
Fixed issues with the earlier pull request. Now works with Q3D.
Did you add tests to cover your changes (yes/no)?
yes
Did you update the documentation accordingly (yes/no)?
yes
Did you read the CONTRIBUTING document (yes/no)?
yes
Summary
This pull request implements the ability to render and use resistive ports in Eigenmode simulations in order to find the Q-factors of resonators and to simulate other dissipative effects.
Details and comments

Included a variable in QAnsysRenderer when execute_design is called to store the solution type
After that, when create_ports is called by hfss_renderer, choose to create RLC ports if the solution type is Eigenmode
Updated add_mesh to add extra meshing to ports
Added tutorial to showcase how-to.

@ThomasGM4 : Can you please review this? Thanks

@ThomasGM4 In case all the issues have been addressed, could you please merge and close this pull request? Thanks

Hey @SamarthH , stumbled across another error while doing some tests of this PR. Pretty sure it is unrelated but wanting to make certain first.

May I ask what the error is? Thanks