Alaska?

I just attempted to run the first few lines of the example from the U.S. Data and Package Basics vignette, but replacing the location with the intersection of the Chena and Tanana Rivers in Interior Alaska:
library(sf)
library(nhdplusTools) #

start_point <- st_sfc(st_point(c(-147.911472, 64.796633)), crs = 4269)
start_comid <- discover_nhdplus_id(start_point)

and I get an error:
Error in: https://labs.waterdata.usgs.gov/api/nldi/linked-data/comid/position?f=json&coords=POINT%28-147.911472%2064.796633%29
Error in: https://labs.waterdata.usgs.gov/api/nldi/linked-data/comid/NULL/

The code works with c(89.362, 43.090), so I'm guessing this is a case where the dataset/API/R library isn't applicable to Alaska.
Suggestions? Thanks!
> sessionInfo()
R version 4.2.2 (2022-10-31)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Debian GNU/Linux 11 (bullseye)

Matrix products: default
BLAS:   /usr/lib/x86_64-linux-gnu/openblas-pthread/libblas.so.3
LAPACK: /usr/lib/x86_64-linux-gnu/openblas-pthread/libopenblasp-r0.3.13.so

locale:
 [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C               LC_TIME=en_DK.UTF-8        LC_COLLATE=en_US.UTF-8     LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8    LC_PAPER=en_US.UTF-8
 [8] LC_NAME=C                  LC_ADDRESS=C               LC_TELEPHONE=C             LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base

other attached packages:
[1] nhdplusTools_0.6.2 sf_1.0-12          nvimcom_0.9-144

loaded via a namespace (and not attached):
 [1] zip_2.3.0            Rcpp_1.0.10          pillar_1.9.0         compiler_4.2.2       class_7.3-20         tools_4.2.2          jsonlite_1.8.4       lifecycle_1.0.3      tibble_3.2.1
[10] fstcore_0.9.14       pkgconfig_2.0.3      rlang_1.1.0          DBI_1.1.3            cli_3.6.1            curl_5.0.0           dataRetrieval_2.7.12 parallel_4.2.2       e1071_1.7-13
[19] dplyr_1.1.1          httr_1.4.5           xml2_1.3.3           generics_0.1.3       vctrs_0.6.1          classInt_0.4-9       grid_4.2.2           tidyselect_1.2.0     glue_1.6.2
[28] R6_2.5.1             fansi_1.0.4          pbapply_1.7-0        RANN_2.6.1           tidyr_1.3.0          purrr_1.0.1          magrittr_2.0.3       units_0.8-1          fst_0.9.8
[37] utf8_1.2.3           KernSmooth_2.23-20   proxy_0.4-27

That's correct. Sorry for the trouble.
For Alaska applications, you will have to go to NHD data directly. Unfortunately, nhdplusTools support for Alaska (region 19) is pretty thin. I've recently been doing a little more work in region 19 (https://code.usgs.gov/wma/nhgf/mainstems/-/blob/master/reg19_prototype.R) but it's very early.
If you want to dig in, you could work with my new work over in hydroloom https://github.com/DOI-USGS/hydroloom and make some hay, but there are a few things that would require fairly specific knowledge of the NHD and some of the stuff in hydroloom.
What application are you trying to accomplish? Maybe I could use it as an excuse to advance parts of that work?

Thanks for the reply! I will take a look at hydroloom and see what I can do. I just looked at the region 19 code; it's nice to see clearly written tidyverse-style R.
We are working on a project that's concerned with vehicle pollution entering the Chena River (and upstream tributaries) so my initial task was getting line layers for the Chena River and all the tributaries that drain into it. After that layer is intersected with a road layer, one important parameter will be the distance the crossing is from the Chena River, so some understanding of the network and direction of flow will matter for calculating the path and distance to the Chena. We have done this sort of work using the NHD directly, but it isn't easy and your package looked like a much simpler workflow that also requires no non-reproducible ArcMap/ArcGIS Pro mouse work.

Alright -- so a quick doodle testing out some of the stuff I've been working on was productive.
I would like to:

add a function to nhdplusTools that can retrieve the HU04 NHD data -- maybe nhdR would help here? https://jsta.github.io/nhdR/reference/nhd_plus_get.html ??
write the mappings to hydroloom attribute names for base NHD attributes. https://github.com/DOI-USGS/hydroloom/issues/5
Set up index_points_to_lines so it will return the line indexes without measures which are not included in the base NHD. https://github.com/DOI-USGS/hydroloom/issues/6
Create some better support for detecting and fixing loops in topologies. https://github.com/DOI-USGS/hydroloom/issues/7

With those caveats, the below shows how to index your point to an NHD flowline and do an upstream / downstream navigation. There's no "upmain" or "downmain" withouth more work -- which is what the prototype I linked above does, but this is probably a good start?
library(hydroloom)
library(dplyr)
options(timeout = 60000)
u <- "https://prd-tnm.s3.amazonaws.com/StagedProducts/Hydrography/NHD/HU4/GDB/NHD_H_1908_HU4_GDB.zip"
f <- file.path("../../../Data/ak", basename(u))

download.file(u, f, mode = "wb")

zip::unzip(f, exdir = dirname(f))

fs <- list.files(dirname(f), pattern = ".*1908.*.gdb", full.names = TRUE)

fl <- sf::read_sf(fs, "NHDFlowline")

fl <- filter(fl, ftype != 566)

fl <- select(fl, id = permanent_identifier, gnis_id, gnis_name, reachcode,
             flowdir, wbid = wbarea_permanent_identifier, ftype, fcode)

# measures will be incorrect but we can fix this later.
fl <- mutate(fl, aggregate_id_from_measure = 0, aggregate_id_to_measure = 100)

point <- sf::st_sfc(sf::st_point(c(-147.911472, 64.796633)),
                              crs = 4269)

i <- hydroloom::index_points_to_lines(fl, point)

sub <- fl[fl$id == i$id,]

mapview::mapview(list(sub, point))

flow_table <- sf::read_sf(fs, "NHDFlow")
# need to get the flow table into hydroloom ids
flow_table <- select(flow_table,
                     id = from_permanent_identifier,
                     toid = to_permanent_identifier)

# LOOPS!!!
flow_table <- flow_table |>
  filter(id %in% fl$id) |>
  mutate(toid = ifelse(!toid %in% id, "", toid)) |>
  mutate(r = 1:n())

remove <- left_join(flow_table, flow_table,
               by = c("toid" = "id")) |>
  filter(id == toid.y) |>
  pull(r.x)

flow_table <- filter(flow_table, !r %in% remove) |>
  select(-r)

down <- navigate_network_dfs(flow_table, sub$id, direction = "down")
up <- navigate_network_dfs(flow_table, sub$id, direction = "up")

subdown <- fl[fl$id %in% unique(unlist(down)),]
subup <- fl[fl$id %in% unique(unlist(up)),]

mapview::mapview(list(subup, subdown, point))

```

![image](https://user-images.githubusercontent.com/1492803/232954093-765540fc-a6c9-43b9-9b57-9fb6c1e354d9.png)

Excellent! Thanks so much! I will try your code and see where it takes me tomorrow morning.

FYI, here's what I came up with as a first cut for the analysis I need to do:
library(tidyverse)
library(glue)
library(sf)
library(fs)
library(zip)
# devtools::install_github("DOI-USGS/hydroloom")
library(hydroloom)

options(timeout = 60000)
u <- glue(
  "https://prd-tnm.s3.amazonaws.com/",
  "StagedProducts/Hydrography/NHD/",
  "HU4/GDB/NHD_H_1908_HU4_GDB.zip"
)
d <- "./data/ak"
if (!dir_exists(d)) {
  dir_create(d)
}
f <- path(d, basename(u))

if (!file_exists(f)) {
  download.file(u, f, mode = "wb")

  zip::unzip(f, exdir = d)
}

fs <- dir_ls(d, regexp = ".*1908.*.gdb")

# Chena & Tanana River intersection
point <- sf::st_sfc(
  sf::st_point(c(-147.911472, 64.796633)),
  crs = 4269
)

i <- hydroloom::index_points_to_lines(fl, point)

# Map of NHD data model:
# https://d9-wret.s3.us-west-2.amazonaws.com/assets/palladium/production/s3fs-public/atoms/files/NHD%20v2.3%20Model%20Poster%2006012020.pdf
fc <- sf::read_sf(fs, "NHDFCode") |>
  select(fcode, description) |>
  rename(fcode_description = description)

# Get flowlines from FileGDB
fl <- sf::read_sf(fs, "NHDFlowline") |>
  # Don't include "Coastline"
  filter(ftype != 566) |>
  select(
    permanent_identifier, # 40-char unique identifier
    gnis_id, # GNIS unique identifier
    gnis_name, # Proper name of geographic entity
    reachcode, # first 8 chars = subbasin code (FIPS 103), next 6 random
    flowdir, # direction of flow relative to coordinate order. 1 = WithDigitized, 0 = Unintialized (?!)
    wbarea_permanent_identifier, # pid of waterbody through which this flows
    ftype, # unique identifier of feature type
    fcode # feature type, characteristics, values
  ) |>
  rename(
    id = permanent_identifier,
    wbid = wbarea_permanent_identifier
  ) |>
  # inner_join(i, by = "id") |>
  left_join(fc, by = "fcode") |>
  mutate(
    # required for hydroloom funcs:
    aggregate_id_from_measure = 0,
    aggregate_id_to_measure = 100
  )

st_geometry(fl) <- "wkb_geometry"

sub <- fl %>% inner_join(i, by = "id")

# to / from flow table, filtered to segments in fl
full_flow_table <- sf::read_sf(fs, "NHDFlow") |>
  select(from_permanent_identifier, to_permanent_identifier) |>
  rename(
    id = from_permanent_identifier,
    toid = to_permanent_identifier
  )

filtered_flow_table <- full_flow_table |>
  inner_join(
    fl %>%
      st_drop_geometry() %>%
      select(id),
    by = "id"
  ) |>
  mutate(
    toid = ifelse(!toid %in% id, "", toid),
    r = row_number()
  )

remove <- left_join(
  filtered_flow_table, filtered_flow_table,
  by = c("toid" = "id"),
  relationship = "many-to-many"
) |>
  filter(id == toid.y) |>
  pull(r.x)

flow_table <- filter(filtered_flow_table, !r %in% remove) |>
  select(-r)

# Traverse the flow network for all upstream segments
up <- navigate_network_dfs(flow_table, sub$id, direction = "up")

# Filter flowlines to these segments
subup <- fl[fl$id %in% unique(unlist(up)), ] |>
  inner_join(flow_table, by = "id") |>
  select(
    id, toid,
    gnis_id, gnis_name, reachcode, wbid,
    ftype, fcode, fcode_description,
    wkb_geometry
  )

mapview::mapview(list(subup, point))

# At this point, I think we can use this sf data frame for getting distances
# to the Chena River. First, get the segment that the crossing is on:
crossing_point <- sf::st_sfc(
  sf::st_point(c(-147.2204, 65.0092)),
  crs = 4269
)

crossing_index <- hydroloom::index_points_to_lines(fl, crossing_point)

crossing_segment <- fl %>%
  inner_join(crossing_index, by = "id")

# Now do the same thing as above, but go down
chena_flow_table <- subup |>
  st_drop_geometry() |>
  select(id, toid)

downstream_crossing <- navigate_network_dfs(
  chena_flow_table,
  crossing_segment$id,
  direction = "down"
)

subdown <- subup[subup$id %in% unique(unlist(downstream_crossing)), ] |>
  inner_join(chena_flow_table, by = c("id", "toid")) |>
  select(
    id, toid,
    gnis_id, gnis_name, reachcode, wbid,
    ftype, fcode, fcode_description,
    wkb_geometry
  )

That's about 90% of where I wanted to get. The next steps for my particular analysis are to get the length of subdown to where it intersects the Chena River (instead of to the intersection of the Chena and Tanana Rivers), which seems pretty easy for this segment, but will be more complicated if there is more than one path to the Chena.
Thanks very much!

Very cool. There's plenty of other smarts that could be added if we do a little more network derivative calculation. The prototype workflow I linked previously is actually going to get plowed into the NHD in the long run. So better capabilities are coming.
For the record, I did tick off a few of the things I mentioned doing up above. They are now on the latest release of hydroloom.
https://github.com/DOI-USGS/hydroloom/blob/main/vignettes/flow-table.Rmd is the vignette I got out of the deal. Needs writing and some more description of what's happening but this was a great excuse to work that up. Thanks for the prompt.


Confusing migration docs regarding 'rule'

Do you want to request a feature or report a bug?
bug (well possibly)
What is the current behavior?
Looking at the migration docs, it looks like use is a property on module now (http://prnt.sc/dx2yjt).
module.exports = {
  ...
  module: {
    use: [{
      test: /\.tsx?$/,
      loader: 'ts-loader?' + JSON.stringify({ transpileOnly: false })
    }]
  }
}

Link to docs: https://webpack.js.org/guides/migrating/#what-are-options-
But the module docs doesn't say anything about this: https://webpack.js.org/configuration/module/
Issue was created as requested by @TheLarkInn .
Original tweet thread: https://twitter.com/frederikprijck/status/821619514269925376
What is the expected behavior?
Correct docs. (this sounds a bit harsh, but I didn't know what the expected behavior could be besided correct docs. )
PS: I'm not 100% sure the docs are incorrect. But it's confusing people over at the gitter channel aswell as @TheLarkInn and myself.
PS2: I'd be more then happy to throw in a PR if this is incorrect.

I'd thing it has to be:
module.exports = {
  ...
  module: {
    rules: [{
      test: /\.tsx?$/,
      use: 'ts-loader'
    }]
  },
  // does not work with webpack 2
  ts: { transpileOnly: false }
}

module.exports = {
  ...
  module: {
    rules: [{
      test: /\.tsx?$/,
      use: 'ts-loader?' + JSON.stringify({ transpileOnly: false })
    }]
  }
}

and
module.exports = {
  ...
  module: {
    rules: [{
      test: /\.tsx?$/,
      use: 'ts-loader'
      options:  { transpileOnly: false }
    }]
  }
}

On top of that, I'm unsure if use is allowed to be assigned with a string. Docs indicate it has to be an array.
https://webpack.js.org/configuration/module/#rule-use

Passing a string (i.e. use: [ "style-loader" ]) is a shortcut to the loader property (i.e. use: [ { loader: "style-loader "} ]).


Remove override for<EMAIL_ADDRESS>

The bug in v2.2.3 was fixed in v2.2.4.

Description

Types of Changes

[ ] Bug fix (non-breaking change that fixes an issue)
[ ] New feature (non-breaking change that adds functionality)
[ ] Documentation update
[ ] Breaking change (could cause existing functionality to not work as expected)
[ ] Other changes (non-breaking changes that does not fit any of the above)

Breaking changes include:

Removing a public function or component or prop
Adding a required argument to a function
Changing the data type of a function parameter or return value
Adding a new peer dependency to package.json

Changes

(change1)

How to Test-Drive This PR

(step1)

Checklists

General

[ ] Changes are covered by test cases
[ ] CHANGELOG.md updated with a short description of changes (not required for documentation updates)

Accessibility Compliance
You must check off all items in one of the follow two lists:

[ ] There are no changes to UI

or...

[ ] Changes were tested with a Screen Reader (iOS VoiceOver or Android Talkback) and had no issues
[ ] Changes comply with WCAG 2.0 guidelines levels A and AA
[ ] Changes to common UI patterns and interactions comply with WAI-ARIA best practices

Localization

[ ] Changes include a UI text update in the Retail React App (which requires translation)

we have to make sure that any version above 2.2.2 works okay with chakra 2.x. Can you try cleaning and reinstall the packages plz?

i noticed the package-lock.json in template-retail-react-app did not change. did you forget to update the lock file?

It doesn't actually have nwsapi in it!


[BUG] Example video, unit 3 hands-on colab, not working

What do you want to improve?

Explain the typo/error or the part of the course you want to improve

[BUG] Example video, unit 3 hands-on colab, not working
This one:
%%html

Also, don't hesitate to open a Pull Request with the update.

Hey there 👋 did you used the google colab notebook or the hands-on version?


Security - CVE-2017-17485 & CVE-2018-5968 on Jackson dependency

Hello,
running owasp dependendency-check on a project using jongo will cause the error below because jongo uses a version of jackon-databind affected by CVE-2017-17485 & CVE-2018-5968.
[ERROR] Failed to execute goal org.owasp:dependency-check-maven:3.0.2:check (default) on project authzforce-ce-core-pdp-testutils:
[ERROR]
[ERROR] One or more dependencies were identified with vulnerabilities:
[ERROR]
[ERROR] jackson-databind-2.7.3.jar: CVE-2017-17485, CVE-2018-5968

see the mentioned pull request for the fix

Hello, I can see that the fixing PR #326 is now merged and planned to be part of milestone 1.4.0, but there are still a few open issues planned as well, blocking the release. Could you to do a hotfix release in the meantime (to have this security fix part of the release)? Thank you.


fix(meta-key): fix edge cases for meta key usage.

This PR solves some edge cases that #686 doesn't account for. It turns out that String.fromCharCode(e.keyCode) isn't very reliable to determining which key was pressed. On top of that, it will always incorporate the fact that the alt key was pressed so we need a manual way to determine which key was pressed when the option to use alt as meta is turned on. That way we can add the meta (esc) sequence before the key that was actually pressed. I've tested this on my Mac (I use the meta key heavily) and this is working for all of my use cases.
Let me know if you'd like me to attach an issue to this PR as well.

@rauchg @leo Will you review and give me feedback? Thanks for all your work on this! Hyperterm is awesome!
CC: @aharris88

@aurelienbottazini, you may have some insight on this as well. P.S. Thanks for your contributions!

I'll wait on comments by @aurelienbottazini, otherwise LGTM!

@rauchg Look good to me.
Thanks for the improvement @rauchg !

Please rebase, @nicksrandall!

@leo @rauchg I rebased so you should be good to merge. Thanks!!

:blush: thx!


Does the disable User Registration variable exsist?

I'd like to be able to set globalSettings__disableUserRegistration to true but cannot find if the config file ever gets set?

It's not implemented yet, there's an issue for it: #13


Update changelog

Demo: https://s3.amazonaws.com/vitessce-data/demos/2020-08-03/5f87866/index.html?dataset=linnarsson-2018&theme=dark

I'm testing all browsers now.  Feel free to do one.

I will check firefox


Is it possible to get Left and right different for root ?

I would like to have my right border and my left border always different, i explain :
For my 'parent 1', the borders are 1 and 2, and for my 'parent 2' i would like to have automatically 3 and 4. Is it possible ?

And if my 'parent 1' has a child, the borders of parent 1 would be 1 and 4 and the children borders 2 and 3 and 'parent 2' would be 5 and 6.

yes, do not add root column at all.

Ok, thank you for your answer.
What is the interest ?
What is the best practice ? Using root or not ?
Thank you.

it depends on your requirements, if for example the project tree is based per company, so one root tree might be based per company. since the tree is not concurrently safe, it might be convenient to lock the company for update before updating or inserting tree node. Otherwise, if your tree is a category tree for products, then there is no point in having root column.
In general, it would be convenient to make root a relation instead and there is a plan to support that one day.. it depends on your requirements, if for example the project tree is based per company, o root tree might be based per company

Thank you a lot !
It helps me !


Data Studio not able to authorise community connector

I'm trying to do small exercise following below links https://github.com/GoogleCloudPlatform/fourkeys/blob/main/setup/INSTALL.md#collecting-changes-data .
However i get below message when trying to authorize from this page

"This app is blocked
This app tried to access sensitive info in your Google Account. To keep your account safe, Google blocked this access."
Please advise

I'm getting this too.  Cannot tell if I did something wrong.
How can I reset and restart to rule out my own human error?
Is this an issue you can reproduce?

Duplicate of https://github.com/GoogleCloudPlatform/fourkeys/issues/86
So sorry!  We have a workaround available: https://github.com/GoogleCloudPlatform/fourkeys/issues/86#issuecomment-823574890.


Format the getting started section to make it clearer

Description

The Getting Started section in README.md is a little messy.  For example:

Register your (conda or virtual) environment with Jupyter:
python -m ipykernel install --user --name my_environment_name --display-name "Python (reco)"

Start the Jupyter notebook server
jupyter notebook

will look better than:

Register your (conda or virtual) environment with Jupyter:

python -m ipykernel install --user --name my_environment_name --display-name "Python (reco)"

Start the Jupyter notebook server

jupyter notebook

Please compare getting started@simonz/format-getting-started with getting started@staging
Related Issues

Checklist:

[X] I have followed the contribution guidelines and code style for this project.
[ ] I have added tests covering my contributions.
[X] I have updated the documentation accordingly.
[X] This PR is being made to staging branch and not to main branch.

Codecov Report

Merging #1603 (cb20d22) into staging (4982381) will decrease coverage by 0.01%.
The diff coverage is n/a.

:exclamation: Current head cb20d22 differs from pull request most recent head dac495a. Consider uploading reports for the commit dac495a to get more accurate results

@@             Coverage Diff             @@
##           staging    #1603      +/-   ##
===========================================
- Coverage    58.23%   58.22%   -0.02%
===========================================
  Files           84       84
  Lines         8462     8462
===========================================
- Hits          4928     4927       -1
- Misses        3534     3535       +1

Flag
Coverage Δ

pr-gate
58.22% <ø> (-0.02%)
:arrow_down:

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

Impacted Files
Coverage Δ

recommenders/evaluation/spark_evaluation.py
86.60% <0.00%> (-0.45%)
:arrow_down:

Continue to review full report at Codecov.

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


drivers: espi_saf: Add Microchip MEC172x eSPI SAF version 2 driver

Microchip MEC172x has a modified eSPI SAF hardware implementation. Hardware changes include multiple clock dividers for each SPI flash device and data transfer using QMSPI local DMA.
Other fixes as well:

boards: mec172xevb: Fix cmake no sources warning
MEC172x adjust clock based on OTP
MEC172x QMSPI clock fix
Set default interrupt priority to 3 for all Microchip MEC172x eSPI host child devices
(except the UART's which are set to 1)

Hi @albertofloyd
There are few Koncifgs missing the in the combined Kconfig.xec (specific to MEC17xx) and hence the below compliance check error. Shall I add them under ESPI_XEC_V2 ?
CONFIG_ESPI_PERIPHERAL_ACPI_EC_IBF_EVT_DATA drivers/espi/espi_mchp_xec_host_v2.c:431, drivers/espi/espi_mchp_xec_host_v2.c:450, drivers/espi/espi_mchp_xec_host_v2.c:586, drivers/espi/espi_mchp_xec_host_v2.c:598
CONFIG_ESPI_PERIPHERAL_KBC_IBF_EVT_DATA    drivers/espi/espi_mchp_xec_host_v2.c:194
CONFIG_ESPI_PERIPHERAL_KBC_OBE_CBK         drivers/espi/espi_mchp_xec_host_v2.c:236
CONFIG_ESPI_PERIPHERAL_XEC_MAILBOX         drivers/espi/espi_mchp_xec_host_v2.c:108, drivers/espi/espi_mchp_xec_host_v2.c:169
CONFIG_ESPI_XEC_PERIPHERAL_ACPI_SHD_MEM_SIZE drivers/espi/espi_mchp_xec_host_v2.c:101, drivers/espi/espi_mchp_xec_host_v2.c:692
CONFIG_ESPI_XEC_PERIPHERAL_HOST_CMD_PARAM_SIZE drivers/espi/espi_mchp_xec_host_v2.c:100, drivers/espi/espi_mchp_xec_host_v2.c:103, drivers/espi/espi_mchp_xec_host_v2.c:489, drivers/espi/espi_mchp_xec_host_v2.c:691, drivers/espi/espi_mchp_xec_host_v2.c:694, drivers/espi/espi_mchp_xec_host_v2.c:696, drivers/espi/espi_mchp_xec_host_v2.c:775

ned Kconfig.xec (specific to MEC17xx) and hence the below compliance check error. Shall I add them under ESPI_XEC_V2 ?

Yes

@jvasanth1 since this did not make it in time for RC1, you have two options:

wait until the v3.2 window opens up and get this merged
split the bug fixes into a separate PR to be merged for v3.1, with the new driver deferred to v3.2

we can approve this PR now and wait for the next window for merging.

@mbolivar-nordic can you help to review the responses to your review comments?

@MaureenHelm can you help to review and approve?

@MaureenHelm and @albertofloyd can you help to approve this PR?

@MaureenHelm can you help to review and approve?


Filter User Index

I adding a custom field to the users table and would like to be able to filter the filter the results based on the user viewing the list. I dont see anywhere in the code. Is it possible within the index method? Seems pagination is pretty much the only configurable option.

You need to just program it up.


Delayed startup of docker.run

Hello,
I'm noticing delays on startup of my run instances. For example, as I "tail" my stdout log for the calling function, I can see when it has reached docker.run call. I also monitor the shared volume folder and sometimes, not always, it can take 50-60 seconds before the output log created by the code running in the container appears. Once it starts running, everything works correctly. Other times there are no delays. I start up and delete a container for every file that gets processed.
I have experimented with different things, including restarting Docker Desktop, restarting the Docker deamon, restarting my machine, reducing used memory to avoid memory swapping, etc. I'm running in Windows, by the way.
Any thoughts? Thanks in advance,

Tracy

Hi! This seems concerning. We need to know if the delay comes from Docker or Python-on-whales.
If you try to do the same things with the command line (outside python), does this delay occurs?

Thanks for your response. My sense is that it's something on the Docker side, since restarting Docker Desktop seems to resolve it most of the time. Next time I see this behavior, I'll try the debug option you suggest.
Here are the relevant bits of code. As I look at this I realize that I assume the dependencies are downloaded when the image is built, not when the container is run. Is that true?
the calling function
  shutil.copyfile(os.path.join(input_path, f),
                  os.path.join(docker_win_path, f))
  agl_docker_start(docker_win_path, docker_container_path)

the function that calls docker.run
def agl_docker_start(win_path, docker_path):
from python_on_whales import docker
logging.info('agl_docker_start: %s %s', win_path, docker_path)
docker.run(
"agl_image",
name="agl_container",
volumes=[(win_path, docker_path)],
detach=False,
remove=True,
)
The Dockerfile
FROM python:3.9-buster
WORKDIR ./
RUN apt-get update
RUN apt-get install -y software-properties-common
RUN apt-get install -y gdal-bin
RUN apt-get install -y libgdal-dev
RUN export CPLUS_INCLUDE_PATH=/usr/include/gdal
RUN export C_INCLUDE_PATH=/usr/include/gdal
RUN apt-get install -y python-gdal
COPY requirements_agl.txt ./
RUN pip install -r requirements_agl.txt
COPY agl_main.py ./
COPY utilities.py ./
CMD ["/bin/sh", "-c", "python agl_main.py > /tmp/shareddata/output.log 2>&1"]
requirements_agl.txt
DateTime
make
setuptools
numpy
pygdal==<IP_ADDRESS>
elevation
rasterio
pandas
typing
docker


cfdyndns: 0.2.0 -> 0.2.1

Description of changes
fixes #323969

Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Already done in https://github.com/NixOS/nixpkgs/pull/323855

Oh well


C++ Flight test

[x] Multirotor

[ ] Fixedwing

Flew on the test branch on 7/7/17

Closed in testing of #218 and #220


Reliable and easy to setup way to deploy Crawl4ai

Hey everyone,
The final step of development—deployment—is the most challenging. I'm sure many of you will agree with me.
Could someone share their experience on the best way to deploy Crawl4AI? Some options to consider are:

Using a big cloud provider like AWS, Azure, or GCP
Considering modern cloud platforms like Railway, Fly, or Vultr
Choosing between a single container or a swarm
Using Kubernetes
Configuring for a server or cluster

Thank you in advance for your answers and thoughts!

@sean-cofinance I've just recently set this up on Modal.com which was a pretty smooth exercise, here's my code if it helps:
import modal

# Install the necessary dependencies as custom container image which we will pass to our functions
crawler = modal.Image.debian_slim(python_version="3.10").pip_install_from_requirements("requirements.txt").run_commands(
    "apt-get update",
    "apt-get install -y software-properties-common",
    "apt-add-repository non-free",
    "apt-add-repository contrib",
    "playwright install-deps chromium",
    "playwright install chromium",
    "playwright install",
)

import asyncio
from crawl4ai import AsyncWebCrawler
import playwright
from typing import Optional, Union, List
from pydantic import BaseModel, Field
from fastapi import Header, HTTPException
from jwt import decode, PyJWTError
import os

app = modal.App("crawler")

class CrawlRequest(BaseModel):
    url: str
    bypass_cache: bool = Field(default=False)
    # other kwargs

# Define the function that will be executed in the container
@app.function(image=crawler)
@modal.web_endpoint(method="POST", docs=True)
async def crawl(request: CrawlRequest, authorization: str = Header(...)):
    # You will want to have your own authorization strategy here to protect your endpoint
    print(f"Crawling URL: {request}")
    # Create an instance of AsyncWebCrawler
    async with AsyncWebCrawler(verbose=True) as crawler:
        # Run the crawler on the given URL
        crawl_kwargs = request.dict(exclude_unset=True)
        try:
            result = await crawler.arun(**crawl_kwargs)
            print(result)
            return result
        except Exception as e:
            error_message = f"Error during crawling: {str(e)}"
            print(error_message)
            return {"error": error_message}

# Entrypoint that will be used to trigger the crawler when testing locally
@app.local_entrypoint()
async def main(url: str):
    result = crawl.remote(CrawlRequest(url=url))
    print(result)
    return result

My requirements.txt:
crawl4ai
asyncio
playwright
fastapi[standard]
pydantic
PyJWT

@chanmathew, I can't wait to try this out today! Thank you so much. This is really intriguing, and I'm super excited about it!


Add Regionalne Centrum Edukacji Zawodowej

School website: https://www.rcezbilgoraj.lbl.pl/
IT course website: https://www.rcezbilgoraj.lbl.pl/websites/recruitment/technik_programista.php

@agentKGB11 First stage of verification passed, official domain for Regionalne Centrum Edukacji Zawodowej w Biłgoraju is rcezbilgoraj.lbl.pl as far as I verified. This is just an informational note. Pull request is still in the review. I appreciate your patience while waiting for the final decision.


bugfix and some small maintenance items

just discovered this module while looking for something else. This is really neat!

So I ran into some more issues. To track those down I wrote tests. To debug the tests I wrote ldoc based documentation to help me understand the code better. After fixing the issues, I just added CI and effectively had done a major overhaul over the entire repo...
This also includes a breaking change, since I had to strip out the exit-code normalization code, since that was impossible to get right with different platforms and Lua versions.


Add a panel to adjust various styles and generate json string of settings

See examples in three.js website.

Gio.js Playground, have fun!


setWindowHandle is not a function

Is it possible to solve this error. It saying setWindowHandle is not a function and it's undefined.
Windows 11

+1

Hi! Are you using some kind of bundler? Vite for example messed up the imports for me as well.
Check out this, it's probably the same issue: https://github.com/paymoapp/node-active-window/issues/2#issuecomment-1720943964
Basically:

you have to tell vite/your bundler to not bundle your module (treat it as an external module)
you have to use CJS interoperability, since the module is bundled as CJS.

We have a config like this when bundling our electron main with vite:
import { builtinModules } from 'module';
import { defineConfig } from 'vite';

export default defineConfig({
	root: __dirname,
	envDir: process.cwd(),
	build: {
		outDir: '../../dist_electron/electron/main',
		emptyOutDir: true,
		sourcemap: true,
		target: 'node16',
		lib: {
			entry: 'index.ts',
			formats: ['cjs']
		},
		rollupOptions: {
			external: [
				'@paymoapp/electron-shutdown-handler', // this is important
				...builtinModules.flatMap(p => [p, `node:${p}`])
			],
			output: {
				entryFileNames: '[name].cjs',
				interop: 'auto' // and this is important
			}
		}
	}
});

No I wasn't using any bundler.

Could you please provide your environment then? And as a simple debugging step, please do the following:
import ElectronShutdownHandler from '@paymoapp/electron-shutdown-handler';

console.log(ElectronShurdownHandler);

Currently I don't have the project with me right now @gergof.

Use this
const ElectronShutdownHandler = require('@paymoapp/electron-shutdown-handler').default


After upgrading from 2.3.4 to 3.1.4 the form now allows entering 19 digits (it looks like: xxxx xxxx xxxx xxxx xxx), before it was allowing the usual 16 digits I want.

If I enter any more than 16 digits then it quite rightly raises a validation error so I guess the fact it allows me to enter them is a bug rather than a new type of credit card I'm not familiar with.

The options I'm using:
  <input type="text"
         ng-model="payment.cardNumber"
         cc-number
         cc-format
         cc-eager-type
         cc-type="cardType"
         name="cardNumber"
         class="form-control"
         placeholder="{{placeholder.cardNumber}}"
         required
         mongoose-error />

The Visa spec allows for 19 digits which is why you're seeing that behavior.

Btw, I understand that stuff like this is hard to keep track of. I made this lib ultra modular so that the regexes and other validation stuff could evolve independent of any framework.
Here's Visa:
https://github.com/bendrucker/creditcards-types/blob/acaf9813056e452f80b70c1ad1eb2ab7529fcef6/src/types.js#L7-L11
And you can try the Luhn algorithm here:
https://tonicdev.com/571826753121781100a4a9cb/577fcf13741fad1300f32ec7

@bendrucker thanks for putting up with my ignorance on these matters :+1:


LMS_SetLOFrequency not work when freq<30mhz

could add Automatically HF mode feature on LMS API like #62

my limesdr hardware versione 1.2 os win10
my test samplerate 8mhz and freq 20mhz
I found setting LMS_SetLOFrequency freq lower than 30Mhz after LMS_StartStream, this is not work
this is my mod basicRX.cpp test code

auto t1 = chrono::high_resolution_clock::now();
size_t count = 0;
while ( chrono::high_resolution_clock::now() - t1 < chrono::seconds( 20 ) ) /* run for 5 seconds /
{
int samplesRead;
/ Receive samples /
samplesRead = LMS_RecvStream( &streamId, buffer, bufersize, NULL, 1000 );
/ I and Q samples are interleaved in buffer: IQIQIQ... */
if ( count % 10 == 0 )
{
printf( "Count:%d Received %d samples\n", count, samplesRead );
}
count++;
if ( count == 200 )
{
LMS_SetLOFrequency( device, LMS_CH_RX, 0, 20e6 );
printf( "setting freq\n" );
}

or using my test version sdrsharp plugin
https://mega.nz/#!3RElmDxD!_YqGHtKOHc8Y-LRSb1FUEUjz0v7sjsUnjokmOUuuwDQ

Closing. Old issue.
LMS_SetLOFrequency() supports setting frequency to <30 MHz.
Also LimeSDR v1.2 are no longer supported so if there are problems with v1.2 boards they will not be resolved.


Instructions to create a development environment for M1/M2/osx-arm64

What is your issue?
The current instructions to create a development environment for MacOS don't work for an M1/M2 Mac.
The conda environment solve fails on cdsm2 presumably because it's not available for osx-arm64.
I tried looking for related discussion and/or issues with recommendations, but didn't see any.

After removing cdsm2 from the environment yml file, installing, and running the test suite I'm seeing a bunch of failures related to pandas imports:
ImportError: Pandas requires version '2022.03.0' or newer of 'xarray' (version '0.1.dev4835+g31c6e62.d20231106' currently installed)
Happy to add more detail here and/or log a separate issue if that would be helpful.

@kafitzgerald - thanks for filing this issue. We should update the contributing docs here to make this an easier process.
For your second problem, can you share what xr.show_versions() returns? It seems like the test suite is picking up an old version of xarray?

No problem (see below).  I think it's just the editable install it's seeing?

versions
>>> xr.show_versions()
/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/_distutils_hack/__init__.py:33: UserWarning: Setuptools is replacing distutils.
  warnings.warn("Setuptools is replacing distutils.")
INSTALLED VERSIONS
commit: None
python: 3.10.13 | packaged by conda-forge | (main, Oct 26 2023, 18:09:17) [Clang 16.0.6 ]
python-bits: 64
OS: Darwin
OS-release: 21.6.0
machine: arm64
processor: arm
byteorder: little
LC_ALL: None
LANG: en_US.UTF-8
LOCALE: ('en_US', 'UTF-8')
libhdf5: 1.14.2
libnetcdf: 4.9.2
xarray: 0.1.dev4835+g31c6e62.d20231106
pandas: 2.1.2
numpy: 1.24.4
scipy: 1.11.3
netCDF4: 1.6.5
pydap: installed
h5netcdf: 1.2.0
h5py: 3.10.0
Nio: None
zarr: 2.16.1
cftime: 1.6.3
nc_time_axis: 1.4.1
PseudoNetCDF: 3.2.2
iris: 3.7.0
bottleneck: 1.3.7
dask: 2023.10.1
distributed: 2023.10.1
matplotlib: 3.8.1
cartopy: 0.22.0
seaborn: 0.13.0
numbagg: 0.6.0
fsspec: 2023.10.0
cupy: None
pint: 0.20.1
sparse: 0.14.0
flox: 0.8.1
numpy_groupies: 0.10.2
setuptools: 68.2.2
pip: 23.3.1
conda: None
pytest: 7.4.3
mypy: None
IPython: None
sphinx: None

That is surprising — we try and fallback to a much higher version if setuptools_scm resolve the version...
I don't have the g31c6e62 commit on my end locally — could we try switching to the main branch?
Not to get too deep into git, but are the tags updated?

🤦🏻♀  I hadn't fetched the tags.  My bad (nothing wrong with the contrib docs here).  All is looking good now on that front.
Interestingly I did see what looks to be a duplicate of #7879 consistently when not using the optional -n argument.

log for the segfault on test_open_mfdataset_manyfiles
pytest xarray
========================================================= test session starts =========================================================
platform darwin -- Python 3.10.13, pytest-7.4.3, pluggy-1.3.0
rootdir: /Users/katelynw/xarray
configfile: pyproject.toml
plugins: timeout-2.2.0, cov-4.1.0, hypothesis-6.88.3, xdist-3.3.1, env-1.1.1
collected 17513 items / 1 skipped

xarray/tests/test_accessor_dt.py .............................................................................................. [  0%]
............................................................................................................................... [  1%]
.................................................................                                                               [  1%]
xarray/tests/test_accessor_str.py ............................................................................................. [  2%]
............................................................................................................................... [  2%]
.......                                                                                [  2%]
xarray/tests/test_array_api.py ...........                                                                                [  2%]
xarray/tests/test_backends.py ..................................x................................................s............. [  3%]
......................x...............................................s.s................................x..................... [  4%]
....................................................................................................................x.......... [  4%]
............................................................................................................................... [  5%]
x...................................................................................................................sssssssssss [  6%]
sssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss [  7%]
sssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss [  7%]
sssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss [  8%]
sssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss [  9%]
ssssssssssssssssssssssssssssssssss...................................x........................................................x [ 10%]
......................ss..................................x............................................................x....... [ 10%]
..................................................x.......................................................x.................... [ 11%]
.......................................x....................................................................................... [ 12%]
...x..........................................................................................x................................ [ 12%]
.......................s.XXXXXXXXXXXXXXXXXXXXXXXXFatal Python error: Segmentation fault

Thread 0x000000017d3cf000 (most recent call first):
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/concurrent/futures/thread.py", line 81 in _worker
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/threading.py", line 953 in run
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/threading.py", line 1016 in _bootstrap_inner
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/threading.py", line 973 in _bootstrap

Current thread 0x000000017c3c3000 (most recent call first):
  File "/Users/katelynw/xarray/xarray/backends/netCDF4_.py", line 418 in open_store_variable
  File "/Users/katelynw/xarray/xarray/backends/netCDF4_.py", line 443 in <genexpr>
  File "/Users/katelynw/xarray/xarray/core/utils.py", line 471 in FrozenDict
  File "/Users/katelynw/xarray/xarray/backends/netCDF4_.py", line 442 in get_variables
  File "/Users/katelynw/xarray/xarray/backends/common.py", line 210 in load
  File "/Users/katelynw/xarray/xarray/backends/store.py", line 43 in open_dataset
  File "/Users/katelynw/xarray/xarray/backends/netCDF4_.py", line 617 in open_dataset
  File "/Users/katelynw/xarray/xarray/backends/api.py", line 573 in open_dataset
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/dask/utils.py", line 73 in apply
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/dask/core.py", line 127 in _execute_task
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/dask/local.py", line 225 in execute_task
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/dask/local.py", line 239 in <listcomp>
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/dask/local.py", line 239 in batch_execute_tasks
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/concurrent/futures/thread.py", line 58 in run
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/concurrent/futures/thread.py", line 83 in _worker
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/threading.py", line 953 in run
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/threading.py", line 1016 in _bootstrap_inner
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/threading.py", line 973 in _bootstrap

Thread 0x000000017b3b7000 (most recent call first):
  File "/Users/katelynw/xarray/xarray/backends/lru_cache.py", line 55 in __getitem__
  File "/Users/katelynw/xarray/xarray/backends/file_manager.py", line 211 in _acquire_with_cache_info
  File "/Users/katelynw/xarray/xarray/backends/file_manager.py", line 199 in acquire_context
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/contextlib.py", line 135 in __enter__
  File "/Users/katelynw/xarray/xarray/backends/netCDF4_.py", line 403 in _acquire
  File "/Users/katelynw/xarray/xarray/backends/netCDF4_.py", line 409 in ds
  File "/Users/katelynw/xarray/xarray/backends/netCDF4_.py", line 347 in __init__
  File "/Users/katelynw/xarray/xarray/backends/netCDF4_.py", line 400 in open
  File "/Users/katelynw/xarray/xarray/backends/netCDF4_.py", line 603 in open_dataset
  File "/Users/katelynw/xarray/xarray/backends/api.py", line 573 in open_dataset
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/dask/utils.py", line 73 in apply
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/dask/core.py", line 127 in _execute_task
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/dask/local.py", line 225 in execute_task
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/dask/local.py", line 239 in <listcomp>
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/dask/local.py", line 239 in batch_execute_tasks
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/concurrent/futures/thread.py", line 58 in run
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/concurrent/futures/thread.py", line 83 in _worker
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/threading.py", line 953 in run
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/threading.py", line 1016 in _bootstrap_inner
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/threading.py", line 973 in _bootstrap

Thread 0x000000017a3ab000 (most recent call first):
  File "/Users/katelynw/xarray/xarray/backends/lru_cache.py", line 55 in __getitem__
  File "/Users/katelynw/xarray/xarray/backends/file_manager.py", line 211 in _acquire_with_cache_info
  File "/Users/katelynw/xarray/xarray/backends/file_manager.py", line 199 in acquire_context
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/contextlib.py", line 135 in __enter__
  File "/Users/katelynw/xarray/xarray/backends/netCDF4_.py", line 403 in _acquire
  File "/Users/katelynw/xarray/xarray/backends/netCDF4_.py", line 409 in ds
  File "/Users/katelynw/xarray/xarray/backends/netCDF4_.py", line 348 in __init__
  File "/Users/katelynw/xarray/xarray/backends/netCDF4_.py", line 400 in open
  File "/Users/katelynw/xarray/xarray/backends/netCDF4_.py", line 603 in open_dataset
  File "/Users/katelynw/xarray/xarray/backends/api.py", line 573 in open_dataset
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/dask/utils.py", line 73 in apply
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/dask/core.py", line 127 in _execute_task
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/dask/local.py", line 225 in execute_task
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/dask/local.py", line 239 in <listcomp>
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/dask/local.py", line 239 in batch_execute_tasks
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/concurrent/futures/thread.py", line 58 in run
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/concurrent/futures/thread.py", line 83 in _worker
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/threading.py", line 953 in run
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/threading.py", line 1016 in _bootstrap_inner
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/threading.py", line 973 in _bootstrap

Thread 0x000000017939f000 (most recent call first):
  File "/Users/katelynw/xarray/xarray/backends/lru_cache.py", line 55 in __getitem__
  File "/Users/katelynw/xarray/xarray/backends/file_manager.py", line 211 in _acquire_with_cache_info
  File "/Users/katelynw/xarray/xarray/backends/file_manager.py", line 199 in acquire_context
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/contextlib.py", line 135 in __enter__
  File "/Users/katelynw/xarray/xarray/backends/netCDF4_.py", line 403 in _acquire
  File "/Users/katelynw/xarray/xarray/backends/netCDF4_.py", line 409 in ds
  File "/Users/katelynw/xarray/xarray/backends/netCDF4_.py", line 348 in __init__
  File "/Users/katelynw/xarray/xarray/backends/netCDF4_.py", line 400 in open
  File "/Users/katelynw/xarray/xarray/backends/netCDF4_.py", line 603 in open_dataset
  File "/Users/katelynw/xarray/xarray/backends/api.py", line 573 in open_dataset
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/dask/utils.py", line 73 in apply
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/dask/core.py", line 127 in _execute_task
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/dask/local.py", line 225 in execute_task
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/dask/local.py", line 239 in <listcomp>
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/dask/local.py", line 239 in batch_execute_tasks
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/concurrent/futures/thread.py", line 58 in run
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/concurrent/futures/thread.py", line 83 in _worker
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/threading.py", line 953 in run
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/threading.py", line 1016 in _bootstrap_inner
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/threading.py", line 973 in _bootstrap

Thread 0x0000000178393000 (most recent call first):
  File "/Users/katelynw/xarray/xarray/backends/lru_cache.py", line 55 in __getitem__
  File "/Users/katelynw/xarray/xarray/backends/file_manager.py", line 211 in _acquire_with_cache_info
  File "/Users/katelynw/xarray/xarray/backends/file_manager.py", line 199 in acquire_context
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/contextlib.py", line 135 in __enter__
  File "/Users/katelynw/xarray/xarray/backends/netCDF4_.py", line 403 in _acquire
  File "/Users/katelynw/xarray/xarray/backends/netCDF4_.py", line 409 in ds
  File "/Users/katelynw/xarray/xarray/backends/netCDF4_.py", line 447 in get_attrs
  File "/Users/katelynw/xarray/xarray/backends/common.py", line 212 in load
  File "/Users/katelynw/xarray/xarray/backends/store.py", line 43 in open_dataset
  File "/Users/katelynw/xarray/xarray/backends/netCDF4_.py", line 617 in open_dataset
  File "/Users/katelynw/xarray/xarray/backends/api.py", line 573 in open_dataset
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/dask/utils.py", line 73 in apply
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/dask/core.py", line 127 in _execute_task
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/dask/local.py", line 225 in execute_task
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/dask/local.py", line 239 in <listcomp>
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/dask/local.py", line 239 in batch_execute_tasks
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/concurrent/futures/thread.py", line 58 in run
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/concurrent/futures/thread.py", line 83 in _worker
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/threading.py", line 953 in run
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/threading.py", line 1016 in _bootstrap_inner
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/threading.py", line 973 in _bootstrap

Thread 0x0000000177387000 (most recent call first):
  File "/Users/katelynw/xarray/xarray/backends/lru_cache.py", line 68 in __setitem__
  File "/Users/katelynw/xarray/xarray/backends/file_manager.py", line 221 in _acquire_with_cache_info
  File "/Users/katelynw/xarray/xarray/backends/file_manager.py", line 199 in acquire_context
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/contextlib.py", line 135 in __enter__
  File "/Users/katelynw/xarray/xarray/backends/netCDF4_.py", line 403 in _acquire
  File "/Users/katelynw/xarray/xarray/backends/netCDF4_.py", line 409 in ds
  File "/Users/katelynw/xarray/xarray/backends/netCDF4_.py", line 347 in __init__
  File "/Users/katelynw/xarray/xarray/backends/netCDF4_.py", line 400 in open
  File "/Users/katelynw/xarray/xarray/backends/netCDF4_.py", line 603 in open_dataset
  File "/Users/katelynw/xarray/xarray/backends/api.py", line 573 in open_dataset
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/dask/utils.py", line 73 in apply
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/dask/core.py", line 127 in _execute_task
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/dask/local.py", line 225 in execute_task
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/dask/local.py", line 239 in <listcomp>
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/dask/local.py", line 239 in batch_execute_tasks
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/concurrent/futures/thread.py", line 58 in run
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/concurrent/futures/thread.py", line 83 in _worker
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/threading.py", line 953 in run
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/threading.py", line 1016 in _bootstrap_inner
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/threading.py", line 973 in _bootstrap

Thread 0x000000017637b000 (most recent call first):
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/threading.py", line 372 in notify
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/threading.py", line 484 in release
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/concurrent/futures/thread.py", line 81 in _worker
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/threading.py", line 953 in run
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/threading.py", line 1016 in _bootstrap_inner
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/threading.py", line 973 in _bootstrap

Thread 0x000000017536f000 (most recent call first):
  File "/Users/katelynw/xarray/xarray/backends/lru_cache.py", line 68 in __setitem__
  File "/Users/katelynw/xarray/xarray/backends/file_manager.py", line 221 in _acquire_with_cache_info
  File "/Users/katelynw/xarray/xarray/backends/file_manager.py", line 199 in acquire_context
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/contextlib.py", line 135 in __enter__
  File "/Users/katelynw/xarray/xarray/backends/netCDF4_.py", line 403 in _acquire
  File "/Users/katelynw/xarray/xarray/backends/netCDF4_.py", line 409 in ds
  File "/Users/katelynw/xarray/xarray/backends/netCDF4_.py", line 347 in __init__
  File "/Users/katelynw/xarray/xarray/backends/netCDF4_.py", line 400 in open
  File "/Users/katelynw/xarray/xarray/backends/netCDF4_.py", line 603 in open_dataset
  File "/Users/katelynw/xarray/xarray/backends/api.py", line 573 in open_dataset
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/dask/utils.py", line 73 in apply
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/dask/core.py", line 127 in _execute_task
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/dask/local.py", line 225 in execute_task
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/dask/local.py", line 239 in <listcomp>
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/dask/local.py", line 239 in batch_execute_tasks
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/concurrent/futures/thread.py", line 58 in run
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/concurrent/futures/thread.py", line 83 in _worker
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/threading.py", line 953 in run
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/threading.py", line 1016 in _bootstrap_inner
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/threading.py", line 973 in _bootstrap

Thread 0x0000000174363000 (most recent call first):
  File "/Users/katelynw/xarray/xarray/backends/lru_cache.py", line 55 in __getitem__
  File "/Users/katelynw/xarray/xarray/backends/file_manager.py", line 211 in _acquire_with_cache_info
  File "/Users/katelynw/xarray/xarray/backends/file_manager.py", line 199 in acquire_context
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/contextlib.py", line 135 in __enter__
  File "/Users/katelynw/xarray/xarray/backends/netCDF4_.py", line 403 in _acquire
  File "/Users/katelynw/xarray/xarray/backends/netCDF4_.py", line 409 in ds
  File "/Users/katelynw/xarray/xarray/backends/netCDF4_.py", line 447 in get_attrs
  File "/Users/katelynw/xarray/xarray/backends/common.py", line 212 in load
  File "/Users/katelynw/xarray/xarray/backends/store.py", line 43 in open_dataset
  File "/Users/katelynw/xarray/xarray/backends/netCDF4_.py", line 617 in open_dataset
  File "/Users/katelynw/xarray/xarray/backends/api.py", line 573 in open_dataset
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/dask/utils.py", line 73 in apply
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/dask/core.py", line 127 in _execute_task
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/dask/local.py", line 225 in execute_task
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/dask/local.py", line 239 in <listcomp>
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/dask/local.py", line 239 in batch_execute_tasks
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/concurrent/futures/thread.py", line 58 in run
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/concurrent/futures/thread.py", line 83 in _worker
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/threading.py", line 953 in run
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/threading.py", line 1016 in _bootstrap_inner
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/threading.py", line 973 in _bootstrap

Thread 0x0000000173357000 (most recent call first):
  File "/Users/katelynw/xarray/xarray/backends/lru_cache.py", line 55 in __getitem__
  File "/Users/katelynw/xarray/xarray/backends/file_manager.py", line 211 in _acquire_with_cache_info
  File "/Users/katelynw/xarray/xarray/backends/file_manager.py", line 199 in acquire_context
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/contextlib.py", line 135 in __enter__
  File "/Users/katelynw/xarray/xarray/backends/netCDF4_.py", line 403 in _acquire
  File "/Users/katelynw/xarray/xarray/backends/netCDF4_.py", line 409 in ds
  File "/Users/katelynw/xarray/xarray/backends/netCDF4_.py", line 443 in get_variables
  File "/Users/katelynw/xarray/xarray/backends/common.py", line 210 in load
  File "/Users/katelynw/xarray/xarray/backends/store.py", line 43 in open_dataset
  File "/Users/katelynw/xarray/xarray/backends/netCDF4_.py", line 617 in open_dataset
  File "/Users/katelynw/xarray/xarray/backends/api.py", line 573 in open_dataset
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/dask/utils.py", line 73 in apply
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/dask/core.py", line 127 in _execute_task
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/dask/local.py", line 225 in execute_task
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/dask/local.py", line 239 in <listcomp>
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/dask/local.py", line 239 in batch_execute_tasks
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/concurrent/futures/thread.py", line 58 in run
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/concurrent/futures/thread.py", line 83 in _worker
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/threading.py", line 953 in run
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/threading.py", line 1016 in _bootstrap_inner
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/threading.py", line 973 in _bootstrap

Thread 0x0000000102fc0580 (most recent call first):
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/threading.py", line 320 in wait
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/queue.py", line 171 in get
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/dask/local.py", line 138 in queue_get
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/dask/local.py", line 501 in get_async
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/dask/threaded.py", line 90 in get
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/dask/base.py", line 628 in compute
  File "/Users/katelynw/xarray/xarray/backends/api.py", line 1035 in open_mfdataset
  File "/Users/katelynw/xarray/xarray/tests/test_backends.py", line 3533 in test_open_mfdataset_manyfiles
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/_pytest/python.py", line 194 in pytest_pyfunc_call
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/pluggy/_callers.py", line 77 in _multicall
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/pluggy/_manager.py", line 115 in _hookexec
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/pluggy/_hooks.py", line 493 in __call__
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/_pytest/python.py", line 1792 in runtest
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/_pytest/runner.py", line 169 in pytest_runtest_call
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/pluggy/_callers.py", line 77 in _multicall
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/pluggy/_manager.py", line 115 in _hookexec
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/pluggy/_hooks.py", line 493 in __call__
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/_pytest/runner.py", line 262 in <lambda>
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/_pytest/runner.py", line 341 in from_call
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/_pytest/runner.py", line 261 in call_runtest_hook
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/_pytest/runner.py", line 222 in call_and_report
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/_pytest/runner.py", line 133 in runtestprotocol
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/_pytest/runner.py", line 114 in pytest_runtest_protocol
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/pluggy/_callers.py", line 77 in _multicall
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/pluggy/_manager.py", line 115 in _hookexec
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/pluggy/_hooks.py", line 493 in __call__
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/_pytest/main.py", line 350 in pytest_runtestloop
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/pluggy/_callers.py", line 77 in _multicall
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/pluggy/_manager.py", line 115 in _hookexec
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/pluggy/_hooks.py", line 493 in __call__
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/_pytest/main.py", line 325 in _main
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/_pytest/main.py", line 271 in wrap_session
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/_pytest/main.py", line 318 in pytest_cmdline_main
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/pluggy/_callers.py", line 77 in _multicall
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/pluggy/_manager.py", line 115 in _hookexec
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/pluggy/_hooks.py", line 493 in __call__
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/_pytest/config/__init__.py", line 169 in main
  File "/Users/katelynw/miniconda3/envs/xarray-tests/lib/python3.10/site-packages/_pytest/config/__init__.py", line 192 in console_main
  File "/Users/katelynw/miniconda3/envs/xarray-tests/bin/pytest", line 10 in <module>

Extension modules: numpy.core._multiarray_umath, numpy.core._multiarray_tests, numpy.linalg._umath_linalg, numpy.fft._pocketfft_internal, numpy.random._common, numpy.random.bit_generator, numpy.random._bounded_integers, numpy.random._mt19937, numpy.random.mtrand, numpy.random._philox, numpy.random._pcg64, numpy.random._sfc64, numpy.random._generator, pandas._libs.tslibs.np_datetime, pandas._libs.tslibs.dtypes, pandas._libs.tslibs.base, pandas._libs.tslibs.nattype, pandas._libs.tslibs.timezones, pandas._libs.tslibs.ccalendar, pandas._libs.tslibs.fields, pandas._libs.tslibs.timedeltas, pandas._libs.tslibs.tzconversion, pandas._libs.tslibs.timestamps, pandas._libs.properties, pandas._libs.tslibs.offsets, pandas._libs.tslibs.strptime, pandas._libs.tslibs.parsing, pandas._libs.tslibs.conversion, pandas._libs.tslibs.period, pandas._libs.tslibs.vectorized, pandas._libs.ops_dispatch, pandas._libs.missing, pandas._libs.hashtable, pandas._libs.algos, pandas._libs.interval, pandas._libs.lib, pandas._libs.ops, numexpr.interpreter, bottleneck.move, bottleneck.nonreduce, bottleneck.nonreduce_axis, bottleneck.reduce, pandas._libs.arrays, pandas._libs.tslib, pandas._libs.sparse, pandas._libs.indexing, pandas._libs.index, pandas._libs.internals, pandas._libs.join, pandas._libs.writers, pandas._libs.window.aggregations, pandas._libs.window.indexers, pandas._libs.reshape, pandas._libs.groupby, pandas._libs.json, pandas._libs.parsers, pandas._libs.testing, scipy._lib._ccallback_c, yaml._yaml, numba.core.typeconv._typeconv, numba._helperlib, numba._dynfunc, numba._dispatcher, numba.core.runtime._nrt_python, numba.np.ufunc._internal, numba.experimental.jitclass._box, _cffi_backend, scipy.linalg._fblas, scipy.linalg._flapack, scipy.linalg.cython_lapack, scipy.linalg._cythonized_array_utils, scipy.linalg._solve_toeplitz, scipy.linalg._decomp_lu_cython, scipy.linalg._matfuncs_sqrtm_triu, scipy.linalg.cython_blas, scipy.linalg._matfuncs_expm, scipy.linalg._decomp_update, scipy.sparse._sparsetools, _csparsetools, scipy.sparse._csparsetools, scipy.sparse.linalg._isolve._iterative, scipy.sparse.linalg._dsolve._superlu, scipy.sparse.linalg._eigen.arpack._arpack, scipy.sparse.csgraph._tools, scipy.sparse.csgraph._shortest_path, scipy.sparse.csgraph._traversal, scipy.sparse.csgraph._min_spanning_tree, scipy.sparse.csgraph._flow, scipy.sparse.csgraph._matching, scipy.sparse.csgraph._reordering, scipy.linalg._flinalg, cftime._cftime, cytoolz.utils, cytoolz.itertoolz, cytoolz.functoolz, cytoolz.dicttoolz, cytoolz.recipes, xxhash._xxhash, psutil._psutil_osx, psutil._psutil_posix, markupsafe._speedups, numpy.linalg.lapack_lite, matplotlib._c_internal_utils, PIL._imaging, matplotlib._path, kiwisolver._cext, _brotli, netCDF4._netCDF4, h5py._errors, h5py.defs, h5py._objects, h5py.h5, h5py.utils, h5py.h5t, h5py.h5s, h5py.h5ac, h5py.h5p, h5py.h5r, h5py._proxy, h5py._conv, h5py.h5z, h5py.h5a, h5py.h5d, h5py.h5ds, h5py.h5g, h5py.h5i, h5py.h5f, h5py.h5fd, h5py.h5pl, h5py.h5o, h5py.h5l, h5py._selector, pyproj._compat, pyproj._datadir, pyproj._network, pyproj._geod, pyproj.list, pyproj._crs, pyproj.database, pyproj._transformer, pyproj._sync, matplotlib._image, rasterio._version, rasterio._err, rasterio._filepath, rasterio._env, rasterio._transform, rasterio._base, rasterio.crs, rasterio._features, rasterio._warp, rasterio._io, numcodecs.compat_ext, numcodecs.blosc, numcodecs.zstd, numcodecs.lz4, numcodecs._shuffle, msgpack._cmsgpack, numcodecs.jenkins, numcodecs.vlen, numcodecs.fletcher32, scipy.spatial._ckdtree, scipy._lib.messagestream, scipy.spatial._qhull, scipy.spatial._voronoi, scipy.spatial._distance_wrap, scipy.spatial._hausdorff, scipy.special._ufuncs_cxx, scipy.special._ufuncs, scipy.special._specfun, scipy.special._comb, scipy.special._ellip_harm_2, scipy.spatial.transform._rotation, scipy.ndimage._nd_image, _ni_label, scipy.ndimage._ni_label, scipy.optimize._minpack2, scipy.optimize._group_columns, scipy.optimize._trlib._trlib, scipy.optimize._lbfgsb, _moduleTNC, scipy.optimize._moduleTNC, scipy.optimize._cobyla, scipy.optimize._slsqp, scipy.optimize._minpack, scipy.optimize._lsq.givens_elimination, scipy.optimize._zeros, scipy.optimize.__nnls, scipy.optimize._highs.cython.src._highs_wrapper, scipy.optimize._highs._highs_wrapper, scipy.optimize._highs.cython.src._highs_constants, scipy.optimize._highs._highs_constants, scipy.linalg._interpolative, scipy.optimize._bglu_dense, scipy.optimize._lsap, scipy.optimize._direct, scipy.integrate._odepack, scipy.integrate._quadpack, scipy.integrate._vode, scipy.integrate._dop, scipy.integrate._lsoda, scipy.special.cython_special, scipy.stats._stats, scipy.stats.beta_ufunc, scipy.stats._boost.beta_ufunc, scipy.stats.binom_ufunc, scipy.stats._boost.binom_ufunc, scipy.stats.nbinom_ufunc, scipy.stats._boost.nbinom_ufunc, scipy.stats.hypergeom_ufunc, scipy.stats._boost.hypergeom_ufunc, scipy.stats.ncf_ufunc, scipy.stats._boost.ncf_ufunc, scipy.stats.ncx2_ufunc, scipy.stats._boost.ncx2_ufunc, scipy.stats.nct_ufunc, scipy.stats._boost.nct_ufunc, scipy.stats.skewnorm_ufunc, scipy.stats._boost.skewnorm_ufunc, scipy.stats.invgauss_ufunc, scipy.stats._boost.invgauss_ufunc, scipy.interpolate._fitpack, scipy.interpolate.dfitpack, scipy.interpolate._bspl, scipy.interpolate._ppoly, scipy.interpolate.interpnd, scipy.interpolate._rbfinterp_pythran, scipy.interpolate._rgi_cython, scipy.stats._biasedurn, scipy.stats._levy_stable.levyst, scipy.stats._stats_pythran, scipy._lib._uarray._uarray, scipy.stats._statlib, scipy.stats._sobol, scipy.stats._qmc_cy, scipy.stats._mvn, scipy.stats._rcont.rcont, scipy.cluster._vq, scipy.cluster._hierarchy, scipy.cluster._optimal_leaf_ordering, shapely.lib, shapely._geos, shapely._geometry_helpers, cartopy.trace, scipy.fftpack.convolve, tornado.speedups, cf_units._udunits2, scipy.io.matlab._mio_utils, scipy.io.matlab._streams, scipy.io.matlab._mio5_utils (total: 250)
zsh: segmentation fault  pytest xarray

🤦🏻♀ I hadn't fetched the tags. My bad (nothing wrong with the contrib docs here). All is looking good now on that front.

No stress!
Out of interest, was this an old clone? Or did a new clone hit this issue? We should fix on our end if a new clone could have this issue...

Interestingly I did see what looks to be a duplicate of #7879 consistently when not using the optional -n argument.

Interesting, thanks. These are plausibly bugs in netCDF. Xarray is pure-python, so we can't segfault ourselves, though we can call libraries incorrectly. It's somewhat of an intractable problem to push these upstream though...
In the meantime, if you don't need to run netcdf tests, uninstalling it will work!

just for reference, we're in the process of removing cdms2 support entirely from xarray (it is deprecated since the first release after May this year): cdms2 itself is in maintenance-only mode and will be archived end of this year. For the removal to happen in xarray, we just need to decide on a date.
As for the segfaults: these are caused by netcdf4 dropping the global library lock in recent versions, which exposed our own locks not working properly for netcdf4 (but only for a threading scheduler). Concurrency issues like this are really tricky to debug, though, which I think is the reason why nobody got around to fixing these yet.

Out of interest, was this an old clone? Or did a new clone hit this issue? We should fix on our end if a new clone could have this issue...

It was a new clone of my new fork, but I hadn't added or fetched the upstream repo yet per the instructions and therefore didn't have the tags.
And thanks for the info on cdms2 and netcdf4!


Set up automatic creation of GitHub Releases

https://www.appveyor.com/docs/deployment/github/

done!


[Bug]: Documented "Loops: Chatbot" example doesn't work

What happened?
In the documented example, the loop controller doesn't receive a default value for "message history".
I could only get the example to work by adding an empty array node to the default for data 1, so it gets seeded with [] rather than undefined.
What was the expected functionality?
Documented example doesn't work
Relevant screenshots
Fixed example:

Thanks for the report!


Media Integration and Organization

Issue Details
This issue focuses on enhancing the features related to adding and editing notes within the application. The key improvement areas include enabling media uploads to Amazon S3 bucket and organizing notes by folders, similar to the Joplin app. The aim is to improve the overall functionality and user experience of the note-taking feature.
Technical Requirements
Modify the media upload functionality to support uploading to Amazon S3 Bucket. This will require changes in the backend to handle the upload process and in the frontend to manage the UI interactions for media uploads.
Implement a folder organization system for notes. This should include UI changes to allow users to create, delete, and navigate between folders, as well as backend changes to support the folder structure.
Add functionality to sort notes by tags. This will require both frontend and backend changes to allow users to assign tags to notes and then filter or sort notes based on these tags.
Acceptance Criteria
Media can be uploaded through the application and is saved to the Amazon S3 Bucket.
Users can organize their notes into folders, and the UI reflects this folder structure appropriately.
Users have the ability to sort notes by tags, enhancing the note management experience.
Issue
The current project enhancement involves significant improvements to the note-taking functionalities. Specifically, the integration of media uploads to Amazon S3 bucket and the implementation of a folder organization system for notes, akin to the Joplin app. These features aim to streamline the user's experience in managing and organizing notes and media within the application.

Media Uploads through S3 Bucket: 10 hours
Folder Organization of Notes: 10 hours
Sort by Tags Functionality: 10 hours

working on this within the branch of 58-note-component-redesign  also this issue is related to https://github.com/oss-slu/lrda_website/issues/62

This can be talked about at the meeting on wednesday.


Removing entry point for Wannier90

Pull Request Test Coverage Report for Build<PHONE_NUMBER>9
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 93.016%

Totals

Change from base Build<PHONE_NUMBER>7:
0.0%

Covered Lines:
35744

Relevant Lines:
38428

💛  - Coveralls


Add OpenGraph Protocol for site preview

This change should enables preview card of the website using
https://ogp.me/
See:
https://odone.io/posts/2019-04-15-adding-twitter-cards-to-hakyll-posts.html

Thanks !


fix: in tcc mode, json.Unmarshal requestContext.Headers failed

ref:
https://github.com/CECTC/dbpack/issues/12
https://github.com/cectc/dbpack/issues/194
Ⅰ. Describe what this PR did

requestContext.Headers unmarshal failed
Incorrect host passed in
Got wrong QueryString

Ⅱ. Does this pull request fix one issue?
Ⅲ. Why don't you add test cases (unit test/integration test)?
Ⅳ. Describe how to verify it
verified by tcc sample

Ⅴ. Special notes for reviews

how to find this bug

how to find this bug
When I develop the tcc sample and start debugging, the program does not run correctly, and was not submitted or rolled back as expected.

how to find this bug

When I develop the tcc sample and start debugging, the program does not run correctly, and was not submitted or rolled back as expected.

your test script can be a unittest ?

how to find this bug

When I develop the tcc sample and start debugging, the program does not run correctly, and was not submitted or rolled back as expected.

your test script can be a unittest ?

ok， i will add unit test for RequestContext.Encode and RequestContext.Decode

Codecov Report

Merging #195 (fef1a34) into dev (9e741de) will decrease coverage by 2.89%.
The diff coverage is 25.64%.

@@            Coverage Diff             @@
##              dev     #195      +/-   ##
==========================================
- Coverage   46.36%   43.46%   -2.90%
==========================================
  Files          77       81       +4
  Lines        8713     9386     +673
==========================================
+ Hits         4040     4080      +40
- Misses       4286     4905     +619
- Partials      387      401      +14

Impacted Files
Coverage Δ

pkg/dt/distributed_transaction_manger.go
0.00% <0.00%> (ø)

pkg/filter/dt/filter_http.go
16.34% <ø> (ø)

pkg/filter/dt/transaction.go
0.00% <0.00%> (ø)

pkg/dt/context.go
57.14% <35.71%> (ø)

pkg/dt/mysql_undo_log_manager.go
0.00% <0.00%> (ø)

pkg/dt/mysql_undo_executor.go
0.00% <0.00%> (ø)

Continue to review full report at Codecov.

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


Documentation tells users to use version 5.0 when creating pod file

Documentation should tell users to use version 8.0.

This has been fixed, thanks for reporting!


Add support for AWS and GCP signers

Hi all,
I am thinking of contributing to this project signers for either or both AWS and GCP.
Do you believe the creation of these signers would benefit this project?
Many thanks,
Apostolos

Hi @maestros, we believe this would benefit ethsigner. It would be a great contribution thank you!

Hi @siladu, thanks for replying. That's great! I wanted to confirm with you that this functionality is currently missing from the project and that it would be a valuable addition. I will put this work in my backlog then. I might contact you again if I need to clarify some questions during the design and development of these new signers.

That's great thank you @maestros. Feel free to ask questions. Would you like to leave this issue open to track your questions?
Another option if you prefer is this channel on the ConsenSys Discord: https://discord.com/channels/697535391594446898/907168742272798750

Closed due to inactivity. Feel free to open a new issue or PR if you start work on it.


Release 1.2.10 with telemetry fixes

@jwunderl feel free to merge & test. I validated only changes are for the telemetry.


Empty table property in cloud request for standalone checks causes cloud integration to fail

Soda Cloud does not support check results without table property. This property is filled with checks for X and is not present in "standalone" checks with no table property e.g.
checks:
  ....

Options:

Disallow checks without table association
This seems very suboptimal as such checks have been identified as useful

Detect a table from the checks automatically
Seems unreliable and too much work

Change cloud to accept checks with no table.
This is technically easy, but more challenging from product point of view - the UI would have to deal with such checks appropriately.

@m1n0 Can you elaborate what you mean here?

@tombaeyens I updated the title and description with proper context.

I don't think this is severe enough that warrants extra work.


Missleading linting error message when no values.yaml file is provided for a chart

Hi!
The summary
In the chart of my project, I'm using several values files such as:

values-staging.yaml
values-production.yaml

Despite the chart successfully deploying, the linter would throw an error I could not understand:
[ERROR] templates/: render error in "test/templates/second-worker-deployment.yaml": template: test/templates/second-worker-deployment.yaml:8:21: executing "test/templates/second-worker-deployment.yaml" at <.Values.workers.second_worker.replicas>: nil pointer evaluating interface {}.second_worker

How to reproduce
Create a test chart with the following files:

Chart.yaml

name: test
version: 1.0.0
description: helm chart for test
maintainers:
  - name: Foo Bar
    email<EMAIL_ADDRESS>

values-staging.yaml

workers:
  first_worker:
    replicas: 1
  second_worker:
    replicas: 1

And two templates:

first-worker-deployment.yaml

kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: worker-first-worker
  labels:
    name: worker-first-worker
spec:
  replicas: {{.Values.workers.first_worker.replicas}}

second-worker-deployment.yaml

kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: worker-second-worker
  labels:
    name: worker-second-worker
spec:
  replicas: {{.Values.workers.second_worker.replicas}}

Now run helm lint test on the chart to get:
==> Linting test
[INFO] Chart.yaml: icon is recommended
[INFO] values.yaml: file does not exist
[ERROR] templates/: render error in "test/templates/second-worker-deployment.yaml": template: test/templates/second-worker-deployment.yaml:8:21: executing "test/templates/second-worker-deployment.yaml" at <.Values.workers.second_worker.replicas>: nil pointer evaluating interface {}.second_worker

Error: 1 chart(s) linted, 1 chart(s) failed

Inverting the template files order (by renaming them for example) would lead to the error being raised on the last file of the template folder.
Expected behavior
Well just the following output, without an error:
==> Linting test
[INFO] Chart.yaml: icon is recommended
[INFO] values.yaml: file does not exist

Output of helm version:
Client: &version.Version{SemVer:"v2.14.2", GitCommit:"a8b13cc5ab6a7dbef0a58f5061bcc7c0c61598e7", GitTreeState:"clean"}

This would be a great feature addition. PRs welcome.

If the templates are not rendered with the default values.yaml , shouldn't we throw an error? I do understand that there are different values yamls that works for users, but there's no default in this case, so if anyone uses the chart with no values yaml, then it would fail which should be explicit and the same should happen for linting or templating with no values yamls.
A better way to tackle such a problem would be at the chart level. The helm chart can have different ways to handle this error -> use required functions to say that the value is required has no default and also show good error messages and also handle nested object values and nil values

To add to the above, if linting should not fail without passing values yamls, a default values yaml should be present in the chart and it's a good practice to have default values yaml, so that anyone can easily install the chart with sane defaults - it's okay even if it's not prod values which could be drastically different

This is correct behavior. If no values file is present, and no values are passed into the linter it MUST fail with a fatal error. The reason for this is that a failed template render is by definition a linter failure.
Use the -f flag to pass in values. In a future version of Helm, we will probably add lint-values.yaml support to allow linter-only test data.


add cyclegan example script

Thanks for the review. I will make the necessary changes

Thank you @fchollet . I have added all the files


Missing Git tag for 0.11.11 and 0.11.12 releases

It would be nice to keep PyPI releases and git tags in sync :)

Sorry, forgot to push the v0.11.11 tag, it is now there.

There is no tag for v0.11.12 (yet).

Now there is. I'll update the releasenotes tomorrow (probably).

And thanks again for your vigilance.


How to stop without saving?

Is it possible to stop the recording and discard it?

You would need to manually remove the created file using something like RNFS.unlink(path)


ECONNREFUSED after swagger setup with YAML file.

I'm working on API First mode generating routes from openapi3.x specifications, and using supertests to execute BDD, serving the swagger-ui by using yaml.file, sort of like:
//swagger.decorator.ts
import YAML from 'yamljs'
import swaggerUi from 'swagger-ui-express'
import { ExpressCommonDecorator } from './express-common.decorator'

const swaggerDocument = YAML.load('./api-openapi.yaml')
const swaggerOptions = {
  port:3002,
  explorer : true
}

export default class SwaggerExpressDecorator extends ExpressCommonDecorator{

  configureAddon(): void {
    this.app.use('/swagger', swaggerUi.serve, swaggerUi.setup(swaggerDocument, swaggerOptions))
  }

}

For some reason, this line: YAML.load('./api-openapi.yaml'), make all supertests get broken, with the following error:
Error: connect ECONNREFUSED <IP_ADDRESS>:80
        at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1141:16)

Funky behavior = Removing the YAML.load('./api-openapi.yaml'), everything backs to normal.
I'm suspecting the I/O to read the yaml is hanging the app configuration and for some reason, supertest.default(app) not waiting this promise.
Additional infos:
The decorator ExpressCommonDecorator don't do nothing, its just a abstract class used to change/remove/add all decorators on going, without changing any code from server.ts with minimal impact.
//express-common.decorator.ts
import express from 'express'

export abstract class ExpressCommonDecorator {
  app: express.Application;

  constructor(app: express.Application) {
    this.app = app
    this.configureAddon()
  }

  abstract configureAddon(): void;
}

and server:
const app = express(),
  extended = true

// Decorate app with express ui/docs
new SwaggerExpressDecorator(app)

I forget the workaround in use:
if(process.env.NODE_ENV !== 'test') {
      const swaggerDocument = YAML.load('./dynamo-openapi.yaml')
      const swaggerOptions = {
        port:3002,
        explorer : true
      }
      this.app.use('/swagger', swaggerUi.serve, swaggerUi.setup(swaggerDocument, swaggerOptions))
}


Keeping source tree in sync with 0.14.0 release on pypi.

The github source tree was, previous to this commit, lagging behind the
release on pypi. Github code was version 0.13.1 and Pypi was 0.14. The
code in this commit is the one published on PyPi.

No plan on merging this PR ?

OK. I tagged it over there, on my own account, as there seem to be no activity on this PR. Tag 0.14.0.
https://github.com/gl-yziquel/chevron/tree/0.14.0


Move embulk-jruby-strptime into embulk-core with refactoring, making licenses clearer, and giving reasonable visibilities

@muga @sakama Before addressing #860, #846, and #830, let me refactor embulk-jruby-strptime to make it easier to modify. Can you have a look?

@sakama @muga Thanks!
@muga Yeah, I tried to divide, but the original code has had much mutual dependencies. Once refactoring one place, other places needed to change as well... Some more refactoring changes (which could be divided) are in the waiting list, actually. ;)


Link missing

Add the geo to the selected attribute on a user. The list of available geos can be found in this table.
That line is on Step 9. There is no link for the table.

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

ID: b285f539-0487-0de5-24ef-89f773a1081d
Version Independent ID: b4f26f73-6b46-9703-692b-abe1f0d5f825
Content: Azure AD Connect: Configure preferred data location for Microsoft 365 resources
Content Source: articles/active-directory/hybrid/how-to-connect-sync-feature-preferreddatalocation.md
Service: active-directory
Sub-service: hybrid
GitHub Login: @billmath
Microsoft Alias: billmath

@nicoride93
Thanks for your feedback! I've assigned this issue to the author who will investigate and update as appropriate.

The following issue is being closed due to the age.  If this is still an issue, please re-submit this.  Thank you.
#please-close


Suggestion to be added in for a good perpose

Is there a way for you guys to add a add/remove in tinkers construct for modifiers. so like for me i want to remove certus quarts as a modifier so it will not give sharpness to anything if i try to use it in the tool station and such

How should we add Modifier? Each modifier has its onw logic which define its behaviour. Removing is already possible.

I sead add / remove a item as a modifier so like removed certus quarte being able to give you sharpness in the tool station

Sorry, I don't think this good to implement in Minetweaker/Modtweaker. The items for the modifiers are save in the modifer object itself. Since each specific modifertype class has it's unique structure we can't access this in a general way.

it would be awesome because for example extra tic has a certus quarts pick axe and to repair it you need certus quarts but if you have an available modifier then it repairs it and gives you sharpness on the tool


HMS-3165 fix: blank custom deployment

This change add ephemeral cluster rules to deploy commits on dev cluster for getting earlier state on dev cluster, fixing the unfinished initial changes for HMS-2678 for the frontend.
Now we could deploy the custom local commits in the ephemeral cluster allowing earlier verification (and not getting the blank screen).

Merged in the graph of #30.


[language][prover] Integrate new prelude with translator.

Motivation
This takes up the work Shaz did on the new memory and array encoding and integrates it with the translator. The prelude has also been tweaked a bit:

Sectioninzing, rearranging, and documenting for better readability.
Adding helpers to abstract from actual memory model for the translated code. This should allows us for now to easier experiment with the encoding.
Fixing some type check errors.

Nothing has been tested yet with real verification, but with this change we should be ready to do so.
Have you read the [Contributing Guidelines on pull requests]
Yes
Test Plan
Existing tests, updated golden tests.
Related PRs
NA

Updated this PR to also eliminate has_type deep check and instead using is#XXX for type assumptions on shallow level only (as suggested by Clark previously).

@bors-libra r=sblackshear,cbarrettfb

:pushpin: Commit a8b530e has been approved by sblackshear,cbarrettfb

:hourglass: Testing commit a8b530e5272b9855089fc2f5fadb5aae9d507139 with merge 13409365d89b3ef78bb0b9d4ed2f144148cda6fe...

:sunny: Test successful - checks-circle_commit_workflow
Approved by: sblackshear,cbarrettfb
Pushing 13409365d89b3ef78bb0b9d4ed2f144148cda6fe to master...


Change WandB forecast table format

🚀 Feature Request
Now we squash forecast dataframe to given format in WandbLogger. It is not necessary anymore because we have TSDataset.to_flatten that can help with the task.
Motivation
If we can use an existing data format, we shouldn't create a new one.
Proposal
Replace _prepare_table method with TSDataset.to_flatten
Test cases
No response
Alternatives
No response
Additional context
No response
Checklist

[x] I discussed this issue with ETNA Team

closed in #309


[docs] mention need for redux-promise-middleware

README.md make no mention of redux-promise-middleware although it's impossible to get it working without it or an equivalent.
https://github.com/feathers-plus/feathers-redux/blob/master/example/client/middleware/index.js#L12

A PR is welcome.

ProTip: You have to include redux-promise-middleware and redux-thunk
in your middleware.

https://github.com/feathers-plus/feathers-redux/blame/master/README.md#L128
It's a little low down in the README, but it's there.

oh, okay :) shall we close this then?


Bring dependencies current

Signed-off-by: Gábor Lipták<EMAIL_ADDRESS>By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Hey @gliptak, thanks for the PR, but we have a policy of restricting dependency upgrades to project maintainers.


fixed the blance

I fixed the blance so it is balance

I corrected a merge conflict and I am waiting for the pull request to pass the continuous integration deployment and tests.


UI improvements of Camps Admin

Multiple improvements that I can think of, discuss here or on Slack
Illustration:

Ugly buttons
Status localization
Time/Date format


luci-app-openvpn: not reachable over IPv6 configured by LUCI

Hi!
in the package "luci-app-openvpn"
OpenWrt 18.06.2 r7676-cddd7b4c77 / LuCI openwrt-18.06 branch (git-19.275.23087-48f58d9) is a configuration problem in the files
/usr/lib/lua/luci/model/cbi/openvpn-advanced.lua and /usr/lib/lua/luci/model/cbi/openvpn-basic.lua
both files contains
ListValue,"proto",{ "udp", "tcp-client", "tcp-server"  }
But need to contain the ipv6 versions too.
So the line needs to be:
ListValue,"proto",{ "udp", "tcp-client", "tcp-server" ,"udp6", "tcp6-client", "tcp6-server" }.
source: https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4/

proto indicates the protocol to use when connecting with the remote, and may be “tcp” or “udp”.
For forcing IPv4 or IPv6 connection suffix tcp or udp with 4/6 like udp4/udp6/tcp4/tcp6.

P.S. maybe the whole cataloge of options needs to be checked for completeness.
P.P.S. The std path of openvpn-easy-rsa gernerated profiles do not match the std setup of luci too.
Br
GFTwrt

The missing option are also not applied to 19.07 and master
@GFTwrt please open a pull request


Can't update Motrix

no such "app-update.yml"

Error When checking for update

no such "app-update.yml"

Solve with this :
https://github.com/agalwood/Motrix/issues/1083

ref to #1006


Try make build in either the hbm or the litedram code to see the MiGen simulator

Explored this, provides a path forward on simulation of AXI interface, taking cues from test_axi and test_hbm files.


Add blogpost on accessibility

And also

Add Jekyll stuff to .gitignore.
Add simple README to explain how to get started on adding a blog post

OK to merge @rnystrom?

Thanks for the copy edits 😍
Sent with GitHawk

Can you make them into em dashes, —?


Issue after changing password

Casdoor cannot recognize the logged-in user after changing password:

Fixed in: https://github.com/casdoor/casdoor/commit/377ac05928e0c0f82c3e5f0e5ff3b86ce3177cff


ClientModel: multipart investigation

Back to looking at what "option 2" looks like

API change check
API changes are not detected in this pull request.


Crud for model with JSON property not working (provided nested relation is not allowed)

Hi,
I'm trying out this CRUD generation service and hit a bit of a blocker:
This is my simple prisma model:
model Label {
  id           String   @id @default(cuid())
  createdAt    DateTime @default(now())
  updatedAt    DateTime @updatedAt
  name         String
  data         Json
}

I've followed the steps to set up the crud controller and it automatically created a label module.
However, when I fire a request:
curl --request POST \
  --url http://localhost:3000/label \
  --header 'content-type: application/json' \
  --data '{
  "name": "Testing",
  "data": {
    "someprop": "somval"
  }
}'

It returns the following error:
{
  "message": "Provided nested relation is not allowed: data",
  "error": "Bad Request",
  "statusCode": 400
}

You can see it's complaining about the JSON object.
When I try to create a new label from PrismaClient directly, there is no problem.
Not sure if this is a bug or a security feature on the crud controller?

Hi! Json fields are not supported at the moment. This is described in the Limitations section of the docs.
The suggested workaround at the moment is to store the JSON object as a string.