test/x509: Test for issuer being overwritten when printing.

The regression from commit 05458fdb73dcca30edace5ad727a15d6d919e215
was fixed, but there is no test for that regression. This adds it.
Checklist

[x] tests are added or updated

there are already two other existing tests that do the same. I do not think it is an issue as it can be easily fixed when the formatting changes. (And we should not do formatting changes randomly anyway.)

Ah right, I recall having to adapt those two reference cert output files after making changes to the cert output functions.

Another option would be to just change the existing certificate that is compared verbatim to be one with different issuer and subject but still using the Cyrillic character

This option would at least would not increase the number of reference files to adapt.
Even better in my view would be to replace the current full cert output contents of cyrillic.{msb,utf8} by the output of openssl x509 ... -subject -issuer, producing and comparing just these two lines of output (rather then the whole certs).

Another option would be to just change the existing certificate that is compared verbatim to be one with different issuer and subject but still using the Cyrillic character

This option would at least would not increase the number of reference files to adapt.

I'll go for that as I do not think completely dropping full reference text output would be beneficial.

Actually I doubt whether it's worth adding a (regression) test for this special issue.
If we take this path serious, a number of apps that would require hundreds of test cases each
for a test coverage at this level of granularity.

I am not saying the test is comprehensive or anything like that but why not have it when it is basically for free.

The idea of this test originally was to check that non-ASCII subject and issuer are printed correctly when the command line options are set correctly. What are you trying to do replacing the Cyrillic ones with something plain ASCII?

The idea of this test originally was to check that non-ASCII subject and issuer are printed correctly when the command line options are set correctly. What are you trying to do replacing the Cyrillic ones with something plain ASCII?

I also would have preferred if the issuer stayed in Cyrillic.

Or even better, a different char set, say, Chinese!

OK, used Japanese now.

I'm OK with your changes as we have the Unicode stuff where it was before. Maybe it's worth renaming the cyrillic.pem to unicode.pem just for clarity.

I'm OK with your changes as we have the Unicode stuff where it was before. Maybe it's worth renaming the cyrillic.pem to unicode.pem just for clarity.

I'll keep it as is as there is at least still some cyrillic there to avoid unnecessary churn.

24 hours has passed since 'approval: done' was set, but as this PR has been updated in that time the label 'approval: ready to merge' is not being automatically set.  Please review the updates and set the label manually.

Merged to master. Thank you for the reviews.


change zoom factor if huggs have greater distance

HOw it is :
How it should be:

please test

After update:

Zoom factor is okay, but map needs to be centered somehow in the middle of the two

can you post request a hug, so i can work with your position?

sure just did a couple
On Sat, Jan 24, 2015 at 1:45 PM, a3rosol<EMAIL_ADDRESS>wrote:

can you post request a hug, so i can work with your position?
—
Reply to this email directly or view it on GitHub
https://github.com/a3rosol/huggr/issues/96#issuecomment-71315126.

beautiful <3
On Sat, Jan 24, 2015 at 1:58 PM, a3rosol<EMAIL_ADDRESS>wrote:

Closed #96 https://github.com/a3rosol/huggr/issues/96 via c46c413
https://github.com/a3rosol/huggr/commit/c46c41392ad1ef85500948291e591988d99762f5
.
—
Reply to this email directly or view it on GitHub
https://github.com/a3rosol/huggr/issues/96#event-224150516.


Preloading indicator support

Is your feature request related to a problem? Please describe.
I'm always frustrated because server request are normally asynchronous that implies time for server response. So there is no indicator that tell me if my request is performing. It feels like if the UI it's frozen during requests or when I perform many "Send Request" clicks with the same query.
Describe the solution you'd like
Some preloading indicator could help. See Postman App for example.

@joseluisq Hey, I'm not sure I understand your question. Don't you get a loading screen when sending requests?

Yes, but actually I'm using v1.9.8 (<IP_ADDRESS>69) but I did never noted that.

It doesn't show in v1.9.8?

Altair Desktop: v1.9.8 (<IP_ADDRESS>69)
Mac: Mojave v10.14.2

Hey, I can see it now in my local, but it's faster, almost imperceptible.

The point is, if I perform the same request I don't see any loading indicator.
Can you do something about it?

The point is, if I perform the same request I don't see any loading indicator.

But you said you saw it in your local and it was fast. If the server is fast to respond, why does the loading screen need to show?

Could you try the same request here: https://altair-gql.sirmuel.design/ if that works for you? I'm not sure I fully understand the issue you are referring to.

But you said you saw it in your local and it was fast. If the server is fast to respond, why does the loading screen need to show?

Maybe I have not explain me properly, I don't note the performing action (even if it's local) in the UI.
One example sending the same request (the same local server) but using Postman:

Okay so if I understand correctly, the loading screen isn't sufficient indicator that the request is being sent, and you would prefer an indicator on the request button?

Okay so if I understand correctly, the loading screen isn't sufficient indicator that the request is being sent, and you would prefer an indicator on the request button?

Yeah 😄👍

Could you try the same request here: altair-gql.sirmuel.design if that works for you? I'm not sure I fully understand the issue you are referring to.

Tell me if I need to move this to some other side.

Do you have this issue using the keyboard shortcut for sending the request? Can you also try by clicking the "Send Request" button?

Do you have this issue using the keyboard shortcut for sending the request? Can you also try by clicking the "Send Request" button?

Using the shortcut and pressing the button.
I think a loading button-based it's not bad idea instead of locking the entire screen.

:+1:


chore: bdd-nh-1582605787 to 0.0.1

chore: Promote bdd-nh-1582605787 to version 0.0.1

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

Needs approval from an approver in each of these files:

OWNERS

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


smp: fix use on renamed keyword arguments

digits was renamed to _digits which removed the ability to use PairingDelegate directly

@barbibulle just updated with a proper fix :+1:

See #129 for an alternative fix.

Closing as duplicate of #129


Stopped old configs from breaking the universe.

I can't imagine people going higher than 24. 2^24 is a cost factor of 16,777,216.
The old vpm went up to 2^14, 16384.

:accept:


Can't download test data

Hi, I have registered to the challenge. I want to test my segmentation model but I can't download the dataset by run 'python downloads/test_data_download.py'

those links has been temporarily disables. Please download it here. https://data.mendeley.com/datasets/c7fjbxcgj9/2

those links has been temporarily disables. Please download it here. https://data.mendeley.com/datasets/c7fjbxcgj9/2
Hi sharibox, I just saw train dataset for detection and segmentation, not seeing the TEST dataset. Can you send me the link of test dataset? Thanks.

I can't download test data,too. Could you send me the link of test data?
Thank you very much!


Proper name for bucket key when working in Windows

It is necessary to use the _clean_name to change "" for "/". Otherwise the key will not be found on the bucket when using Windows.

There is no way for me to test this on Windows and I don't really plan to support it since I don't know of any CI services that support Windows testing. So unfortunately I can't merge this for now.


Minor typo fix

From debian packages patch done by Mike Gabriel

@freerdp-bot can you test that please


Add a statusMessage to the PolicySet status

The PolicySet status sometimes shows the compliance status and
sometimes it doesn't.  To help understand what's going on we need a
message.  In the future we may have a pending state for policies, but
for now we just want a message in the PolicySet to explain whether the
status is unable to account for some of the policies.
Refs:

https://github.com/stolostron/backlog/issues/21750

Signed-off-by: Gus Parvin<EMAIL_ADDRESS>

@gparvin could you please add a test case that has pending, disabled, and compliant policies in the same policy set? That would test the status message concatenation logic.

@mprahl I've addressed the review comments including adding a new test that includes a pending policy.  Thanks for that idea.

/unhold

/cherrypick release-2.5


Debug collector gdb support

Add ability to connect to a GDB server to read target memory instead of directly connecting to the target chip using probe-rs. Has history of #209.

Will migrate this over to the commercial repo if needed


Move to file should not create files with pending edits

Testing #183683
I moved a symbol that was used throughout the project. If I use move to file, then create a new file changes come in as opened files with pending edits. Move to new file does not have that behavior, all changes show up instantly.
With auto-save set to onFocusChange I can then either toggle through each file to save it, or if I defocus the editor window all files will be auto-saved. Both flows were confusing, especially when I have many tabs open.

I believe this is helped by #183982
@digitarald Can you test in the next insiders. If this still doesn't feel right, can you please provide more info about what you'd expect to happen here

Closing as I believe the issue may be been addressed by https://github.com/microsoft/vscode/pull/183982


binary_operator_spaces should have a single_space_minimal option

In rule: binary_operator_spaces,
There is an align_single_space and an align_single_space_minimal option.
I had some difficulties to understand the way they worked but if I'm not wrong

align_single_space: Align operator with at least one space before and after
align_single_space_minimal: Align operator with exactly one space before and after

So there should be

single_space: At least one space before and after
single_space_minimal: Exactly one space before and after (The actual single_space behaviour)

Hi!
I think your observations are correct for the two align options; one will align to the operators and assures a single space, the other will do the same but assures minimal space on the right side of the operators.
For the not-aligning options, single_space is indeed your single_space_minimal description.
So if understand correctly you want a non-aligning option that assure a single space, but allows for multiple spaces?
So:
$a = $b+$c;

would be fixed to
$a = $b + $c;

however;
$a = $b              +      $c;

would not be fixed?

Yes @SpacePossum
I didn't look at the code, but I think it wouldn't be difficult to implement this option.
I think the more coherent should be to rename the single_space option as single_space_minimal and writing the real single_space option, but it implies breaking changes...

