[Bug?]: Error: Client-only API called on the server side. When using npm run dev on a brand new solidstart project

Duplicates

[X] I have searched the existing issues

Latest version

[X] I have tested the latest version

Current behavior 😯
On running npm run dev for new solid start project (using basic template) throws a bunch of errors about trying to use client side only features on server side. Old projects run fine.
Expected behavior 🤔
SolidStart project should start on local host 3000.
Steps to reproduce 🕹
Steps:

npm init solid@latest
Project Name: datePicker
Is this a SolidStart project? Yes
Which template would you like to use? basic
Use Typescript? No
Project successfully created!
cd datePicker
npm install
npm run dev

dev

vinxi dev

vinxi v0.4.3
vinxi starting dev server
WARN  No valid compatibility date is specified.                                                      nitro 9:59:42 PM
ℹ Using 2024-04-03 as fallback.                                                                      nitro 9:59:42 PM
Please specify compatibility date to avoid unwanted behavior changes:
- Add compatibilityDate: '2024-11-26' to the config file.
- Or set COMPATIBILITY_DATE=2024-11-26 environment variable.
➜ Local:    http://localhost:3000/
➜ Network:  use --host to expose
11. ctrl+click on http://localhost:3000/
12.  command line updates to:

dev
vinxi dev

vinxi v0.4.3
vinxi starting dev server
WARN  No valid compatibility date is specified.                                                      nitro 9:59:42 PM
ℹ Using 2024-04-03 as fallback.                                                                      nitro 9:59:42 PM
Please specify compatibility date to avoid unwanted behavior changes:
- Add compatibilityDate: '2024-11-26' to the config file.
- Or set COMPATIBILITY_DATE=2024-11-26 environment variable.
➜ Local:    http://localhost:3000/
➜ Network:  use --host to expose
9:59:52 PM [vite] page reload vinxi/routes
9:59:52 PM [vite] page reload vinxi/routes (x2)
9:59:52 PM [vite] page reload vinxi/routes (x3)
9:59:54 PM [vite] Error when evaluating SSR module<EMAIL_ADDRESS>|- Error: Client-only API called on the server side. Run client-only code in onMount, or conditionally run client-only component with .
at Module.notSup (file:///mnt/c/Users/almos/Documents/Codes/web_dev/datePicker/node_modules/solid-js/web/dist/server.js:1136:9)
at eval (/mnt/c/Users/almos/Documents/Codes/web_dev/datePicker/node_modules/@solidjs/router/dist/index.js:1470:49)
at async instantiateModule (file:///mnt/c/Users/almos/Documents/Codes/web_dev/datePicker/node_modules/vinxi/node_modules/vite/dist/node/chunks/dep-CB_7IfJ-.js:52972:5)
9:59:54 PM [vite] Error when evaluating SSR module /src/app.jsx:
|- Error: Client-only API called on the server side. Run client-only code in onMount, or conditionally run client-only component with .
at Module.notSup (file:///mnt/c/Users/almos/Documents/Codes/web_dev/datePicker/node_modules/solid-js/web/dist/server.js:1136:9)
at eval (/mnt/c/Users/almos/Documents/Codes/web_dev/datePicker/node_modules/@solidjs/router/dist/index.js:1470:49)
at async instantiateModule (file:///mnt/c/Users/almos/Documents/Codes/web_dev/datePicker/node_modules/vinxi/node_modules/vite/dist/node/chunks/dep-CB_7IfJ-.js:52972:5)
9:59:54 PM [vite] Error when evaluating SSR module<EMAIL_ADDRESS>|- Error: Client-only API called on the server side. Run client-only code in onMount, or conditionally run client-only component with .
at Module.notSup (file:///mnt/c/Users/almos/Documents/Codes/web_dev/datePicker/node_modules/solid-js/web/dist/server.js:1136:9)
at eval (/mnt/c/Users/almos/Documents/Codes/web_dev/datePicker/node_modules/@solidjs/router/dist/index.js:1470:49)
at async instantiateModule (file:///mnt/c/Users/almos/Documents/Codes/web_dev/datePicker/node_modules/vinxi/node_modules/vite/dist/node/chunks/dep-CB_7IfJ-.js:52972:5)
9:59:54 PM [vite] Error when evaluating SSR module<EMAIL_ADDRESS>|- Error: Client-only API called on the server side. Run client-only code in onMount, or conditionally run client-only component with .
at Module.notSup (file:///mnt/c/Users/almos/Documents/Codes/web_dev/datePicker/node_modules/solid-js/web/dist/server.js:1136:9)
at eval (/mnt/c/Users/almos/Documents/Codes/web_dev/datePicker/node_modules/@solidjs/router/dist/index.js:1470:49)
at async instantiateModule (file:///mnt/c/Users/almos/Documents/Codes/web_dev/datePicker/node_modules/vinxi/node_modules/vite/dist/node/chunks/dep-CB_7IfJ-.js:52972:5)
9:59:54 PM [vite] Error when evaluating SSR module /src/entry-server.jsx:
|- Error: Client-only API called on the server side. Run client-only code in onMount, or conditionally run client-only component with .
at Module.notSup (file:///mnt/c/Users/almos/Documents/Codes/web_dev/datePicker/node_modules/solid-js/web/dist/server.js:1136:9)
at eval (/mnt/c/Users/almos/Documents/Codes/web_dev/datePicker/node_modules/@solidjs/router/dist/index.js:1470:49)
at async instantiateModule (file:///mnt/c/Users/almos/Documents/Codes/web_dev/datePicker/node_modules/vinxi/node_modules/vite/dist/node/chunks/dep-CB_7IfJ-.js:52972:5)
9:59:54 PM [vite] Error when evaluating SSR module $vinxi/handler/ssr:
|- Error: Client-only API called on the server side. Run client-only code in onMount, or conditionally run client-only component with .
at Module.notSup (file:///mnt/c/Users/almos/Documents/Codes/web_dev/datePicker/node_modules/solid-js/web/dist/server.js:1136:9)
at eval (/mnt/c/Users/almos/Documents/Codes/web_dev/datePicker/node_modules/@solidjs/router/dist/index.js:1470:49)
at async instantiateModule (file:///mnt/c/Users/almos/Documents/Codes/web_dev/datePicker/node_modules/vinxi/node_modules/vite/dist/node/chunks/dep-CB_7IfJ-.js:52972:5)
[h3] [unhandled] H3Error: Client-only API called on the server side. Run client-only code in onMount, or conditionally run client-only component with .
at Module.notSup (file:///mnt/c/Users/almos/Documents/Codes/web_dev/datePicker/node_modules/solid-js/web/dist/server.js:1136:9)
at eval (/mnt/c/Users/almos/Documents/Codes/web_dev/datePicker/node_modules/@solidjs/router/dist/index.js:1470:49)
at async instantiateModule (file:///mnt/c/Users/almos/Documents/Codes/web_dev/datePicker/node_modules/vinxi/node_modules/vite/dist/node/chunks/dep-CB_7IfJ-.js:52972:5) {
cause: Error: Client-only API called on the server side. Run client-only code in onMount, or conditionally run client-only component with .
at Module.notSup (file:///mnt/c/Users/almos/Documents/Codes/web_dev/datePicker/node_modules/solid-js/web/dist/server.js:1136:9)
at eval (/mnt/c/Users/almos/Documents/Codes/web_dev/datePicker/node_modules/@solidjs/router/dist/index.js:1470:49)
at async instantiateModule (file:///mnt/c/Users/almos/Documents/Codes/web_dev/datePicker/node_modules/vinxi/node_modules/vite/dist/node/chunks/dep-CB_7IfJ-.js:52972:5),
statusCode: 500,
fatal: false,
unhandled: true,
statusMessage: undefined,
data: undefined
}
Context 🔦
run new SolidStart project in dev mode successfully. Old projects run fine.
Your environment 🌎
System:
  OS Name: Microsoft Windows 11 Home
  OS Version: 10.0.22631 N/A Build 22631
  System Type:               x64-based PC
  Processor(s):              1 Processor(s) Installed.
                             [01]: Intel64 Family 6 Model 154 Stepping 3 GenuineIntel ~2700 Mhz
Binaries:
  Node: v20.13.1
  npm: 10.9.0

same issue

I had the same issue as well. Using pnpm create solid@latest, pnpm install, pnpm dev. Didn't give the same issues.

Same issue. I'm running npm version 10.9.0 and node version v22.11.0 on MacOS.

Same Problem.  :( ... checked some (not all!) package-versions and they all seem to be the same as in my working projects

Also observed with npm on macos, but works with pnpm

I was able to reproduce this by updating to Vite 6 on the main project. So it is some sort of mismatch on versioning I think. I do use pnpm to be fair so I hadn't noticed it on any of the projects or examples until I made the vite 6 change. We also happen to be working on updating Vinxi and Vite versions so there should be a release soon that has all the matching versions again. I'm not sure how wrong versions are getting included. Something to do with package resolution and locking I guess but I'm gathering it has to do with sub dependencies depending on different versions of Vite.

Hi Rayan! I would like to ask about deployment solid start. Where can I do that?

Same issue on every pnpm create solid@latest example I've used.
I did investigate further using hackernews example using a 3 weeks old sandbox hackernews example in my local env
I've done the following steps:
pnpm create solid@latest
pnpm install
pnpn dev

At this stage I had the Client-only API on the server side error than I did
rm -Rf node_modules
# copy the pnpm-lock.yaml from the 3 weeks old sandbox
pnpm install
pnpm dev

Everything works with the old libs lock references I did perform a diff between the 2 pnpm-lock.yaml
I think some dependencies upgrade created a regression.
I found vite to have a dependency to a new version 6.0.2
I did force to override on the package.json with vite: 5.4.10
and it works.
This is my new package.json
{
  "name": "example-hackernews",
  "type": "module",
  "scripts": {
    "dev": "vinxi dev",
    "build": "vinxi build",
    "start": "vinxi start"
  },
  "dependencies": {
    "@solidjs/router": "^0.15.0",
    "@solidjs/start": "^1.0.10",
    "solid-js": "^1.9.2",
    "vinxi": "^0.4.3"
  },
  "pnpm": {
    "overrides": {
      "vite": "5.4.10"
    }
  },
  "engines": {
    "node": ">=18"
  }
}

I think is something specifically with<EMAIL_ADDRESS>I did override with version<EMAIL_ADDRESS>and it works.

This package.json works for NPM (added "overrides"):
{
  "name": "example-basic",
  "type": "module",
  "scripts": {
    "dev": "vinxi dev",
    "build": "vinxi build",
    "start": "vinxi start",
    "version": "vinxi version"
  },
  "dependencies": {
    "@solidjs/meta": "^0.29.4",
    "@solidjs/router": "^0.15.0",
    "@solidjs/start": "^1.0.10",
    "solid-js": "^1.9.2",
    "vinxi": "^0.4.3"
  },
  "overrides": {
    "vite": "5.4.10"
  },
  "engines": {
    "node": ">=18"
  }
}

@Lunatic83 , is vite 6.0.3 any better?

I just tried 6.0.3 and it's still broken 😭
{
  "name": "example-basic",
  "type": "module",
  "scripts": {
    "build": "vinxi build",
    "dev": "vinxi dev",
    "start": "vinxi start",
    "version": "vinxi version"
  },
  "dependencies": {
    "@solidjs/meta": "^0.29.4",
    "@solidjs/router": "^0.15.0",
    "@solidjs/start": "^1.0.10",
    "solid-js": "^1.9.3",
    "vinxi": "^0.4.3"
  },
  "pnpm": {
    "overrides": {
      "vite": "6.0.3"
    }
  },
  "engines": {
    "node": ">=18"
  }
}

@caseybaggz what if you use vinxi 0.5.1?

@caseybaggz what do you see with vinxi 0.5.1?

Yes!
Working package.json v& pnPm
{
  "name": "example-basic",
  "type": "module",
  "scripts": {
    "build": "vinxi build",
    "dev": "vinxi dev",
    "start": "vinxi start",
    "version": "vinxi version"
  },
  "dependencies": {
    "@solidjs/meta": "^0.29.4",
    "@solidjs/router": "^0.15.0",
    "@solidjs/start": "^1.0.10",
    "solid-js": "^1.9.3",
    "vinxi": "^0.5.1"
  },
  "engines": {
    "node": ">=18"
  }
}

Explicitly downloading vite@5 in the packages seem to solve the issue.
Maybe it's a peer deps issue from vinxi?

@MengLinMaker , in combination with which vinxi versions?

Tried importing with clientOnly, failed. Saw this, fixed dependency versions, failed. Downloaded pnpm, tried again, failed. I was excited to revamp an old website with the framework I learned web development with, but it would be stupid of me to continue trying!

@MengLinMaker , in combination with which vinxi versions?

<EMAIL_ADDRESS>with vite@5

@romanobro56 Probably tried SolidStart at an unlucky time. This was never an issue when I started.
I think using an older version of vinxi or vite should be a good temporary workaround.

Can confirm you can fix-forward by upgrading vinxi to ^0.5.1. Seems the better option than downgrading vite?

While the basic app boilerplate was working for me with vinxie 0.5 and vite 6, I was running into issues later when adding real application code (and vite plugins). But downgrading to vinxie 0.4 and vite 5 as suggested here also did not fix the issue for me.
I have this reproducible in this PR of another project. And looking at that case I can't really confirm the theory that vite 6 is leaking into the dependency graph somehow. This is a monorepo using pnpm, and so far I have seen pnpm do a pretty good job not leaking extraneous dependencies as others do. In that solid-start app, when I go into node_modules/vinxie and call require.resolve('vite') in node REPL (just looking into the folder does not tell you the truth how modules get resolved with pnpm's symlink trickery) it does return a path with vite v5. And in the error stack I also see only references to pnpm node_modules folders with vite 5 in them. So I think there must be something more in play here...

@simonihmig I can repro the error in your PR, with vinxi 0.4.3 / vite 5. Paradoxically, I don't see the error when using the main branch with vinxi 0.5.1

Paradoxically, I don't see the error when using the main branch with vinxi 0.5.1

Yeah, as I said earlier, for the plain starter project output the combination vinxie 0.5.1 / vite 6 used to work, but started to show other issues when adding some real code (in this PR).

When using basic template for initializing package, it works ok. But when the package moved to a monorepo with npm workspaces, dev script run is broken with error below. The bare template works fine in both cases.
9:06:35 PM [vite] Error when evaluating SSR module /<EMAIL_ADDRESS>|- Error: Client-only API called on the server side. Run client-only code in onMount, or conditionally run client-only component with <Show>.
    at Module.notSup (file:///home/alex/hobby/solid-project/node_modules/solid-js/web/dist/server.js:1136:9)
    at eval (/home/alex/hobby/solid-project/node_modules/@solidjs/router/dist/index.js:1625:49)
    at async instantiateModule (file:///home/alex/hobby/solid-project/node_modules/vinxi/node_modules/vite/dist/node/chunks/dep-CB_7IfJ-.js:52972:5)

Dependencies:
{
  "dependencies": {
    "@solidjs/meta": "^0.29.4",
    "@solidjs/router": "^0.15.0",
    "@solidjs/start": "^1.0.10",
    "solid-js": "^1.9.2",
    "vinxi": "^0.4.3"
  },
  "overrides": {
    "vite": "5.4.10"
  }
}


[WIP] New about page

Resolves #148
Creates a new about page layout and widgets to follow @thehamspecial 's design mocks.
As part of this, moves the Twitter API calls to a service package to separate the logic.
** Out of scope **
The following items need to be addressed, but I believe they should be in separate PRs:

Absolute text should be replaced with String IDs for localization
String IDs and text should be moved into data/ and loaded

I want to separate this page from that effort, so will save that for a followup (esp since we don't have the strings defined yet).
How to test

Vuetify preview - check against mocks
Locally - check against mocks

Screenshots

@thehamspecial please take a look at this when you get a chance (the netlify preview)
There's currently a first-load issue again on the tweets, so you'll need to do one refresh, but the layout should be there regardless. Let me know if you want changes.

There's currently a first-load issue again on the tweets, so you'll need to do one refresh, but the layout should be there regardless. Let me know if you want changes.

Fixed via asycnData.

@ermish I think I've gone through the comments - let me know if you have anything you insist on that's left.

Changes look good enough if you want to merge in and potentially clean up anything after. At this point, I just want us to get this merged in!

Awesome, done. I can then start getting the i18n strings ported within the next day or two.

Fast follow for keys:
https://github.com/ourjapanlife/findadoc-localization/pull/110
I can put ja translations in after we merge this.


fix certificate unknown authority error using self-sign-ca scripts

After run self-signed-ca.sh instead using cert-manager and apply the sample InferenceService yaml, there is certificate-signed-by-unknown-authority error. this is because the self-signed-ca scripts misses some webhook patches for 0.6.0-rc0 release.

Thanks @haijohn for the contribution ! Looks great!
/lgtm
/approve

/ok-to-test


exclude duplicate error checks

exclude duplicate error checks

@rultor merge

@rultor merge

@graur OK, I'll try to merge now. You can check the progress of the merge here

@rultor merge

@graur Done! FYI, the full log is here (took me 3min)


Add editor shortcuts for our custom icons

Motivation

I noticed that it seems to be pretty easy to define shortcuts (e.g. Alt+I+1) for own functions inside the TinyMCE and I also received some feature requests by municipalities for this. As this isn't a big change and probably benefits some municipalities a lot, I would think of it as a "quick win" that we should implement rather sooner then later.
Proposed Solution

Add the TinyMCE in-built shortcuts to our addIcon functionality. See. https://www.tiny.cloud/blog/creating-keyboard-shortcuts-tinymce/

So does this mean the app should look for any un-listed icons in the svg folded and add them? Or you give users a popup to upload an svg file?


Login/connect to a Perforce server using username/password

The extension keeps denying any request with this error message:

Perforce Log Output
p4.exe info
ERROR:
Error: Command failed: p4.exe print -q -o "C:\Users...\AppData\Local\Temp\tmp-....." "c:\p4......"
c:\p4...... - must create client 'my-computer-name' to access local files.

Can you confirm you have a .p4settings file and you are logged in ?

Please update to version 1.1.0 and try the login command.


WIP: upgrade kubernetes deps to 0.19.2, use golang 1.15

this includes:

update to latest code-generator so we can generate 0.19.2 compliant clients

/test all


incorporate() fails with multi-element fields in info_tabular()

Description
When info_tabular() is provided a multi-element argument to one of its dots parameters, incorporate() fails with error All unnamed arguments must be length 1.
Without running incorporate(), the processing succeeds and the multi-element input is nicely turned into multiple lines in the output.
This can be worked around but the multi-element input is a succinct way of creating multi-line description fields, also making the source code more legible.
Reproducible example
library(pointblank)

# bug

x <- create_informant(tbl = mtcars,
                 label = "Codebook") %>%
  info_tabular(Info = c("Line 1",
                        "Line 2"),
               `Additional` = "Extra info") %>%

  info_snippet(
    snippet_name = "min_wt",
    fn = snip_lowest(column = "wt")
  ) %>%
  info_columns("wt",
               Popis = "weight",
               Min = "minimum is {min_wt}") %>%
  incorporate()

#>

#> ── Incorporation Started - there is a single snippet to process ────────────────

#> ✓ Information gathered.

#> ✓ Snippets processed.

#> Error: All unnamed arguments must be length 1

# snippet and incorporate, single-element info

x <- create_informant(tbl = mtcars,
                 label = "Codebook") %>%
  info_tabular(Info = c("Line 1"),
               `Additional` = "Extra info") %>%
  info_snippet(
    snippet_name = "min_wt",
    fn = snip_lowest(column = "wt")
  ) %>%
  info_columns("wt",
               Popis = "weight",
               Min = "minimum is {min_wt}") %>%
  incorporate()

#>

#> ── Incorporation Started - there is a single snippet to process ────────────────

#> ✓ Information gathered.

#> ✓ Snippets processed.

#> ✓ Information built.

#>

#> ── Incorporation Completed ─────────────────────────────────────────────────────

# no snippet, no incorporate

x <- create_informant(tbl = mtcars,
                 label = "Codebook") %>%
  info_tabular(Info = c("Line 1",
                        "Line 2"),
               `Additional` = "Extra info") %>%
  info_columns("wt",
               Popis = "weight")

# no snippet, incorporate, two-element info

x <- create_informant(tbl = mtcars,
                 label = "Codebook") %>%
  info_tabular(Info = c("Line 1",
                        "Line 2"),
               `Additional` = "Extra info") %>%
  info_columns("wt",
               Popis = "weight") %>%
  incorporate()

#>

#> ── Incorporation Started ───────────────────────────────────────────────────────

#> ✓ Information gathered.

#> Error: All unnamed arguments must be length 1

Created on 2021-11-24 by the reprex package (v2.0.0)
Expected result
I would expect the pipeline to handle multi-element input identically regardless of whether snippets and incorporate() are part of the flow
Session info
R version 4.1.0 (2021-05-18)
Platform: x86_64-apple-darwin17.0 (64-bit)
Running under: macOS Big Sur 11.6.1
Matrix products: default
LAPACK: /Library/Frameworks/R.framework/Versions/4.1/Resources/lib/libRlapack.dylib
locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
attached base packages:
[1] stats     graphics  grDevices datasets  utils     methods   base
other attached packages:
[1] pointblank_0.9.0 forcats_0.5.0    stringr_1.4.0    dplyr_1.0.7
[5] purrr_0.3.4      readr_2.0.2      tidyr_1.1.3      tibble_3.1.3
[9] ggplot2_3.3.3    tidyverse_1.3.0
loaded via a namespace (and not attached):
[1] httr_1.4.2         sass_0.4.0         jsonlite_1.7.2     here_1.0.1
[5] modelr_0.1.8       assertthat_0.2.1   highr_0.8          renv_0.14.0
[9] cellranger_1.1.0   yaml_2.2.1         ptrr_<IP_ADDRESS>00    gdtools_0.2.3
[13] Rttf2pt1_1.3.8     pillar_1.6.2       backports_1.2.1    glue_1.4.2
[17] extrafontdb_1.0    digest_0.6.27      checkmate_2.0.0    rvest_0.3.6
[21] colorspace_2.0-0   htmltools_0.5.2    hrbrthemes_0.8.0   clipr_0.7.1
[25] pkgconfig_2.0.3    broom_0.7.3        haven_2.3.1        scales_1.1.1
[29] processx_3.5.2     tzdb_0.1.2         styler_1.5.1       generics_0.1.0
[33] ellipsis_0.3.2     withr_2.4.2        cli_3.0.1          magrittr_2.0.1
[37] crayon_1.4.2       readxl_1.3.1       evaluate_0.14      ps_1.6.0
[41] fs_1.5.0           fansi_0.5.0        xml2_1.3.2         tools_4.1.0
[45] data.table_1.14.0  hms_1.0.0          lifecycle_1.0.0    munsell_0.5.0
[49] reprex_2.0.0       targets_<IP_ADDRESS>00 callr_<IP_ADDRESS>00   compiler_4.1.0
[53] systemfonts_1.0.1  rlang_0.4.11       grid_4.1.0         gt_0.3.1
[57] rstudioapi_0.13    igraph_1.2.6       rmarkdown_2.11     gtable_0.3.0
[61] codetools_0.2-18   blastula_0.3.2     DBI_1.1.0          R6_2.5.0
[65] lubridate_1.7.10   knitr_1.36         fastmap_1.1.0      extrafont_0.17
[69] utf8_1.2.2         rprojroot_2.0.2    commonmark_1.7     stringi_1.5.3
[73] Rcpp_1.0.6         vctrs_0.3.8        dbplyr_2.1.1       tidyselect_1.1.1
[77] xfun_0.24

I think this should be changed to work as you expect. Thanks for filing this issue!

Thanks for this - unfortunately I'm still seeing the same result when running the first reprex using the current HEAD version (f6c16a99).

I'm so sorry. I worded that terribly (and confused myself after re-reading it just now).
What I mean is that I ought to fix this because it's a worthy bug. This is what you get when you type something quickly on a mobile phone :(. But, this will be fixed soon. I'm even bumping up the priority on this now.

No worries at all - re-reading this I think the correct interpretation of what you wrote is the more plausible one :) i.e. it was me misreading it. Apologies for jumping the gun (I just wanted to make sure I provide feedback and not drop the ball) and no hurry at all.


Rename start to preview in the CLI and package scripts

#1163
Before submitting the PR, please make sure you do the following

[x] It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
[x] This message body should clearly illustrate what problems it solves.
[ ] Ideally, include a test that fails without this PR but passes with it.

Tests

[x] Run the tests with pnpm test and lint the project with pnpm lint

Changesets

[x] If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpx changeset and following the prompts

thanks, this is a good change


Docs: add runtime link to main page

Summary
Add runtime documentation link to main page.
Details and comments
Per request from community / digital team we need to add runtime docs link to main page and remove intro section.
Design mock

Rendered docs

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Iskandar Sitdikov seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

@y4izus FYI

@jakelishman Thanks for the approval. I agree with you. Can you please add me and @y4izus as the code owners for docs? If this should be done in a form of a PR, can you please point me to the file that needs to be changed? Thanks!

Thank you!


Fix 'envenomation' terms

Hello,
After much discussion with the multi-org group @geneontology/multiorganism-working-group
@Antonialock and @FJungo
We propose to change all the terms of pattern 'envenomation resulting in x' to 'toxin-mediated as shown below:

Children of   envenomation
New term label

envenomation resulting in modulation of   vasoactive intestinal polypeptide receptor activity in other organism
toxin-mediated modulation of vasoactive intestinal polypeptide receptor   activity in another organism

envenomation resulting in modulation of   cell migration in other organism
toxin-mediated modulation of cell migration in another organism

envenomation resulting in modulation of   blood pressure in other organism
toxin-mediated modulation of blood pressure in another organism

envenomation resulting in hemolysis in   other organism
toxin-mediated hemolysis in another organism

envenomation resulting in modulation of   blood coagulation in other organism
toxin-mediated modulation of blood coagulation in another organism

envenomation resulting in modulation of   complement activation, alternative pathway in other organism
toxin-mediated modulation of complement activation, alternative pathway   in another organism

envenomation resulting in hemorrhagic   damage to other organism
toxin-mediated hemorrhagic damage to other organism

envenomation resulting in fibrinolysis in   other organism
toxin-mediated fibrinolysis in another organism

envenomation resulting in modulation of   acid-sensing ion channel activity in other organism
toxin-mediated modulation of acid-sensing ion channel activity in another   organism

envenomation resulting in modulation of   calcium channel activity in other organism
toxin-mediated modulation of calcium channel activity in another organism

envenomation resulting in modulation of   ion channel activity in other organism
toxin-mediated modulation of ion channel activity in another organism

envenomation resulting in modulation of   transmission of nerve impulse in other organism
toxin-mediated modulation of transmission of nerve impulse in another   organism

envenomation resulting in modulation of   complement activation in other organism
toxin-mediated modulation of complement activation in another organism

envenomation resulting in modulation of   signal transduction in other organism
toxin-mediated modulation of signal transduction in another organism

envenomation resulting in modulation of   glucagon-like peptide receptor 1 activity in other organism
toxin-mediated modulation of glucagon-like peptide receptor 1 activity in   another organism

envenomation resulting in modulation of G   protein-coupled receptor activity in other organism
toxin-mediated modulation of G protein-coupled receptor activity in   another organism

envenomation resulting in modulation of   receptor activity in other organism
toxin-mediated modulation of receptor activity in another organism

envenomation resulting in modulation of   apoptotic process in other organism
toxin-mediated modulation of apoptotic process in another organism

envenomation resulting in modulation of   complement activation, classical pathway in other organism
toxin-mediated modulation of complement activation, classical pathway in   another organism

envenomation resulting in modulation of   complement activation, lectin pathway in other organism
toxin-mediated modulation of complement activation, lectin pathway in   another organism

envenomation resulting in   fibrinogenolysis in other organism
toxin-mediated fibrinogenolysis in another organism

envenomation resulting in blood   agglutination in other organism
toxin-mediated blood agglutination in another organism

envenomation resulting in depletion of   circulating fibrinogen in other organism
toxin-mediated depletion of circulating fibrinogen in another organism

envenomation resulting in cytolysis in   other organism
toxin-mediated cytolysis in another organism

envenomation resulting in blood vessel   extracellular matrix damage, causing hemorrhagic damage in other organism
toxin-mediated blood vessel extracellular matrix damage, causing   hemorrhagic damage in another organism

envenomation resulting in modulation of   mast cell degranulation in other organism
toxin-mediated modulation of mast cell degranulation in another organism

envenomation resulting in modulation of   platelet aggregation in other organism
toxin-mediated modulation of platelet aggregation in another organism

envenomation resulting in induction of   edema in other organism
toxin-mediated induction of edema in another organism

envenomation resulting in impairment of   hemostasis in other organism
toxin-mediated impairment of hemostasis in another organism

envenomation resulting in modulation of   sensory perception of pain in other organism
toxin-mediated modulation of sensory perception of pain in another   organism

envenomation resulting in damage of   muscle extracellular matrix in other organism
toxin-mediated damage of muscle extracellular matrix in another organism

envenomation resulting in modulation of   voltage-gated potassium channel activity in other organism
toxin-mediated modulation of voltage-gated potassium channel activity in   another organism

envenomation resulting in modulation of   voltage-gated sodium channel activity in other organism
toxin-mediated modulation of voltage-gated sodium channel activity in   another organism

envenomation resulting in muscle damage   in other organism
toxin-mediated muscle damage in another organism

envenomation resulting in myocyte killing   in other organism
toxin-mediated myocyte killing in another organism

envenomation resulting in negative   regulation of acid-sensing ion channel activity in other organism
toxin-mediated negative regulation of acid-sensing ion channel activity   in another organism

envenomation resulting in negative   regulation of blood coagulation in other organism
toxin-mediated negative regulation of blood coagulation in another   organism

envenomation resulting in negative   regulation of calcium channel activity in other organism
toxin-mediated negative regulation of calcium channel activity in another   organism

envenomation resulting in negative   regulation of cell migration in other organism
toxin-mediated negative regulation of cell migration in another organism

envenomation resulting in negative   regulation of complement activation, alternative pathway in other organism
toxin-mediated negative regulation of complement activation, alternative   pathway in another organism

envenomation resulting in negative   regulation of complement activation, classical pathway in other organism
toxin-mediated negative regulation of complement activation, classical   pathway in another organism

envenomation resulting in negative   regulation of complement activation, lectin pathway in other organism
toxin-mediated negative regulation of complement activation, lectin   pathway in another organism

envenomation resulting in negative   regulation of heart rate of other organism
toxin-mediated negative regulation of heart rate of other organism

envenomation resulting in negative   regulation of high voltage-gated calcium channel activity in other organism
toxin-mediated negative regulation of high voltage-gated calcium channel   activity in another organism

envenomation resulting in negative   regulation of low voltage-gated calcium channel activity in other organism
toxin-mediated negative regulation of low voltage-gated calcium channel   activity in another organism

envenomation resulting in negative   regulation of platelet aggregation in other organism
toxin-mediated negative regulation of platelet aggregation in another   organism

envenomation resulting in negative   regulation of sensory perception of pain in other organism
toxin-mediated negative regulation of sensory perception of pain in   another organism

envenomation resulting in negative   regulation of voltage-gated calcium channel activity in other organism
toxin-mediated negative regulation of voltage-gated calcium channel   activity in another organism

envenomation resulting in negative   regulation of voltage-gated potassium channel activity in other organism
toxin-mediated negative regulation of voltage-gated potassium channel   activity in another organism

envenomation resulting in negative   regulation of voltage-gated sodium channel activity in other organism
toxin-mediated negative regulation of voltage-gated sodium channel   activity in another organism

envenomation resulting in occlusion of   the pore of voltage-gated potassium channel in other organism
toxin-mediated occlusion of the pore of voltage-gated potassium channel   in another organism

envenomation resulting in plasminogen   activation in other organism
toxin-mediated plasminogen activation in another organism

envenomation resulting in pore formation   in membrane of other organism
toxin-mediated pore formation in membrane of other organism

envenomation resulting in positive   regulation of G protein-coupled receptor activity in other organism
toxin-mediated positive regulation of G protein-coupled receptor activity   in another organism

envenomation resulting in positive   regulation of acid-sensing ion channel activity in other organism
toxin-mediated positive regulation of acid-sensing ion channel activity   in another organism

envenomation resulting in positive   regulation of argininosuccinate synthase activity in other organism
toxin-mediated positive regulation of argininosuccinate synthase activity   in another organism

envenomation resulting in positive   regulation of blood coagulation in other organism
toxin-mediated positive regulation of blood coagulation in another   organism

envenomation resulting in positive   regulation of blood pressure in other organism
toxin-mediated positive regulation of blood pressure in another organism

envenomation resulting in positive   regulation of cell migration in other organism
toxin-mediated positive regulation of cell migration in another organism

envenomation resulting in positive   regulation of complement activation, alternative pathway in other organism
toxin-mediated positive regulation of complement activation, alternative   pathway in another organism

envenomation resulting in positive   regulation of complement activation, classical pathway in other organism
toxin-mediated positive regulation of complement activation, classical   pathway in another organism

envenomation resulting in positive   regulation of complement activation, lectin pathway in other organism
toxin-mediated positive regulation of complement activation, lectin   pathway in another organism

envenomation resulting in positive   regulation of glucagon-like peptide receptor 1 activity in other organism
toxin-mediated positive regulation of glucagon-like peptide receptor 1   activity in another organism

envenomation resulting in positive   regulation of mast cell degranulation in other organism
toxin-mediated positive regulation of mast cell degranulation in another   organism

envenomation resulting in positive   regulation of platelet aggregation in other organism
toxin-mediated positive regulation of platelet aggregation in another   organism

envenomation resulting in positive   regulation of signal transduction in other organism
toxin-mediated positive regulation of signal transduction in another   organism

envenomation resulting in positive   regulation of vasoactive intestinal polypeptide receptor activity in other   organism
toxin-mediated positive regulation of vasoactive intestinal polypeptide   receptor activity in another organism

envenomation resulting in positive   regulation of voltage-gated sodium channel activity in other organism
toxin-mediated positive regulation of voltage-gated sodium channel   activity in another organism

envenomation resulting in proteolysis in   other organism
toxin-mediated proteolysis in another organism

envenomation resulting in slowing of   activation kinetics of voltage-gated potassium channel in other organism
toxin-mediated slowing of activation kinetics of voltage-gated potassium   channel in another organism

envenomation resulting in vasodilation in   other organism
toxin-mediated vasodilation in another organism

envenomation resulting in zymogen   activation in other organism
toxin-mediated zymogen activation in another organism

Hey @pgaudet, I'm not crazy about the "toxin-mediated" language. All "toxin" means is that it's bad for...something. But does it lead to death? Not always. There are plenty of scorpion venom components that kill insects but not mice. There are also scorpion venom components that kill both (similar mechanism). There are venom components that don't kill but merely provide systemic dysregulation (the  mouse collapses) for a short period of time.
I like emphasizing the effect, and the target needs to be specified, but what makes a toxin a toxin?
Also, do these things have annotations? The term "toxin-mediated slowing of activation kinetics of voltage-gated potassium channel in another organism" sounds like it was formulated by an electrophysiologist...not that there's anything wrong with electrophysiologists.

But are "toxin" and "toxin-mediated" any worse in these respects that "venom" and "envenomation"? Don't both sets of terms describe phenotypes that are dependent on circumstances (like who bites whom) rather than molecular details of processes (like esterase enables hydrolysis of neurotransmitter)?
Caveat: I'm stepping very late into a complicated conversation; apologies is this raises issues that have already been addressed.

@deustp01; Nah, the more the merrier.
I don't have a solution. I'm just noting that toxin is a lot less specific than venom. With venom you know that some critter is stinging or biting another critter and afflicting it with a peptide/protein that it made in some secretory gland. Invoking a "toxin" leads to looser formulations.
In microbial pathogenesis, we distinguish bacterial toxins from toxic effectors in that the latter have to be injected into a host cell while the former are secreted from the bug and must mediate their own uptake into the host cell. Venom components usually bind to a cellular receptor and agonize or antagonize. But they can also bind to extracellular components (coagulation proteins, say) and mess with them.
I want these terms to:

Capture that the context is an interspecies interaction ("in another organism")
Capture the target ("voltage-gated ion channel")
Capture the direction of the change (suppression/inactivation/enhancement/activation--I do NOT like positive or negative regulation unless some allosteric effects are happening--that sounds too much like homeostatic inter-organism processes are occurring instead of a hijacking of a normal function which venoms and toxins do)

Look at the term: "toxin-mediated positive regulation of complement activation, alternative pathway in another organism" is the venom/toxin really "positively regulating" complement activation? Or is it forcibly turning on the pathway and ginning up inflammation "to 11"? I think the latter is more likely.

Hi @genegodbold
There are multiple aspects here - you are right that 'positive regulation' is misleading for processes occurring in other organisms, but let's fix this separately. (The current proposal is to use 'induction' and 'suppression' for inter-species interactions, but I am not sure these are always right either. )
WRT venom: the issue here is that if we use venom we also need to describe 'poisons', see https://github.com/geneontology/go-ontology/issues/20347#issue-741103889
One solution is to do away with these completely, and have for example:
-.  induction of programmed cell death in another organism

.. effector-mediated induction of programmed cell death in host

so that for  toxins and venoms, we'd use the parent class "induction of programmed cell death in another organism".
(instead of another sibling of 'effector-mediated...' that would be 'toxin.-mediated induction of programmed cell death in another organism)
Do you prefer that solution? Maybe the 'toxin-mediated' doesn't add very much.
Thanks, Pascale

Hey @pgaudet
My feeling is the term "induction" blurs agency. How so? The second definition of the American Heritage Dictionary indicates it means "to bring about or stimulate the occurrence of; cause"
This definition includes effects where the target organism/host brings about a reaction to the instigating factor from "another organism". As in the case of effector-mediated immunity (or, in plant pathogenesis lingo "effector-triggered immunity/ETI") the host machinery is there to both detect and react to the provoking stimulus. For plants, apoptosis of the infected cell is what happens when everything is going according to plan for the host.
But in the case of these (former) envenomation terms, there is no "instigating factor", the target organism is the victim of the offending effector. The effector does something to the target organism that is entirely unwanted and deleterious.
I have come to believe that we should have a way to categorize provoking reactions where the host/target organism is doing the work of detection and instigation (as in the case of spike protein from SARS-CoV-2 or bacterial lipopeptides binding to host TLR2 or bacterial lipopolysaccharide (LPS/endotoxin) binding to TLR4 and "inducing" inflammation) BUT I don't think these terms that we are considering above are in that category. These terms (above) should be describing things that the instigating organism is DOING to the target organism/host that the target organism/host does NOT want.
Penelope's comments under the envenomation/poison tag are cogent. For some reason, though, I want to avoid the terms "venom" "toxin" and "poison" entirely in the term name because I think the are too limiting. However venom/toxin/poison might (or even should) be mentioned in the synonyms or use cases.

@pgaudet One way to maybe get around this is to have something like "induction of programmed cell death in another organism" (though this doesn't recognize that there are something like 7 types of programmed cell death from the non-inflammatory to the hyper-inflammatory) as the parent and then under that two children where No. 1 covers programmed cell death that is driven by the host detection and reaction and No 2 covers programmed cell death that is driven by the effector forcibly cleaving a host caspase or IL-1b of the inflammasome to make apoptosis or inflammation happen regardless of the machinery of the host.

@pgaudet We found this article from 2014 in today's multiorg discussion on envenomation: https://onlinelibrary.wiley.com/doi/10.1111/brv.12062: Poisons, toxungens, and venoms: redefining and classifying toxic biological secretions and the organisms that employ them
From the abstract:
"...We further propose a system to classify toxic organisms with respect to delivery mechanism (absent versus present), source (autogenous versus heterogenous), and storage of toxins (aglandular versus glandular). As examples, a frog that acquires toxins from its diet, stores the secretion within cutaneous glands, and transfers the secretion upon contact or ingestion would be heteroglandular–poisonous; an ant that produces its own toxins, stores the secretion in a gland, and sprays it for defence would be autoglandular–toxungenous; and an anemone that produces its own toxins within specialized cells that deliver the secretion via a penetrating wound would be autoaglandular–venomous. Adoption of our scheme should benefit our understanding of both proximate and ultimate causes in the evolution of these toxins."


Move Nanvl and random to datafusion-functions

Is your feature request related to a problem or challenge?
As part of https://github.com/apache/arrow-datafusion/issues/9285 move the nanvl and random functions to the new datafusion-functions/math crate in the new structure.
Describe the solution you'd like
Functions are migrated to the new crate and use the new patterns as described in https://github.com/apache/arrow-datafusion/issues/9286 & https://github.com/apache/arrow-datafusion/pull/9216
Describe alternatives you've considered
No response
Additional context
No response

take


Gettting error on yo fountain-webapp

Type of issue
Not able to setup project using yeoman. getting following error whey i try to install fountain-webapp.
Yo version is 1.8.5
C:\Hema\Philips\H2H\project>yo fountain-webapp
C:\Users\310242265\AppData\Roaming\npm\node_modules\generator-fountain-webapp\node_modules\fountain-generator\lib\Base.js:21
const {framework, modules, js} = this.options;
^
SyntaxError: Unexpected token {
at exports.runInThisContext (vm.js:53:16)
at Module._compile (module.js:373:25)
at Object.Module._extensions..js (module.js:416:10)
at Module.load (module.js:343:32)
at Function.Module._load (module.js:300:12)
at Module.require (module.js:353:17)
at require (internal/module.js:12:17)
at Object. (C:\Users\310242265\AppData\Roaming\npm\node_modules\generator-fountain-webapp\node_modules\fountain-generator\index.js:2:9)
at Module._compile (module.js:409:26)
at Object.Module._extensions..js (module.js:416:10)

My environment

OS version/details: eg. Windows 7 64-bit
Node version: 4.4.4 (run node --version in your terminal)
npm version: 4.4.1 (run npm --version in your terminal)
Version of yo : 1.8.5 (run yo --version in your terminal)

Expected behavior

Current behavior

Steps to reproduce the behavior
Command line output
Paste your error output over here

You need to use a recent version of Node.js (>= 4)

@SBoudrias http://yeoman.io/codelab/setup.html states that you need Node.js v4 or higher, as you do as well, but @hemachandrav is using 4.4.4 and I am experiencing this issue with 4.4.1. Should it be >= v5, or is there a bug here?

Okay, according to #516, the version of Node needs to be 6 or higher.

@zckrs Hey, any chance you're requiring Node 6? If so, I really think generator-fountain-webapp should hold a bit on es6 features and keep support for v4 given it's still widely used.
@betweenbrain I'd suggest opening an issue on the generator-fountain-webapp repository.

Nodejs : v6.11, v7.7
NPM : v5
Nothing works, error :
"events.js:160 -> throw er; // Unhandled 'error' event


6.0.1 Includes binaries for Node 10 for some platforms, despite only Node 12 being supported.

NPM version (npm -v): not relevant
Node version (node -v): not relevant
Node Process (node -p process.versions): not relevant
Node Platform (node -p process.platform): not relevant
Node architecture (node -p process.arch): not relevant
node-sass version (node -p "require('node-sass').info"): not relevant
npm node-sass versions (npm ls node-sass): not relevant

Looks like in the latest release, only the win32-x64 Node 10 binary was removed from the assets, but not all the other platform binaries for Node 10. I believe these were included in error and should be removed as well to avoid confusion.

Nice catch! This has been addressed for 6.0.1 but not 6.0.0 just in case someone out there is being cheeky with the node 10 binaries.


Support phx-change on all elements with @LiveBinding

You can now use phx-change in place of native_binding to manually update the values. This was implemented already for form elements (which use @FormState), but is now possible for other types of element, such as List.
On form elements, the value sent will be in the format %{ "value" => new_value }. If you set a name attribute, it will become %{ "your_custom_name" => new_value }.
Other types of elements will use the name of the attribute (such as, %{ "selection" => new_value }). This allows multiple attributes to send change events without collisions.
Here's an example converting code that uses native_binding to use phx-change.

defmodule TestBedWeb.IndexLive do
  use TestBedWeb, :live_view
  use LiveViewNative.LiveView

  native_binding :selection, :string, default: "1"

  def render(assigns) do
    ~SWIFTUI"""
    <List selection="selection">
      <Text :for={item <- 1..10} id={"#{item}"}>
        <%= item %>
      </Text>
    </List>
    """
  end
end

defmodule TestBedWeb.IndexLive do
  use TestBedWeb, :live_view
  use LiveViewNative.LiveView

  def mount(_params, _session, socket) do
    {:ok, assign(socket, selection: "1")}
  end

  def render(assigns) do
    ~SWIFTUI"""
    <List selection={@selection} phx-change="on_select">
      <Text :for={item <- 1..10} id={"#{item}"}>
        <%= item %>
      </Text>
    </List>
    """
  end

  def handle_event("on_select", %{ "selection" => new_value }, socket) do
    {:noreply, assign(socket, selection: new_value)}
  end
end

So I want to use this PR as a place to discuss this change. It is a bit of a fork in the road for us and let's lay out all of the pros/cons.
For some background, we've had a value_binding feature in LVN for a while now that allows for a two-way data binding between the server state and the client state. When a value is updated on the client the binding works to update the server state and when the server updates the value the client is updated.
value_binding
Pros
It is far easier/quicker to use and it has been well tested to ensure we're encapsulating all of the needs of SwiftUI. SwiftUI is not a web client so we should expect that solutions developed in LiveView itself were done in the context of what makes sense for the web whereas we are tasked with what makes sense for SwiftUI app and also what makes sense for the other native clients that we hope to support in the future.
Cons
We are deviating away from the expected way that LiveView web works. In that world any state changes on the client that need to be reflected on the server are opt-in through events. In some cases the phx-change event along with a named event and the values that are being passed back as arguments. In this we'd align more closely with the LiveView API contract. Because value_binding works for SwiftUI and makes sense for it doesn't guarantee that it will make sense for other native clients. So we're opening the door to other clients offering their own two way data binding solution. Now this creates divergent API that complicates the learning process.
phx-change
Pros
If we do move toward the phx-change side of things and align more closely with LiveView's own implementation we should make every effort to surface all of the edge cases on where value_binding is solving for us that may be complicated or possibly impossible to solve with the change event handling.  We are also creating a more implicit contract that devlopers are required to implement their own handle_event functions. This gives developers more insight into exactly what is happening under the hood.
Cons
Our team has been happily using value_binding for months and has reported that it works and works well. Deviating from this is unfortunately turning back the clock on a lot of work that went into making this feature work flawlessly.

A few other concerns with the current implementation:

Ecto is a dependency that teams are forced into using. What if they don't want Ecto?
The handle_event('_native_bindings', ...) function doesn't give fine grained control to the developer on how to handle the data once it gets to the server.
there is nothing actually "native" here as this is a pattern that could easily also exist on the web. However, after a few years of LiveView itself being used in production by many this pattern has not emerged. We are pushing something that hasn't naturally come from use cases

One thing that still needs to be solved is how change events are declared for modifiers. Native bindings are used for quite a few modifiers:
sheet(is_presented: :my_presented_binding)

One option would be to send a map with value and change keys instead:
sheet(is_presented: %{ value: @is_presented, change: "presentation_changed" })

Alternatively, we could add an extra key to the modifier for the change event.
sheet(is_presented: @is_presented, change: "presentation_changed")

However, this would limit us to a single event for all bindings on a modifier, whereas the first approach allows for a separate event on each.

@carson-katri this is exactly the type of edge cases I want to continue to surface. If there are any more things that native_binding was solving for us that is now not so easy (or hopefully not "impossible") to solve with this change let's vet it all out

One other thing to consider:
From what I can tell, LV does not support phx-change outside of the context of a form.
Would we need to come up with our own name for this attribute, such as lvn-change? Or is this an acceptable extension of phx-change's behavior?

@carson-katri I believe the change event applies to all eventListeners that support that JS event which I think are all inputs: https://github.com/phoenixframework/phoenix_live_view/blob/9ea1402ce162abac90a1b7aff82e7bd528528e51/assets/js/phoenix_live_view/view.js#L895

To articulate my concerns, managing multiple sources of truth can lead to concurrency issues. If the purpose of persist doesn't create this problem I'm OK with it but if we're just using it for token storage maybe we can find another way to do it?

Disclaimer: I have not used LVN in anger yet. My use case relies on Android support so I was waiting for ElixirConf before tracking the main branch and working on an MVP.
Given that I don't have intimate knowledge of the current design goals I am more inclined to favor the phx-change approaching than the native_binding approach because I suspect that:

It will align better with my current LV knowledge (particularly around Streams and form recovery)
Since I am not a SwiftUI or JetPack Compose expert having less magic in the event handling of the LV code will help me reason about my data-flow and recognize when I need to dig into those frameworks to debug when the behavior deviates from the web UI.
It will allow better code reuse and push deviations down strictly into the presentation layer if web, swiftui, and android all use similar data flow.
I don't care about the ecto dependency because all apps will be cross-platform and need a persistence layer. (I'm not going to use CloudKit for the Web)

Philosophically, I think a strong case can be made that the target audience for this product is not a React Native, Flutter, or Android/iOS consultancy looking for a better cross-platform development story, nor is it an Android or iOS shop looking for a more efficient way to develop their existing native apps, but it is the existing Elixir dev or team looking to add native mobile app support to their SaaS product without hiring a native dev or contracting that work out.  With that audience top of mind, aligning with their current LV practices holds more sway than decreasing the lines of code.
If we are extending existing web LV products onto native then we have to write the camera, location, HealthKit, HomeKit, WidgetKit, VisionOS etc...code de novo anyway, so it makes it much easier to just rewrite the presentation layer code for our existing LV CRUD form-heavy LiveViews and then add on additional modules to handle camera, etc...that we need for mobile, perhaps even using platform specific code.
Lastly, if SwiftUI and Jetpack Compose gain their benefit from avoiding state and being declarative then I don't think we should obfuscate the 'Actions Up' phase of declarative UI interaction. However, this is a DY product, not my product, so make the decision that will increase adoption and generate contract engagement.

@kgautreaux the streams argument is a very good one and I've confirmed with Jose that this very well could be a blocker for the native_binding direction all together. We definitely want to support streams, that work is currently happening in Core right now to get streams supported in our channels client.

I don't have a strong opinion on this immediately but some thoughts that crossed my mind while reading?

Why the change? Especially if DY has been busy cranking with the existing pattern seemingly without issue?
I'm not persuaded that the pattern not emerging on the web is dispositive as to its merits for native GUI apps
There is a lot of boiler plate with the proposal, which is kind of the point of two-way data bindings.
Why is this a choice, why must the current pattern be totally thrown out in favor of the new?

Maybe I'm missing the point (likely) but I can't see a need for this change from what you've written. I don't see what problem is being fixed?
That being said I defer to @bcardarella and @carson-katri on this. The above is just what ran through my mind reading this thread.

@stevegraham I think regardless of the other reasons once I heard that Streams can't be supported by native_binding that's a no-go for me.

One thing that still needs to be solved is how change events are declared for modifiers. Native bindings are used for quite a few modifiers:
sheet(is_presented: :my_presented_binding)

One option would be to send a map with value and change keys instead:
sheet(is_presented: %{ value: @is_presented, change: "presentation_changed" })

Alternatively, we could add an extra key to the modifier for the change event.
sheet(is_presented: @is_presented, change: "presentation_changed")

However, this would limit us to a single event for all bindings on a modifier, whereas the first approach allows for a separate event on each.

@carson-katri can you roll back that commit you made to address ☝ let's spend some time disecting the problem so we can ensure we're putting together the best API

@stevegraham I think regardless of the other reasons once I heard that Streams can't be supported by native_binding that's a no-go for me.

Do I understand this correctly: it is not possible to use streams if native_binding is used in the same liveview for anything, even something completely unrelated?

Seems like you could keep the native_binding API if its implementation was a macro that generated code semantically equivalent to the code on the right, i.e. enclose mount in a function that sets the initial "binding" value, generates an "update_BINDINGNAME" event handler, and the underlying view implementations knows to use phx-change to update the "binding". You could have the exact same API, no?

Having two difference ways to do something is a big red flag for me.

I support the new approach with handle_event for re-usability of code between web and native 👍

It's not two ways to do it. It's the same way.

If you've made your mind up IMO you should close this issue to be respectful of other people's time.
I see a way to keep the API as-is whilst implementing it to generate semantically equivalent code to the right in @carson-katri's example, but it doesn't need to be in LVN core. It could be implemented by anyone and published as a hex library.
The only thing I would suggest that would make the library solution nicer is keeping the SWIFTUI hex template API the same, i.e.
<List selection="selection">
  <Text :for={item <- 1..10} id={"#{item}"}>
    <%= item %>
  </Text>
</List>

selection="selection" means it's concerned with an assign called @selection and assumes there is an event handler update_selection that updates @selection implemented in the LV. You might think this this is too magical, that's ultimately a matter of taste and your decision to make.

Having two different ways to do something is a big red flag for me. And we certainly shouldn't be promoting API that is dead ended.

Disagree with this. Many counterexamples in Elixir.

@stevegraham we're still soliciting feedback. Right now I haven't heard an objective reason on the native_binding side. We have the Stream limit which for me is not great. But, as far as the macro goes there's no reason why the macro cannot be extracted out and shared for those that want to use it.

The objective reason is it's a standard pattern in GUI applications, and the alternative solution (as proposed) results in objectively messier application code.
The only legitimate reason against native_binding that has been discussed here is the current implementation purportedly does not work with streams (although it hasn't been explained how?). However, it seems possible to reimplement native_binding such that it becomes compatible, because it seems possible to implement it with a bit of convention over configuration and a macro emitting code semantically equivalent to the new solution at compile-time.
FWIW I'm not sure how useful some of the views on this thread actually are. All this talk about code re-use, but how many have actually written any LVN code, or spent significant time playing with it.

This:

However, after a few years of LiveView itself being used in production by many this pattern has not emerged. We are pushing something that hasn't naturally come from use cases

is explained by this:

We are deviating away from the expected way that LiveView web works. In that world any state changes on the client that need to be reflected on the server are opt-in through events.

re this:

Because value_binding works for SwiftUI and makes sense for it doesn't guarantee that it will make sense for other native clients.

Should be pretty straightforward to look at how the targeted platforms solve for this?

@stevegraham does the extraction of that macro satisfy your concerns here?

I think Picker might need some updates. If I change an assign on the server-side and use the selection attribute, the UI is not updated. If I use value instead, it is. Should the attribute name match the naming used by the swift component?

@drewchandler I think that would be a separate issue, can you open that? It should match the SwiftUI api in Apple's docs. So in this branch for testing we'd want:
<Picker selection={@selection} phx-change="picker_change" />

Folks, I am jumping into the thread a bit late, but does anyone have production examples of native_binding being used?
The reason I ask is the following: in all my time using LiveView, I can't think of a single time where a value was sent to the server only to be stored as an assign and nothing else. Every time a value is sent to the server, it usually triggers other actions, and it may or may not set an assign of said name. Therefore, I am wondering under which circumstances this would be necessary for LVN.
For this reason, I am worried this pattern can lead to misuse. For example, imagine I have a category selector, which sends a "category_id" to the server via native_binding. Also a category may have subcategories, which are loaded based on the "category_id". Because native_binding automatically sets @category_id, some may naively push the logic that loads all subcategories to the template because that's the only place they can react to the @category_id change.
Two additional nitpicks/questions: I don't think there is anything in native_binding that actually ties it to native is there? If this is proven to be a useful pattern based on examples, it may be worth changing its name to something generally applicable. Also, it seems it uses Ecto for casting, and it seems like a bit of an overkill to bring a large library such as Ecto with the only goal of casting assigns.
Thank you for inviting the discussion and have a great weekend :heart:

in all my time using LiveView, I can't think of a single time where a value was sent to the server only to be stored as an assign and nothing else. Every time a value is sent to the server, it usually triggers other actions

This is mostly my experience as well, but sometimes the action triggered may be in a child component, and all that happens in the actual view or live_component where the event was triggered in that case is setting an assign. Here's a recent example:

ThreadLive contains a component .filters and a live component CommentsLive
.filters has UI which trigger events (eg. sort_by) which are sent to ThreadLive
ThreadLive simply sets assigns (eg. sort_by) which are passed to:

.filters for the UI to reflect the current filters
CommentsLive to handle the loading/filtering of comments (that code is there rather than ThreadLive because that component is used in other places like PostLive etc)

@josevalim we don't yet have a production app of significant complexity in production. the LV patterns are pretty well battle tested at this point and with our limited budget I'm always looking for pre-existing works to leverage to reduce our overhead. At it's most simple LVN is essentially an intermediary layer between the already built, working, and proven LiveView programming model and the already built, working, and proven native clients. This debate I find comes down to do you want the app building experience to be more LiveView-esque or more SwiftUI-esque. While I realize, and have witnessed, trying to get SwiftUI things working on server and LV can at times feel very square peg - round hole I think eventually we've come around to mostly good compromises. In this particular case I bear responsibility for letting native_binding hang around this long. Honestly it was one of those tunnel vision situations where I was focused on higher mind things and through some internal app building last week I realized we still had this implemented. It kicked off an internal discussion on its need and if we could and should deviate from it. I understand that taking things away sometimes sucks and I've had my fair share of time being on the receiving end of that in OSS projects but ultimately I'm looking at what is going to enable us long-term for success and what is going to be best for Elixir devs to build native apps. So I tend to side on the phx-change side of the argument before the whole Stream issue came about. Elixir/Phoenix/LiveView devs are our intended consumers of LVN so I'm of the mind that we keep the development experience as familiar to LV as much as possible. The technical limits I think are the nail in the coffin. We could very well expand native_binding but now that's a new API to support and that more surface area. I think if we extract as a macro for those that want to continue to use it that's OK but the recommended path will be what this PR pushes us towards.

@josevalim we don't yet have an app of significant complexity in production

Sure, I expected that, but even a demo with actual functionality suffices. It is only because all the examples I have seen so far that used native_binding was in the examples itself, where the LV has nothing to do.

In this particular case I bear responsibility for letting native_binding hang around this long. Honestly it was one of those tunnel vision situations where I was focused on higher mind things and through some internal app building last week I realized we still had this implemented.

Nah, don't worry too much about it. This is completely normal and expected, especially as you have larger concerns. There are several examples of features that existed in Elixir and Ecto which turned out to not be a good idea, but we ironed them out towards 1.0 (in Ecto's case, towards 2.0 :P).
Something else I will add: removing a shipped feature is hard, adding a non-released feature is easy. So if you are unsure, remove now, consider use cases, and add later.

Something else I will add: removing a shipped feature is hard, adding a non-released feature is easy. So if you are unsure, remove now, consider use cases, and add later.

Exactly where my ehad is at

I am very torn on native_binding vs phx-change. My app is basically a giant form and with phx-change I am having to write a lot of boilerplate handle_event functions to handle every field. I do like the explicitness of phx-change and it fits with the “data down, actions up” style I am used to. Without phx-change , would I have use modifiers or something if I wanted to validate a field?
There are 2 things from the web that I find myself missing:

On the web you can just do phx-change on the <form> instead of having to do every input. In SwiftUI, the Form component seems like it is just a presentational thing and doesn’t have any events.
phx-change events on html elements give you a _target in the params, so you can tell what element triggered the event. If I had the target, I could maybe try writing a single handle_event and use the target to know what field to update.

I guess I have been trying to write LVN code exactly how I would write something in LV, and there is only so far that can take me, because the two platforms are different and will require different patterns.

On the web you can just do phx-change on the <form> instead of having to do every input. In SwiftUI, the Form component seems like it is just a presentational thing and doesn’t have any events.
phx-change events on html elements give you a _target in the params, so you can tell what element triggered the event. If I had the target, I could maybe try writing a single handle_event and use the target to know what field to update.

On the first one we should fix live-form to behave this way. For the second we should add the _target meta data to conform with that LV js is doing: https://github.com/phoenixframework/phoenix_live_view/blob/9ea1402ce162abac90a1b7aff82e7bd528528e51/assets/js/phoenix_live_view/js.js#L55C1-L66

This is a very interesting perspective I did not have @drewchandler. Basically, LiveView/HTML can bundle all inputs for you when you submit a button. So the collecting of state/params happens on the client. LiveView/Swift does not do that, so you need to store all events on the server. This could explain a need for native_binding indeed. So the question is if you will stick to LiveView/Swift style OR you want to provide a HTML Form-like experience within LVN by having additional form components.

I take back all the stuff I said. I did not know about LiveForm.

@josevalim SwiftUI does not have concept of a "form" the same way the web does. We built https://github.com/liveview-native/liveview-native-live-form to address this. It will take all child inputs and serialize them when submitted. I believe this solves @drewchandler's issue

@stevegraham does the extraction of that macro satisfy your concerns here?

Personally, I don't understand the desire for a more verbose solution for framework users when native_binding can be implemented in a streams compatible way, but to be honest I'm not really concerned about the change. The LV part is straightforward enough to implement outside of the framework as a library, or as part of an application.
That being said I don't think this:
<Picker selection={@selection} phx-change="picker_change" />

is a better API design than what it replaces. What other type of event handler other than something updating the state of @selection would be concerned with a change event? I can't think of one. So why the need to explicitly define the name of the handler? Why not assume by convention that a handler called update_THING exists for an assign @THING, and that SUI uses phx-change to communicate the change to the server. It seems superfluous to make this part of the public API. This is exactly the same design principal as assuming a native_binding has been declared in the LV when one used in a template in the current version of LVN.
Ultimately I don't see the need to change the API of the SwiftUI layer. You can have the same API as SwiftUI, i.e.
<Picker selection="selection" />

and have that mean "send update_selection event with new value when @selection changes on the client".
I think there is a stronger argument for leaving the Swift API as-is because it's less straightforward to DRY up for framework users.
My $0.02.

I've added apple/swift-async-algorithms as a dependency for the AsyncChannel class and debounce/throttle extensions of AsyncSequence. The AsyncChannel gives us back pressure, so we can properly await a debounced/throttled event.
The previous Combine implementation had no way of cancelling event tasks that were dropped due to a debounce or throttle, and would just leak the continuation.

I think the arguments in favor of dropping the native_bindings abstraction outweigh those in favor of keeping it, and it seems to be a welcome change based on responses from the community and internally. I just want to mention a few other points that I haven't seen brought up here:

The old approach required the use of an additional macro assign_native_bindings/3 (link) since assign/2 and assign/3 are not overridable in Phoenix. Now all state updates can be handled idiomatically, simplifying both the Elixir and Swift implementations as well as end-user application code.

Native bindings are not composable. You can't have an arbitrary list of elements with separate native bindings since they're "baked in" at compile time via the native_binding/3 macro. The phx-change pattern resolves this by allowing elements to pass dynamic values to their handle_event/3 callbacks, allowing clientside state to be synced from elements that are generated at runtime by the server.

As others have pointed out, the target audience for LiveView Native is Elixir developers who are already using Phoenix and LiveView in their applications. Doing things the "LiveView way" is one of the design goals of this project; the more we can do away with unusual abstractions in the interest of familiarity, the better.

@carson-katri I merged https://github.com/liveview-native/live_view_native/pull/35 and https://github.com/liveview-native/live_view_native_platform/pull/10 so just waiting on https://github.com/liveview-native/liveview-client-swiftui/pull/1058 to be merged and then this to rebased off main before merging.

@supernintendo I agree with all of your points.
For everyone on the thread let me give an example of what I mean:
New (rough) example native binding implementation:
defmodule NativeBinding do
  defmacro native_binding([{key, value}]) do
    quote do
      @behaviour Phoenix.LiveView
      on_mount {NativeBinding, {unquote(key), unquote(value)}}

      def handle_event("update_#{unquote(key)}", %{unquote(key) => value}, socket) do
        {:noreply, assign(socket, unquote(key), value)}
      end
    end
  end

  def on_mount({key, value}, _params, _session, socket) do
    {:cont, Phoenix.LiveView.Utils.assign(socket, key, value)}
  end
end

Example usage:
defmodule TestBedWeb.IndexLive do
  use TestBedWeb, :live_view
  use LiveViewNative.LiveView
  use NativeBinding

  native_binding selection: "1"

  def mount(_params, _session, socket) do
    {:ok, socket}
  end

  def render(assigns) do
    ~SWIFTUI"""
    <List selection={@selection} phx-change="update_selection">
      <Text :for={item <- 1..10} id={"#{item}"}>
        <%= item %>
      </Text>
    </List>
    """
  end
end

You could also have SwiftUI views send a phx-change of "update_#{binding_name}" with %{binding_name => value} by convention meaning your render function could be almost the same as is currently, i.e.
def render(assigns) do
  ~SWIFTUI"""
  <List selection={@selection}>
    <Text :for={item <- 1..10} id={"#{item}"}>
      <%= item %>
    </Text>
  </List>
  """
end

That being said, users might look at the view above and think "where the hell is @selection coming from?", which could be avoided by just keeping the view API the same but , e.g.
def render(assigns) do
  ~SWIFTUI"""
  <List selection="selection">
    <Text :for={item <- 1..10} id={"#{item}"}>
      <%= item %>
    </Text>
  </List>
  """
end

This generates semantically equivalent code to proposal, removes a bunch of boiler plate, and allows the user to manually define their assigns and event handlers when their use case requires departing from convention.
Thoughts?

@stevegraham I appreciate your interest in this issue, I believe the best course of action is to take your macro and have it as a 3rd party lib. This way you can can still benefit from that workflow and others that find benefit can as well, while those that are more accustomed to and expecting a LiveView-like experience will get that by default. We're comfortable with the phx-change direction and we've been given the OK by @chrismccord to extend its use beyond just <form> within the context of LVN.

No problem. I just wanted to make sure I was understood. IMO there are good points either way, but ultimately a direction has to be chosen and it's not my call. 🤝

@carson-katri this looks like it'll require a rebase


Update subscription configuration schema to include new parameters

This change simplifies cloud configurations in our live test pipelines. Currently these parameters get defined per cloud in the live test template, which ends up creating a large, verbose configuration. To simplify these definitions, I'd like to move them into the subscription configuration. The resulting template usage becomes more like:
- name: CloudConfig
  type: object
  default:
    Public:
      SubscriptionConfiguration: $(sub-config-azure-cloud-test-resources)
    Preview:
      SubscriptionConfiguration: $(sub-config-azure-cloud-test-resources-preview)
    Canary:
      SubscriptionConfiguration: $(sub-config-azure-cloud-test-resources-preview)
      Location: 'eastus2euap'                                                                                UsGov:
      SubscriptionConfiguration: $(sub-config-gov-test-resources)
    China:
      SubscriptionConfiguration: $(sub-config-cn-test-resources)

This change will require an update to the above 4 subscription configurations. The script change handles both the old and new data structure.
Passing live test referencing the new configuration: https://dev.azure.com/azure-sdk/internal/_build/results?buildId=600922&view=logs&j=bbd7d436-e05d-51a8-99a8-0701dc9dffeb&t=20f065cd-bf8b-5b9d-5626-dd2113fcfcf1
Passing live test referencing the old configuration: https://dev.azure.com/azure-sdk/internal/_build/results?buildId=600932&view=results

The following pipelines have been queued for testing:java - templatejs - templatenet - templatepython - template You can sign off on the approval gate to test the release stage of each pipeline. See eng/common workflow

@heaths @weshaggard  the latest update includes a couple of things, based on our conversations.

Support the old syntax used in a few places (mainly storage tests for java and js) that involved passing a powershell hash literal down as a parameter string to be rendered directly. This way I can phase this out independently.
Support subscription configuration defining the base set of arm template parameters, if (1.) is not defined.
Add pipeline and/or platform specific arm parameters, passing yaml objects down as pipeline parameters, to be converted. These will all get merged with the arm template parameters from the subscription configuration and passed down to the New-TestResources script as one object.

The following pipelines have been queued for testing:java - templatejs - templatenet - templatepython - template You can sign off on the approval gate to test the release stage of each pipeline. See eng/common workflow

The following pipelines have been queued for testing:java - templatejs - templatenet - templatepython - template You can sign off on the approval gate to test the release stage of each pipeline. See eng/common workflow

The following pipelines have been queued for testing:java - templatejs - templatenet - templatepython - template You can sign off on the approval gate to test the release stage of each pipeline. See eng/common workflow

@heaths @weshaggard updated based on our meeting. For context: due to the object->string rendering limitations with devops yaml, and breaking change concerns with dev usage of the script, I'm adding ArmTemplateParameters as a net new parameter, that's defined as a stringified powershell hash in pipeline yaml like we do in other repos today.
I'm also setting all the new environment variables defined in the new subscription configurations as deployment outputs. Looking at these values more closely, I'm wondering if they are better off being defined in the sdk pipelines instead. Another discussion though.

The following pipelines have been queued for testing:java - templatejs - templatenet - templatepython - template You can sign off on the approval gate to test the release stage of each pipeline. See eng/common workflow

The following pipelines have been queued for testing:java - templatejs - templatenet - templatepython - template You can sign off on the approval gate to test the release stage of each pipeline. See eng/common workflow

The following pipelines have been queued for testing:java - templatejs - templatenet - templatepython - template You can sign off on the approval gate to test the release stage of each pipeline. See eng/common workflow

The following pipelines have been queued for testing:java - templatejs - templatenet - templatepython - template You can sign off on the approval gate to test the release stage of each pipeline. See eng/common workflow

The following pipelines have been queued for testing:java - templatejs - templatenet - templatepython - template You can sign off on the approval gate to test the release stage of each pipeline. See eng/common workflow

The following pipelines have been queued for testing:java - templatejs - templatenet - templatepython - template You can sign off on the approval gate to test the release stage of each pipeline. See eng/common workflow

The following pipelines have been queued for testing:java - templatejs - templatenet - templatepython - template You can sign off on the approval gate to test the release stage of each pipeline. See eng/common workflow

The following pipelines have been queued for testing:java - templatejs - templatenet - templatepython - template You can sign off on the approval gate to test the release stage of each pipeline. See eng/common workflow

The following pipelines have been queued for testing:java - templatejs - templatenet - templatepython - template You can sign off on the approval gate to test the release stage of each pipeline. See eng/common workflow

The following pipelines have been queued for testing:java - templatejs - templatenet - templatepython - template You can sign off on the approval gate to test the release stage of each pipeline. See eng/common workflow


LMStudio App "Cors=true" button broken

Looks like you pushed an update today! Is there a way to turn off autoupdates?
[2024-05-07 10:32:53.913] [INFO] [LM STUDIO SERVER] Stopping server..
[2024-05-07 10:32:53.914] [INFO] [LM STUDIO SERVER] Server stopped
[2024-05-07 10:33:03.858] [INFO] [LM STUDIO SERVER] Verbose server logs are ENABLED
[2024-05-07 10:33:03.858] [INFO] [LM STUDIO SERVER] Heads up: you've enabled CORS. Make sure you understand the implications
[2024-05-07 10:33:03.913] [INFO] [LM STUDIO SERVER] Stopping server..

The error throws the warning message, and then turns off. the warning is being thrown as an error when it shouldn't be.
npx lmstudio install-cli

I fixed this by installing the cli tool which I assume overwrote whatever is broken by the update script.

No, I wasn't running any other lms instances. I can be sure of that. Not sure why I woke up this morning and it wasn't working if it wasn't an update!
I luckily found install-cli  b/c when searching for 'cors' through this repo (linked from the lmstudio docs area) its the only references.
It was very frustrating

pressing cors on
start server, have the server immediately warn me about cors
then shutdown the server,
-I left this out) turn the cors setting back to false.


Update renovatebot/github-action action to 34.39.3

This PR contains the following updates:

Package
Type
Update
Change

renovatebot/github-action
action
patch
v34.39.0 -> v34.39.3

Release Notes

renovatebot/github-action
v34.39.3
Compare Source
See the the changelog for changes in all releases.
34.39.3 (2022-11-27)
Bug Fixes

deps: update renovate/renovate docker tag to v34.39.3 (ab5f18c)

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

@balena-ci I self-certify!


Example of TodoMVC with React-Dart ?

Does this exist?
If not, where is the best example of React-Dart usage?
Thanks!

Best example is currently the Readme. TodoMVC would be great, but does not exist yet.

There's an oldish example here:
http://astashov.github.io/blog/2014/10/17/dart-apps-with-unidirectional-flow-and-persistent-data-structures/
https://github.com/astashov/todomvc/tree/master/labs/architecture-examples/react-dart-uniflow/web/dart

There is also some example in /example directory. It's not a Todolist app, just a very simple frontend to Google Geocode service.


test: disable deprecated embedding model tests

Thank you for opening a Pull Request! Before submitting your PR, there are a few things you can do to make sure it goes smoothly:

[ ] Make sure to open an issue as a bug/issue before writing your code!  That way we can discuss the change, evaluate designs, and agree on the general idea
[ ] Ensure the tests and linter pass
[ ] Code coverage does not decrease (if any source code was changed)
[ ] Appropriate docs were updated (if necessary)

Fixes #<issue_number_goes_here> 🦕

test_create_embedding_generator_multilingual_model

hmmm I retrieved from
https://fusion2.corp.google.com/ci/kokoro/prod:bigframes%2Fpresubmit%2Fpresubmit/activity/dfb811df-d049-4128-a7fe-76c35b698f94/invocations/dfb811df-d049-4128-a7fe-76c35b698f94/targets/bigframes%2Fpresubmit%2Fpresubmit/log
looks like test_create_embedding_generator_multilingual_model is also failing.


Role idempotence

From: https://servercheck.in/blog/testing-ansible-roles-travis-ci-github
Role idempotence
Another important test is the idempotence test—does the role change anything if it runs a second time? It should not, since all tasks you perform via Ansible should be idempotent (ensuring a static/unchanging configuration on subsequent runs with the same settings).
Run the role/playbook again, checking to make sure it's idempotent.

ansible-playbook -i tests/inventory tests/test.yml --connection=local --sudo
| grep -q 'changed=0.*failed=0'
&& (echo 'Idempotence test: pass' && exit 0)
|| (echo 'Idempotence test: fail' && exit 1)
This command runs the exact same command as before, but pipes the results through grep, which checks to make sure 'changed' and 'failed' both report 0. If there were no changes or failures, the idempotence test passes (and Travis sees the 0 exit and is happy), but if there were any changes or failures, the test fails (and Travis sees the 1 exit and reports a build failure).

TIL Idempotency.
I realized this when setting up the fonts. each occurrence of an ansible run would just duplicate more fonts in the fonts dir.

Great. I'm running on this thing. My fonts dir is probably huge. I'll prob do one more reformat for good measure once this thing is stable.

Also, I'm changing some of the descriptions for tasks to use 'ensure' instead of 'install', for example, ensure nsf13 is installed, instead of install nsf13. Since it is not actually installing it but making sure it is installed.

To get SPF13 installed, we just need to run that curl command unless it exists. Secondarily, once it does exist (put task after that task), we need to ensure that the git repo is "latest". You can see the documentation here: http://docs.ansible.com/git_module.html. You should set the update flag to yes.
On the second task that keeps the repo up to date, set a handler to run the bundle install task. That way if it updates the repo bundle install will run.

I've already fixed this for spf13 on https://github.com/poetic/short-stack/commit/f71fc01a257d33cb334cfb45285c4db8b8d92d08. It is a clever fix, since it will also update spf13 if the remote SHA of the latest commit is different than the one on the current install. How cool is that?!

I just closed this with 04576a24bd25b2c84f0437d7e6657d5dd69e83e9.


Quite confused what this application does and how it works. Needs better readme.

I'm looking for an application that checks a github project for new releases every night and if true runs a script.
This looks like what I'm looking for, but I'm utterly confused how this application is supposed to work and the README jumps ahead of it's introduction and immediately starts talking about how to run it with webhooks, as a cronjob and how to use it with docker.
The only thing I know is that I'm not wanting to use webhooks.
Let's take this example:
$ github-release-notifier --package femtopixel/github-release-notifier
{}

Curly brackets?
I get the feeling that what's supposed to happen is that this application outputs the version number of the latest release
and then puts that number into ~/.github_release_notifier/versions/team/project.
But alas it doesn't:
$ cd ~/.github_release_notifier
-bash: cd: /home/folaht/.github_release_notifier: No file or directory

But I can't really tell because I've never succesfully used this application before.

I'm looking for an application that checks a github project for new releases every night and if true runs a script.
You're  ate the right place, this is the exact purpose
This looks like what I'm looking for, but I'm utterly confused how this application is supposed to work and the README jumps ahead of it's introduction and immediately starts talking about how to run it with webhooks, as a cronjob and how to use it with docker.
The only thing I know is that I'm not wanting to use webhooks.

Well, this is how I designed it. If you do not want to use webhooks, we'll have to either rewrite everything, either use a middleware that runs your scripts on every webhook (which is the solution I use for some repositories)

Let's take this example:
$ github-release-notifier --package femtopixel/github-release-notifier
{}

Curly brackets?

There is no --package parameter on the default action (which is cron) (cf https://github.com/femtopixel/github-release-notifier/#usage)
You have no result since you didn't configured anything prior running the program. It seems clear enough for me but, you tell me ;) (cf https://github.com/femtopixel/github-release-notifier/#example)

I get the feeling that what's supposed to happen is that this application outputs the version number of the latest release
and then puts that number into ~/.github_release_notifier/versions/team/project.
But alas it doesn't:
$ cd ~/.github_release_notifier
-bash: cd: /home/folaht/.github_release_notifier: No file or directory

But I can't really tell because I've never succesfully used this application before.

You're right, it puts the latest version found in the specified .github_release_notifier/version file. This file contains a JSON structure on data collected form the differents packages GRN should watch. Also, the file .github_release_notifier/hooks whill contain a JSON structure on what package to watch and what webhook to call.

In a nutshell:

Specify which package to watch and which script should be called when a new version is released (example github-release-notifier --action subscribe --webhook https://example.com/updated --package jaymoulin/google-music-manager)
Define the crontab for GRN to go check frequently for new releases (crontab -l ; echo "0 0 * * * github-release-notifier") | sort - | uniq - | crontab)
Your https://example.com/updated will be called only if a new release exists for the specified package (jaymoulin/google-music-manager in my exemple).  This webhook will receive a JSON structure in its body (example : {  "date": [2017, 11, 13, 19, 46, 35, 0, 317, 0],  "version": "0.7.2",  "title": "Fixes split modules",  "content": "",  "media": "https://avatars0.githubusercontent.com/u/14236493?s=60&v=4",  "author": "jaymoulin"  "package_name": "jaymoulin/google-music-manager" })

As README already states, you can configure default path for both versions/hooks JSON structure files with respectively GRN_VERSIONS_FILE/GRN_HOOKS_FILE environment vars (cf. https://github.com/femtopixel/github-release-notifier/#configuration)

Thanks. I get it now. The cron action is to check for new releases and then call all webhooks.
Looks like I will need to fork your project and rewrite it to suit my needs as I need a github-release-source-compiler.

As I use GRN to build thing on my side, I already developped that kind of script. You can find a docker image at https://github.com/femtopixel/docker-builder for a plug'n'play Docker image or you can use this script to launch your own script https://github.com/femtopixel/docker-builder/blob/master/daemon.py#L15 (pay attention to the selected line)
As maintaining an application (answering questions, fixing bugs, adding new features...) is a hard and time consuming process. If you find this product useful and all the effort I put crafting this, feel free to donate to help me being able to continue maintaining this and creating other great things on those platforms   .


Appstudio update mvp-test-component

Pipelines as Code configuration proposal

Pipelines as Code CI/mvp-test-component-on-pull-request has successfully validated your commit.

StatusDurationName

✅ Succeeded
7 seconds
init

✅ Succeeded
12 seconds
clone-repository

✅ Succeeded
1 minute
build-container

✅ Succeeded
13 seconds
inspect-image

✅ Succeeded
18 seconds
clair-scan

✅ Succeeded
29 seconds
deprecated-base-image-check

✅ Succeeded
1 minute
clamav-scan

✅ Succeeded
12 seconds
sbom-json-check

✅ Succeeded
8 seconds
label-check

✅ Succeeded
7 seconds
optional-label-check

✅ Succeeded
7 seconds
show-sbom

✅ Succeeded
9 seconds
show-summary

Pipelines as Code CI/mvp-test-component-on-pull-request has successfully validated your commit.

StatusDurationName

✅ Succeeded
7 seconds
init

✅ Succeeded
12 seconds
clone-repository

✅ Succeeded
1 minute
build-container

✅ Succeeded
13 seconds
inspect-image

✅ Succeeded
29 seconds
deprecated-base-image-check

✅ Succeeded
18 seconds
clair-scan

✅ Succeeded
1 minute
clamav-scan

✅ Succeeded
12 seconds
sbom-json-check

✅ Succeeded
8 seconds
label-check

✅ Succeeded
7 seconds
optional-label-check

✅ Succeeded
7 seconds
show-sbom

✅ Succeeded
9 seconds
show-summary


cant download pkg by conda

I cant download pkg by conda

same page

Not sure why that is. Meanwhile, you can try pip installing from the repo. But I recommend installing Mayavi with conda.


Subuser doesn't have permissions to instantiate a public layer from other user in the org

Steps to reproduce:
(In an organisation, with user A and user B)

Create two tables in user A, both public with link
In one of them, add read permissions to user B

If you try to use SQL, user B can query both tables as expected with:
    var sql = new cdb.SQL({user: 'userB'});
sql.execute('SELECT * FROM userA.table_read').done(function(data) {
              console.log(data);
            });

    var sql2 = new cdb.SQL({user: 'userB'});
sql2.execute('SELECT * FROM userA.table').done(function(data) {
              console.log(data);
            });

On the other hand, if you try to use createLayer with them:

  cartodb.createLayer(map, {
          user_name: 'userB',
          type: 'cartodb',
          sublayers: [{
            sql: "SELECT * FROM userA.table",
            cartocss: "#table{  polygon-fill: #FF6600;  polygon-opacity: 1;  line-color: #FFF;  line-width: 0.5;  line-opacity: 1; }"
          }]
        })
          .addTo(map)
          .on('done', function(lyr) {
            console.log("lay1");

          }).on('error', function() {
            console.log("some error occurred");
          });

You get:
_cdbc_2525942163_124(
{
errors: [
"Error: could not fetch affected tables and last updated time: permission denied for relation untitled_table_383"
]
}
)

and the layer is not rendered in the map.
cc @rochoa @javisantana

for reference: https://github.com/CartoDB/cartodb-postgresql/commit/1b3db28a741582fc0b6d367bcffd8f0850e92acb#diff-09055399b3e05eafd42d8b91c07cf8f8R359

This is already fixed via https://github.com/CartoDB/cartodb/pull/5021


minor fix to TF slim README

Removing duplicated parameter in TensorFlow-Slim documentation.

Can one of the admins verify this patch?

I signed the CLA.

Sorry, email was not set when I committed the fix. I'll close this PR and resubmit.


Additional Workshed Support

should allow support for CMC + Trainset in addition to asdon. Right now it simply prioritizes asdon > cmc > trainset but I have no calculations to support this choice, It has very little testing since swapping worksheds is a once/day deal and I don't own an asdon

I think this resolves most of the requested changes. The first one, I'm just genuinely clueless on how to check and make sure I'm not overwriting CMC early without including any CMC related functions in the file. I did the best I could with what I know how to do in the end, apologies if it's not to your liking.

👍


Add nightly CI builds with nightly rapids versions

I believe that this is all that is required to build against a nightly rmm version. But this is my first time updating the XGBoost CI.
Fixes https://github.com/dmlc/xgboost/issues/10439

Note that the nightly CI pipeline is currently blocked by https://github.com/dmlc/xgboost/issues/10752