Website: build and deployment overhaul

Our current strategy for deploying production Jekyll-based websites is to have the web servers both building and serving the static website. This has been working relatively well but has the downsides of the deployment of build-only Ruby dependencies on the server and the maintenance of the Ansible role.
The openmicroscopy.jekyll-build role and by extension the OME playbooks are current failing due to upstream issues with bundler 1.16.2 -see https://github.com/bundler/bundler/issues/6537.
Following what has been pioneered in https://github.com/IDR/idr.openmicroscopy.org andhttps://github.com/IDR/idr-analysis.openmicroscopy.org, this PR proposes to switch our building and deployment strategy as follows:

the website are built using the upstream Jekyll Docker images rather than installing dependencies
on tag, the generated website is attached as an artifact of a GitHub release
downstream, the playbooks can be adjusted to consume these artifacts unzip them and be served statically

This PR proposes the first step of this overhaul:

.travis.yml is modified to use the jekyll/builder:pages image assuming we want to keep using the GitHub Pages deployment  to http://openmicroscopy.github.io/www.openmicroscopy.org/ and http://snoopycrimecop.github.io/www.openmicroscopy.org/ for testing PRs against this repository
the htmlproofer step is preserved for internal links
on tags, the deploy strategy is configured to push artifacts to GitHub - https://docs.travis-ci.com/user/deployment/releases/. The GITHUB_OAUTH_TOKEN can be set at the level of the environment variables in Travis rather than being encrypted in the file
Gemfile is removed being redundant with the Jekyll image (also removes the maintenance burden)
_dev.yml is removed. The development configuration (used by GitHub pages) is _config.yml itself while the production configuration is _config.yml and_prod.yml

To test the deployment step, I created a tag from the HEAD of this branch and set up a personal OAuth token in my own Travis builds - see https://github.com/sbesson/www.openmicroscopy.org/releases and https://travis-ci.org/sbesson/www.openmicroscopy.org/builds/402700407

Thanks @manics.  ab03601 updates the Travis file to dynamically retrieve the artifact name from the GitHub repository. I recreated a release artifact for the last commit at https://github.com/sbesson/www.openmicroscopy.org/releases/download/2018.07.11/www.openmicroscopy.org.tar.gz
NB: the last commit also includes a proposed switch to use a Calendar Versioning scheme for upcoming releases. I picked http://calver.org/#youtube-dl as the closest one to our exising YYYY0M0D scheme.

Merging as per discussion with @kennethgillen and @manics


table alias: make really unique

If the alias has already been made on the field once it won't be truly
unique. This will recursively make it unique. Also, it will probably
create a humongous query.

Good catch. Thanks for the PR. I missed such a case in the tests. Will create a test for this and release soon.

Published v0.3.6


typescript: always build when running 'yarn test' [phab:D1359]

Created by evmar at 2017-02-21 23:56:54:
You need to 'yarn build' before you run tests, and it's easy
to overlook.  Make the default behavior always build, and provide
'yarn runtest' for using while developing.
(Really this screams for a real build system but it's so simple
that hopefully this hacky thing will continue to work for now...)

zarko accepted this revision at 2017-02-22 00:10:59

zarko closed via commit 18554417de3dfd0194b6ac72b36570bc0938ace7 at 2017-02-22 00:11:34


Stop doing react-native link for RN projects

Describe the desired behavior
The latest version of react native / react native cli do autolinking via gradle and cocoapods, so we shouldn't need to run the rnlink command anymore. Look at the instructions for RNVI for how to use Cocoapods (we are already using Gradle on the android side). We will need to modify the podfile to add a line and we will need to add a new entry in the Info.plist file too.
Describe the current behavior
Currently we do rnlink to link up fonts for react native vector icons package.
Is this request related to a current issue?
No.
Additional Context

If we can successfully take this out, we may no longer need to include the extra step instructions for removing the duplicate resources and the end of the CLI workflow.

This was fixed in a previous release...forgot to link to the issue for it.


Roll Flutter Engine from 347a4f3b6892 to 591e5cf61db0 (2 revisions)