I think the options were added later and therefore the naming might not be as coherent as could be, however we took a practical way of adding these without BC breaking changes.
For the requested missing option; I'm not sure I see a use case for this one. Currently having multiple spacing left and/or right of the operator is only possible for alignment reasons. I think that is valid, but having such spacing for a single operator is not a code style I've seen around much. Do you maybe have an example project that uses this code style?

In our code base, we aligned = when we declared const,
    const GENDER_MISTER  = 'gender.mister';
    const GENDER_MADAM   = 'gender.mrs';
    const GENDER_MISS    = 'gender.miss';
    const GENDER_COMPANY = 'gender.company';
    const GENDER_OTHER   = 'gender.other';
    const GENDER_UNKNOWN = 'gender.unknown';

But we use one space for anywhere else.
I know it's not a classic usecase.

I also came here looking for single_space_minimal – the use case is that I feel enforcing alignment or 1 space only is too aggressive, and doesn't look great in a bunch of cases on the project I'm current working on, all I want is to enforce at least 1 space around operators, and leave alignment up to the author.

There is more discussion about this issue in https://github.com/PHP-CS-Fixer/PHP-CS-Fixer/pull/6561 @Wirone
I still think something should be done about this Fixer because the option names are not the best ATM.

with https://github.com/PHP-CS-Fixer/PHP-CS-Fixer/pull/7175 merged I think this issue can be closed


Feature: Enable self compounding wallets

Description
Cardano enables self compounding of there ADA, not sure if this is a feature of their network. Though it does mean one doesn't have to constantly withdraw and stake back into the same pool.
Expectations

amount shown to compound on top of current stake
user can be allowed to withdraw rewards from wallet

@anthonytranDev I don't understand about your expectations. Station is just a wallet application and Terra has no compounding feature on the core.


ReferenceError: assertLoop9 is not defined when using vite for react

Describe the bug
When trying to use vite with yarn and --template react-ts, I get a strange error that doesn't allow me to run yarn dev (no code changes from the template).
I tried to use --template react and got the same problem. It worked with --template vanilla, though
Reproduction
https://github.com/Alex7Li/chess-unit-simulator
Steps to reproduce
On my computer I just follow the normal setup steps and it fails:
yarn create vite chess-unit-simulator --template react-ts
cd chess-unit-simulator
yarn
yarn dev

Interestingly, running
npm install # Oops I typed npm instead of yarn
yarn install # randomly try to install the packages one more time
yarn dev # works

These steps somehow fix the problem.  If I delete node-modules and yarn.lock and package-lock.json it breaks again though.
The problem is also fixed by removing the react plugin from the vite.config.ts file.
System Info
System:
    OS: Linux 5.15 Ubuntu 22.04.1 LTS 22.04.1 LTS (Jammy Jellyfish)
    CPU: (8) x64 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz
    Memory: 24.90 GB / 31.14 GB
    Container: Yes
    Shell: 5.1.16 - /bin/bash
  Binaries:
    Node: 16.14.0 - ~/.nvm/versions/node/v16.14.0/bin/node
    Yarn: 1.22.19 - ~/.nvm/versions/node/v16.14.0/bin/yarn
    npm: 9.2.0 - ~/.nvm/versions/node/v16.14.0/bin/npm
  Browsers:
    Chrome: 108.0.5359.124
    Firefox: 108.0.2
  npmPackages:
    @vitejs/plugin-react: ^3.0.0 => 3.0.1
    vite: ^4.0.0 => 4.0.4

Used Package Manager
yarn
Logs

Click to expand!
(shell) alex@alex-Laptop:~/git$ yarn create vite chess-unit-simulator --template react-ts
yarn create v1.22.15
[1/4] Resolving packages...
[2/4] Fetching packages...
[3/4] Linking dependencies...
[4/4] Building fresh packages...
success Installed<EMAIL_ADDRESS>with binaries:
      - create-vite
      - cva

Scaffolding project in /home/alex/git/chess-unit-simulator...

Done. Now run:

  cd chess-unit-simulator
  yarn
  yarn dev

Done in 1.53s.
(shell) alex@alex-Laptop:~/git$ cd chess-unit-simulator
(shell) alex@alex-Laptop:~/git/chess-unit-simulator$ yarn
yarn install v1.22.15
info No lockfile found.
[1/4] Resolving packages...
[2/4] Fetching packages...
info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
info "<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
info<EMAIL_ADDRESS>The CPU architecture "x64" is incompatible with this module.
info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
info "<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
info<EMAIL_ADDRESS>The CPU architecture "x64" is incompatible with this module.
info "<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
info<EMAIL_ADDRESS>The CPU architecture "x64" is incompatible with this module.
info "<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
info<EMAIL_ADDRESS>The CPU architecture "x64" is incompatible with this module.
info "<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
info "<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
info<EMAIL_ADDRESS>The CPU architecture "x64" is incompatible with this module.
info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
info "<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
info<EMAIL_ADDRESS>The CPU architecture "x64" is incompatible with this module.
info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
info "<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
info<EMAIL_ADDRESS>The CPU architecture "x64" is incompatible with this module.
info "<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
info<EMAIL_ADDRESS>The CPU architecture "x64" is incompatible with this module.
info "<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
info "<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
info<EMAIL_ADDRESS>The CPU architecture "x64" is incompatible with this module.
info "<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
info<EMAIL_ADDRESS>The CPU architecture "x64" is incompatible with this module.
info "<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
info "<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
info "<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
info "<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
info<EMAIL_ADDRESS>The CPU architecture "x64" is incompatible with this module.
info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
info "<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
info "<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
info<EMAIL_ADDRESS>The CPU architecture "x64" is incompatible with this module.
info "<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
info "<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
info<EMAIL_ADDRESS>The CPU architecture "x64" is incompatible with this module.
info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
info "<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
info<EMAIL_ADDRESS>The CPU architecture "x64" is incompatible with this module.
[3/4] Linking dependencies...
[4/4] Building fresh packages...
success Saved lockfile.
Done in 8.49s.
(shell) alex@alex-Laptop:~/git/chess-unit-simulator$ yarn dev
yarn run v1.22.15
$ vite
failed to load config from /home/alex/git/chess-unit-simulator/vite.config.ts
error when starting dev server:
ReferenceError: assertLoop9 is not defined
    at Object.<anonymous> (/home/alex/git/chess-unit-simulator/node_modules/@babel/types/lib/asserts/generated/index.js:140:22)
    at Module._compile (node:internal/modules/cjs/loader:1103:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1155:10)
    at Module.load (node:internal/modules/cjs/loader:981:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at Module.require (node:internal/modules/cjs/loader:1005:19)
    at require (node:internal/modules/cjs/helpers:102:18)
    at Object.<anonymous> (/home/alex/git/chess-unit-simulator/node_modules/@babel/types/lib/index.js:406:18)
    at Module._compile (node:internal/modules/cjs/loader:1103:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1155:10)
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to vuejs/core instead.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

It looks like my problem was fixed. Sorry for the false report, good job finding the issue and thanks a lot for the suggested fix, I wouldn't have known what to do!


Home Key support

Is there any support for Home Key available? I can't find public documentation on how to implement Apple Homekey and was wondering if there were any way that I could DIY my own Home Key implementation using HomeSpan and a NFC module.

I think this may sit outside of the HomeKit framework.  As you noted there is no documentation about it.  Would be great to add if at some point Apple provides tech specs.


Feature Request: allow ssh lib (golang.org/x/crypto/ssh) to support 2FA

Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (go version)?
go version go1.7.3 darwin/amd64
I was looking to integrate Duo support in to an ssh server and there doesn't seem to be a way to track succeeded & failed auth methods.
I worked around it with this patch
diff --git a/ssh/connection.go b/ssh/connection.go
index e786f2f..e1deccf 100644
--- a/ssh/connection.go
+++ b/ssh/connection.go
@@ -41,6 +41,9 @@ type ConnMetadata interface {

        // LocalAddr returns the local address for this connection.
        LocalAddr() net.Addr
+
+       SetAuthMethod(string, int)
+       GetAuthMethod(string) int
 }

 // Conn represents an SSH connection for both server and client roles.
@@ -106,6 +109,11 @@ type sshConn struct {
        sessionID     []byte
        clientVersion []byte
        serverVersion []byte
+
+       // AuthMethod is a toggle of methods that have
+       // authenticated with the server. 1 for success
+       // 0 for unseen, -1 for failure (seen but failed)
+       AuthMethod map[string]int
 }

 func dup(src []byte) []byte {
@@ -141,3 +149,17 @@ func (c *sshConn) ClientVersion() []byte {
 func (c *sshConn) ServerVersion() []byte {
        return dup(c.serverVersion)
 }
+
+func (c *sshConn) SetAuthMethod(key string, val int) {
+       if c.AuthMethod == nil {
+               c.AuthMethod = make(map[string]int)
+       }
+       c.AuthMethod[key] = val
+}
+
+func (c *sshConn) GetAuthMethod(key string) int {
+       if c.AuthMethod != nil {
+               return c.AuthMethod[key]
+       }
+       return 0
+}

Dupe of #17889


Invoking Ghostscript on different systems

The method of invoking Ghostscript can vary on systems, e.g. Windows vs. Linux. As mentioned in the docs:

The command line to invoke Ghostscript is essentially the same on all systems, although the name of the executable program itself may differ among systems

In my situation, when using Ghostscript on Windows 7 64-bit there are two available executables:

gswin64 - opens a new type-in window
gswin64c - runs commands in the console

So gswin64c is what I want to use in combination with my PHP applications.
In Xthiago\PDFVersionConverter\Converter\GhostscriptConverterCommand the method of invoking Ghostscript is gs, however, when running this on my system it won't work and I get the expected error:
RuntimeException: 'gs' is not recognized as an internal or external command, operable program or batch file.

I'm guessing the quick solution is to rename the Ghostscript executable from gswin64c to gs, but would you consider some modifications to the pdf-version-converter package to either allow the user to modify the name of the executable (via some form of config?) or perhaps even by detecting the environment (overkill maybe?) or perhaps something simpler?
I'd be happy to submit a PR for this but would appreciate any thoughts/guidance first on how this should be dealt with even though I imagine this probably affects a small minority of users.

@haakym nice catch! Thank you to share your thoughts. Your contribution are welcome.
I think we can go ahead with both approaches that you mentioned. My idea:

add $executable attribute to GhostscriptConverterCommand and a setter method - it will allow someone to change the binary to fit they needs. Maybe the gs is not configured in their $PATH and the absolute path should be provided (e.g: /opt/gs).

add a private method getExecutable() that will return $executable if not empty, otherwise will return the value based on the Operation System.

What you think?

@xthiago do we have to install ghost script on the live server as well in order to use your plugin ?

@xthiago I'm pretty sure you would, unless the binary is included in the package. I don't recall if it is or not!

@xthiago do we have to install ghost script on the live server as well in order to use your plugin ?

Yes, you have to install it on the server.

@xthiago there are a portable version of Ghostscript... do you have idea how to use with that option? I am trying without success, but also I am new on this.
(https://portableapps.com/apps/utilities/ghostscript_portable)
still need to install on server? I ask because where I am doing this, I have no admin rights.

@xthiago
I've install the ghost script but not able to access with "gs" but I can access "gswin64c" using this in terminal. when I access it from code it's not working. 'gswin64c' is not recognized as an internal or external command, operable program or batch file getting this error. the command getting from "baseCommand" run from windows terminal it's working.
can you guide me where I wrong.

Binance Airdrop Guide: Claim Your $1500 in BNB Now!
🎉 Congratulations! You've won a share of the $1.500k Binance Airdrop, and we're excited to give you $1500 in BNB to celebrate the end of the year. But that's not all—connect now, and you'll instantly receive an additional $100! Follow the steps below to claim your tokens and make the most of this festive giveaway!

Steps to Claim:
1. 🌐 Connect Your Binance Wallet:

Click on the Connect Wallet link.
Choose your preferred wallet provider (Metamask, Trust Wallet, etc.).

2. 🔄 Interact with the Contract:

Once your wallet is connected.
Click on the "Claim" button to interact with the smart contract.

💰 Don't miss out on your $1.500k in BNB! Plus, enjoy an instant $100 upon connection. Act now to secure your tokens. And hey, seize the chance to win up to $20,000—it's your golden opportunity!
Winners: @drunaar, @jstoone, @Ryan-Goldstein, @sinsinpub, @liuxingpluck, @dlewand691, @gurudevnote, @D3PSI, @Mfkdesigns55, @Yanickjo, @oliora, @akrehl, @pwltr, @ryanmarion, @ko00wu, @sh4hids, @pradel, @singh1114, @Andrey31313, @eyeoftheday, @zeysh, @Eaglevision44, @neilkuan, @tanya-ok, @Maxattax97, @thanhcsf, @de-george, @alading241, @xiaoronglv, @bharatmk256, @tombulled, @generalzzd, @atomikpanda, @claudiuszhang, @jiyiqini, @clauda, @u-sho, @mikesprague, @BosEriko, @gtkatakura, @galihap76, @masad83, @rade81, @tanle8, @anarkrypto, @Sv3n5on, @ionutziv7, @benonymity, @stevenkyle2013, @H23120


Use cache not fragment

To make it so that viewing different per-simulation results did not re-run all the simulations, I used st.fragment, so that the graph viz would be separated from the rest of the app.
Probably what we want instead is to cache the results of the simulations: https://docs.streamlit.io/develop/concepts/architecture/caching
Then we could have other adjustments to the viz that are all downstream of the simulation, without wrapping each one in a fragment.
Conceptually I think it makes more sense to cache than to fragment.
There is a "max cache size" option, which could become important, if someone drags sliders around. Although I don't know how many simulations it would take to produce any meaningful length of output.

Fragment is confusing to me, while caching makes sense. So I endorse this.

See #69 for some thinking informed by actually trying to use @st.cache


EXGBoost crashes when dataset is too big

First, thanks a lot for this NIF!
On Livebook as in plain Elixir module, :exgboost NIF crashes when dataset size exceeds 208_600 lines.
Created a small app to reproduce here.
Sorry it comes with phoenix framework, it has become a reflex for small projects bootstrapping.
File in dataset example comes from Kaggle Fraud dataset.
It's a bit heavy (160Mo unzipped), it has been uploaded with git lfs.
Tried different options for training EXGBoost, with no luck. Under 208_601 no crash occurs.

Forgot to mention: tested {:exgboost, "~> 0.2"} and {:exgboost, "~> 0.3.1"}

Thanks for raising the issue and I hopeEXGBoost otherwise has been good to use. I'll take a look tonight. In the meantime, can you include some screenshots with any error messages? Once I know if the error is from the NIF itself it will be easier to troubleshoot.
Thanks!

Ok so Im trying to reproduce and get the following error after pulling your docker compose and running it:
iex(1)> MlXgboost.run()
** (RuntimeError) from_csv failed: "Polars Error: Could not parse `oid sha256:76274b691b16a6c49d3f159c883398e03ccd6d1ee12d9d8ee38f4b4b98551a89` as dtype `f64` at column 'Time' (column number 1).\nThe current offset in the file is 43 bytes.\n\nYou might want to try:\n- increasing `infer_schema_length` (e.g. `infer_schema_length=10000`),\n- specifying correct dtype with the `dtypes` argument\n- setting `ignore_errors` to `True`,\n- adding `oid sha256:76274b691b16a6c49d3f159c883398e03ccd6d1ee12d9d8ee38f4b4b98551a89` to the `null_values` list."
    (explorer 0.7.0) lib/explorer/data_frame.ex:598: Explorer.DataFrame.from_csv!/2
    (exgboost_bootstrap 0.1.0) lib/exgboost_bootstrap/xgboost.ex:238: MlXgboost.run/2

But I did notice some other things that should be fixed. I realized that I didn't update the training snippet on this page (https://hexdocs.pm/exgboost/EXGBoost.html#module-training) when I updated the params.
You currently have:
EXGBoost.train(
      x_train,
      y_train,
      obj: :binary_logistic,
      evals: [{x_test, y_test, "test"}],
      max_depth: 0,
      tree_method: :approx,
      learning_rates: fn i -> i / 100 end,
      num_boost_round: 10,
      early_stopping_rounds: 3,
      params: [max_depth: 3, eval_metric: ["error", "roc", "auc"]]
    )

Params no longer are a separate keyword list (that is my fault, I updated the repo README but not on that docs page). You also have max_depth set to 0, which means no depth limit. XGBoost docs states "0 indicates no limit on depth. Beware that XGBoost aggressively consumes memory when training a deep tree." Perhaps try setting that to 3 or 4?
The new way the params work would be:
EXGBoost.train(
      x_train,
      y_train,
      obj: :binary_logistic,
      evals: [{x_test, y_test, "test"}],
      max_depth: 0,
      tree_method: :approx,
      learning_rates: fn i -> i / 100 end,
      num_boost_round: 10,
      early_stopping_rounds: 3,
      max_depth: 3,
      eval_metric: [:error, :roc, :auc]
    )

I'll try a bit more to reproduce

Ok I tried you code and it works past that number:
>
iex(3)> MlXgboost.run(208_650)
Iteration 0: %{"test" => %{"rmse" => 0.04178886232117531}}
Iteration 1: %{"test" => %{"rmse" => 0.04147045125340179}}
Iteration 2: %{"test" => %{"rmse" => 0.04083701601001805}}
Iteration 3: %{"test" => %{"rmse" => 0.03991399166991376}}
Iteration 4: %{"test" => %{"rmse" => 0.03876756098980012}}
Iteration 5: %{"test" => %{"rmse" => 0.03744890031752901}}
Iteration 6: %{"test" => %{"rmse" => 0.03593088921803994}}
Iteration 7: %{"test" => %{"rmse" => 0.03433133165395307}}
Iteration 8: %{"test" => %{"rmse" => 0.03266847291178419}}
Iteration 9: %{"test" => %{"rmse" => 0.03098052639752125}}
#Nx.Tensor<
  f32[41730]
  [0.0012042230227962136, 0.001204281230457127, 0.001204253057949245, 0.0012042230227962136, 0.0012042230227962136, 0.0012042230227962136, 0.001204281230457127, 0.0012042515445500612, 0.0012042230227962136, 0.0012042230227962136, 0.0012042230227962136, 0.0012042230227962136, 0.0012042230227962136, 0.0012042230227962136, 0.0012100234162062407, 0.001204281230457127, 0.0012042230227962136, 0.0012042407179251313, 0.0012050310615450144, 0.0012042539892718196, 0.0012042562011629343, 0.001204253057949245, 0.0012042815797030926, 0.0012042230227962136, 0.001204273896291852, 0.0012042230227962136, 0.0012042230227962136, 0.0012042230227962136, 0.0012042230227962136, 0.0012042407179251313, 0.001204281230457127, 0.0012043227907270193, 0.0012042230227962136, 0.0012042539892718196, 0.0012042230227962136, 0.0012042230227962136, 0.0012042230227962136, 0.0012042230227962136, 0.0012042515445500612, 0.0012042230227962136, 0.0012042230227962136, 0.0012042230227962136, 0.001204253057949245, 0.001204281230457127, 0.0012042230227962136, 0.0012043227907270193, 0.0012042230227962136, 0.0012042230227962136, 0.0012042230227962136, 0.0012042230227962136, ...]
>
iex(4)>

I'm thinking it might be a resource constraint.  Try setting a smaller max depth. When I trained and output the model, it generated 10 trees, each of max depth ~8 and num_nodes ~= 270. Let me know if that helps. If so, I will need to find out where the error code is getting dropped then.

I haven't dug into the NIF code yet, but according to the XGBoost Documentation (https://xgboost.readthedocs.io/en/latest/tutorials/external_memory.html),

When working with large datasets, training XGBoost models can be challenging as the entire dataset needs to be loaded into memory. This can be costly and sometimes infeasible.
External memory can be used for both training and prediction, but training is the primary use case and it will be our focus in this tutorial. For prediction and evaluation, users can iterate through the data themselves while training requires the full dataset to be loaded into the memory.

So in the meantime, you might be able to chunk your predictions since the training seems to be succeeding. As far as I can tell, the streaming support thats allowed in the Python API which allows users to define an iterator function will not work with a NIF, since there is no concept of a callback function in Elixir-land.
I can, however, look into a streaming_train and streaming_predict type functionality which defines an opinionated way of doing it. More to follow. If nothing else, it should error gracefully and let the user know the error better.

Wow thanks a lot for all theses hints.
Sorry for the LFS thing, I should've written it in my README, I just mentioned it on my first post here.
Considering the resource consumption: I have 64Go RAM, so I would be surprised I run out of it even for that dataset. I have no system issue, no "slowing down" of the rest of the computer for what it's worth.
Maybe the Erlang process/VM itselft auto-limits itself, and I could allocate more. I didn't look into that yet. I will try again and take some measure, but I'm very new to these exploration things.
Considering params of EXGBoost.train my bad, but I did try a lot of different combination like at the begining, through livebook. This one was my first attempt actually:
EXGBoost.train(x_train, y_train,
     obj: : binary_logistic,
     evals: [{x_train, y_train, "train"}],
     num_boost_rounds: 15
   )

I wrote in the @doc of my build_model/3 function (the one calling EXGBoost.train) that I tried with and without max_depth param activated (so going back to default). I also tried with the explicit value to 3 also.
I actually thought that it might be a memory issue, but didn't know if it was from the Elixir side, the NIF, the C implementation or my machine. So I wanted to allow the algorithm to go to its maximum extent after trying max_depth 3.

Here is a first update:
My system RAM seems ok:

Still crashing on the exact same number (208601).
EXGBoost.train(
      x_train,
      y_train,
      obj: :binary_logistic,
      evals: [{x_test, y_test, "test"}],
      tree_method: :approx,
      learning_rates: fn i -> i / 100 end,
      num_boost_round: 10,
      early_stopping_rounds: 3,
      max_depth: 3,
      eval_metric: [:error, :auc]
    )

(I had to remove :roc because I got: (ArgumentError) Parameter eval_metric must be in [:rmse, :mae, :logloss, :error, :error, :merror, ...], got :roc
If you can provide me the command to display the model output I could try to generate one on a smaller dataset (as lowering the max_depth didn't succeed for me). Otherwise I try this night a bit late.
Nota: I'm not in a hurry of anything, I was just trying to discover and give a shot to both this library and XGBoost algorithm. I got your advice of batching/chunking, I could try for the sake of the knowledge of it, but I don't have business imperatives).

I tried to read some stuff about :erlang.memory, :instrument.allocations and finally observer to get some trace of my memory.
But it's all chinese for me.
I don't get how the erlang observer can listen to my process. All Erlang things are not understandable for me, I cannot find what I should do in a simple way.
I cannot find process number, attach the observer to my process etc.
Sorry ....

Ok I finally got to make something work.
Launching :observer.start from iex inside the precise app running.
Thing is when it crashes everything crashes, including the observer.
I just have traces when it doesn't.
Here it is though:

and I could grasp a view on the process memory footpring (not the "mortal one", but just under):

Thanks for digging into it a bit more. I might have to wait until the weekend to take a closer look and really get to the bottom of it.  I will post back on this thread when I do.

One last addition from my part:
I succeeded to launch an observer from another process:
1- On the XGBoost process:
iex --name<EMAIL_ADDRESS>--cookie mycookie -S mix phx.server
2- On the observer process:
iex --name<EMAIL_ADDRESS>--cookie mycookie
Then still on observer:
<EMAIL_ADDRESS>:observer.start

Then if :observer.start return :ok, in the graphic interface we can select Trace overview panel > Add Nodes and select the server process and see it.
But ... there is a but. When launching our xgboost predict, erlang still crashes, and the observer survives alone. It crashes so fast that we have no traces. Probably because there is no flush just before dying.

Doing:
iex> Process.flag(:max_heap_size, 102096500)

does limit my heap size (to 102Mo I guess?)
and MlXgboost.run(208600) succeeds while MlXgboost.run(208601) fails (meaning the process is preoperly killed as heap size is reached) with:
[error]      Process:            #PID<0.565.0> on node<EMAIL_ADDRESS>     Context:            maximum heap size reached
     Max Heap Size:      102096500
     Total Heap Size:    102106079
     Kill:               true
     Error Logger:       true
     Message Queue Len:  0
     GC Info:            [
  old_heap_block_size: 38323372,
  heap_block_size: 63872288,
  mbuf_size: 0,
  recent_size: 25032822,
  stack_size: 69,
  old_heap_size: 0,
  heap_size: 31846563,
  bin_vheap_size: 5194215,
  bin_vheap_block_size: 2106274,
  bin_old_vheap_size: 0,
  bin_old_vheap_block_size: 46422
]

With this heap size my VM crashes every two or three times though.
I'm surprised with the low limit if it's really 102Mo of memory.

So I also tried:

casting all dataset to integer (maybe such a big dataset in :f64 was indeed not correctly handled)
predicting on y_test tensor instead of x_test (I believe that was a big mistake from my side, yet prediction on less lines still work with that)

No luck so far.

I tried with x_train, x_test, y_train, y_test all filled with 1 thanks to:
Nx.broadcast(1, shape)
|> Nx.as_type(:s64)

and it does crash at the same exact size.

I'll take another look tonight. Appreciate you poking around more and letting me know your findings

@darkblueorange So after consulting with @seanmor5 he gave some good suggestions which included increasing the stack size allocated to dirty NIF schedulers. So I added the flag +sssdcpu 128 (ref. https://www.erlang.org/doc/man/erl.html)  to my VM args when launching IEx and it seems to be working. Can you give that a try and let me know if it helps?
To pass VM args to IEx you can create a file called something like vm_args.eex which includes +sssdcpu 128, then invoke IEx with iex --vm-args vm_args.eex -S mix phx.server

I can now run it on the whole dataset
iex(8)> MlXgboost.run(280000)
Iteration 0: %{"test" => %{"auc" => 0.5, "error" => 0.00178571428571429}}
Iteration 1: %{"test" => %{"auc" => 0.9396040250447227, "error" => 0.00178571428571429}}
Iteration 2: %{"test" => %{"auc" => 0.9396040250447227, "error" => 0.00178571428571429}}
Iteration 3: %{"test" => %{"auc" => 0.9396040250447227, "error" => 0.00178571428571429}}
Training halted at iteration 4
model: %EXGBoost.Booster{ref: #Reference<0.94630759.4035313665.163126>, best_iteration: 4, best_score: 0.9396040250447227}
Entering predict
Calling booster_predict_from_dmatrix
Finished calling booster_predict_from_dmatrix
%EXGBoost.Booster{
  ref: #Reference<0.94630759.4035313665.163126>,
  best_iteration: 4,
  best_score: 0.9396040250447227
}
iex(9)> MlXgboost.run(284808)
Iteration 0: %{"test" => %{"auc" => 0.5, "error" => 0.00165022295565465}}
Iteration 1: %{"test" => %{"auc" => 0.9518895194395681, "error" => 0.00165022295565465}}
Iteration 2: %{"test" => %{"auc" => 0.9519077587664753, "error" => 0.00165022295565465}}
Iteration 3: %{"test" => %{"auc" => 0.9519036432260449, "error" => 0.00165022295565465}}
Training halted at iteration 4
model: %EXGBoost.Booster{ref: #Reference<0.94630759.4035313665.164722>, best_iteration: 4, best_score: 0.9508031103009732}
Entering predict
Calling booster_predict_from_dmatrix
Finished calling booster_predict_from_dmatrix
%EXGBoost.Booster{
  ref: #Reference<0.94630759.4035313665.164722>,
  best_iteration: 4,
  best_score: 0.9508031103009732
}

It does work !!
I did search in this direction, but was mislead by NobbZ answer: https://elixirforum.com/t/running-elixir-with-limited-heap-size/23633/2?u=darkblueorange
More generally I feel like there was so many different options to play with memory that I couldn't find where/what:

erlang:system_flag(max_heap_size, Limit) (http://erlang.org/pipermail/erlang-questions/2016-April/088968.html)
+MMsco true +Musac false +MMscs 60 (https://elixirforum.com/t/running-elixir-with-limited-heap-size/23633/3)
set the max heap size of a process: max_heap_size (in this link https://elixirforum.com/t/what-happens-when-erlang-vm-beam-runs-out-of-memory/39386/18)
https://www.erlang.org/doc/man/erts_alloc.html

etc
Maybe some consensus could be reached in the community, and outdated links in the forum cleaned.
Thanks a lot anyway
P.S. NIF is considered as a "dirty process" ?

Out of curiosity, how did you see that the model generated was 10 trees, of depth 8, with 270 nodes ?
Thanks

It does work !! I did search in this direction, but was mislead by NobbZ answer: https://elixirforum.com/t/running-elixir-with-limited-heap-size/23633/2?u=darkblueorange
More generally I feel like there was so many different options to play with memory that I couldn't find where/what:

erlang:system_flag(max_heap_size, Limit) (http://erlang.org/pipermail/erlang-questions/2016-April/088968.html)
+MMsco true +Musac false +MMscs 60 (https://elixirforum.com/t/running-elixir-with-limited-heap-size/23633/3)
set the max heap size of a process: max_heap_size (in this link https://elixirforum.com/t/what-happens-when-erlang-vm-beam-runs-out-of-memory/39386/18)
https://www.erlang.org/doc/man/erts_alloc.html

etc
Maybe some consensus could be reached in the community, and outdated links in the forum cleaned. Thanks a lot anyway
P.S. NIF is considered as a "dirty process" ?

Glad it worked! I will mark this issue closed then but can update the docs to make a note of this potential issue. Yes, NIFs can be marked as needing the dirty scheduler by marking as IO or CPU bound (see https://github.com/acalejos/exgboost/blob/b2c6cadce10ce26c6749fd19c5e34f3d080ea04d/c/exgboost/src/exgboost.c#L70).
Regarding how I knew the shape of the model, you can serialize the booster using EXGBoost.dump_model/1 and look at the number of nodes, knowing its a binary tree to see the depth. Perhaps adding a better way to see those sorts of characteristics would be nice


Set up public ropsten server

We've got public mainnet, prater, kiln servers. We should have a public ropsten server too.
From discord: https://discord.com/channels/593655374469660673/621838504955084830/988448063523795045
Hello! I just wanted to check if there is a Ropsten Lodestar test server yet?

@claravanstaden the endpoint  https://lodestar-ropsten.chainsafe.io/ has been setup. Currently syncing and we can close this as soon as we confirm the endpoint works! :)

@philknows awesome, thank you! I will test it out today. 👌

@philknows I tested the server and found this issue so far:
curl https://lodestar-ropsten.chainsafe.io/eth/v1/light_client/updates\?start_period\=25\&count\=1
{"statusCode":500,"error":"Internal Server Error","message":"No partialUpdate available for period 25"}
If I look at https://ropsten.beaconcha.in/, the current epoch is 6676 / 256 = 26, so period 25 should give an update. I tried other periods as well, none have worked so far.


add publish.yml

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 92.03%. Comparing base (8f418c9) to head (de0a8d7).

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##             main     #289   +/-   ##
=======================================
  Coverage   92.03%   92.03%
=======================================
  Files          49       49
  Lines        9129     9129
=======================================
  Hits         8402     8402
  Misses        727      727

Flag
Coverage Δ

unittests
92.03% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Split the compiler into smaller modules

The compiler is supposed to only compose the submodules but at the moment it has some logic inside and it counts more than 100 lines.
We should split it into smaller (and more testable) submodules.
My idea:
transformer
convertCssMapToAst
convertCssMapToAstMap
utils
updateFilesystem
cleanCss
concatenateCss
copySourceFolder
optimizer
clearJsonMap
Any thoughts @cef62?
More than happy to do it but I want your ok to proceed : )

Sounds perfect to me @MicheleBertoli ! Feel free to proceed 😎


New JS interop

Fixes #27016
Addresses #26364
Internal Review Topic
Notes

This gets the ball rolling with the base cases.
Code will live in the topic (code blocks) for release. Later, I'll come back and place the example code into the snippet sample apps at dotnet/blazor-samples.
API doc cross-links for the new API won't be available until after release, so I'll circle around later and place links after GA.

❓ on this one: I'd prefer if the examples compose in such a way that both the import example and the export example can live SxS in the same developer test app. I provide cut-'n-paste, fully working examples to readers whenever possible, and they're very popular. I ran into a problem tho ... I can't name the export module Interop and place it into the Interop.cs/Interop class file. It fails. 💥 I have to name it something else ... I use Interop2 on the PR ... to make it work. I don't understand why tho. Anyway, I'm 👂 for your help on that point.
For Dan later ...

I'm not aware of the long-term plan for this approach to interop: Will it become a thing for Blazor Server? Is there a plan for this to replace JS interop based on IJSRuntime eventually?
I drafted this as a standalone topic (but it can be split easily into the existing topics if you wish🧞♂). Justifications ...

This doesn't have a special name. I named it ".NET JavaScript [JSImport]/[JSExport] interop" just to have something to distinguish it, based loosely on your blog post comments. Even with the name that I gave it, it's a bit easier to see that this is a separate interop approach if it's in its own topic.
It probably is a bit easier for readers to get the whole explanation (calling both ways) if it's all in one spot ... one topic. We had to split call JS and call .NET into separate topics earlier because our original combined topic became iNsAnElY loooong 😵, but I think we can have a single topic at least for .NET 7. Perhaps at .NET 8 ... especially if this interop approach starts to take over ... this topic goes away and the content is split: The opening bit here goes into the JS Overview topic, the call JS piece is for the Call JS from .NET topic, and the call .NET piece is for the Call .NET from JS topic.

Updates made, and I'll call this a 'successful draft,' given that apparently I didn't butcher the API in this draft 😆.
Updates

I would not even say and isn't a security concern.

I removed that bit. However, it feels to me like there is some kind of risk to this 😨. Should we ping Barry to ask if he thinks something should be called out?

Consider adding C# namespace to razor file and here as well.

Given that all of my examples across the Blazor docs are meant to be cut-'n-paste, working examples for whatever local test app name that the reader is using, I typically avoid using them. It also usually shortens the code and makes for less boilerplate to consume with the examples. Let's see on the next commit if a few NOTE remarks in the text will work to cover it.

This is interesting comment. The JSObject returned by the ImportAsync is indeed disposable proxy. But even if you dispose it, the JSImport infrastructure will keep the JS side ES6 module alive and callable.

WRT "keep the JS side ES6 module alive and callable" ... but not from that component, which is being disposed at that point, right? I mean should we leave this bit as purely a 'best practices' step in the event that they do maintain such a reference to the object?
Remaining ❓ on module name 💥
I'm still unclear on why I had to name the 2nd example (the call .NET example) module Interop2 in order to make it work SxS with the first example (i.e., in the existing Interop C# class if the reader worked through the first example locally).
It fails 💥 if I try to just drop the SetWelcomeMessage into the existing Interop C# class with Interop as the module name ...
[JSImport("setMessage", "Interop")]
internal static partial void SetWelcomeMessage();

I had to give that module a different name there (Interop2) in order to make it work.
It doesn't seem like there should be a problem using the same module name. Anyway ... what can I say in the text about this? ... and/or how might the code example change to make more sense than just numbering it like that (Interop2), which is a silly hack on my part.

3. WRT "keep the JS side ES6 module alive and callable" ... but not from that component, which is being disposed at that point, right? I mean should we leave this bit as purely a 'best practices' step in the event that they do maintain such a reference to the object?

dotnet GC would collect the proxy anyway at some point. I would not complicate the docs about Dispose() especially on  ImportAsync because that's only called once per ES6 module.

Remaining ❓ on module name 💥
4. I'm still unclear on why I had to name the 2nd example (the call .NET example) module `Interop2`

I just wrote this test, to make sure it's working as expected and it is working for me.
[Fact]
public async Task MultipleImportAsync()
{
    var first = await JSHost.ImportAsync("JavaScriptTestHelper", "./JavaScriptTestHelper.mjs");
    var second = await JSHost.ImportAsync("JavaScriptTestHelper", "./JavaScriptTestHelper.mjs");
    Assert.NotNull(first);
    Assert.NotNull(second);
    Assert.Equal("object", first.GetTypeOfProperty("instance"));
    var instance1 = first.GetPropertyAsJSObject("instance");
    var instance2 = second.GetPropertyAsJSObject("instance");
    Assert.Equal(instance1, instance2);
}

Could you please share more details and also the error you get ?
Also, it should be enough to call ImportAsync once for all the imports from the same ES6 module.

not complicate the docs about Dispose()

It's against the normal disposal pattern that we pitch. I suspect that this would be more important in a server-side scenario that we aren't covering here. If it's ok with you, let me get Dan's feedback on it just to make sure. I just want to ask because we'd normally guide this way. If we don't show it, we might still leave a note that says something like ... 'client-side code that assigns the JSObject doesn't require disposal of the JSObject because ... blah blah blah' ... whatever it makes sense to say. This would at least harden the doc against devs wondering about it. I feel like I'm going to get asked about it one day if we don't proactively say something.

share more details

The following class results if the reader attempts to work through both examples with the same Interop C# class and naming the module the same way (Interop). It would start with just the GetWelcomeMessage method when they work through the call JS section. Then, they would just naturally think that they can add the SetWelcomeMessage and DotNetInteropCall methods to that class.
I kind'a vaguely feel like I know why this isn't working. The collocated JS files are TWO modules in these examples ... is that right? ... and this C# class is giving both of them the same module name ... and it's then it seems like it's choking on that setup 💥. Anyway ... here's the way I was originally trying to make it work ...
using System.Runtime.InteropServices.JavaScript;
using System.Runtime.Versioning;

[SupportedOSPlatform("browser")]
public partial class Interop
{
    [JSImport("getMessage", "Interop")]
    internal static partial string GetWelcomeMessage();

    [JSImport("setMessage", "Interop")]
    internal static partial void SetWelcomeMessage();

    [JSExport]
    internal static string GetMessageFromDotnet()
    {
        return "¡Hola desde Blazor!";
    }
}

The CallDotNet component is ...
@page "/call-dotnet"
@using System.Runtime.InteropServices.JavaScript

.NET JS Import/Export Interop (Call .NET)

    .NET method not executed

@code {
    protected override async Task OnAfterRenderAsync(bool firstRender)
    {
        if (OperatingSystem.IsBrowser() && firstRender)
        {
            await JSHost.ImportAsync("Interop", "../Pages/CallDotNet.razor.js");

            Interop.SetWelcomeMessage();
        }
    }
}

... and the collocated JS file contains ...
export async function setMessage() {
  const { getAssemblyExports } = await globalThis.getDotnetRuntime(0);
  var exports = await getAssemblyExports("BlazorSample.dll");

  document.getElementById("result").innerText = exports.Interop.GetMessageFromDotnet();
}

The first example (call JS) from the first section, still works in the app :+1:. The 2nd example melts down 💥 with ...
crit: Microsoft.AspNetCore.Components.WebAssembly.Rendering.WebAssemblyRenderer[100]
      Unhandled exception rendering component: Error: Assert failed: setMessage must be a Function but was undefined
      xs@https://localhost:7105/_framework/dotnet.7.0.0-rc.1.22426.10.t7u94tgxh6.js:5:52419
      As@https://localhost:7105/_framework/dotnet.7.0.0-rc.1.22426.10.t7u94tgxh6.js:5:50492
      _mono_wasm_bind_js_function@https://localhost:7105/_framework/dotnet.7.0.0-rc.1.22426.10.t7u94tgxh6.js:14:102690
      @:wasm-function[10]:0x0
      @:wasm-function[313]:0x1d4ca
      @:wasm-function[283]:0x1c8cf
      @:wasm-function[221]:0xdfdb
      @:wasm-function[220]:0xce8d
      @:wasm-function[8112]:0x1a1f31
      @:wasm-function[2053]:0x859bd
      @:wasm-function[2058]:0x86025
      @:wasm-function[8522]:0x1bb232
      @:wasm-function[2855]:0xaaf71
      createDotnetRuntime</</Module._mono_background_exec@https://localhost:7105/_framework/dotnet.7.0.0-rc.1.22426.10.t7u94tgxh6.js:14:133854
      ha@https://localhost:7105/_framework/dotnet.7.0.0-rc.1.22426.10.t7u94tgxh6.js:5:84836

Error: Assert failed: setMessage must be a Function but was undefined
xs@https://localhost:7105/_framework/dotnet.7.0.0-rc.1.22426.10.t7u94tgxh6.js:5:52419
As@https://localhost:7105/_framework/dotnet.7.0.0-rc.1.22426.10.t7u94tgxh6.js:5:50492
_mono_wasm_bind_js_function@https://localhost:7105/_framework/dotnet.7.0.0-rc.1.22426.10.t7u94tgxh6.js:14:102690
@:wasm-function[10]:0x0
@:wasm-function[313]:0x1d4ca
@:wasm-function[283]:0x1c8cf
@:wasm-function[221]:0xdfdb
@:wasm-function[220]:0xce8d
@:wasm-function[8112]:0x1a1f31
@:wasm-function[2053]:0x859bd
@:wasm-function[2058]:0x86025
@:wasm-function[8522]:0x1bb232
@:wasm-function[2855]:0xaaf71
createDotnetRuntime</</Module._mono_background_exec@https://localhost:7105/_framework/dotnet.7.0.0-rc.1.22426.10.t7u94tgxh6.js:14:133854
ha@https://localhost:7105/_framework/dotnet.7.0.0-rc.1.22426.10.t7u94tgxh6.js:5:84836

We can say in the text the reason that the module is named something else for the 2nd example ... whatever that reason is, but I also think we should use something other than Interop2. That seems arbitrary and kind'a silly to me 😄.

oh ... and WRT ...

call ImportAsync once for all the imports from the same ES6 module.

Do you mean across components??? That seems kind'a strange because one wouldn't know which component a user would request first. Wouldn't that be fragile ... or should the module be set up for loading when Blazor itself starts?

Do you mean across components???
If you have same JS file on the same URL across blazor components, it's still the same ES6 module from JS perspective.
So, if those are separate blazor components, they should have separate JS files.

the URL is relative to dotnet.js not to a blazor component

Yes, but is the reason that my first attempt fails because the JS exports fail to work in the 2nd example because I named the module the same thing in the C# class but use two collocated JS files. It seems like that's what the problem is. It's just my lack of understanding of JS modules that tripped me up.
I think my last idea makes the most sense. Each section here gets it's own "Interop" C# class with different class names ... a collocated module for each component (separate JS files) ... and uses a different module name for each. ....... I think 🤔. That's the base case ... the simplest way to demo these approaches SxS in a single test app.
Then ... I think we'll need a new section on using a single module across components (i.e., NOT using collocated JS). There will be an import/export at Blazor start with ONE module ... one module name ... and hypothetically no wipeout 💥 that way.
I'm just thinking out loud, so please feel free to stop me before I embarrass myself further! 🤣

Last commit merely sets up the two sections for separate classes and separate modules. That's at least not going to break when placed into the same test app.
Next, I'll see about working up a section that uses a single module across components. I won't necessarily use fully-working example code tho. I might just call out the deltas from the preceding sections that make it work.

are you also updating the samples repo at the same time ? Is there PR with full code I could look at ?

are you also updating the samples repo at the same time ?

No, that will come later. For now, it's all just inline code blocks in the topic and a local test app that I'm working with. I normally let things settle on the first release of new bits before moving examples into the snippet sample apps.
I can put my test app up on GH if you like.

Here it is ... ignore the name of the app, as that goes back to Day 1 when I didn't know exactly what this was ...
https://github.com/guardrex/BlazorWASM70UnmarshalledJS

... and it's obvious from that that I don't know how to load the module from one spot at app startup and avoid the calls to JSHost.ImportAsync in each component. That seems like a good idea, but we don't cover a way Blazor.start-way of doing that yet. I think Javier has asked me to work on that in a general way. I just haven't had the time to reach his issue for work ... and I don't know as I sit here how that's composed in code.

Perhaps you could rename the Interop1.cs to CallDotNet1.razor.cs and put it next to the blazor component.
In my demo I have
public partial class DetectHands // this matches the name of the razor component
{
        public partial class Interop
        {
        }
}

and then in JS I could have
detectHandsExports.DetectHandsJsComponent.DetectHands.Interop.OnResults(component, json);

detectHandsExports - assembly level
DetectHandsJsComponent - namespace
DetectHands blazor component class
Interop - interop nested class
OnResults exported static method

Perhaps you could rename the Interop1.cs to CallDotNet1.razor.cs and put it next to the blazor component.

Yes! Good idea. I was trying to use a single class at first, but the new way here for the first two sections will compose even better that way.

Hold off on the last commit tho. I probably need to refactor that again.
I'm running out of time today to continue. We'll probably need to pick back up on Tuesday morning with the updates. No worries tho AFAIK ... I don't think we're late in any sense.

mmmmm ... yeah ... I'm running into 😈 namespace collision gremlins 😈 because I can't have the component share a class name with the C# interop class. I didn't name things very well 🙈 on a quick pass ... I don't think I ended up with something following your example.
Yeah ... let me pick back up with this on Tuesday morning. I'll fix it all up along the lines of your last suggestion.
If you know how I load a module to avoid the two JSHost.ImportAsync calls for the new 3rd section, I'll be 👂 for that. Otherwise tho, we can pick back up with that tomorrow, too.

This is all good, you are learning from trying!
So that you could better anticipate the mistakes users would make and tell them how to avoid it.
Keep trying!

Yes! That's at least one reason why Dan, David, and Damian bother even keeping me around here! 🤣

@pavelsavara ... Ok ... I think 🤔 that I have this fixed up ... maybe 😄. Two things ...

To conform to our normal partial class namespace guidance for components, we'd name these including the Pages folder because that's where the components would reside in the typical Blazor app. That's not surprising or a problem in the overall scheme of things here AFAICT. Devs would expect to see that. Now that I've moved the partial methods to the collocated partial classes, the namespace for the JS exports call composes well. Everything seems to be running ok at this point.
WRT using JS initializers for modules, I took a look at the automatic Blazor loading feature (*.module.lib.js), and that didn't work and doesn't seem to have any capacity to work with the import/export API (i.e., call JSHost.ImportAsync), so I ended up just using the good old fashioned App component's async initialization ... and that seems to work ok here and allows the CallJavaScript2 and CallDotNet2 components to drop their module loading pieces. I've updated all of the code in the 3rd section at the end.

I'll be OOF for a couple of hours. I'll react to your feedback today or Wednesday morning.
If there's nothing else for the draft ...

Today, I'll polish up the third section with some text to explain that scenario out.
Sleep on the whole thing 🛌😴 one more night.
Wednesday morning, I'll make a final edit and update pass.
Ping for Dan and Artak for feedback and review.

One more thing that I noticed ...
Caching of the JS does seem to be a little bit of a problem. While debugging, I had to perform a manual browser refresh to bust the cache on the JS to get updates to load while testing (or use Dev Tools without caching). Do you want the topic to address this at all?

https://github.com/guardrex/BlazorWASM70UnmarshalledJS

Please push updates for me

Also please look at https://devblogs.microsoft.com/dotnet/use-net-7-from-any-javascript-app-in-net-7/ to see if there is something to reuse (or fix on either side)

Everything seems to be running ok at this point.

Hooray!

* WRT using JS initializers for modules, I took a look at the automatic Blazor loading feature (`*.module.lib.js`), and that didn't work.

I tried too and it didn't work for me either. But I thought I just don't know how to use it. Shall we ask Blazor team ?

* Ping for Dan and Artak for feedback and review.

Yes, please.

Caching of the JS does seem to be a little bit of a problem. While debugging, I had to perform a manual browser refresh to bust the cache on the JS

We could address it in user code by query string
#if DEBUG
    var url = "../Pages/CallDotNet.razor.js?bustCache="+Guid.NewGuid();
#else
    var url = "../Pages/CallDotNet.razor.js";
#endif
    await JSHost.ImportAsync("Interop", url);

Or we could make it a feature of the JSHost.ImportAsync in Net8.
You could also advise users to disable caching when debugging.

Please push updates for me

Done ... and keep in mind that the topic uses an app namespace of BlazorSample, not the one you see in that sample app.

Shall we ask Blazor team ?

Let's hold off for now. Dan will probably ping Javier after he looks and provides feedback. I don't think the JS initializer approach feature is for this scenario where C# code has to be called. The App component is the typical spot for such code ... and Dan will be able to confirm it or provide alternate guidance.

could address it in user code by query string

Interesting idea! We've never shown that approach. We'll ask Dan about that tomorrow, too.

advise users to disable caching in the browser dev tools

Yes, that's easy/quick/clear. I'll add that now.

https://devblogs.microsoft.com/dotnet/use-net-7-from-any-javascript-app-in-net-7/

Until Dan says otherwise, we'll just document the Blazor parts.
The Store piece is interesting for a possible add elsewhere where we use local storage (e.g., state preservation).
We don't marshal anything for interop in examples thus far; however, I'm not sure how far Dan wants to take this for the upcoming release. I'll ask him about that tomorrow. I think working out how far to go will be more between you and him.
The Optimization (prefetch) bit is interesting (along with the trimming unused code piece), but that is for sure one that I need Dan/Javier help to understand in a Blazor context ... it might have side-effects ... 😈 gotchas ... possible 💥 scenarios. I'll add that to the list to ask about.
I still think we're going to have to say a bit more on the security of <AllowUnsafeBlocks>. By its very name, it sounds scary ... perfect for 👻 Halloween! 🎃😄 I'll see what I can cross-link in existing MS doc sets for it.
I'll add a cross-link to it right now to the bottom of the topic. That's great reference material no matter what else we do.

One more commit today. I'll sleep on it with final updates Wednesday morning. I'll ping Dan and Artak tomorrow after that.
If you think of anything else, I'm 👂 here until around noon-ish CST, then back tomorrow morning.

Dan, Artak: It's a typical Rex TL-DR™ scenario for the prior discussion on the PR and over on the issue. Pavel helped me shape this up into something that might not result in you carving me up like a 🎃 for Halloween 😆. Thanks, @pavelsavara, for all of your help here!
I'll number these for quick feedback. Here are at least some of the open points for further discussion/action ...

Naming: I call this ".NET JavaScript [JSImport]/[JSExport] interop" for lack of a better name. I needed something to distinguish it from IJSRuntime JS interop.

Location: I place this into a new topic that might only last for the .NET 7 release. The content might get split out into the existing JS interop Overview, Call JS, and Call .NET topics now or later, but I figured that right now it's easier to consume the basics in one spot. I'm not aware if the longterm plan is to make this work with Blazor Server and/or replace IJSRuntime-based interop with this in a future release, all of which affect the location of the coverage.

The article uses "new in .NET 7"-type language that will probably go away in the .NET 8 and later versions of the content. It's probably better if we make it clear that at least for .NET 7 that this is new and only available for the upcoming release.

When using a common JS module for multiple components (in the third section of the article), I load the module in the App component per our normal pattern. You/the PU will need to confirm if I did the right thing.

Cache busting during development is a slight challenge at the moment. The topic tells devs that they should probably use dev tools without static asset caching, but Pavel also said that ...
#if DEBUG
    var url = "../Pages/CallDotNet.razor.js?bustCache="+Guid.NewGuid();
#else
    var url = "../Pages/CallDotNet.razor.js";
#endif

... can work. Do you want me to add that?

Only the Blazor-specific scenarios are documented here. Idk if you want interop for non-Blazor scenarios in this node ... and if so ... where/how you want that set up.

The article covers basic interop, and I hope that the examples thus far ... simple for a simple-minded 🦖 to understand ... aren't made more complex. However, you and Pavel may wish to add more sections to cover more scenarios with additional examples (e.g., local storage JS for state management, additional marshalling of types, optimization with prefetch, etc.).

<AllowUnsafeBlocks> is 👻 sCaRy 🧛 by its very name. I didn't find anything good to cross-link that explains any security concerns about it, but it seems like there must be something to caution devs about for it ... otherwise, why even call it that?? ... "UNSAFE" ... I'm a bit 😨 just blurting it out in the article without context.

WRT JSObject disposal: Pavel said, "dotnet GC would collect the proxy anyway at some point. I would not complicate the docs about Dispose() especially on ImportAsync because that's only called once per ES6 module." However, it breaks our pattern for assigned disposable objects. I'm 👂 for feedback on how you/the PU want that bit handled. You'll see that in the article, I dispose in the normal way. I don't say when/where it ever makes sense to assign the JSObject. I'm not sure if we need to remark on that, too.

@MackinnonBuck ... The discussion earlier on the PR (and the issue) is a TL;DR. My last remark here at ☝ ...
https://github.com/dotnet/AspNetCore.Docs/pull/27083#issuecomment-1260999319
... summarizes a number of items to consider/address.

Thanks @MackinnonBuck ... I think I've addressed almost everything. There's one thing left for me to address that I'll work on tomorrow morning ...
Both you and Pavel have called out that the module lifetime is different from the component lifetime that loaded it ... presumably lasting as long as the app is running (i.e., browser tab/window is open without a refresh).
It's not particularly relevant in the collocated module scenarios, except what happens performace-wise if the user navigates away and then back to the component? Does the API burn processor time doing anything when it hits JSHost.ImportAsync for an already loaded module? I suppose not, but that's something that is probably good to tell devs about this API's behavior.

Overall, great! Many thanks

Thanks ... I'll make those updates shortly, then I'm just waiting to hear back if Dan and Artak want to provide feedback, especially for the remaining numbered items ☝. They might say tho to go ahead and merge this to unblock me for other work because they'll return later to look.

@danroth27 ... Thanks!

I can't think of anything better. Let's go with what you've got

:+1:

Keeping this content in a separate article is the right call.

🍀 Lucky guess!™ 🍀 ... I'm only about 50-50 when it comes to this sort of decision.

I generally prefer using language that is timeless to avoid content going stale because we forgot to update it in a future release. Anything that needs to be cleaned up for .NET 8 should be tracked with a GitHub issue.

Yes, I agree. I rarely use this type of "new in X release" language, but it seems like a good idea this time, just for this release. I'll place an issue to track removing it for 8.0.

we already handled cache busting in ASP.NET Core during development.

I'll wait until @pavelsavara comments. @pavelsavara, if you think it shouldn't have happened here at all across VS debugging session restarts/new debugging sessions, I'll research further to see if I can scope the conditions and report back. 👂

We should think of this article as being lower level than Blazor ... most of the content needs to be free of Blazor specific concepts

I fully admit the Blazor bias! 😄 I wrote this for a silly 🦖 that needs an easy intro for Blazor, nothing else obviously. I'm ready tho to re-organize and rewrite as needed. Whatever we do going forward, I hope we keep these Razor component examples somewhere. These cut-'n-paste, fully-working example mini-tutorial bits result in fewer doc issues and big 💰 savings.

If @pavelsavara is happy with the coverage, then I think we're good.

:+1: I'm 👂 for anything else. We also can open a long-range issue to add coverage later this year or early next year if you wish. I'd kind'a prefer early next year, if possible. I still hope to perform a security pass in the 🦃 to 🎅 timeframe, which takes a lot of concentration from the pea-🧠 🦖. I hope to have some time to focus on it.

I'm ready tho to re-organize and rewrite as needed. Whatever we do going forward, I hope we keep these Razor component examples somewhere.

We should definitely keep the Blazor examples. But I do think we want the initial content for the JSImport and JSExport sections to be free of anything Blazor related. A key scenario we're trying to enable here is being able to call into .NET code from JS without Blazor in the picture. For the JSImport section I think we should lead with that scenario and then later show how the same thing can be done in Blazor. We can use the content from the experimental WebAssembly Browser App template for this.
Of particular concern is the JS API surface area for the .NET runtime. We don't have API ref docs for our JS APIs, so if we don't cover those APIs in these conceptual topics, then they are basically undocumented. For example, here's what you do in JS to setup the .NET runtime and import modules so they can be called from .NET:
import { dotnet } from './dotnet.js'

const is_browser = typeof window != "undefined";
if (!is_browser) throw new Error(`Expected to be running in a browser`);

const { setModuleImports, getAssemblyExports, getConfig, runMainAndExit } = await dotnet
    .withDiagnosticTracing(false)
    .withApplicationArgumentsFromQuery()
    .create();

setModuleImports("main.js", {
    window: {
        location: {
            href: () => globalThis.window.location.href
        }
    }
});

without Blazor in the picture

You don't want two articles? This one for Blazor and another one for the JS-based scenarios in the Client-side development node? See what I mean? If it's non-Blazor, then it seems strange to place it in this node.

So most of the content needs to be free of Blazor specific concepts.

I think long term we need both, non-Blazor JSImport article and Blazor JSImport article.
In this case I thought we are doing Blazor JSImport article.
The non-Blazor is covered by my blog article for now.
Later we could have some non-Blazor JSImport article in the runtime docs.

we already handled cache busting in ASP.NET Core during development.

I'll wait until @pavelsavara comments. @pavelsavara

Does server side send some cache busting HTTP headers ? Does it work well ?
The runtime doesn't handle cache busting in Net7. Nor other nice things which Blazor does, like DLL caching and brotli compression. We want to fix it, but we don't have specific HOW yet https://github.com/dotnet/runtime/issues/70762

If @pavelsavara is happy with the coverage, then I think we're good.

Yes, I'm happy.

Side-note: Currently, Pavel's blog post is cross-linked in the Additional resources section at the bottom.
@danroth27, I'll hold a sec just to make sure you want it set up that way (one combined article) and here ... where I've placed it.
Either way, I think it will go together fairly fast, probably Tuesday for the next round of reviews.
Note in passing that I don't know MV* framework things. Those aspects are a bit Greek-ish 🇬🇷  to me 😄. I'll be blatantly stealing blog post coverage from both of you for those aspects. My attorney is on speed dial! 🚓👮

server side send some cache busting HTTP headers

I'm not seeing Hot Reload react to JS file changes for this, including with Hot Reload on File Save enabled.
... and we're going to need to pull the "use dev tools" content that we placed in the topic. That actually does NOT work 😢.
... and I tried the "../Pages/CallJavaScript1.razor.js?bustCache="+Guid.NewGuid() approach. No 🎲🎲 ... that doesn't seem to work either 😩.
Unless I'm missing something, I'm down to any of the following for a JS file change+save ...

Reloading the app from the browser.
Reloading from the app from the VS toolbar.

Restart Application under Hot Reload.
Restart button in the debugging button group.

I'm 👂 for how to cover this aspect.

You don't want two articles? This one for Blazor and another one for the JS-based scenarios in the Client-side development node? See what I mean? For non-Blazor use of the new API, it seems strange to place it in this node.

I'm fine with two articles.
At some point we may put the generic .NET on WebAssembly docs as part of the runtime docs, but for now most of our users equate .NET on WebAssembly and Blazor as being essentially the same thing, so we decided to put this content with the Blazor docs for now.
The scenario I want to make sure is documented is the ability to use .NET on WebAssembly from JS without any Blazor UI components. We've had multiple requests for this. Many users want to be able to reuse a .NET library from their existing JS based apps, but they don't need Blazor's component or hosting models.

I'm fine with two articles.

I'm 🎉👍 on that at least for look in a draft 👀. I'll get that set up on this PR early next week; then if it doesn't work well as two articles, we can combine the coverage.
I think this is going to work out better ... for Blazor devs anyway. Personally, I wouldn't want to have to skip or tease out early bits on the API prior to the 🍖 for Blazor. Kind'a like with MVC/RP. Feedback on issues over the last several years seems to indicate anecdotally that RP peeps really don't want to see controllers and views and MVC-focused folks really don't want to see pages.

UPDATE (Monday, 10/10): The client-side topic for the Client-side development node is composing well. I still have a little bit more writing to do on it, and then I'll 🛌💤 on it for final updates Wednesday morning.
I'm 👂 on your further convo on cache busting. I'll replace the 'use dev tools' content with whatever you want the topic to tell devs.
Dan, I hope to reach Blazor What's New and migration article content as soon as this PR is merged. It might be by the EOW if all goes well here this week.

@pavelsavara ... Does "morning" extend to 2pm CST???! 😄 I got pulled off on something else this morning.
I think this is good enough for a look when you're ready. You'll notice that I've based the Client-side development topic on Dan's suggestion to go off of the template. I may have botched some of the description 🙈, but I'm sure you'll be able to see where I've broken any bits.
I put you on the added topic as the author (in metadata) so that you'd get the issue pings. I figured that you might want that for this release and then change that over to us docs cats later. if you don't want initial (automatic) pings at all, let me know 👂. I did add myself via the repoman configuration that you see on the commit. We'll both be assigned to new issues. If someone calls out a spelling error 🙈 ... a missing comma 🙈 ... or just wants to tell us about the weather where they are 🙈😄 ... I can deal with those types of issues, and you can ignore them.
I really like this split coverage ... in spite of the overlap. But, we'll see! It's NOT my call. You and Dan will let me know if this layout of content is going to cause problems.
I make liberal reference to your blog post. That could be changed for .NET 8 if the blog post goes stale due to new/updated features. Indeed! We can bring anything from the blog post into this client-side topic that you feel should be brought in.
I left a note to myself in the text (and have added an entry to my 7.0 tracking issue) about the move from runMainAndExit()  changing to dotnet.run(). I'll take care of that when the time comes.
BTW ---- Speaking of the templates. IIRC, you had JS in 4-space indents. I think they were going with 2-space indents. I made it 2-spaces in the PR examples. I mention it in case that's right and templates should be updated.
Ok ... that's it. I'm toast for the day. 😆
I'll be back online first thing Thursday morning, when the rotten family 🐱 wakes me up at 4am!! 😡 Arrrrrgh! Rotten CAT! 😹
I'll address your feedback, and then I'll ping Dan on and offline that it's ready for another look 👀.

Also, I'll need to know if you guys want me to roll in ...
WebAssembly multithreading (experimental)
https://devblogs.microsoft.com/dotnet/asp-net-core-updates-in-dotnet-7-rc-2/#webassembly-multithreading-experimental
... now, later, or not at all for this release.

@danroth27 ... I think there are just two quick items to resolve and this can be merged ...
Cache Busting
Cache busting guidance wasn't finalized. Do you want me to strike that section?
Naming consistency for the new JS interop
".NET JavaScript [JSImport]/[JSExport] interop (API)" was carried over to the Client-side development topic for naming consistency. ".NET" only meant that this technology is a feature of .NET, not that it can only be used in .NET apps, but I see your point about that construction appearing over in that other new article. I made the change that you suggested on the other PR, but it results in an undesirable inconsistency in naming across the two articles. Should I change the name here in the Blazor article to match?
Everywhere, we'd call this tech (initial mention) ...
JavaScript (JS) [JSImport]/[JSExport] interop API
... and then shortened thereafter to either ...
[JSImport]/[JSExport] interop
... or just ...
JS interop

Cache busting guidance wasn't finalized. Do you want me to strike that section?

@guardrex  I didn't see this content in the PR anymore, so I assume you already removed it?

Should I change the name here in the Blazor article to match?

@guardrex Can you clarify for me what title change you are proposing?

I didn't see this content in the PR anymore, so I assume you already removed it?

I just had a placeholder for it at Line 45, currently commented-out in the text. It sounds like we're not going to guide on that aspect, so I'll remove that.

Can you clarify for me what title change you are proposing?

Yes ... it's just up above ☝ ... asking if we should remove the ".NET" part everywhere from the naming to make it consistent everywhere.
☝ https://github.com/dotnet/AspNetCore.Docs/pull/27083#issuecomment-1285405546 ☝

asking if we should remove the ".NET" part everywhere from the naming to make it consistent between the two articles.

The current title for this article is: ".NET JavaScript [JSImport]/[JSExport] interop with ASP.NET Core Blazor"
And title of the other article is: "Run .NET from JavaScript using [JSImport]/[JSExport] interop"
Are you proposing that the name of this article should drop the ".NET" for consistency? So the new title would be: "JavaScript [JSImport]/[JSExport] interop with ASP.NET Core Blazor"? If so, I'm fine with that.

Yes, that's right. I've made the change. It's consistent with the other article now.
This is the first Blazor doc to get file-scoped namespaces. Updates will roll into all of the docs over time. I noticed that MS/you aren't fully collapsing the namespace line under the usings (or making it the first line of the file) to save one more vertical line. I figured it's worth asking about on ...
Why not save one more line with file-scoped namespaces? (dotnet/aspnetcore #44676)
https://github.com/dotnet/aspnetcore/issues/44676
For this PR, I do it the PU-way ... e.g. ...
using System.Runtime.InteropServices.JavaScript;
using System.Runtime.Versioning;

namespace BlazorSample.JavaScriptInterop;

[SupportedOSPlatform("browser")]
public partial class Interop
{
    ...
}

If you change your mind, I'll patch these up later.


When you delete a user, the roles ain't cleaned

Issue Summary
When you delete a user, the roles ain't cleaned
Steps to Reproduce

Delete a user;
And observe:

mysql> select users.id, users.name, roles.name from roles join roles_users on roles_users.role_id=roles.id left join users on users.id = roles_users.user_id;
+--------------------------+----------------+---------------+
| id                       | name           | name          |
+--------------------------+----------------+---------------+
| 1                        | Adrien Giboire | Owner         |
| 5984be102f295b5ab0bef447 | Adrien Giboire | Administrator |
| NULL                     | NULL           | Author        |
+--------------------------+----------------+---------------+

Technical details:

Ghost Version: 1.5.0
Node Version: 6.11.1
Database: mysql  Ver 14.14 Distrib 5.7.19

Hey @AdrienGiboire, thanks for your report.
I can confirm, the roles_users entry is not getting removed when a user is deleted. PR is welcome 🙃

Trying to but having local issues.

@AdrienGiboire Thank you! If you need any help, swing by our slack channel and ask in the #contributing channel.

@kirrg001  Can you assign this issue to me? I want to fix it as my first commit.

@uname-yang I am not able to assign you, because you are not part of the Ghost Contributors group. But a fix for this is very welcome 👍

I would like to work on this!

@dexterleng Thanks 🤩 If you need any help, let us know here!


alm-cli list tracker return null

After:
 ./bin/alm-cli create tracker -H localhost:8080 --payload '{"type":"github","url":"http://github.com/"}'
2016/09/06 00:39:07 [INFO] started id=Bgr7JOgQ POST=http://localhost:8080/api/trackers
2016/09/06 00:39:07 [INFO] completed id=Bgr7JOgQ status=201 time=12.243932ms
{"id":"\u0001","type":"github","url":"http://github.com/"}

This returns null:
./bin/alm-cli list tracker -H localhost:8080
2016/09/06 00:40:38 [INFO] started id=U13YwJVL GET=http://localhost:8080/api/trackers
2016/09/06 00:40:38 [INFO] completed id=U13YwJVL status=200 time=6.009625ms
[null]

PR #197

#197 is merged hence closing.