https://github.com/flutter/engine/compare/347a4f3b6892...591e5cf61db0
2023-03-09<EMAIL_ADDRESS>Roll Fuchsia Mac SDK from SlKTzfi-Jbx8nt3me... to lfirU5p2GigxFWZVA... (flutter/engine#40158)
2023-03-09<EMAIL_ADDRESS>Remove single-window assumption from scenario_app (flutter/engine#40156)
Also rolling transitive DEPS:
fuchsia/sdk/core/mac-amd64 from SlKTzfi-Jbx8 to lfirU5p2Gigx
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Please CC jimgraham@google.com,rmistry<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose
To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md

Commit queue failed; closing this roll.


Develop a more concise naming scheme for BpfPrograms

The names are currently very long.  For example:
k get bpfprograms.bpfman.io
NAME                                                                                TYPE          STATUS         AGE
bpfapplication-sample-kprobe-try-to-wake-up-bpfman-deployment-control-plane-try-to-wake-up                         application   bpfmanLoaded   109s
bpfapplication-sample-tc-ingress-eth0-bpfman-deployment-control-plane-eth0                                         application   bpfmanLoaded   104s
bpfapplication-sample-tracepoint-syscalls-sys-enter-kill-bpfman-deployment-control-plane-syscalls-sys-enter-kill   application   bpfmanLoaded   106s
bpfapplication-sample-uprobe-malloc-bpfman-deployment-control-plane-libc-bpfman-daemon-wbktz-bpfman                application   bpfmanLoaded   97s
bpfapplication-sample-uprobe-malloc-bpfman-deployment-control-plane-libc-bpfman-daemon-wbktz-bpfman-agent          application   bpfmanLoaded   100s
bpfapplication-sample-xdp-eth0-bpfman-deployment-control-plane-eth0                                                application   bpfmanLoaded   94s
kprobe-example-bpfman-deployment-control-plane-try-to-wake-up                                                      kprobe        bpfmanLoaded   69s
tc-pass-all-nodes-bpfman-deployment-control-plane-eth0                                                             tc            bpfmanLoaded   28s
tracepoint-example-bpfman-deployment-control-plane-syscalls-sys-enter-openat                                       tracepoint    bpfmanLoaded   28s
uprobe-example-bpfman-deployment-control-plane-libc                                                                uprobe        bpfmanLoaded   58s
uprobe-example-containers-bpfman-deployment-control-plane-libc-bpfman-daemon-wbktz-bpfman                          uprobe        bpfmanLoaded   43s
uprobe-example-containers-bpfman-deployment-control-plane-libc-bpfman-daemon-wbktz-bpfman-agent                    uprobe        bpfmanLoaded   50s
xdp-pass-all-nodes-bpfman-deployment-control-plane-eth0                                                            xdp                          18s

We need a way to uniquely and deterministically determine the names of the BpfProgram objects created on a given node resulting from a given *Program or BpfApplication CRD.  The bpfman agent controller uses this name to compare the existing programs (getExistingBpfPrograms()) to the expected programs (getExpectedBpfPrograms()) during a reconcile pass.
An idea is to create a name for the BpfProgram object based on the *Program or BpfApplication CRD name plus a randomly generated string, and then save a longer unique and deterministic string used for comparisons and lists.

Here's the new output:
$ kubectl get bpfprograms.bpfman.io
NAME                                        TYPE          STATUS         AGE
bpfapplication-sample-kprobe-e9584268       application   bpfmanLoaded   6m31s
bpfapplication-sample-tc-5c64641c           application   bpfmanLoaded   6m24s
bpfapplication-sample-tracepoint-1f1a61a1   application   bpfmanLoaded   6m26s
bpfapplication-sample-uprobe-72e8858d       application   bpfmanLoaded   5m9s
bpfapplication-sample-uprobe-b4fde6c2       application   bpfmanLoaded   5m1s
bpfapplication-sample-xdp-f3ef4383          application   bpfmanLoaded   4m53s
fentry-example-cd940fa0                     fentry        bpfmanLoaded   5m20s
fexit-example-fd53742b                      fexit         bpfmanLoaded   6m20s
kprobe-example-f24ff1d3                     kprobe        bpfmanLoaded   6m11s
tc-pass-all-nodes-563ab6b1                  tc            bpfmanLoaded   5m51s
tracepoint-example-4a04a14a                 tracepoint    bpfmanLoaded   6m1s
uprobe-example-17e5ab9b                     uprobe        bpfmanLoaded   5m30s
uprobe-example-containers-9412fff0          uprobe        bpfmanLoaded   5m23s
uprobe-example-containers-d6b84e71          uprobe        bpfmanLoaded   5m26s
xdp-pass-all-nodes-c6626947                 xdp           bpfmanLoaded   5m40s```


Diacritics in the PUA range?

I am currently working on making a font for a conlang.

Blue: Characters
Orange: Diacritics
I want to keep the range of characters in PUA, so when the font is used with normal texts, normal texts won't be affected.
This is one of the diacritics.

So how do I make a PUA unicode become a diacritic with mkfont?
How can I configure some specific OpenType features?
Is it possible to do within mkfont?

Hey there!
Sadly mkfont doesn't explicitly support OpenType features -- some are supported under the hood, but the library I'm using doesn't support character variants nor kerning (ugh, I know :( )
Depending on your conlang architecture, you may be able to hijack existing sets that have matching diacritics? Otherwise you'll have to resort to create individual ligatures for each possible combination in lieu of OpenType ones.
As for PUA, although it's a bit painful to do, you can access them at the very bottom of the Unicode blocks in the Content browser area:

After a bit of research, I found various ways to implement my conlang font
And I found this tutorial for Fontforge
https://www.youtube.com/watch?v=io56-xzCbms
Can mkfont also do this?
i.e.: Adding mark/ mkmk anchors to characters/ PUA characters?

hmmm sadly no, I need to change the underlying font engine to support more advanced features :(
This is something I plan on doing in the future but I need to evaluate how much work that means first and I don't have a lot of time to focus on that at the moment.


Remove pairs from commands

https://github.com/TheOdinProject/odin-bot-v2/blob/master/botCommands/simpleCommands.js#L64

submitted a PR #60


BackendFetch: headers are evaluated once the client is created

Hello 👋🏼
We are using the tolgee/vue adapter and are running into a problem when using BackendFetch.
We have an API that acts as a proxy between the public web and the tolgee API and therefore wanted to start using BackendFetch. The API is protected using a jwt-like token and therefore fetching the translations must wait until the user has gotten a fresh token.
function createClient() {
  const { getToken } = useToken()
  const client = Tolgee().use(FormatIcu())

  if (!import.meta.env.DEV) {
    client.use(
      BackendFetch({
        prefix: `${import.meta.env.VITE_EMT_API_URL}/api/v1/i18n`,
        headers: {
          Accept: 'application/json',
          Authorization: `Bearer ${getToken()}`
        }
      })
    )
  }

  return client
}

The problem is that headers is evaluated once the client is created instead of when the request is submitted. I haven't found a way to make this evaluation lazy and therefore an outdated token is sent.
I guess one option could be to introduce a new method getHeaders() which is executed on request rather than client initialization.

Hey, I think you can solve this by creating custom plugin for fetching. The BackendFetch is basically just a simple helper around plugin API.
const customPlugin: TolgeePlugin = (tolgee, tools) => {
  tools.addBackend({
    async getRecord(data) {
      return (
        await data.fetch(`/i18n/${data.language}.json`, {
          headers: { Authorization: `Bearer ${getToken()}` },
        })
      ).json();
    },
  });
  return tolgee;
};

And then pass this to tolgee instead of BackendFetch:
const tolgee = Tolgee()
  .use(customPlugin)
  .init({
    ...
  });

That is a pretty sweet idea, @stepan662. Thank you. I would have thought creating a plugins involves more work.
In case anyone lands on this thread - this is what we have implemented:
interface ApiFetchOptions {
  prefix: string
  modifyHeaders: (defaultHeaders: Record<string, string>) => Record<string, string>
}

const ApiFetch = (options: ApiFetchOptions) => {
  const plugin: TolgeePlugin = (tolgee, tools) => {
    tools.addBackend({
      async getRecord(data) {
        return (
          await data.fetch(`${options.prefix}/${data.namespace}/${data.language}.json`, {
            headers: options.modifyHeaders({
              Accept: 'application/json'
            })
          })
        ).json()
      }
    })

    return tolgee
  }

  return plugin
}

function createClient() {
  const { getToken } = useToken()
  const client = Tolgee().use(FormatIcu())

  // Note: we are using a custom plugin in order to be able to set the Authorization header
  // dynamically based on the current user's token. The default `BackendFetch` plugin can
  // only set headers on plugin initialization rather than on each request
  if (!import.meta.env.DEV) {
    client.use(
      ApiFetch({
        prefix: `${import.meta.env.VITE_EMT_API_URL}/api/v1/i18n`,
        modifyHeaders(defaultHeaders) {
          return {
            ...defaultHeaders,
            Authorization: `Bearer ${getToken()}`
          }
        }
      })
    )
  }

  return client
}


Support headless browsers

Developers working with Shaka Player have always been able to launch headless versions of browsers, for example with --browsers ChromeHeadless.  Since Shaka Player started using this launcher, users can no longer do that.  (Though --use-xvfb is still available for Linux.)
We should support headless browser variants where possible.

I made some progress on this. @joeyparrish please take a look at https://github.com/ppaneksamsung/karma-local-wd-launcher/commit/b7987a75db654343b113e57b0084032b8d6fc871 if you'll have some time and share your opinion if this approach is correct. I'm still working on this because a lot shaka-player's tests fail, for example:
Chrome Headless 80.0.3987.132 (Linux x86_64) TextDisplayer layout using UI moves cues to avoid controls FAILED
        Error: ui-cue-with-controls: Expected 0.9394849000884838 not to be less than 0.95.
            at <Jasmine>
            at Function._callee4$ (test/test/util/util.js:460:46 <- test/test/util/util.js:759:58)
            at tryCatch (node_modules/babel-polyfill/dist/polyfill.js:6900:40)
            at Generator.invoke [as _invoke] (node_modules/babel-polyfill/dist/polyfill.js:7138:22)

Thanks for working on this!  I'll take a look at your fork soon.
For the purposes of this, you can ignore "TextDisplayer layout" failures.  Those Shaka Player tests are newly-enabled by this module, and it's possible that our thresholds for passing screenshots are too high.  (Screenshots depend on rendering, which depends on your GPU, so small differences are to be expected on the edges of things.)
You can disable them for now in Shaka Player by editing test/ui/text_displayer_layout_unit.js and changing filterDescribe to xfilterDescribe:
https://github.com/google/shaka-player/blob/6d76a135e5128dfd47653acea025d0a264d121d5/test/ui/text_displayer_layout_unit.js#L20
Or you can modify the threshold (and send a PR to Shaka Player) by editing the same file and changing minSimilarity:
https://github.com/google/shaka-player/blob/6d76a135e5128dfd47653acea025d0a264d121d5/test/ui/text_displayer_layout_unit.js#L38

I think your changes so far look perfect to me.  Please send a PR when you are ready!

Okay, I sent a PR.
To summarize:
$ python3 build/test.py --use-xvfb --browsers Edge Chrome Firefox
...
Chrome 80.0.3987.132 (Linux x86_64): Executed 2192 of 2208 (skipped 16) SUCCESS (7 mins 33.103 secs / 7 mins 29.178 secs)
Edge 98.0.1108.43 (Linux x86_64): Executed 2145 of 2208 (29 FAILED) (skipped 63) (7 mins 31.821 secs / 7 mins 28.343 secs)
Firefox 73.0 (Ubuntu 0.0.0): Executed 2144 of 2208 (3 FAILED) (skipped 64) (8 mins 10.906 secs / 8 mins 5.297 secs)
TOTAL: 32 FAILED, 6449 SUCCESS

$ python3 build/test.py --browsers EdgeHeadless ChromeHeadless FirefoxHeadless
...
Chrome Headless 80.0.3987.132 (Linux x86_64): Executed 2192 of 2208 (6 FAILED) (skipped 16) (7 mins 51.683 secs / 7 mins 47.684 secs)
Edge 98.0.1108.43 (Linux x86_64): Executed 2145 of 2208 (29 FAILED) (skipped 63) (7 mins 9.529 secs / 7 mins 6.256 secs)
Firefox 73.0 (Ubuntu 0.0.0): Executed 2144 of 2208 (skipped 64) SUCCESS (8 mins 25.067 secs / 8 mins 19.563 secs)
TOTAL: 35 FAILED, 6446 SUCCESS

In case of Chrome Headless, 5 of fails can be caused by --disable-gpu flag as you pointed out (Expected 0.9394849000884838 not to be less than 0.95.).  There are some problems with screenshots on Edge browsers (headless and not), because screenshots are not similar at all (for example: Expected 0.0010140377756393578 not to be less than 0.95.) and there is one flaky test:
Chrome Headless 80.0.3987.132 (Linux x86_64) StreamingEngine gap jumping won't jump large gaps with preventDefault() FAILED
        Error: Expected 2 to be 1.
            at <Jasmine>
            at _callee17$ (test/media/streaming_engine_integration.js:530:25 <- test/media/streaming_engine_integration.js:896:33)
            at tryCatch (node_modules/babel-polyfill/dist/polyfill.js:6900:40)
            at Generator.invoke [as _invoke] (node_modules/babel-polyfill/dist/polyfill.js:7138:22)

Basing on above, I think that there are no issues with headless browsers itself.

The screenshots for Edge on Linux are completely missing.  We don't have that combination in our test infrastructure yet.  So those 29 are expected until somebody adds them.  Sorry for that!  The screenshot tests are only very recently available outside the Google test lab, and we're still dealing with a few issues like that.
If you want to send a PR with adjustments to the threshold for screenshot similarity, that would be appreciated!


uv dendency resolution upper-bound problem leading to a suboptimal resolution

Hi! I'm trying to upgrade accelerate to use uv pip install and we're hitting a weird issue where the dependency resolution wants to only install a very old version of datasets and as a result our suite fails. I'm specifying the exact same environment and everything as the working old installation via just pip install & python 3.8. As a result it should be installing datasets 3.0.0 like the original workflow does, however we're finding it's installing an old 2.x.x version instead.
Any help would be appreciated.
Here is the old workflow and here is the new one.
A broken run log is available here, which is showing that the wrong version of datasets is being installed (should be 3.0.0+)

Hey. I'm happy to look into why that version of datasets is selected, but it's likely that this is an equally valid resolution to whatever you're seeing with pip install. Your datasets dependency is unconstrained, so my guess is that uv is installing a new version of some other package (as compared to pip's resolution) which is leading us to be forced into selecting an older version of datasets. In the absence of defined constraints, it's not clear that using datasets 3.0.0 is better than 2.x.x (assuming we're giving you a newer version of some other package than in pip's resolution). My suggestion here is typically to add a constraint on datasets itself, if you're expecting a certain version to be used.

(I'll try to figure out the dependencies that are leading to this resolution, though. It's typically because something else you depend on is applying an upper-bound on datasets.)

@charliermarsh however the key is it's not. Using pip install natively gives a different valid resolution than using uv. If that were the case, I'd expect them to be the same as well but they are not

Can you clarify your comment? There are many equally-valid resolutions for that set of constraints. Separately, do you have a reference to pip's resolution that I can use for comparison (e.g., a comparable CI run)?

@charliermarsh sure.
Currently working run: https://github.com/huggingface/accelerate/actions/runs/11285497593/job/31412054466?pr=3154
Broken run: https://github.com/huggingface/accelerate/actions/runs/11293796747/job/31412771583
(See the Show Installed Libraries steps)
Otherwise phrased as:

uv pip install's resolution version for datasets leads to datasets==2.14.4
pip install's resolution version for datasets leads to the expected datasets==datasets==3.0.1

Ok... So it looks like the uv resolution ends up choosing a more recent version of fsspec (fsspec==2024.9.0), while the pip resolution ends up with fsspec==2024.6.1. datasets then applies an upper-bound constraint to fsspec (fsspec[http] (<=2024.6.1,>=2023.1.0)), so we backtrack to an older version of datasets that does not have such a bound.
pip's resolution is more intuitive in that case (and we're working on adding better heuristics for these kinds of upper-bound cases -- it also happens often with Numba, which puts an upper-bound on Numba), but formally both are correct -- they're just different solutions given the set of constraints. That's why I'd typically recommend adding a datasets>=3 lower-bound to your requirements. Otherwise, it's not incorrect for a resolver to give you a resolution that prioritizes getting the most recent fsspec, even if it's not the preferred outcome.
\cc @konstin as another example of this upper-bound problem leading to a suboptimal resolution

Sadly doing such a large pin like that is a bit of a non-negotiable with our testing and resolutions since we build our frameworks to be backwards compatible as much as possible. I'd rather wait to upgrade to uv until this problem can be fixed.

To clarify, I consider the resolution here to be formally correct, but unintuitive for users (and want to change it -- the same pattern has come up before).

Another option is you can reorder your dependencies to instruct uv to prioritize datasets over other packages.

I want to offer a more general perspective on version constraints: Using the APIs of your dependencies, you require at least a certain version of that dependency implictly: There's a specific version under which your code works, and lower version that doesn't have the APIs you use yet. By specifying lower bounds on your dependencies, you make those bounds explicit, and you avoid your users accidentally installing an older, incompatible version due to other (transitive) dependencies they have: In your case, datasets v3 is selectable, but in other cases, a user may depend on a library foo that has datasets<3, they get a broken accelerate and don't realize that it's due to the transitive datasets v2 that should have never been selected.
You can test your lower version bounds with --resolution lowest or --resolution lowest-direct (https://docs.astral.sh/uv/concepts/resolution/#lower-bounds). We recommend a CI jobs that checks whether the package works with one of these resolution-lowest settings.

As a user who was advertised to use uv as a drop in replacement, this comes with expectations that behaviors, including resolutions, will be the same between uv and standard pip. The point of this issue is it's not, and if I have the choice of running a debugging script to figure out sudden lower bounds and using the Sam, I will stick to using what doesn't break.

As someone who contributes to pip's resolution code it should be noted that pip makes no guarantees it will produce the same resolution between pip versions, in fact pip makes no guarantees it would produce the same resolution on the same version of pip when run twice in a row.
Pip only guarantees that if it produces a resolution, it will be a valid resolution, so if uv is doing that then I would consider that compatible with pip. As pip can just as easily break your assumptions about what it should resolve to between versions.
That said, I have been a long advocate that Python package resolution algorithms should prefer requirements with upper bounds. I plan to open a PR this weekend to solve https://github.com/pypa/pip/issues/12993 on the pip side, it is a less extreme version of my previous suggestion but it seems to have significant real world improvement, in my testing, of both solving faster and giving a resolution more intuitive to a user.
I think uv should probably do the same, but they would need to do their own testing. But, like, if uv could hold off for a bit, I might be able to brag I made a PR that made pip resolve faster than uv in a handful of extreme edge cases 😉 .

I've confirmed that more recent versions of uv correctly resolves to datasets==3.2.0.


Add Kodi notifications

Allow sending of start-up and trade advice to Kodi and derivatives

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
Feature that enables sending messages to Kodi.

What is the current behavior? (You can also link to an open issue here)
No such functionality exists.

What is the new behavior (if this is a feature change)?
This addition will send optional startup message and advice to an active Kodi installation if the jsonrpc service is enabled.

Other information:

This is cool! Thanks!

Refactored a little bit as the message string was too long and kodi was ignoring it.    Removed the unnecessary node-fetch and utilised the already installed request module & a little tidy up.


RenderEngine kustomize not support HelmChartInflationGenerator (must specify --enable-helm)

Hi, I'm unable to bake manifsest
I have kustomization.yaml file with content:
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: default

helmChartInflationGenerator:
  - chartName: sealed-secrets
    chartRepoUrl: https://bitnami-labs.github.io/sealed-secrets
    chartVersion: 2.0.2
    releaseName: sealed-secrets
    releaseNamespace: base
    values: ./values.yaml

and I'm indicate on it in my action<EMAIL_ADDRESS>      - name: Bake deployment SealedSecrets
        uses<EMAIL_ADDRESS>        with:
          renderEngine: 'kustomize'
          args: --enable-helm #  I need something like this
          kustomizationPath: ${{ inputs.KUSTOMIZE_SEALED_SECRETS_PATH }}
          kubectl-version: latest
        id: bake-sealed-secrets

but in this step I'm receiving a error
error: accumulating resources: accumulation err='accumulating resources from '../../../base/sealed-secrets': '/home/runner/work/code-iac/code-iac/argocd/iac/base/sealed-secrets' must resolve to a file': recursed accumulation of path '/home/runner/work/code-iac/code-iac/argocd/iac/base/sealed-secrets': trouble configuring builtin HelmChartInflationGenerator with config: `
name: sealed-secrets
releaseName: sealed-secrets
repo: https://bitnami-labs.github.io/sealed-secrets
valuesFile: ./values.yaml
version: 2.0.2
`: must specify --enable-helm
Error: Error: Failed to run bake action. Error: Error: The process '/opt/hostedtoolcache/kubectl/1.23.4/x64/kubectl' failed with exit code 1
    at ExecState._setResult (/home/runner/work/_actions/azure/k8s-bake/v2.1/node_modules/@actions/exec/lib/toolrunner.js:592:25)
    at ExecState.CheckComplete (/home/runner/work/_actions/azure/k8s-bake/v2.1/node_modules/@actions/exec/lib/toolrunner.js:575:18)
    at ChildProcess.<anonymous> (/home/runner/work/_actions/azure/k8s-bake/v2.1/node_modules/@actions/exec/lib/toolrunner.js:469:27)
    at ChildProcess.emit (events.js:[31](https://github.com/xxx/runs/5496238727?check_suite_focus=true#step:5:31)4:20)
    at maybeClose (internal/child_process.js:1022:16)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:287:5)

in kustomize I can reproduce it with ommit flag  --enable-helm but after I add it to args like this:
kustomize build --enable-helm .  it works perfeclty
There is any plan to add this feature?

We are working on this now with #61.


(i) CLI updates, (ii) makefile, (iii) misc updates

WIP (Work in progress)

Updates
    - Added: makefile
    - Code style: Misc minor code style updates for PEP8 and other PEP compliance.
      - Comments at top of file
      - Spacing
      - Import reordering: (i) standard libary, (ii) external packages, (iii) imports from within package.
    - Documentation
      - Added some code comments.
      - Added CLI help text.
      - Updated formatting of README
    - Updates: CLI
      - Added ability to call the package directory: `python -m comp_loinc`
      - Added / updated help text
      - Added defaults
      - Updated types: str -> path for several
      - Added: Path types: requirement for some paths: (i) exists=True, (ii) writable=True
      - Added: Path types relative to absolute path resolution: resolve_path=True

@putmantime I think this is ready for review / merging.


bump minimum versions, drop py38

This updates our minimum versions based on our 24/18/12 month policy.
Details are shown below.

[x] User visible changes (including notable bug fixes) are documented in whats-new.rst

❯ ./ci/min_deps_check.py ./ci/requirements/min-all-deps.yml
...

Package           Required             Policy               Status
----------------- -------------------- -------------------- ------
python            3.9     (2020-10-07) 3.9     (2020-10-07) =
boto3             1.20    (2021-11-08) 1.20    (2021-11-08) =
bottleneck        1.3     (2021-01-20) 1.3     (2021-01-20) =
cartopy           0.20    (2021-09-17) 0.20    (2021-09-17) =
cdms2             3.1     (-         ) -       (-         ) (!)
cfgrib            0.9     (2019-02-25) 0.9     (2019-02-25) =
cftime            1.5     (2021-05-20) 1.5     (2021-05-20) =
dask-core         2022.1  (2022-01-14) 2022.1  (2022-01-14) =
distributed       2022.1  (2022-01-14) 2022.1  (2022-01-14) =
flox              0.5     (2022-05-02) 0.3     (2021-12-28) > (!)
h5netcdf          0.13    (2022-01-12) 0.13    (2022-01-12) =
h5py              3.6     (2021-11-17) 3.6     (2021-11-17) =
hdf5              1.12    (2021-01-01) 1.12    (2021-01-01) =
iris              3.1     (2021-11-23) 3.1     (2021-11-23) =
lxml              4.7     (2021-12-14) 4.7     (2021-12-14) =
matplotlib-base   3.5     (2021-11-17) 3.5     (2021-11-17) =
nc-time-axis      1.4     (2021-10-23) 1.4     (2021-10-23) =
netcdf4           1.5.7   (2021-04-19) 1.5     (2021-04-19) = (w)
numba             0.55    (2022-01-14) 0.55    (2022-01-14) =
numpy             1.21    (2021-06-22) 1.21    (2021-06-22) =
packaging         21.3    (2021-11-18) 21.3    (2021-11-18) =
pandas            1.3     (2021-07-02) 1.3     (2021-07-02) =
pint              0.18    (2021-10-26) 0.18    (2021-10-26) =
pseudonetcdf      3.2     (2021-10-16) 3.2     (2021-10-16) =
pydap             3.2     (2020-10-13) 3.2     (2020-10-13) =
rasterio          1.2     (2021-09-02) 1.2     (2021-09-02) =
scipy             1.7     (2021-06-27) 1.7     (2021-06-27) =
seaborn           0.11    (2020-09-19) 0.11    (2020-09-19) =
sparse            0.13    (2021-08-28) 0.13    (2021-08-28) =
toolz             0.11    (2020-09-23) 0.11    (2020-09-23) =
typing_extensions 4.0     (2021-11-17) 4.0     (2021-11-17) =
zarr              2.10    (2021-09-19) 2.10    (2021-09-19) =

Errors:
-------
1. not found in conda: cdms2

@pydata/xarray - This PR is ready for discussion / review.
Our minimum versions policy says its time to drop Python 3.8. But do we want to do that?
I'll note that work is already underway to support Python 3.11 (#7316).

Our minimum versions policy says its time to drop Python 3.8. But do we want to do that?

Numpy is about to do it too: https://github.com/numpy/numpy/pull/23053 so I'm :+1: on it.

I'm doing a bit of an audit on our conditional version logic. A few questions that I don't know how to resolve on my own.
_SupportsDType - @headtr1ck, do you have a suggestion for how to handle this comment:
https://github.com/pydata/xarray/blob/b21f62ee37eea3650a58e9ffa3a7c9f4ae83006b/xarray/core/types.py#L57-L62
timedeltas - @spencerkclark, do you have a suggestion for how to handle this comment:
https://github.com/pydata/xarray/blob/b21f62ee37eea3650a58e9ffa3a7c9f4ae83006b/xarray/coding/times.py#L358-L363

GenericAlias - @Illviljan, do you have a suggestion for how to handle this comment:
https://github.com/pydata/xarray/blob/b4e3cbcf17374b68477ed3ff7a8a52c82837ad91/xarray/core/coordinates.py#L31-L40

@jhamman, I believe you should simply remove GenericAlias  and the __class_getitem__ it was a hack copied from a newer version of collections, see https://github.com/pydata/xarray/pull/7285#discussion_r1027253337.
Commit testing the hack: https://github.com/pydata/xarray/pull/7285/commits/d8bef27e54aa9e81873d5d64fca6a1d4d324ca62

@jhamman nice -- thanks for noting that.  I think you can replace timedeltas with unique_timedeltas here:
https://github.com/pydata/xarray/blob/b21f62ee37eea3650a58e9ffa3a7c9f4ae83006b/xarray/coding/times.py#L365
and then remove any reference to timedeltas in the rest of the function.

@Illviljan, @shoyer, or @keewis - do any of you have suggestions for how to respond to this comment?
https://github.com/pydata/xarray/blob/b21f62ee37eea3650a58e9ffa3a7c9f4ae83006b/xarray/core/types.py#L57-L62

I'm not sure at all about this but maybe you're supposed to go back to something like this?
https://github.com/pydata/xarray/pull/6834/commits/7fcc11ffb20583caf1976191997bd2a7525ac218#diff-791d93adb64d0986ac499ce1ba831cc95b4ffbde0dfe98b28d929935b05d7134L49
from numpy.typing._dtype_like import _DTypeLikeNested, _ShapeLike, _SupportsDType

From #6834.

After thinking about this a bit more, I suggest we leave the numpy dtype issue for later. I'd rather not import the private dtypes (at least as part of this PR).
So plan for going forward. @dcherian has already approved this PR. I think it would be good to get one more reviewer to double check things here. Then, assuming things are looking good, I'd like to merge. I will open an issue about the dtype import to track that separately.

I have very few time lately but I should be able to have a look in the next few days of you can wait a bit longer.
But also fine if you merge now and I check this dtype thing later.

Thanks @jhamman

Hi,
Just to let you know that this change breaks python 3.8 setups with automatic updates becuase the pandas version is not restricted, so it will be happily updated to version 2 or higher. Which in turn is not compatible with xarray < 2023.2, which cannot be installed on python 3.8 because of this change.
Don't know why the min python version was changed, this PR doesn't say why it was necessary.
Cheers.

Here is our support policy for versions: https://docs.xarray.dev/en/stable/getting-started-guide/installing.html#minimum-dependency-versions though I think we dropped py38 too early.
For your current issue, I'm surprised this patch didn't fix it: https://github.com/conda-forge/conda-forge-repodata-patches-feedstock/pull/429
cc @hmaarrfk @ocefpaf

Hi @dcherian

Here is our support policy for versions: https://docs.xarray.dev/en/stable/getting-started-guide/installing.html#minimum-dependency-versions though I think we dropped py38 too early.

I assume you have given this a lot of thought, but imho the minimum dependency versions should be decided according to features needed, not timing.

For your current issue, I'm surprised this patch didn't fix it: conda-forge/conda-forge-repodata-patches-feedstock#429

Thanks for the pointer.
I am not sure why, maybe I was updating too eagerly before the feedstock was fixed, but mamba update --all on py38 pulled pandas 2.0 without updating xarray.
python3.8 -m pip install xarray will  result in incompatible versions.

cc @hmaarrfk @ocefpaf

Hi,

I assume you have given this a lot of thought, but imho the minimum dependency versions should be decided according to features needed, not timing.

It's not based on timing. The policy is there so that, when a developer finds that they have to do extra labour to support an old version of a dependency, they can instead drop the support for the old version without needing to seek approval from the maintainers.

That's not how I interpret the link given by @dcherian, which states "rolling" minimum versions based on age.

This also breaks xarray on ubuntu 20.04 which ships with Python 3.8 and is supported until April 2025. Python 3.8 is also supported at least until October 2024. Together with the Pandas 2 issue (that I am also running into), this is very unfortunate.

This also breaks xarray on ubuntu 20.04 which ships with Python 3.8 and is supported until April 2025. Python 3.8 is also supported at least until October 2024.

Not investing effort to support 5 years old dependencies was a very conscious decision. This is not something unique we do; we simply adhere to NEP29: https://numpy.org/neps/nep-0029-deprecation_policy.html
If for whatever reason you want to use python shipped by ubuntu 20.04, as opposed to conda/venv/poetry/whatever, you should also be prepared to stick to older versions of the python packages. Note that 5 years is the duration of security support. I'm not personally aware of security issues in xarray since Python 3.8 was abandoned (I've been a bit out of the loop and I could be proven wrong), but in the unlikely event that one should arise in xarray, we would consider a backport to Python 3.8.

It just occurred to me that xarray dropped Python 3.8 3 months before what NEP-29 recommends. I think this is a problem.
Let's continue this discussion on #7777.


TypeError null.(systeminformation.lib:cpu) fatalmodellineParts.trim is not a function

Sentry again, this time feels like a code bug :-)
https://sentry.iobroker.net/share/issue/8a131e2017404538b3f0ca3f7c7288be/
TypeError: modellineParts.trim is not a function
  File "/usr/local/iobroker/node_modules/iobroker.info/node_modules/systeminformation/lib/cpu.js", line 418, col 61, in null.<anonymous>
    result.speed = modellineParts[1] ? modellineParts.trim() : '0';
  File "child_process.js", line 299, col 7, in ChildProcess.exithandler
  File "events.js", line 315, col 20, in ChildProcess.emit
  File "domain.js", line 486, col 12, in ChildProcess.EventEmitter.emit
  File "internal/child_process.js", line 1048, col 16, in maybeClose
  File "internal/child_process.js", line 439, col 11, in Socket.<anonymous>
  File "events.js", line 315, col 20, in Socket.emit
  File "domain.js", line 486, col 12, in Socket.EventEmitter.emit
  File "net.js", line 673, col 12, in Pipe.<anonymous>

@Apollon77 sorry definitely my fault! Corrected. Version 4.30.11 just released.

np! Awesome fast fix! Thank you


NIFI-5816 Switch SFTP processors to use SSHJ

I used the atmoz/sftp Docker container to test the SFTP processors:
https://github.com/atmoz/sftp
Generate Server Keys
ssh-keygen -t ed25519 -f ssh_host_ed25519_key < /dev/null
ssh-keygen -t rsa -b 4096 -f ssh_host_rsa_key < /dev/null

Generate User Keys
ssh-keygen -t ed25519 -f foo_ed25519_key < /dev/null
ssh-keygen -t rsa -b 4096 -f foo_rsa_key < /dev/null

Launch Container
docker run \
-v /path/to/sftp-keys/foo_rsa_key.pub:/home/foo/.ssh/keys/foo_rsa_key.pub:ro \
-v /path/to/sftp-keys/foo_ed25519_key.pub:/home/foo/.ssh/keys/foo_ed25519_key.pub:ro \
-v /path/to/sftp-keys/ssh_host_ed25519_key:/etc/ssh/ssh_host_ed25519_key \
-v /path/to/sftp-keys/ssh_host_rsa_key:/etc/ssh/ssh_host_rsa_key \
-v /path/to/sftp-share:/home/foo/sftp-share \
-p 2222:22 -p 1080:1080 -d atmoz/sftp \
foo::1001

Then you can configured an SFTP processor to with host of 'localhost' and port of '2222'.

I'm excited by these changes, I was working on some changes ~ a year ago to add basic SSH processors like ExecuteSSH, but wasn't all that thrilled by the existing library.  To prepare, I added some unit tests to make sure I didn't break SFTP: NIFI-5381.  Have you looked to see if any of these features we are trying to resolve, like larger key sizes, can be tested by extending the existing test SSH Server I added: nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/test/java/org/apache/nifi/processors/standard/util/SSHTestServer.java?

I did write a new unit test for SFTPTransfer that tests every method in the class using the SSHTestServer, and I ran that unit test against the old implementation and the new one to prove everything works the same.
As far as testing the key size, I didn't do that through a unit test, but from a quick look at the SSHTestServer it seems like it may be possible using setPublickeyAuthenticator instead of the password authenticator.
Also, thanks for setting up that test server :)


Andy/214 game page

214
Issue Number(s): #214 .
What does this PR change and why?

Game summary screen is populated with the correct data
GameFinished screen implemented for after a game is completed
Start buttons direct to intro screens
Video tab removed

Checklist

[ ]  Game Summary Screens Fetch the Proper Data
[ ]  After a game is completed, direct to Congrats Screen.
[ ]  Each Game is previewed by the Preview Page
[ ]  Video Tab is Gone

Critical Changes / Notes

None

Related PRs

None

Testing
Test each start button, check to see if each game directs to game finished screen and then summary screen when complete. Ensure data on section summary is correct.

Good job on this PR! In the future be wary of the figma styles and try to reuse components as much as possible (as seen with the continue button) but thanks for getting it in on time!


daemon: Do not attach bpf_host to L3 dev if skb_change_head is unavailable

See commit msgs.

Is ETH_HLEN only ever used in bpf_lxc (i.e., not in bpf_host)?

@pchaigno In bpf_lxc it's used for NodePort BPF rev-DNAT.

test-me-please

test-1.20-4.9

test-1.13-netnext

k8s-1.19-kernel-4.19 hit a complexity issue.

I think 4.19 hit the following:
R0=inv(id=0,umin_value=18446744071562067968,var_off=(0xffffffff80000000; 0x7fffffff)) R1=pkt_end(id=0,off=0,imm=0) R2=pkt(id=0,off=40,r=40,imm=0) R6=ctx(id=0,off=0,imm=0) R7=inv4294967162 R8=inv40 R9=ctx(id=0,off=0,imm=0) R10=fp0,call_-1 fp-240=0 fp-248=0 fp-256=0 fp-264=0 fp-272=0 fp-280=0 fp-296=ctx fp-304=map_value fp-320=0
	 2562: (61) r6 = *(u32 *)(r9 +16)
	 2563: (bf) r1 = r9
	 2564: (b7) r2 = 14
	 2565: (b7) r3 = 0
	 2566: (85) call bpf_skb_change_head#43
	 unknown func bpf_skb_change_head#43

The helper is not available in 4.19.

Ah, I guess it may be easier to fix? :-S
The helper was added in 4.10 but is accessible from tc BPF programs only since v5.8 with commit 6f3f65d. I guess we now need a probe for this.

test-me-please

test-net-next

test-net-next

test-me-please

CI 4.9:
Egress DNS connectivity should be allowed for pod "app2-5cc5d58844-xwz5j"
Expected command: kubectl exec -n<PHONE_NUMBER>50k8spolicytestbasictestchecksallkindofkubernetespoli app2-5cc5d58844-xwz5j -- host -v -R3 -N1 -t A kubernetes.default.svc.cluster.local.
To succeed, but it failed:
Exitcode: 1
Err: exit status 1
Stdout:
 	 Trying "kubernetes.default.svc.cluster.local"
	 Host kubernetes.default.svc.cluster.local not found: 5(REFUSED)
	 Received 54 bytes from <IP_ADDRESS>#53 in 2 ms

test-4.9

test-gke

CI net-next hit https://github.com/cilium/cilium/issues/15455.

test-net-next

Converted this to draft, as this is blocked by https://github.com/cilium/cilium/pull/15565.

test-me-please

CI 4.9 hit https://github.com/cilium/cilium/issues/15097.
CI 4.19 looks like transient k8s errors.

test-4.9

test-4.19

CI 4.19 hit https://github.com/cilium/cilium/issues/15455. Marking as ready-to-merge.


feat(xKeys): Add support for xKeys

Feature
Add support for xKeys / curve keys.
This allows to implement a NATS Auth Callout service in Rust.
Related Issues
Release Information
next
Consumer Impact

This PR add a new dependency: crypto_box from RustCrypto, but only behind a feature (not enabled by default).
Without the feature, no visible changes are expected.
Testing
Unit Test(s)
I mirrored the relevant test from KeyPair to XKey
Acceptance or Integration
Manual Verification
I implemented a simple auth callout service in Rust against a NATS server (at least version 2.10.4 is required because of https://github.com/advisories/GHSA-mr45-rx8q-wcm9)

@tinou98 Just a heads up that I am reviewing this! Just being extra careful to make sure this lines up with other implementations

In the Go SDK, the new curve type appears to be just another type of keypair.

My first implementation was following this pattern, but in the end I never find useful the fact that they share the same interface : I never used an xKeys the same way I used a key. They don't support the same operation (seal / open for xKeys, sign / verify for keys).

Curious if you think this pattern would be applicable to Rust too

Sure, with a trait, we could get really close. I see 3 options here :

A trait with only the shared methods (seed, public_key, key_pair_type) (I guess that was @thomastaylor312 idea)
A trait with all the methods (the one that don't make sense return an error) + some generic method to create them, that would return a Box<dyn Trait> (but at the cost of a heap allocation)
An enum that contains either a NKeys or an XKeys (with something like enum_dispatch)
We get the best of both world here : no heap allocation, easy cast into specific type if required, but only 1 type for the people that don't care. The only drawbacks I see is the unusable method : you always get a seal method, but can't call it if it's not an xKey.

IMHO:
I like the idea of 1.
I don't find that 2 blend nicely in the Rust ecosystem.
And 3 is OK, but I'm not sure if it really provides added value.

Ok, just one more small thing about handling the error instead of unwrapping and then we're good.
I also think I like 1 the best, but also understand that I don't think people will use an XKey like a normal Nkey. If you want to implement a trait, great! Otherwise I'll either keep as is or do the trait as a follow up

I was going to convert to a trait, but realise that would mean user need to import this trait to use those methods.
That mean this would be a braking change, don't know if it's worth it then.

Yeah I knew it would be a breaking change but the more I think about it, the more I think it wouldn’t be worth the breaking change. Let’s just go with what you’ve got


Integrated Romanian(ro) locale

Thanks for your contribution @alexcontra. That was fast.
LGTM

Version 8.1.0 of form_builder_validators has been published


How to create mongodb Store ?

only redis example ?

Duplicate of #33

@antony-hai It is almost same between Redis and MongoDB. You can use some modules like mongoose to make it easier. 😄


updated export NGSPICE_VERSION= 42  in iic-osic-setup.sh file

In iic-osic-setup.sh file under setup environment setting NGSPICE version taken is 36 whereas latest version available for installation is 42.
Same has been updated:
# Define setup environment

# ------------------------

export MY_PDK_ROOT="$HOME/pdk"

export MY_STDCELL=sky130_fd_sc_hd

export SRC_DIR="$HOME/src"

export OPENLANE_DIR="$HOME/OpenLane"

my_path=$(realpath "$0")

my_dir=$(dirname "$my_path")

export SCRIPT_DIR="$my_dir"

export NGSPICE_VERSION= 42

# This selects which sky130 PDK flavor (A=sky130A, B=sky130B, all=both)  is installed

export OPEN_PDK_ARGS="--with-sky130-variants=A"

export MY_PDK=sky130A

Thanks for the contribution!


Update outputs.tf

FIX spelling in output description: redshidt -> redshift
Description
Spelling fix
Motivation and Context
Presentation to end users.
Breaking Changes
None
How Has This Been Tested?

[ ] I have updated at least one of the examples/* to demonstrate and validate my change(s)
[ ] I have tested and validated these changes using one or more of the provided examples/* projects
[ ] I have executed pre-commit run -a on my pull request

This issue has been resolved in version 3.15.0 :tada:


Add ControllerAsync and ControllerDescribedAsync

Create branch: issue-33-add-controllerasync-and-controllerdescribedasync from main.


[package] npx command internal spawn() may not fire correctly with arguments in Linux-based systems

Related with: #70

![image](https://user-images.githubusercontent.com/70824102/175338950-3c93dc98-b68f-4aec-affb-f7f6a1476d61.png)

![image](https://user-images.githubusercontent.com/70824102/175339040-625d4899-0e37-43b4-87e6-4266d5913262.png)

Solved


Support for ULID, UUID/GUID and ObjectID

Awesome project, congrats!
A time ago, I try discover the code used by the uber gift card, just for validation. But without success, probably is a custom code.
Another detectors, nice to have, is the follow:
ULID: 01ERJ58HMWDN3VTRRHZQV2T5R5
UUID: b2ced6f5-2542-4f7d-b131-e3ada95d8b75
GUID: f0b93a8a-b808-4b92-9ba1-6acb977be8d1
ObjectID: 5fc7c33a7ef88b139122a38a

I Don't think that it is possible to check valid ULID's using regex.

We could add a regex for if it starts with:

ULID
UUID
GUID
ObjectID

But the actual ID itself would be incredibly hard due to the nature of it :-)

Just my 2 cent 💦
For ObjectId, and if that's the MongoDB's BSON ObjectId, timestamp could be extracted from it :
import struct
oid = bytes.fromhex("5fc7c33a7ef88b139122a38a")
datetime.fromtimestamp(struct.unpack(">i", oid[0:4])[0])
# datetime.datetime(2020, 12, 3, 0, 39, 22)

Was referenced from here. And here's how bson validating if the string is a valid ObjectId.
And, nice project :)


Sub functions within a component sometime missed

Regression from 0.2.3 to 0.2.4: If I have a component like
const Clock = () => {
  ...
  const show = () => {
     ...
  }
}

export default Clock

then the subfunction show() is ignored and the complexity is significantly higher than if I used the following syntax:
export default function Clock() {
   ...
   const show = () => {
      ...
   }
}

I think both should result in the same values after analysis.

Sorry for the delay in getting back to you.
Thanks for letting me know.
I will investigate and fix.

@nimisis
I have looked into this and it may not be a bug.
Is it the cognitive complexity that you found to be a bug?
If so, there is a distinct difference in the example you submitted.
The latter can be treated as a faux-class in the history of JS, while the former cannot be treated as a faux-class.
See the chapter JavaScript: Missing class structures in Cognitive Complexity for specifics.

Despite the recent addition of classes to JavaScript by the ECMAScript 6 specification, the feature is not yet widely adopted. In fact, many popular frameworks require the continued use of the compensating idiom: the use of an outer function as a stand-in to create a kind of namespace or faux class. So as not to penalize JavaScript users, such outer functions are ignored when they are used purely as a declarative mechanism, that is when they contain only declarations at the top level.
However, the presence at the top level of a function (i.e. not nested inside a sub-function) of statements subject to structural increments indicates something other than a pure declarative usage. Consequently, such functions should receive a standard treatment.

Since the arrow function cannot be a pseudo-class, I believe the current implementation is correct. What do you think?
new (() => {}) // Uncaught TypeError: (intermediate value) is not a constructor
new (function () {}) // {}

Again, please let me know if you think this is the problem!
Thank you for your inquiry!


Merges Master to Live. See commits for details.

Docs Build status updates of commit 76be690:
:clock10: Full build: the average full build time is 11 min(s) 46 sec(s), this is based on the last 1000 build(s) for this repository.

Docs Build status updates of commit 76be690:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

sharepoint/sharepoint-ps/sharepoint-online/Enable-SPOCommSite.md
:white_check_mark:Succeeded
View (sharepoint-ps)

sharepoint/sharepoint-ps/sharepoint-online/Get-SPODataConnectionSetting.md
:white_check_mark:Succeeded
View (sharepoint-ps)

sharepoint/sharepoint-ps/sharepoint-online/Get-SPOHubSite.md
:white_check_mark:Succeeded
View (sharepoint-ps)

sharepoint/sharepoint-ps/sharepoint-online/Remove-SPOUser.md
:white_check_mark:Succeeded
View (sharepoint-ps)

sharepoint/sharepoint-ps/sharepoint-online/Start-SPOSiteRename.md
:white_check_mark:Succeeded
View (sharepoint-ps)

sharepoint/sharepoint-ps/sharepoint-online/Unregister-SPOHubSite.md
:white_check_mark:Succeeded
View (sharepoint-ps)

sharepoint/sharepoint-ps/sharepoint-server/Set-SPContentDatabase.md
:white_check_mark:Succeeded
View (sharepoint-ps)

skype/skype-ps/skype/Set-CsMobilityPolicy.md
:white_check_mark:Succeeded
View (skype-ps)

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

Docs Build status updates of commit 3aa5262:
:clock10: Full build: the average full build time is 11 min(s) 46 sec(s), this is based on the last 1000 build(s) for this repository.

Docs Build status updates of commit 3aa5262:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

sharepoint/sharepoint-ps/sharepoint-online/Enable-SPOCommSite.md
:white_check_mark:Succeeded
View (sharepoint-ps)

sharepoint/sharepoint-ps/sharepoint-online/Get-SPODataConnectionSetting.md
:white_check_mark:Succeeded
View (sharepoint-ps)

sharepoint/sharepoint-ps/sharepoint-online/Get-SPOHubSite.md
:white_check_mark:Succeeded
View (sharepoint-ps)

sharepoint/sharepoint-ps/sharepoint-online/Remove-SPOUser.md
:white_check_mark:Succeeded
View (sharepoint-ps)

sharepoint/sharepoint-ps/sharepoint-online/Start-SPOSiteRename.md
:white_check_mark:Succeeded
View (sharepoint-ps)

sharepoint/sharepoint-ps/sharepoint-online/Unregister-SPOHubSite.md
:white_check_mark:Succeeded
View (sharepoint-ps)

sharepoint/sharepoint-ps/sharepoint-server/Set-SPContentDatabase.md
:white_check_mark:Succeeded
View (sharepoint-ps)

skype/skype-ps/skype/Set-CsMobilityPolicy.md
:white_check_mark:Succeeded
View (skype-ps)

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Code commented out of nc_test4/tst_h_files3.c

This whole file is commented out. Not much point in having a test if it is just commented out.
I will uncomment this code and see if it runs, and if there is any reason it should not run every time tests are run.

This was an old program that checked memory consumption of HDF5 in various circumstances. I was chasing a bug at the time and found this info helpful. But this code does not test netcdf at all, the bug I was chasing is long gone, and there is really no reason to have this code any more.
So I have deleted it and removed it from the Makefile.am. PR up shortly.


Updates go-licenses and silences some new noisy messages (#871)

Issue #, if available:
Description of changes:
Backport updates to support new go-licenses
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/lgtm

/approve


Add commit hash to UI

https://www.figma.com/file/DTJwC2mQ9kvyjM0171tqHR/New-AirSwap-Website?node-id=6788%3A6015

Should be added in the settings menu. In my view this is not information that needs to be displayed to the user all the time
https://www.figma.com/file/DTJwC2mQ9kvyjM0171tqHR/New-AirSwap-Website?node-id=9932%3A6740

Yeah that's better! I would like to suggest we either put in on top or at the bottom:
In between is not the right place for it - I feel like at the bottom is the best - as it's secondary info and not really a 'setting'

Yeah that's better! I would like to suggest we either put in on top or at the bottom:
In between is not the right place for it - I feel like at the bottom is the best - as it's secondary info and not really a 'setting'

https://www.figma.com/file/DTJwC2mQ9kvyjM0171tqHR/airswap-web?node-id=10127%3A6930
Added github icon, removed external link icon (whole element should be linked), changed date format to ISO 8601, changed font to monospace and extended line to make it its own section


Support decrypting PBES2 key bags in pkcs12

Only supports PBKDF2 key derivation function (without Scrypt).
Supports AES-CBC and DES-EDE3-CBC encryption schemes.
cc @jethrogb

pkcs12 support is removed in rust-mbedtls


Ritual Splinters: "no data" exchange rate

Ritual Splinters: Fix "no data" from poe ninja.

Currently can't be fixed because Rogue's Marker is missing from poe ninja's page. This has been reported at poe ninja.


Pairwise Farcaster Bot | Thank You Cast.

BONUS POINTS!
Once someone has used the app and delegated or voted for all 4 options, they should stop receiving the casts, and we should send them a separate cast:

@username thank you for playing with Pairwise! YOU ROCK!

Originally posted by @GriffGreen in #21
Success Criteria:

[ ] A delegated to B and the bot sends casts every day to B to go and use the app.
[ ] B do all categories, (vote or delegate) then bot should send Thank You Cast instead of regular casts.
[ ] The thank you cats should be only one time.

@RamRamez can you jump into this?

I'm on it

Done! (waiting for code review and merge)

GM
can you update me please if it's merged?
CC: @mmahdigh

It's merged on staging. I created a PR for the release.
https://github.com/GeneralMagicio/pw-backend/pull/68

could you please tell me more about this issue and farcaster bot that I be able to test this?
@RamRamez @mmahdigh

@maryjaf

It means that they have engaged with https://github.com/pairwise completely... there are 3 categories and the budget, for each of those 4 things, they can vote or delegate, if they have voted or delegated 4 times

then we will send them the cast

@username! Thank you for playing with Pairwise!
YOU ROCK!

with this Farcaster account on staging

@maryjaf consider this user that has delegated or voted to all 3 possible categories + budget

Sorry @maryjaf I now updated the success criteria, apologies for missing this.

B do all categories, (vote or delegate) then bot should send Thank You Cast instead of regular casts.

I haven't received this cast it seems there is a problem related to cron job

A delegated to B and the bot sends casts every day to B to go and use the app.

Could someone please delegate to me (maryjaf)to check this  @MoeNick @RamRamez

B do all categories, (vote or delegate) then bot should send Thank You Cast instead of regular casts.

I haven't received this cast it seems there is a problem related to cron job

@maryjaf The CI/CD is not set yet and my PR wasn't deployed. @mmahdigh deployed my PR and now it's working.

A delegated to B and the bot sends casts every day to B to go and use the app.

Could someone please delegate to me (maryjaf)to check this @MoeNick @RamRamez

Sure @maryjaf, I delegated to you

A delegated to B and the bot sends casts every day to B to go and use the app.

Could someone please delegate to me (maryjaf)to check this @MoeNick @RamRamez

Sure @maryjaf, I delegated to you


ipython_directive should raise Exceptions to the user when building docs

Making this a priority for 0.7, cc @adamklein

Maybe even better, set call_pdb=True by default, and switch it off with
that :suppress-like option.
On Mon, Jan 16, 2012 at 9:38 AM, Wes McKinney <
<EMAIL_ADDRESS>
wrote:

IPython captures all the exceptions so you'll have to look at the output
and raise an exception if it has a traceback. Should add an option (like
:suppress) to "allow exceptions in this block"

Reply to this email directly or view it on GitHub:
https://github.com/wesm/pandas/issues/568#issuecomment-3511456

which of course doesn't work b/c i/o is being redirected. darn.
On Mon, Jan 16, 2012 at 10:12 AM, Adam Klein<EMAIL_ADDRESS>wrote:

Maybe even better, set call_pdb=True by default, and switch it off with
that :suppress-like option.
On Mon, Jan 16, 2012 at 9:38 AM, Wes McKinney <
<EMAIL_ADDRESS>
wrote:

IPython captures all the exceptions so you'll have to look at the output
and raise an exception if it has a traceback. Should add an option (like
:suppress) to "allow exceptions in this block"

Reply to this email directly or view it on GitHub:
https://github.com/wesm/pandas/issues/568#issuecomment-3511456


Bug: fzf crawls to a halt when scrolling through the preview on file search

RTFM Checklist

[X] I have searched exisiting issues / discussions
[ ] I have read the Wiki including the Advanced section
[ ] I have read man fzf / I am well versed in shell fzf

Operating system
Linux
Shell
zsh
Neovim version (nvim --version)
NVIM v0.10.2
Fzf version (fzf --version)
N/A installed today with ./install --bin as per README
Output of :lua print(os.getenv('FZF_DEFAULT_OPTS'))
nil
Is the problem reproducible with mini.sh?

[ ] My issue is reproducible with mini.sh
[ ] My issue IS NOT reproducible with mini.sh
[X] I have not tested with mini.sh (not relevant, requires LSP, Windows, etc)

Fzf-lua configuration
require('fzf-lua').setup {
        winopts = {
          height = 0.95,
          width = 0.95,
        },
      }

Describe the bug / steps to reproduce
I couldn't record too much to avoid the size limit, but, as seen on the video, if I scroll through the preview, it gets slower and slower until it just freezes. Then it continues after a few seconds but very laggy and slow. I'm trying to scroll during all the video, even when it shows the scroll has stopped and then continues.

Preview a file that makes the preview window scroll.
Scroll up and down for a few seconds. It starts crawling until it halts.

https://github.com/user-attachments/assets/2e268f5b-b7d4-4758-9cee-2bfecee6b15e

Probably related to treesitter, might be related to the beta of #1552.

Do you have nvim-treesitter-context installed?
Can you try the below and lmk which of these solves the issue?

:FzfLua buffers  previewer.treesitter.context=false
:FzfLua buffers  previewer.treesitter.enable=false
:FzfLua buffers  previewer.syntax=false

Thanks for having a look :)

Probably related to treesitter, might be related to the beta of #1552.

Do you have nvim-treesitter-context installed?

Nope.

Does this happen on all filetypes or just some (.cs as demonstrated)?

I also tried with .tsx files, as C# files make my NeoVim a bit slow. But I have the same behaviour.
I just tried .md and plain text files, and I get the same behaviour even on short files where the preview doesn't need much scrolling.

Can you try the below and lmk which of these solves the issue?

:FzfLua buffers  previewer.treesitter.context=false

I get the same issue on a plain text file (131).

:FzfLua buffers  previewer.treesitter.enable=false

I get the same issue on the same plain text file.

:FzfLua buffers  previewer.syntax=false

I get the same issue on the same plain text file.

One thing I've noticed is that I can reproduce the issue very quickly if I just hold <S-down>. It takes a longer time to reproduce if I press and release quickly.

One thing I've noticed is that I can reproduce the issue very quickly if I just hold <S-down>. It takes a longer time to reproduce if I press and release quickly.

Perhaps some auto command in your config is causing this? Can you try with mini.sh?

One thing I've noticed is that I can reproduce the issue very quickly if I just hold <S-down>. It takes a longer time to reproduce if I press and release quickly.

Perhaps some auto command in your config is causing this? Can you try with mini.sh?

Good call. I've just tried mini.sh and I get the exact same behaviour.

I can't seem to reproruce this, can you try 1568 branch and let me know if this feels better and if you see fzf-lua messages saying skip page-down (or up) in :messages?

I have a feeling this is related to the preview scrollbar of type border and setting winopts.preview.scrollbar to false (disable) or float will work better, if you can confirm my suspecion the solution is near.

@srodrigo, I believe https://github.com/ibhagwan/fzf-lua/commit/f07f0d310c12cbd62ab48148cd760cfa606e8117 is in high liklihood to solve this issue.
Kindly reopen the issue if I'm wrong or confirm it's solved?

I can't seem to reproruce this, can you try 1568 branch and let me know if this feels better and if you see fzf-lua messages saying skip page-down (or up) in :messages?
Also can you try the below and lmk if any of these makes a difference?
:FzfLua buffers winopts.preview.scrollbar=border -- the default
:FzfLua buffers winopts.preview.scrollbar=float
:FzfLua buffers winopts.preview.scrollbar=false

Sorry, just logged in now.

@srodrigo, I believe f07f0d3 is in high liklihood to solve this issue.

This indeed solved the issue! It works with the default settings.
Thank you so much @ibhagwan :)

This indeed solved the issue! It works with the default settings.

Ty for the confirmation, happy my hunch worked and that was the issue :-)
Was also a much needed change anyways.


Bag replicator is putting messages on the DLQ that seem to complete successfully

As of right now, there are eight messages on the bag replicator DLQ (a couple of duplicate IDs). At a casual glance, the bag replicator has successfully copied all the objects for each bag (the numbers are correct, at least), so it’s not clear why it’s failed.
   12273 b2146201x_access.txt
   12273 b2146201x_archive.txt
   11638 b2150751x_access.txt
   11638 b2150751x_archive.txt
   11232 b2475092x_access.txt
   11232 b2475092x_archive.txt
   62700 b2475772x_access.txt
   62700 b2475772x_archive.txt
      18 b24962648_access.txt
      18 b24962648_archive.txt
   10806 b2877212x_access.txt
   10806 b2877212x_archive.txt

If it wasn't for b24962648, I’d wonder if we’re just timing out the messages? Not sure why that  particular bag fell over.

@alexwlchan Can this be closed?

@pollecuttn I want to leave it a few more days and check it doesn't crop up; it's a transient issue so hard to know for sure if/when it's fixed!


Useful link for GAMs

Gavin Simpson has a whole course available
https://twitter.com/ucfagls/status/1494746095670505480

Noam Ross also: https://noamross.github.io/gams-in-r-course/
@mitchest thoughts on these?  do you want to add these to the bottom of your tutorial?


Enable Faceting in Show Details of Facets

We want faceting in the modal that we display after users click on "show details" in recordset.
This requires changes in ermrestjs.

The changes in ermrestjs are done. The only missing issue here is the UX. We should discuss what should be the appropriate UX for having facet in the facet modal.

Based on my understanding we're not going to pursuit this given the confusing UX, so I'm going to close this. If a new requirement came up that needed this feature we should create a new issue with more information.


Solving quadratically constrained quadratic problems

Hi,
I am using the MPC class for a differential drive robot in order to track a moving target.  In order to avoid a collision with the moving target and other dynamic obstacles, I used the implemented ObstacleConstraint. However, it appears that HPIPM is not able to solve the problem with the obstacle constraint. The solver returns flag 2, "minimum step length reached".
I have reduced the problem to a single NLOC (without MPC loop), similar to the example ex_NLOC_generalConstrained, which I have attached along with the configuration files. I hope it is executable.
Do you have any suggestions? Or maybe an example of an implementation of the ObstacleConstraint? I have been wondering whether this issue arises due to the quadratic form of the constraint or whether it is an implementation error from my side regarding the ObstacleConstraint.
Thanks a lot!
NLOC_ObstacleConstraint.tar.gz

Hi @hmcm
I general I do not see any major obstacles which should prevent hpipm from solving your problem, so it is most likely some kind of configuration issue. Let's debug this step by step.

First of all, can you verify that the problem is reasonably solved when you remove both box and general constraints, and only consider the differential-drive dynamics? If your cost function is well-tuned, you should end up very closely to your desired final configuration.

Secondly, let's leave the box constraints away for the time being and only consider the general constraints. Do you get the same error when leaving away the box constraints entirely?

Hi @markusgft ,
thanks for your fast reply!

If I remove all constraints, the goal position is reached with a smooth trajectory. HPIPM returns that the QP was solved. Maybe as an additional point here: I have been using the MPC with the differential-drive dynamics without the obstacle constraint (but with box constraints), and it behaves as expected.

If I remove the box constraints and only consider the general constraints, HPIPM returns with flag 3, "NaN in computations" (By the way, is it possible that there is a mistake in the HPIPMInterface-impl in line 201? You consider hpipm_status_==2 twice, but do not consider hpipm_status_==3, see https://github.com/ethz-adrl/control-toolbox/blob/5a9ed9c8ec4dc78bc9067e2b27563610117725cb/ct_optcon/include/ct/optcon/solver/lqp/HPIPMInterface-impl.hpp#L201).

If I consider both box constraints and general constraints and solve using ILQR, I have the same issue (flag 2, minimum step length reached). Also for 1) and 2), I get the same behaviour as with GNMS.

Hi @hmcm
Thanks for pointing this out, this is clearly a bug, of course it should be hpipm_status_ == 3.

Hi @markusgft
I opened the pull request for the patch. As for the feature, that sounds very promising!
Regarding my issue: When I move the obstacle to a completely different region (pos_obstacle = (-10,-10) when goal = (10,10)), I still get the same numerical problems with only the general constraints. If I add the box constraints, hpipm still returns flag 2. (both for GNMS and ILQR)

Hi @hmcm
I just looked at your example and I believe I found potential problems.
Firstly -- and this is a problem on our end -- you are using a constraint container which was never really tested in combination with the NLOC solver. The obstacle constraint class was originally developped for the NLP-based solvers, and honestly, without going through a test procedure I cannot tell you right away if they work together. What I would recommend you is to quickly implement the obstacle- inequality constraint from scratch, following the example in ex_NLOC_generalConstrained.cpp.
Next, when working with HPIPM, it would make sense to reduce the dimension of the constraints to the actually numerically relevant order. The third row of your inquality constraint, which represents orientation, is redundant and the constraint Jacobian is set to zero all the time. This may lead to issues in hpipm. I would recommend you to use x- and y coordinates only in a custom implementation of the general constraint.
If you do this, I am pretty sure it is going to work!

Hi @markusgft
Thanks a lot for looking into it! I will try to implement your approach next week and see if I can get it working!

Hi @markusgft ,
I implemented the obstacle constraint from scratch and reduced the dimensions to x and y (implementation attached). To make it as simple as possible, I consider the obstacle as a unit circle and only provide the center coordinates as an input for the class constructor. However, I still get exactly the same problems. I have tried using the automatic differentiation as in the ex_NLOC_generalConstrained.cpp as well, but this didn't change the result either... Did I misunderstand any of your instructions? Or is this what you had in mind?
Reimplementation_ObstacleConstraint.tar.gz

Hi @hmcm, could you quickly try with the following settings for the nloc solver
ilqr
{
    nlocp_algorithm GNMS
    integrator EULER
    useSensitivityIntegrator false
    discretization Forward_euler
    timeVaryingDiscretization false
    dt 0.005
    K_sim 1
    K_shot 1
    epsilon 0
    max_iterations 100
    fixedHessianCorrection false
    recordSmallestEigenvalue false
    min_cost_improvement 1e-5
    maxDefectSum 1e-5
    meritFunctionRho 0.0
    meritFunctionRhoConstraints 0.0
    nThreads 1
    nThreadsEigen 1
    locp_solver HPIPM_SOLVER
    printSummary true
    debugPrint false
    logToMatlab 0

    line_search
    {
        type NONE
        adaptive false
        maxIterations 10
        alpha_0 1.0
        n_alpha 0.5
        debugPrint true
    }

    lqoc_solver_settings
    {
        lqoc_debug_print        true
        num_lqoc_iterations  	5
    }
}

Hi @markusgft,
I tried it and still get the "minimum step length reached" flag. Anything in particular that I should pay attention to?

Hi @hmcm
I think we are at the point where we need to validate that it works in a setting without the differential constraint. Can you try formulating the dynamics as a second-order dynamic system, i.e. simply a moving point mass? Ideally, could you also put this in a repo that you can give me access to, so that I can jump in with debugging in case we need it?
Best
Markus

Hi @markusgft
I will try that, but unfortunately I won't have time before next week. Thanks a lot for the help so far and I will get back to you as soon as I have reformulated the dynamics and put it into a repo!
Best
Hannah

Hi @hmcm, I would still be interested in following up on your issue and debugging the problem. Did you by any chance find time to look into the modified example?
Best!

Hi @markusgft
I am sorry this took so long, but I had a lot going on. I tried to implement a second order system as you proposed. However, I am not sure I understood you correctly. I just implemented a point mass with four states (x, y, v_x, v_y) which is actuated with a force in x-direction and a force in y-direction. However, if I try solving the control problem for this system, the line search returns that the control is unstable. Was this the kind of system you had in mind?
I invited you as a collaborator to the repo where I uploaded everything, there I also included the constraint class. I tried figure out why the control is unstable and will get back to work on it next Thursday. Sorry for only providing you with something incomplete, but maybe it is already of some help!
Best
Hannah

Hi @hmcm
Thanks for sharing your repo. I took a quick look, and indeed there is some issue that I can confirm. For instance, in my case, GNMS with constraints diverges instantly. I will try allocate some time to find and fix the problem.

Should be resolved by #142


Add caching to GraphQL API

It's useful to cache data from ipfs.
In mcp case, a project will upload their whole data content to ipfs. As for the mcp service, it may only need one or two rows from the whole content. (take json file as example).
But the project will request metadata for different users regularly, and future requesting user is still inside the  reuested ipfs content.
In this situation, we don't have to fetch content from ipfs again in a short time.
You can check this resource.
xxxxxxxxx


Error while sending a message to user due to captcha

Summary
selfbot
Reproduction Steps
when selfbot tries to send a message to user-based object, it throws '400 Bad Request (error code: 0)'
Code
class SelfBot(discord.Client):
	def __init__(self, token: str, connector):
		super().__init__()
		self.token = token
		self.connector = connector
		self.success = 0
		self.fail = 0
		self.work_status = True

	def get_id(self):
		return self.user.id

	async def send_to_user(self, user_id: int, message: str, file: str = None):
		try:
			user = await self.fetch_user(user_id=user_id)
			if file:
				await user.send(message, file=discord.File(file))
			else:
				await user.send(message)
			self.success += 1
		except Exception as e:
			self.fail += 1
			print(e)
			if self.fail > 100:
				self.work_status = False

Expected Results
Message sended
Actual Results
Throwing error because of hCaptcha verification
System Information
Python v3.10.0-final
discord.py-self v1.9.1-final
aiohttp v3.7.4.post0
system info: Windows 10 10.0.19044
Checklist

[X] I have searched the open issues for duplicates.
[X] I have shared the entire traceback.
[X] I am using a user token (and it isn't visible in the code).

Additional Information
it is on closed issues but it is still an active issue

Captcha handling exists in the master branch.

Captcha handling exists in the master branch.

it is not working


Update HubSpot

It seems they've made it even more expensive for SSO... Currently top of the leaderboard for percentage increase...

Closing PR as no desire to re-work a PR submitted so long ago.


InvalidOperationException on parsing

Brief Description
I'm trying to make bindings for a providers library, but it always throws this exception "System.InvalidOperationException: 'the sequence contains no matching elements'"
OS: Windows 10 version 19042.789
Used headers
Used settings
Target: MSVC/GCC/Clang
at System.Linq.Enumerable.First[TSource](IEnumerable1 source, Func2 predicate)
at CppSharp.Generators.CSharp.CSharpSources.GenerateFieldGetter(Field field, Class class, QualifiedType returnType)
at CppSharp.Generators.CSharp.CSharpSourcesExtensions.GenerateField(CSharpSources gen, Class class, Field field, Action3 generate, Boolean isVoid) at CppSharp.Generators.CSharp.CSharpSources.GeneratePropertyGetter[T](T decl, Class class, Boolean isAbstract, Property property) at CppSharp.Generators.CSharp.CSharpSources.GenerateProperties(Class class) at CppSharp.Generators.CSharp.CSharpSources.GenerateClassProperties(Class class) at CppSharp.Generators.CSharp.CSharpSources.VisitClassDecl(Class class) at CppSharp.AST.Class.Visit[T](IDeclVisitor1 visitor)
at CppSharp.Generators.CSharp.CSharpSources.VisitDeclContext(DeclarationContext context)
at CppSharp.Generators.CodeGenerator.VisitNamespace(Namespace namespace)
at CppSharp.Generators.CSharp.CSharpSources.VisitNamespace(Namespace namespace)
at CppSharp.Generators.CodeGenerator.VisitTranslationUnit(TranslationUnit unit)
at CppSharp.AST.TranslationUnit.Visit[T](IDeclVisitor`1 visitor)
at CppSharp.Generators.CSharp.CSharpSources.Process()
at CppSharp.Generators.Generator.GenerateModuleTemplate(Module module)
at CppSharp.Generators.Generator.Generate()
at CppSharp.Driver.GenerateCode()
at CppSharp.ConsoleDriver.Run(ILibrary library)
at OrionBindingsGenerator.Program.Main(String[] args) en MyPath\Program.cs:línea 14

We need some way to reproduce the issue, could you post a minimal (if possible) example header to reproduce the crash?

@miker1423, @tritao's correct - I can see you've skipped the section for used headers which is arguably the most useful piece we need to track problems down.


outdated parse5 dependency through

@MeirionHughes, looks like parse5 dependency should be updated for aurelia-pal-nodejs.
When i clone and build and link aurelia-template-lint npm module to my project then everything works as expected, but when i do a clean install of gulp-aurelia-template-lint (deleting node_modules before running npm install) then i get an error that seems to be caused by old parse5 version, that comes through:
`+--<EMAIL_ADDRESS>| `--<EMAIL_ADDRESS>|   `--<EMAIL_ADDRESS>|     `--<EMAIL_ADDRESS>|       `--<EMAIL_ADDRESS>
and even if i manually install npm i<EMAIL_ADDRESS>--save-dev then i have 2 versions and<EMAIL_ADDRESS>will still be used for linting.
Therefore the following error:
TypeError: Cannot read property 'line' of undefined
at next.attrs.attrs.map (C:\path\to\aurelia-app\node_modules\aurelia-template-lint\dist\ast.js:26:97)
at Array.map (native)
at Parser.parser.on (C:\path\to\aurelia-app\node_modules\aurelia-template-lint\dist\ast.js:22:32)
at emitMany (events.js:132:20)
at Parser.emit (events.js:201:7)
at Parser.SAXParser._handleToken (C:\path\to\aurelia-app\node_modules\template-lint\node_modules\parse5\lib\sax\index.js:171:14)
at Parser.SAXParser._runParsingLoop (C:\path\to\aurelia-app\node_modules\template-lint\node_modules\parse5\lib\sax\index.js:149:18)
at Parser.SAXParser._transform (C:\path\to\aurelia-app\node_modules\template-lint\node_modules\parse5\lib\sax\index.js:76:14)
at Parser.Transform._read (_stream_transform.js:167:10)
at Parser.Transform._write (_stream_transform.js:155:12)
at doWrite (_stream_writable.js:307:12)
at writeOrBuffer (_stream_writable.js:293:5)
at Parser.Writable.write (_stream_writable.js:220:11)
at Readable.ondata (_stream_readable.js:556:20)
at emitOne (events.js:96:13)
at Readable.emit (events.js:188:7)
at Readable.read (_stream_readable.js:382:10)
at flow (stream_readable.js:762:34)
at emitReadable (_stream_readable.js:434:3)
at _combinedTickCallback (internal/process/next_tick.js:71:11)
at process._tickCallback (internal/process/next_tick.js:98:9)

Hmm, looks like I made incorrect assumptions, as I saw cached/outdated diff that included parse5/package.json - real problems must be somewhere else (probably related my html)

I'm reopening, as there seems to be some kind of mess with parse5 versions (2 versions in aurelia-template-lint project).
What i found out, is that when linting after normal installation (without using npm link), then attribute name only contains local name of the attribute - for example for
      <svg class="icon">
          <use xlink:href="icons.svg#some_selector"></use>
      </svg>

ast.ts attribute name field contains only "href" (and there is prefix property, that contains "xlink") while if i run the project after npm link (or from the tests), then name property contains "xlink:href" and there is no prefix property on the attribute.

I'll send a PR shortly to work around the parse5 version difference. @MeirionHughes if You have better suggestions, then I'll listen gladly, but I'm a bit sleepy at the moment (would like to get it solved eventually)

PR with workaround is ready.
One more thing to note: I'm running node v6.3.0 and npm 3.10.3 - i thought that they don't need dedupe any more (thought that npm does it now automatically), but probably i'm missing smth.

I think its because you're supposed to use peerDependencies yourself now.
jsdom uses parse5 1.4 and we use parse5 2.1. Looks like updating jsdom to parse5 2 is slow: https://github.com/tmpvar/jsdom/pull/1316

do You mean, i should put gulp-aurelia-template-lint to peerDependencies instead of devDependencies? (sry, i'm still quite new to npm and JS ecosystem in general)

No no; generally if you want to depend on a package, but not its version you can use peerDependency... this is how a few things with typescript for example (its your job to install a typescript version you want to use. I don't think that applies here because its quite interwind.
I've had another look and from what I can tell the aurelia-template-lint is defiantly using version 2 and jsdom has a subfolder with version 1.5.1. So it does manage to deal with version mismatches of older dependencies. i.e. cannot be de-duped.

hmm, so gulp-aurelia-template-lint should still be in devDependencies and i should put smth else in my project into peerDependency (probably parse5 or dependency that wants to use parse5, such as jsdom)?

might be able to make pal-nodejs a peerDependency of your other project (the one your linking from). but jsdom defiantly needs 1.5.1 and the linter needs 2.1.x.
You might be seeing an issue with the module resolution of nodejs itself (linking to a project that has a dependency that cannot be deduped).

so I tried following:
aurelia-app/package.json:
{
...
  "devDependencies": {
    "gulp-aurelia-template-lint": "^0.9.1",
    ...
  },
  "peerDependencies": {
    "aurelia-pal-nodejs": "^1.0.0-alpha.1"
  },
...
}

then deleted node_modules and ran npm install, that installed 3 versions of parse5:
+--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>| `--<EMAIL_ADDRESS>|   +--<EMAIL_ADDRESS>|   `--<EMAIL_ADDRESS>+--<EMAIL_ADDRESS>| `--<EMAIL_ADDRESS>|   +--<EMAIL_ADDRESS>|   +--<EMAIL_ADDRESS>|   | `--<EMAIL_ADDRESS>
(Note: aurelia-template-lint and template-lint even want different versions of parse5).
Running gulp task still results in the same error (stacktrace in initial comment) including
TypeError: Cannot read property 'line' of undefined
at next.attrs.attrs.map (C:\path\to\aurelia-app\node_modules\aurelia-template-lint\dist\ast.js:26:97)
...
at Parser.SAXParser.handleToken (C:\path\to\aurelia-app\node_modules\template-lint\node_modules\parse5\lib\sax\index.js:171:14)

and C:\path\to\aurelia-app\node_modules\template-lint\node_modules\parse5\package.json contains "version": "2.2.0".
@MeirionHughes, am I doing smth wrong?

right there we go... reproduced it.

Still failing for me; I'll fix.

I've reverted both projects to 2.1 and locked can you rimraf your node_modules and reinstall.

doing that right now :+1:

works great, now everything works as expected, even with
config.debug = true;
Thanks @MeirionHughes, this project is just fantastic!


Possible to update template?

Is it possible to update the template after super has been called?
I need to do some logic to work out the template, but I can't use this before super has been called in ES6.
Won't work:
export default class BaseWidget extends Vue {
    constructor(options) {

        // Work out template but need to use 'this'

        super(options);

Ideal:
export default class BaseWidget extends Vue {
    constructor(options) {
        super(options);

        this.template = this.getTemplate();

You can't directly use ES6 class to subclass Vue - you should use Vue.extend.
If you really want ES6 classes, take a look at this: https://github.com/vuejs/vue-class-component

I think I will just have to do something like this for now:
import BaseWidget from "./BaseWidget";

export default class GridItem extends BaseWidget {
    constructor(options) {
        options.template = $('#template-widget-GridItem').html();
        super(options);
    }
}


PATCH method doesn't work

Isn't that code supposed to work?
#include "crow.h"
#include <cassert>
#include <iostream>
#include <string>
#include <functional>
#include <sstream>

using namespace std;
using namespace placeholders;

int main()
{
    crow::SimpleApp app;

    CROW_ROUTE(app, "/patch")
        .methods("PATCH"_method)
    ([](const crow::request& req) {
        return "test";
    });

    auto port = 18080;
    app.port(port).multithreaded().run();
}

It gives "invalid method" error on CROW_ROUTE. "PATCH" for operator""_method is not defined in common.h. I tried adding it in analogy with "POST" (add in , but it still doesn't work: error 404 on PATCH-request.
(2016-09-22 07:03:48) [INFO    ] Request: <IP_ADDRESS>:35958 0x23bbf00 HTTP/1.1 invalid /patch

Looks like it can't parse PATCH here
} else if (parser->index == 1 && parser->method == HTTP_POST) {
          if (ch == 'R') {
            parser->method = HTTP_PROPFIND; /* or HTTP_PROPPATCH */
          } else if (ch == 'U') {
            parser->method = HTTP_PUT; /* or HTTP_PURGE */
          } else if (ch == 'A') {
            parser->method = HTTP_PATCH;
          } else {
            CROW_SET_ERRNO(HPE_INVALID_METHOD);
            goto error;
          }
        }

But I still don't really understand what's going on here.

Any Progress here?

Still doesn't work? Example from tests looks same as above one (https://github.com/ipkn/crow/blob/master/tests/unittest.cpp#L328).


fastembed 3 panic on Windows 11: Failed to retrieve onnx/model.onnx

The program panics while attempting to load the onnx/model.onnx model，When running fastembed 3 on Windows 11 with Rust 1.78.0.
thread 'main' panicked at \fastembed-3.9.0\src\text_embedding.rs:130:33:
Failed to retrieve onnx/model.onnx

Whereas it runs smoothly with fastembed 2.

Can you try clearing the .fastembed_cache directory?

The .fastembed_cache directory was not found. Due to some network issues, direct access to hugginface.co is not possible. The version of ureq relied upon by hf-hub does not support configuring proxy parameters such as HTTPS_PROXY through environment variables, preventing the download of models.
Could you please instruct me on how to manually download the model to the cache folder? I attempted this, but it might not be in the correct format, leading to a failure to run.

You can just download the model repo from the HuggingFace site and set the value for the cache_dir path when initializing TextEmbedding.

Thank you for your answer. hf-hub seems to be not very user-friendly. I solved the problem by using the huggingface_hub  library in Python to download the model.

@zhaoyii How can I use the files downloaded by huggingface_hub in fastembed?

@Anush008 hf-hub already supports the HF_ENDPOINT environment variable:

https://github.com/huggingface/hf-hub/commit/ac22200ea0b5af4d8c362f699be0340647b19060

Hey @holmofy. We'll have to wait for hf-hub to make a new release.


Test questions

When I execute the "torchpack dist-run -np 8 python tools/test.py configs/nuscenes/det/transfusion/secfpn/camera+lidar/swint_v0p075/convfuser.yaml pretrained/bevfusion-det.pth --eval bbox" command,it stops at the following position:

Would you mind trying out single GPU evaluation (i.e. -np 1) or adding the -v flag to your command? Besides, there are two on-going PRs working on docker support for BEVFusion. I would also recommend you to have a try at them:
PR from @bentherien and PR from me.

Thank! This problem has been solved.
Can you tell me the training command?

@zhenghw111, the training code is under internal review and quality check, we will keep you posted on the progress of code release.

OK, thank you!

作者你好，请问模型架构中fuser层的作用是什么？

@kentang-mit  作者你好，请问模型架构中fuser层的作用是什么？

@kentang-mit @zhenghw111 请问在bevfusion.py中，camera得到的future的维度为[1,80,128,128]，lidar得到的future的维度为[1，256，180，180]，他们的维度最后两维不相等，这是为什么呢？

Hi @kkangshen,
I will first translate your questions into English such that other readers might understand the context better.

What's the function of the fuser in BEVFusion?

This module is used to combine the information from camera and LiDAR sensors. In our experiments, we confirm that it is sufficient to use only one convolution layer (followed by BN/ReLU).

Mismatched dimensionalities: the output of the camera encoder is in [1, 80, 128, 128] and the output of the LiDAR encoder is [1, 256, 180, 180].

I think I kept output resolution of both branches the same. For detection it is [180, 180], and for segmentation it is [128, 128].
Best,
Haotian

Hi @kentang-mit
Thanks for your answer, but there are still some problems here, if the two dimensions are not equal the output of the camera encoder is in [1, 80, 128, 128] and the output of the LiDAR encoder is [1, 256, 180, 180 ], there will be an error when torch.cat(inputs, dim=1) how should this problem be solved.

Hi @kkangshen,
I would suggest you to use the same output resolutions for both branches.
If you really want to have different resolutions for camera and LiDAR branches, I would suggest you to have a look at this class in our segmentation head implementation, which actually changes the resolution of the output BEV feature map to a target size. You can use a similar resolution to align the resolutions of both branches first and then concatenate them together for further processing.
Best,
Haotian

s

Hi @kentang-mit
Thank you very much for replying，I have the following questions。

I run the test.py file torchpack dist-run -np 8 python tools/test.py configs/nuscenes/det/transfusion/secfpn/camera+lidar/swint_v0p075/convfuser.yaml pretrained/bevfusion- det.pth --eval bbox,
When running, it is found that the dimension obtained by extract_camera_features is different from the dimension obtained by extract_lidar_features. If I want to make the two feature dimensions the same, how should I modify it.
I want to do the detection task, do I need to convert the features obtained by extract_camera_features into [1, 80, 180, 180]
When I passed the debug script, I found that when the checkpoint = load_checkpoint(model, args.checkpoint, map_location="cpu") was executed, the dx, nx, and bx parameters in the configuration file were changed. I don't know if this caused the extract_camera_features The feature becomes [1, 80, 128, 128]

That sounds pretty interesting to me @kkangshen. I can confirm that your observation in 3 is reasonable because dx, nx and bx are defined as model parameters, so loading the checkpoint might override these values in the configuration file. But I actually have tested these pretrained models we released and I did not run into this issue. Would you mind downloading the latest checkpoints again (because we updated them very recently) and make sure that the correct checkpoint is loaded (for example, please do not load the segmentation checkpoint if you want to do detection)?

@kkangshen 请问在pycharm上调试时是如何启动torchpack库的？我现在无法调试...

The problem related to PyCharm debugging has been resolved in another issue. I'm closing this one since it is resolved.

@kkangshen 请问在pycharm上调试时是如何启动torchpack库的？我现在无法调试...
你将dist.init()注释掉 ，使用单个gpu就可以

@kkangshen I also want to debug on pycharm now. I can run the program in the terminal, but the debug parameter is passed in and an error is reported.

When debugging, I commented out dist.init() as you said, and set distributed to False,

I think my dataloader is fine, because the terminal input command can run the program,do you know why？please


ENH: stats: add informative error message to boxcox_normmax for non-positive input

Reference issue
See https://github.com/scipy/scipy/issues/18761
What does this implement/fix?
improves input checks and exception handling of boxcox_normmax

adds an informative error message if the x argument has non-positive, non-finite, or NaN values
adds this as a requirement/assume to the docstring
improves the existing error message where optimizer returns None
adds a test for the x and modifies the test for optimizer to match the new message

I took the liberty of making some subjective adjustments. For instance, I don't think NaNs are finite, so I removed "non-NaN" to shorten the text. Also, the user won't get the error message about optimizer unless it is passed, so I think it's reasonable to omit the interruption ", if passed,". Hope you don't mind. If CI comes back green tomorrow, I'll merge.

For instance, I don't think NaNs are finite, so I removed "non-NaN" to shorten the text.

Sure, as you please!
You're saying, finite implies non-NaN?
Not sure whether the average user will have this implication at the top of their mind. I usually find it "safer" to spell out requirements more verbosely. The NaN issue might surprise the user.
But I do not have a strong opinion.

Also, the user won't get the error message about optimizer unless it is passed, so I think it's reasonable to omit the interruption ", if passed,".

We had this problem/discussion in sktime, the subtle point being that it might not be the user but another method that passes sth to boxcox_normmax. If it is not the user (as can be common), the user will not be aware of what was passed or not.
More generally, we've learnt the hard way that error messages should also be informative if they are raised in as scenario where the method/function is not directly interacted with by the user.
A common bad example would be "exception: x must be finite" - well, probably, but which function exactly is this supposed to refer to? The traceback is not always helpful in this case, as the intended reference can be an arbitrary number of levels above the exception...

The NaN issue might surprise the user.

Sure, I considered this. I agree that it's possible for a user to receive the message, check their data only for negative and infinite numbers, and not realize that np.isfinite(np.nan) and math.isfinite(math.nan) are both False. I just weighed this possibility against the extra words differently. If you prefer, please feel free to add this back, and I will not change it.

More generally, we've learnt the hard way that error messages should also be informative if they are raised in as scenario where the method/function is not directly interacted with by the user.

Yes, I realized that this is what you were after. For instance, you were careful to include the names of the calling function boxcox_normmax in the error message, so I didn't remove that. But I thought about how if the user is not directly interacting with boxcox_normmax, and optimizer is being passed to boxcox_normmax without their knowledge, I couldn't see how "if passed" would help them. I preserved the rest of the detail, though.


Implement IBufferWriter

This PR allows users of RMS to write directly to the underlying memory without the limitations of GetBuffer() (copying, and failing on streams larger than 2GB).
The only real complexity is handling calls to GetMemory() and GetSpan() with a non-zero size hint. If the hint is larger than the space left in the current block the methods rent and return a temporary buffer from the memory manager. A later call to Advance() copies the data into the stream and returns the buffer.

@benmwatson How do the instructions look?

@benmwatson How do the instructions look?

very nice. Thank you! I've approved this and will merge it in soon. I have some more documentation fixes I want to do next week, and I'll plan on releasing 2.0 late next week.