Not working autocompletion in python-mode

Observed behavior
I have in the settings
(require 'company)
(setq company-idle-delay 0.2
      company-minimum-prefix-length 3)

When I open *.py autocompletion not working.

Expected behaviour
Autocompletion works when I open the file the first time.

Steps to reproduce

Create and open test.py file
Run describe-variable company-backends. Its value is (company-capf company-dabbrev company-ispell company-yasnippet)
Run python-mode and again describe-variable company-backends. Current value is ((company-anaconda) company-capf company-dabbrev company-ispell company-yasnippet)

System information

Click to expand
DOOM Doctor
Running Emacs v25.3.1, commit 5dacbb7cb1c6ac246a9ccd15e6c4290def67757c

shell: /bin/zsh
Compiled with:
  JPEG RSVG IMAGEMAGICK NOTIFY ACL GNUTLS LIBXML2 ZLIB
  TOOLKIT_SCROLL_BARS NS MODULES
uname -a:
  Darwin MacBook-Air-Aleksandr.local 17.0.0 Darwin Kernel Version
  17.0.0: Thu Aug 24 21:48:19 PDT 2017;
  root:xnu-4570.1.46~2/RELEASE_X86_64 x86_64

Attempt to load DOOM: success!

I did a fresh install from the dev branch and still it doesn't work out of the box.

@Githeo Did you enable both :completion company and :lang python (or the module for the programming language you are testing with)?

Hello @filalex77, in the .doom/init.el file the:completion companywas already enabled and I enabled the :lang python too. Still no completion.
Do I need to run some other commands before?

just did it and I also add in the init.el
(require 'company)
(setq company-idle-delay 0.2
      company-minimum-prefix-length 3)

with no luck.
The only way so far to make it work is to disable global-company-mode and then to re-enable it at each time I open emacs.

Hello @filalex77, in the .doom/init.el file the:completion companywas already enabled and I enabled the :lang python too. Still no completion.
Do I need to run some other commands before?

the same problem.

@alinbxSorcerer Is there any way you can get completion working (for example, by restarting global-company-mode)? If not, please try manually installing dependencies for anaconda-mode (the Python backend for Emacs used by :lang python):
pip install jedi json-rpc service_factory

Be sure to check your Python version (for example, to use pip3 for Python 3), whether you have permissions for a system-wide installation (sudo pip install or pip install --user may work, but please consult the documentation for your OS of choice).
If that doesn't help, please let me know, and also describe your environment in more detail. Pasting the output of M-x doom/info RET would be a good start. Good luck!

@alinbxSorcerer Is there any way you can get completion working (for example, by restarting global-company-mode)? If not, please try manually installing dependencies for anaconda-mode (the Python backend for Emacs used by :lang python):
pip install jedi json-rpc service_factory

Be sure to check your Python version (for example, to use pip3 for Python 3), whether you have permissions for a system-wide installation (sudo pip install or pip install --user may work, but please consult the documentation for your OS of choice).
If that doesn't help, please let me know, and also describe your environment in more detail. Pasting the output of M-x doom/info RET would be a good start. Good luck!

It does not work and the details.

emacs   version    26.1
        features   XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 THREADS LIBSYSTEMD LCMS2
        build      Apr 11, 2019
        buildopts  (--build x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib --libexecdir=/usr/lib --localstatedir=/var/lib --infodir=/usr/share/info --mandir=/usr/share/man --enable-libsystemd --with-pop=yes --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/26.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/26.1/site-lisp:/usr/share/emacs/site-lisp --with-sound=alsa --without-gconf --with-mailutils --build x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib --libexecdir=/usr/lib --localstatedir=/var/lib --infodir=/usr/share/info --mandir=/usr/share/man --enable-libsystemd --with-pop=yes --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/26.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/26.1/site-lisp:/usr/share/emacs/site-lisp --with-sound=alsa --without-gconf --with-mailutils --with-x=yes --with-x-toolkit=gtk3 --with-toolkit-scroll-bars 'CFLAGS=-g -O2 -fdebug-prefix-map=/build/emacs-cQxEw2/emacs-26.1+1=. -fstack-protector-strong -Wformat -Werror=format-security -Wall' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro')
        windowsys  x
        daemonp    server-running
doom    version    2.0.9
        build      HEAD -> develop, origin/develop, origin/HEAD 7c8badc8f 2019-09-28 12:47:21 -0400
system  type       gnu/linux
        config     x86_64-pc-linux-gnu
        shell      /bin/bash
        uname      Linux 5.0.0-27-generic #28-Ubuntu SMP Tue Aug 20 19:53:07 UTC 2019 x86_64
        path       (~/anaconda3/bin ~/anaconda3/bin ~/anaconda3/bin ~/anaconda3/bin ~/anaconda3/condabin ~/anaconda3/bin /usr/local/sbin /usr/local/bin /usr/sbin /usr/bin /sbin /bin /usr/games /usr/local/games /snap/bin ~/.emacs.d/bin ~/.emacs.d/bin ~/.emacs.d/bin ~/.emacs.d/bin /usr/lib/emacs/26.1/x86_64-linux-gnu/)
config  envfile    envvar-file
        elc-files  0
        modules    (:completion company helm ivy :ui doom doom-dashboard doom-quit hl-todo modeline nav-flash ophints (popup +all +defaults) vc-gutter vi-tilde-fringe window-select workspaces :editor file-templates fold multiple-cursors rotate-text snippets :emacs dired electric vc :term eshell shell term :tools eval flycheck (lookup +docsets) magit :lang data emacs-lisp markdown (org +dragndrop +ipython +pandoc +present) python sh :config (default +bindings +smartparens))
        packages   (n/a)
        elpa       (n/a)

- OS: darwin (x86_64-apple-darwin18.6.0)
- Shell: /usr/local/bin/fish
- Emacs: 26.2 (Aug 07, 2019)
- Doom: 2.0.9 (HEAD -> develop, origin/develop, origin/HEAD f754d4ff 2019-07-23 18:23:17 +0200)
- Graphic display: t (daemon: nil)
- System features: JPEG RSVG IMAGEMAGICK GLIB NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS MODULES THREADS LCMS2
- Details:
```elisp
env bootstrapper: envvar-file
elc count: 0
uname -a:  Darwin 18.6.0 Darwin Kernel Version 18.6.0: Thu Apr 25 23:16:27 PDT 2019; root:xnu-4903.261.4~2/RELEASE_X86_64 x86_64
modules:   (:completion company ivy :ui doom doom-dashboard doom-quit hl-todo modeline nav-flash ophints (popup +all +defaults) treemacs vc-gutter vi-tilde-fringe window-select workspaces :editor evil file-templates fold multiple-cursors rotate-text snippets :emacs dired electric vc :tools eval flycheck (lookup +docsets) magit :lang data emacs-lisp markdown (org +dragndrop +ipython +pandoc +present) python sh :config default)
packages:  n/a
exec-path: (/usr/local/Cellar/pyenv-virtualenv/1.1.3/shims ~/.pyenv/shims /usr/local/bin /usr/bin /bin /usr/sbin /sbin /Library/TeX/texbin . ~/Library/Android/sdk/platform-tools/ /usr/local/Cellar/emacs-plus/26.2/libexec/emacs/26.2/x86_64-apple-darwin18.6.0/)

@Githeo There were some changes (not necessarily related to :lang python) since 2019-07-23, would you mind running doom update?
Also, lsp-python-ms support was added. Consider setting it up, LSP is objectively better than any company backend.

@filalex77 I did the doom update. Now a completion is shown but it's the common one for all the variables only.
How could I switch to lsp-python-ms?

@Githeo

Quit Emacs.]
Add +lsp flag to :lang python in init.el

:lang
-python
+(python +lsp)

Run doom refresh
Launch Emacs. Run M-x lsp-python-ms-setup RET to install the server.
Try opening up a .py file and see what you get!

lsp-python-ms-setup doesn't pop up after M-x. Is it not installed?

bin/doom  install lsp-python-ms
Insecure mode on
Doom core autoloads is up-to-date
Looking for packages to install...
No packages to install!

Hello all, I had a similar problem with doom-emacs with windows.
By trial and error, I found that doom emacs is looking for config files in a different directory. So I created a symbolic link.
In my case, I created a symbolic link to the .emacs.d folder at  $HOME/AppData/Roaming  to point to $HOME.
This solved my problem and I can see python completions.


Update vendored urllib3

In current boto3, if you use a session (and correspondingly an HTTP connection pool), some messages will be logged at INFO level that should be logged at DEBUG level. For example:
2018-11-26 17:53:48,231:INFO:botocore.vendored.requests.packages.urllib3.connectionpool:Starting new HTTPS connection (1): route53.amazonaws.com

and
2018-10-10 08:51:44,033:INFO:requests.packages.urllib3.connectionpool:Resetting dropped connection: route53.amazonaws.com

This was fixed in https://github.com/urllib3/urllib3/commit/5c729531137c836f7ec6ec325a423b40aae8742c, which is incorporated into v1.17 of urllib. Could botocore update its vendored version? This caused some confusion on a Let's Encrypt forum thread where the "Resetting dropped connection" message (which is harmless) bubbled up at INFO level, making it seem like the cause of an unrelated error.
https://community.letsencrypt.org/t/issue-with-aws-api-when-using-certbot-dns-route53-with-many-domains/75259

Unfortunately, we can't update the vendored urllib3 as we don't use it in botocore anymore. We just keep it around for legacy purposes in case customers are using it.

I can confirm that, after upgrading to latest versions of everything, the problem I reported is gone. Thanks for your attention!

Hey,
I see that you're keeping urllib3 for legacy problem.
We use your boto3 lib and found out that its opening our code (and anyone else who is including botocore) to a high severity vulnerability CVE2018-20060

Please could you reconsider removing (or updating) this library, to remove the vulnerability?


Got Error: NextRouter was not mounted when using next/router directly

Description
This issue is weird, and I don't know if next-intl is supposed to do this.
For a next.js project with next-intl, normally, we should do this by the official documentation:
import { useRouter } from "@/library/navigation";
...
const router = useRouter();

And for some reasons, I am trying to import and use the useRouter from next/router, so codes become like this:
import { useRouter } from "next/router"
...
const router = useRouter();

I will receive an issue like:

I can understand that next-intl needs some support from next/router and maybe modified it, but I didn't notice this from the official documentation, and this issue took me some time to figure out. And for my scenario, I am trying to develop a public component, which needs next/router, and I import it directly. Now I need to build a setup for this component to make it okay with both the original next.js project and the next-intl project.
Verifications

[X] I've verified that the problem I'm experiencing isn't covered in the docs.
[X] I've searched for similar, existing issues on GitHub and Stack Overflow.
[X] I've compared my app to a working example to look for differences.

Mandatory reproduction URL
https://github.com/LikeDreamwalker/nextjs-mui-zustand-template/tree/dev-next-router-issue
Reproduction description
I make the demo in my public repo, so you can try it as:

pnpm i
pnpm run dev
In src\components\MenuList\index.tsx, you can see the comment and by using the different useRouter to reproduce the issue

Also you can do this:

Open an project with next-intl
By changing the using like:

// If we are trying to use the useRouter hook from next/router
// We will receive an issue like:
// Error: NextRouter was not mounted. https://nextjs.org/docs/messages/next-router-not-mounted
import { useRouter } from "next/router";
// But using from next-intl will be okay
// import { useRouter } from "@/library/navigation";
...
  const router = useRouter();

Expected behaviour

Use useRouter from next/router shouldn't have an error
Or next-intl can make a more preceding notification
Or next-intl can make a more clear alert in the official document (and please forgive me if I missed it)

Also, for my scenario, if I am trying to use render or portal from react-dome to attach a component to the app, I actually can't use the useRouter even if it comes from next-intl's createSharedPathnamesNavigation, which will bring me in:

Really need some help now.

im not great with this but maybe import useRouter from next/navigation instead and see if that works


implement a simple ROI configuration per video

define a ROIs configuration per video.

The ROIs configuration of a video defines a coordinate system and a set of square ROIs, all defined by user clicks.

ideally the definition of ROIs per video is automatically linked to the video (potentially as metadata?)
the general idea is to improve and integrate in the pipeline the step that is currently done using this (broken) repo

this repo may also be worth a look

these annotation tools from Dash look super useful for ROI definition

as suggested by @niksirbi in the standup today, it will probably be good to try to be compatible with Napari's input data format (directly or via an util function). It would be neat if a user labelling in DLC (whose latest gui is in Napari) can visualise simultaneously the ROIs that have been defined for a video.


Properly decide on availability of $secrets argument

What would you like to be added:

currently $secrets is documented to be available everywhere, but I know @cdavernas mentioned it should only be available in input.from to avoid leaks.
Why is this needed:

I understand the reasoning but I'm concerned it might have unintended consequences. Keeping $secrets accessible everywhere makes it clear to the author that they're dealing with sensitive information, ensuring caution in its use. However, if $secrets is only available in input.from, there's a risk that as the data moves through the pipeline, the secret could be aliased, potentially obscuring its sensitive nature.
do:
- someUnsafeCall:
  call: http
  with:
    method: get
    endpoint: ${ "https://unsafe.server.com/api/shitty-auth/\($secrets.token)" # <-- the use of sensitive data is clear

vs
do:
- someUnsafeCall:
  input:
    from:
      token: $secrets.token
  call: http
  with:
    method: get
    endpoint: https://unsafe.server.com/api/shitty-auth/{token} # <-- the use of sensitive data is not obvious

@JBBianchi I agree with you, but on the other hand leaving them accessible everywhere is like telling to the authors it's ok to use them everywhere, like when calling a (potentially custom) function.
Plus, if the user explicitly decided to flow it down, the responsibility is IMHO his.

@JBBianchi good point

@JBBianchi good point. It's much harder to accidentally leak the $secrets arg than the input

I disagree. I don't see why it would be harder. For most users, $secrets is just gonna be yet another runtime expression variable.
Annyways, whatever you guys decide is fine by me. I just think we should be extra careful with those, as it's our responsibility to "educate" authors on the proper approach to adopt when using this feature.

To quote ChatGPT:
In a Serverless Workflow, the availability of the $secrets argument should be carefully considered to balance security and flexibility.

Security Considerations
Limiting Scope: Making $secrets available only at the workflow input (or in controlled, specific places) reduces the risk of accidental exposure or misuse of sensitive data. The broader the availability of secrets, the higher the chances of them being logged, passed to unintended functions, or exposed in runtime errors.
Principle of Least Privilege: This principle suggests that secrets should only be accessible where absolutely necessary. By restricting $secrets to workflow input, you adhere to this principle, ensuring that secrets are only available to components that truly need them.
Flexibility Considerations
Complex Workflows: In some workflows, you might need to access secrets at different stages, not just at the beginning. Allowing $secrets to be available throughout the workflow can enhance flexibility and make the workflow easier to design and maintain.
Modular and Reusable Components: If different parts of the workflow are designed to be modular and reusable, they might require access to secrets independently. This scenario would argue for broader access to $secrets.
Best Practice Recommendation
Given the above considerations, the most secure approach is to limit the availability of $secrets to the workflow input and specific, well-defined points within the workflow where access is necessary. This could include:

The start of the workflow to initialize required parameters.
Specific states or functions that need secret access.
Ensuring secrets are not accidentally passed down through the workflow unnecessarily.
Implementation Strategy
Default Restriction: Make $secrets available by default only at the workflow input.
Explicit Access: Allow developers to explicitly declare if and where they need access to $secrets within the workflow. This could be achieved via configuration or annotations, requiring an extra step to expose secrets, thus making users consciously decide when and where secrets are needed.
This approach balances security with the necessary flexibility, ensuring that secrets are protected while still allowing workflows to function as needed.

I think it's easier to leak when the secret has to be put in the input
imagine I want to send some object (e.g. pet) to an api key authenticated API, first I write:
do:
  - apiCall:
      call: http
      with:
        method: post
        endpoint: https://server.com/api/pets
        body: ${ . }

... then I realise I forgot auth so I add it
do:
  - apiCall:
      input:
        from:
          key: ${ $secrets.apiKey }
      call: http
      with:
        method: post
        endpoint: https://server.com/api/pets
        headers:
          X-API-Key: ${ .key }
        body: ${ . }

and I already made the subtle mistake of no ONLY sending my api key, because input transformations have so much impact an the whole task. It would have been much harder to make such a mistake when using $secrets

Maybe there is a mitigation to be found with implicitly "sharing" a new $secrets variable ?
e.g.:
do:
  - apiCall:
      input:
        $secrets:
          key: ${ $secrets.apiKey }
      call: http
      with:
        method: post
        endpoint: https://server.com/api/pets
        headers:
          X-API-Key: ${ $secrets.key }
        body: ${ . }

And, for instance
do:
  - apiCall:
      input:
        from:
          key: ${ $secrets.apiKey }
#...

Would fail because we do not inject $secrets when processing input.from but only input.$secrets ?
Just throwing ideas here.

Would fail because we do not inject $secrets when processing input.from but only input.$secrets ?

This feels like it achieves the same just with extra steps because now I have to use ${ .$secrets.foo } (extra .) instead of ${ $secrets.foo } inside the task which seems really confusing. Plus I see this to just being used as
do:
  - apiCall:
      input:
        $secrets: ${ $secrets } # also looks terrible doesn't it 😅
      call: http
      with:
        ...

@matthias-pichler very good sample, which perfectly demonstrates your rightful concerns. You could however leak them in a similar fashion using the runtime expression argument.
Anyways, I won't endlessly ramble on the subject: I think you make a strong and valid point.
@JBBianchi even though I love both the idea and the (awesome) will to find a consensual solution, I feel this would complexify things for authors and might even be confusing.

To conclude, you guys convinced me, and have my vote to definitely close that issue!

I don't think we should dismiss this topic, the concern is real. Imagine a distributed runtime where each activity processor is a FaaS for instance.
Is it really a good idea to always send the all $secrets over the wire ?
Shouldn't we find a way to explicitly send the $secrets required by the activity ?
In that case, shouldn't we enforce a variable name that clearly underlines the sensitive nature of the data to the author ?

Imagine a distributed runtime where each activity processor is a FaaS for instance.

Very good point, which was also, if I remember properly, part of the motivation of the initial restriction.
@matthias-pichler Any idea/suggestion?

Imagine a distributed runtime where each activity processor is a FaaS for instance.

Our runtime is currently implemented such that every task is run in a Lambda Function.
I understand that it's not ideal/least privilege that every Lambda Function needs access to the secrets, however given the tradeoffs I would still prefer having $secrets everywhere. Furthermore currently we have input transformation and task execution in two separate functions but due to performance considerations I am currently merging input/output transforms and task executions into one Lambda Function. So given these circumstances (which I assume are fairly common) it wouldn't change anything and every Task Lambda Function would still need access to secrets for the sake of input transformations

Imagine a distributed runtime where each activity processor is a FaaS for instance.

Our runtime is currently implemented such that every task is run in a Lambda Function.
I understand that it's not ideal/least privilege that every Lambda Function needs access to the secrets, however given the tradeoffs I would still prefer having $secrets everywhere. Furthermore currently we have input transformation and task execution in two separate functions but due to performance considerations I am currently merging input/output transforms and task executions into one Lambda Function. So given these circumstances (which I assume are fairly common) it wouldn't change anything and every Task Lambda Function would still need access to secrets for the sake of input transformations

Well, I'm glad that my hypothetical use-case is an actual one. But I don't think it's OK to share secrets with "everyone", that's quite against their purpose.
What are the arguments against "explicitly select" the secrets provided to a task ?
The following is just a conceptual example, the how can be adjusted:
document:
  #...
use:
  secrets:
  - GitHubToken
  - XToken
do:
  - release:
      secrets:
        - GitHubToken # explicitly share the `GitHubToken` secret
      call: http
      with:
        method: GET
        endpoint:
          uril: https://api.github.com/my-repo/release
          token: ${ $secrets.GitHubToken }
- announceOnX:
      secrets:
        - XToken # explicitly share the `XToken` secret
      call: http
      with:
        method: POST
        endpoint:
          uril: https://api.github.com/my-repo/release
          token: ${ $secrets.XToken }
        body: ${ "Checkout our new release at \(.artifact.url)" }
- updateInternalRegistry:
      call: http
      with:
        method: POST
        endpoint:
          uril: https://server.local
          token: ${ $secrets.GitHubToken } # <--- error, $secrets is empty

It does add an extra step but it doesn't seem to be a huge overhead.

Well, I'm glad that my hypothetical use-case is an actual one. But I don't think it's OK to share secrets with "everyone", that's quite against their purpose.

I don't quite agree with "share secrets with "everyone"" ... all the Lambda Functions are managed and implemented by us and it would not be any different if it were run in a container. If a custom function (which we don't control) is invoked the input and any expressions in it are evaluated on our side and then the untrusted code is executed with the parsed input... I don't really see who'd we be sharing the secrets with?

What are the arguments against "explicitly select" the secrets provided to a task ?

I think the only one I have is that it's just more work for authors and it seems super repetitive, e.g. when building a workflow that calls the same API 4 times having to specify it 5 times in total (including at the workflow level).
It's also so much more overhead around secrets that I have not seen from any other workflow engine. E.g. Pipedream, GitHub, GitLab, etc you define secrets and then they are available as environment variables.

I don't quite agree with "share secrets with "everyone"" ... all the Lambda Functions are managed and implemented by us and it would not be any different if it were run in a container. If a custom function (which we don't control) is invoked the input and any expressions in it are evaluated on our side and then the untrusted code is executed with the parsed input... I don't really see who'd we be sharing the secrets with?

I must admit I dramatized the situation (although I wouldn't say relying on a 3rd party infrastructure is the same as running a container on your own isolated host). My concern doesn't 100% apply on the situation you describe. The problem would rather be when calling a 3rd party activity processor, or if the network has been compromised (e.g. subject to MitM attacks).

I think the only one I have is that it's just more work for authors and it seems super repetitive, e.g. when building a workflow that calls the same API 4 times having to specify it 5 times in total (including at the workflow level).
It's also so much more overhead around secrets that I have not seen from any other workflow engine. E.g. Pipedream, GitHub, GitLab, etc you define secrets and then they are available as environment variables. And I don't really see any reason why we should make it much more complicated

I agree, it's not very pretty and quite cumbersome.


Bugfix - Update Gulp version to "^4.0.0"

This request fixes the new email project creation error regarding the bad package.json gulp link.

Please merge this. It take me a lot of time to know this small bug.

Will fix this issue: https://github.com/zurb/foundation-emails/issues/934

Can someone with write access merge this? Please and thank you!

bump

Please for the love of God merge this fix. A small bug that will save a lot of headaches, StackOverflow and Google searches.

Please merge this guys! Took some time to figure this out.

bump bump


[1.12.2] Poor performance with high item counts

An rs system with just drives and a few million items is already enough to easely delay a tick by 40 seconds or more upon being loaded or edit(if you take out drives with items in them).
This makes rs worthless for real mass storage as about 10 million items are sufficient to time everyone out before it loads and thus nobody can ever get near that system anymore, even removing the controller causes this delay for some reason.

Minecraft: 1.12.2
Forge: <IP_ADDRESS>11
Refined Storage: Refined Storage 1.6.14

Does this issue occur on a server? [yes/no]
yes(Same does however occur in singleplayer)

Please run some profiling on the server when this happens to find out what causes this. Possibly another mods interacts badly with the system. I've had bigger systems plenty of times and have never had players get timed out due to them.
https://refinedstorage.raoulvdberge.com/wiki/profiling

Even with just this mod it happends

And it ain't constant lag, it just locks everything up so badly that not even a profiler can spot it

Good that probably makes it possible to fix the issue, if we can find out what causes it with the profiling info.

It are spikes which profilers do not manage to catch

So the entire PC freezes when this happens? Only thing I can think of that could cause this is a broken or very slow hard drive/ssd? That would probably also cause other issues though so.. yeah not sure what could cause that.

No, it just turns the entire server unresponsive for quite a bit to the point that the profilers do not spot it

Can you give me reproduction steps, with just RS installed? And something less vague than "just insert a lot of items". Tell me exactly what you're doing.

Refined storage simply cannot handle a lot of items efficiently, simple as that


fix panic due to index out of range on getOutstandingUploads

Fixes #2908
Hello I am proposing this change to avoid getting panic error: index out of range on function getOutstandingUploads

Please sign your commits following these rules:
https://github.com/moby/moby/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "check-range-getOutstandingUploads" git@github.com:hernandanielg/distribution.git somewhere
$ cd somewhere
$ git commit --amend -s --no-edit
$ git push -f

Amending updates the existing PR. You DO NOT need to open a new one.

Sorry for the delay... @caervs done, can you please check? :) thanks!

ping @caervs

Thanks for the change @hernandanielg. Please format the file with gofmt (missing a space before the second parameter). Otherwise, LGTM.

Done @caervs

@caervs Any ETA on getting this in a release?
This error has prevented us from upgrading our registries for a while now.

@caervs Could you please re-check this?

Hello @Spjak @awprice
I don't think @caervs is looking into this anymore. can somebody else take over?
Bests

Closed as it seems nobody will take care of this

@hernandanielg what about reopen this pr? it's a really issue to prevent us using s3 backend storage.

@hernandanielg any possible workaround for us with S3 backend storage?


Add MIT license with link to graphql-tools for code copied from apollographql/graphql-tools

Hi! I think this is the best way to add this license. I noticed some of the files had changes to them as well, not sure what the best way to handle that is.
I identified these files by looking for identical code within these files, even though the file names are not always the same.

Hi, apart from the RemoteSchemaFactory.ts, which includes some fundamental changes to the code, I think the licenses make a lot of sense.
But as you have this in the license:
 The above copyright notice and this permission notice shall be included in all
 copies or substantial portions of the Software.

It's fair to include it everywhere :)
Thanks for the PR!


Huge size increase since 6662

In 6658, the libpdfium.a size for macOS was ~25Mb.
Now, the last libpdfium.a is 294Mb 🤔
Is it intended or does a configuration changed somewhere during the build process ?
Thanks !

Sorry. It was fixed here:
https://github.com/paulocoutinhox/pdfium-lib/releases/tag/6694
After CI finish build, it will be available there.

No worries, thanks for your responsiveness!


set minSdk to 21

I have changed and confirmed that the library works well on Android API Level 21.
I have created my develop branch from master so as to update your develop with the missing changes
This fixes #5

Thanks, I'll review this and merge :)


Added a migration guide when coming from discord.py

Summary
This just adds a migration guide for users coming from discord.py, since I've seen many people with the issue of having both, nextcord and discord.py installed
Checklist

[ ] If code changes were made then they have been tested.

[ ] I have updated the documentation to reflect the changes.

[ ] This PR fixes an issue.
[ ] This PR adds something new (e.g. new method or parameters).
[ ] This PR is a breaking change (e.g. methods or parameters removed/renamed)
[x] This PR is not a code change (e.g. documentation, README, ...)

Already exists: https://nextcord.readthedocs.io/en/latest/migrating_to_nextcord.html


Periodically refresh CNI configuration

Hopefully this is the right place to raise this.
Recently had some users hitting this issue: https://github.com/projectcalico/calico/issues/2200
It turned out to be that when using containerd with Kubernetes, CNI config file changes on disk are not picked up without a restart of containerd.
When using docker, CNI config is periodically reloaded, and so changes are picked up for future containers. It would be great if the same was true when using containerd as the runtime.

What release are you on? We fixed this last June. When a pod is created we use the current cni config files for that pod.

See https://github.com/containerd/cri/pull/825 :-)

@mikebrow thanks for the pointer, I think it is likely that an older version is in use then. I'll double check and report back here.

Yep, looks like it was an older version. Sorry for the noise - thanks!


[🐛 Bug]:  deploying nextjs keep showing error

next-on-pages environment related information
System:
Platform: win32
Arch: x64
Version: Windows 10 Pro
CPU: (4) x64 Intel(R) Core(TM) i5-7300U CPU @ 2.60GHz
Memory: 8 GB
Shell: C:\Program Files\Git\usr\bin\bash.exe
Binaries:
Node: 16.18.0
Yarn: 1.22.19
npm: 9.6.5
pnpm: N/A
Package Manager Used: pnpm
Relevant Packages:
@cloudflare/next-on-pages: 0.10.1
vercel: N/A
next: N/A
Description
2023-05-20T19:00:25.892141Z	Cloning repository...
2023-05-20T19:00:27.190695Z	From https://github.com/karapy/yaratopia
2023-05-20T19:00:27.191345Z	 * branch            2cde84f8fc740b0fe13c7434697c27bbd8b44c52 -> FETCH_HEAD
2023-05-20T19:00:27.191533Z
2023-05-20T19:00:27.261383Z	HEAD is now at 2cde84f cloudflare pakage
2023-05-20T19:00:27.261992Z
2023-05-20T19:00:27.372431Z
2023-05-20T19:00:27.402954Z	Success: Finished cloning repository files
2023-05-20T19:00:27.962313Z	Installing dependencies
2023-05-20T19:00:27.971142Z	Python version set to 2.7
2023-05-20T19:00:31.278696Z	v16.20.0 is already installed.
2023-05-20T19:00:32.967266Z	Now using node v16.20.0 (npm v8.19.4)
2023-05-20T19:00:33.152709Z	Started restoring cached build plugins
2023-05-20T19:00:33.164723Z	Finished restoring cached build plugins
2023-05-20T19:00:33.582952Z	Attempting ruby version 2.7.1, read from environment
2023-05-20T19:00:35.110767Z	Using /opt/buildhome/.rvm/gems/ruby-2.7.1
2023-05-20T19:00:36.124527Z	Using PHP version 5.6
2023-05-20T19:00:36.218254Z	5.2.5 is already installed.
2023-05-20T19:00:36.235412Z	Using Swift version 5.2.5
2023-05-20T19:00:36.235965Z	Started restoring cached node modules
2023-05-20T19:00:36.247425Z	Finished restoring cached node modules
2023-05-20T19:00:36.881551Z	Installing NPM modules using NPM version 8.19.4
2023-05-20T19:00:38.070873Z	npm WARN config tmp This setting is no longer used.  npm stores temporary files in a special
2023-05-20T19:00:38.071205Z	npm WARN config location in the cache, and they are managed by
2023-05-20T19:00:38.07139Z	npm WARN config     cacache.
2023-05-20T19:00:38.496687Z	npm WARN config tmp This setting is no longer used.  npm stores temporary files in a special
2023-05-20T19:00:38.497114Z	npm WARN config location in the cache, and they are managed by
2023-05-20T19:00:38.497451Z	npm WARN config     cacache.
2023-05-20T19:00:58.287728Z	npm WARN deprecated<EMAIL_ADDRESS>This package has been deprecated and is no longer maintained. Please use @rollup/plugin-inject.
2023-05-20T19:00:58.398812Z	npm WARN deprecated<EMAIL_ADDRESS>Please use @jridgewell/sourcemap-codec instead
2023-05-20T19:00:59.0535Z	npm WARN deprecated<EMAIL_ADDRESS>This functionality has been moved to @npmcli/fs
2023-05-20T19:01:14.29031Z
2023-05-20T19:01:14.291004Z	added 1086 packages, and audited 1087 packages in 36s
2023-05-20T19:01:14.291196Z
2023-05-20T19:01:14.291345Z	264 packages are looking for funding
2023-05-20T19:01:14.292606Z	  run npm fund for details
2023-05-20T19:01:14.293154Z
2023-05-20T19:01:14.293441Z	found 0 vulnerabilities
2023-05-20T19:01:14.324353Z	NPM modules installed
2023-05-20T19:01:14.39095Z	Installing Hugo 0.54.0
2023-05-20T19:01:15.075268Z	Hugo Static Site Generator v0.54.0-B1A82C61A/extended linux/amd64 BuildDate: 2019-02-01T10:04:38Z
2023-05-20T19:01:15.078144Z	Started restoring cached go cache
2023-05-20T19:01:15.096728Z	Finished restoring cached go cache
2023-05-20T19:01:15.188696Z	go version go1.14.4 linux/amd64
2023-05-20T19:01:15.202325Z	go version go1.14.4 linux/amd64
2023-05-20T19:01:15.207151Z	Installing missing commands
2023-05-20T19:01:15.207419Z	Verify run directory
2023-05-20T19:01:15.207578Z	Executing user command: npx @cloudflare/next-on-pages@1
2023-05-20T19:01:15.873275Z	npm WARN config tmp This setting is no longer used.  npm stores temporary files in a special
2023-05-20T19:01:15.873617Z	npm WARN config location in the cache, and they are managed by
2023-05-20T19:01:15.873842Z	npm WARN config     cacache.
2023-05-20T19:01:17.158294Z	npm WARN exec The following package was not found and will be installed<EMAIL_ADDRESS>2023-05-20T19:01:27.293599Z	npm WARN deprecated<EMAIL_ADDRESS>This functionality has been moved to @npmcli/fs
2023-05-20T19:01:27.683246Z	npm WARN deprecated<EMAIL_ADDRESS>This package has been deprecated and is no longer maintained. Please use @rollup/plugin-inject.
2023-05-20T19:01:27.892852Z	npm WARN deprecated<EMAIL_ADDRESS>Please use @jridgewell/sourcemap-codec instead
2023-05-20T19:01:32.592895Z	⚡ @cloudflare/next-on-pages CLI v.1.0.0
2023-05-20T19:01:32.595754Z	⚡ Detected Package Manager: pnpm
2023-05-20T19:01:32.596006Z	⚡ Preparing project...
2023-05-20T19:01:32.598112Z	⚡ Project is ready
2023-05-20T19:01:32.598418Z	⚡ Building project...
2023-05-20T19:01:32.616448Z	node:events:491
2023-05-20T19:01:32.616776Z	      throw er; // Unhandled 'error' event
2023-05-20T19:01:32.617003Z	      ^
2023-05-20T19:01:32.617147Z
2023-05-20T19:01:32.61735Z	Error: spawn pnpx ENOENT
2023-05-20T19:01:32.617538Z	    at Process.ChildProcess._handle.onexit (node:internal/child_process:285:19)
2023-05-20T19:01:32.617754Z	    at onErrorNT (node:internal/child_process:485:16)
2023-05-20T19:01:32.617884Z	    at processTicksAndRejections (node:internal/process/task_queues:83:21)
2023-05-20T19:01:32.618082Z	Emitted 'error' event on ChildProcess instance at:
2023-05-20T19:01:32.618299Z	    at Process.ChildProcess._handle.onexit (node:internal/child_process:291:12)
2023-05-20T19:01:32.618489Z	    at onErrorNT (node:internal/child_process:485:16)
2023-05-20T19:01:32.618618Z	    at processTicksAndRejections (node:internal/process/task_queues:83:21) {
2023-05-20T19:01:32.618733Z	  errno: -2,
2023-05-20T19:01:32.618853Z	  code: 'ENOENT',
2023-05-20T19:01:32.618962Z	  syscall: 'spawn pnpx',
2023-05-20T19:01:32.619069Z	  path: 'pnpx',
2023-05-20T19:01:32.619182Z	  spawnargs: [ 'next-on-pages-vercel-cli', 'build' ]
2023-05-20T19:01:32.619303Z	}
2023-05-20T19:01:32.656709Z	Failed: build command exited with code: 1
2023-05-20T19:01:33.390451Z	Failed: error occurred while running build command
Reproduction
No response
Pages Deployment Method
Pages CI (GitHub/GitLab integration)
Pages Deployment ID
No response
Additional Information
No response
Would you like to help?

[ ] Would you like to help fixing this bug?

Hello, I'm sorry to hear that you're having issues. It looks like the CLI has detected that you are using pnpm in your project, but is unable to spawn pnpx.
I am going to assume that you are using build image v1. If so, have you added pnpm as part of your build/install commands? This can be done with npm add -g pnpm, before installing your dependencies.

npm add -g pnpm

yes I am using pnpm

npm add -g pnpm

yes I am using pnpm

I'm looking at your build log, specifically the following line:
2023-05-20T19:01:15.207578Z Executing user command: npx @cloudflare/next-on-pages@1

This indicated to me that you have not added pnpm to your build environment as part of your command.
Can you try changing your Build Command to the following please, and then redeploying:
npm add -g pnpm && npx @cloudflare/next-on-pages@1

npm add -g pnpm

yes I am using pnpm

I'm looking at your build log, specifically the following line:
2023-05-20T19:01:15.207578Z Executing user command: npx @cloudflare/next-on-pages@1

This indicated to me that you have not added pnpm to your build environment as part of your command.
Can you try changing your Build Command to the following please, and then redeploying:
npm add -g pnpm && npx @cloudflare/next-on-pages@1

I removed anything about pnpm and tried again but this time i got another log file and keep getting error:
 2023-05-20T19:32:54.711153Z	Cloning repository... 2023-05-20T19:32:55.796761Z	From https://github.com/karapy/yaratopia 2023-05-20T19:32:55.797389Z	 * branch            386c21a1fc9ca802b31be0b8fd7b5d6fd788b328 -> FETCH_HEAD 2023-05-20T19:32:55.797589Z	 2023-05-20T19:32:55.860417Z	HEAD is now at 386c21a remove pnpm 2023-05-20T19:32:55.861076Z	 2023-05-20T19:32:55.96953Z	 2023-05-20T19:32:55.999918Z	Success: Finished cloning repository files 2023-05-20T19:32:56.614829Z	Installing dependencies 2023-05-20T19:32:56.624035Z	Python version set to 2.7 2023-05-20T19:32:59.870568Z	v16.20.0 is already installed. 2023-05-20T19:33:01.535911Z	Now using node v16.20.0 (npm v8.19.4) 2023-05-20T19:33:01.707086Z	Started restoring cached build plugins 2023-05-20T19:33:01.718957Z	Finished restoring cached build plugins 2023-05-20T19:33:02.124703Z	Attempting ruby version 2.7.1, read from environment 2023-05-20T19:33:03.657406Z	Using /opt/buildhome/.rvm/gems/ruby-2.7.1 2023-05-20T19:33:04.644379Z	Using PHP version 5.6 2023-05-20T19:33:04.735025Z	5.2.5 is already installed. 2023-05-20T19:33:04.751405Z	Using Swift version 5.2.5 2023-05-20T19:33:04.751945Z	Started restoring cached node modules 2023-05-20T19:33:04.762339Z	Finished restoring cached node modules 2023-05-20T19:33:05.426273Z	Installing NPM modules using NPM version 8.19.4 2023-05-20T19:33:06.595734Z	npm WARN config tmp This setting is no longer used.  npm stores temporary files in a special 2023-05-20T19:33:06.596053Z	npm WARN config location in the cache, and they are managed by 2023-05-20T19:33:06.596289Z	npm WARN config     [cacache](http://npm.im/cacache). 2023-05-20T19:33:06.998324Z	npm WARN config tmp This setting is no longer used.  npm stores temporary files in a special 2023-05-20T19:33:06.998712Z	npm WARN config location in the cache, and they are managed by 2023-05-20T19:33:06.998949Z	npm WARN config     [cacache](http://npm.im/cacache). 2023-05-20T19:33:27.209613Z	npm WARN deprecated<EMAIL_ADDRESS>This package has been deprecated and is no longer maintained. Please use @rollup/plugin-inject. 2023-05-20T19:33:27.318455Z	npm WARN deprecated<EMAIL_ADDRESS>Please use @jridgewell/sourcemap-codec instead 2023-05-20T19:33:27.897615Z	npm WARN deprecated<EMAIL_ADDRESS>This functionality has been moved to @npmcli/fs 2023-05-20T19:33:42.755392Z	 2023-05-20T19:33:42.756051Z	added 1086 packages, and audited 1087 packages in 36s 2023-05-20T19:33:42.756304Z	 2023-05-20T19:33:42.756494Z	264 packages are looking for funding 2023-05-20T19:33:42.756765Z	  run npm fund for details 2023-05-20T19:33:42.757646Z	 2023-05-20T19:33:42.75787Z	found 0 vulnerabilities 2023-05-20T19:33:42.787583Z	NPM modules installed 2023-05-20T19:33:42.84803Z	Installing Hugo 0.54.0 2023-05-20T19:33:43.504208Z	Hugo Static Site Generator v0.54.0-B1A82C61A/extended linux/amd64 BuildDate: 2019-02-01T10:04:38Z 2023-05-20T19:33:43.506867Z	Started restoring cached go cache 2023-05-20T19:33:43.521822Z	Finished restoring cached go cache 2023-05-20T19:33:43.61335Z	go version go1.14.4 linux/amd64 2023-05-20T19:33:43.626775Z	go version go1.14.4 linux/amd64 2023-05-20T19:33:43.631682Z	Installing missing commands 2023-05-20T19:33:43.631968Z	Verify run directory 2023-05-20T19:33:43.632121Z	Executing user command: npx @cloudflare/next-on-pages@1 2023-05-20T19:33:44.270045Z	npm WARN config tmp This setting is no longer used.  npm stores temporary files in a special 2023-05-20T19:33:44.270352Z	npm WARN config location in the cache, and they are managed by 2023-05-20T19:33:44.270528Z	npm WARN config     [cacache](http://npm.im/cacache). 2023-05-20T19:33:45.747646Z	npm WARN exec The following package was not found and will be installed<EMAIL_ADDRESS>2023-05-20T19:33:55.697443Z	npm WARN deprecated<EMAIL_ADDRESS>This functionality has been moved to @npmcli/fs 2023-05-20T19:33:56.168043Z	npm WARN deprecated<EMAIL_ADDRESS>This package has been deprecated and is no longer maintained. Please use @rollup/plugin-inject. 2023-05-20T19:33:56.377056Z	npm WARN deprecated<EMAIL_ADDRESS>Please use @jridgewell/sourcemap-codec instead 2023-05-20T19:34:00.87031Z	⚡ @cloudflare/next-on-pages CLI v.1.0.0 2023-05-20T19:34:00.872965Z	⚡ Detected Package Manager: npm 2023-05-20T19:34:00.873255Z	⚡ Preparing project... 2023-05-20T19:34:00.875463Z	⚡ Project is ready 2023-05-20T19:34:00.875791Z	⚡ Building project... 2023-05-20T19:34:01.535176Z	▲  npm 2023-05-20T19:34:01.536058Z	▲  WARN config tmp This setting is no longer used.  npm stores temporary files in a special 2023-05-20T19:34:01.536356Z	▲  npm WARN config location in the cache, and they are managed by 2023-05-20T19:34:01.53656Z	▲  npm WARN config     [cacache](http://npm.im/cacache). 2023-05-20T19:34:02.747629Z	▲  npm 2023-05-20T19:34:02.748147Z	▲  WARN exec The following package was not found and will be installed<EMAIL_ADDRESS>2023-05-20T19:34:11.56901Z	▲  npm 2023-05-20T19:34:11.570265Z	▲  WARN deprecated<EMAIL_ADDRESS>This functionality has been moved to @npmcli/fs 2023-05-20T19:34:16.254046Z	▲  Next-On-Pages-Vercel-CLI CLI 29.3.0-next-on-pages-fix-3 2023-05-20T19:34:16.60216Z	▲  Installing dependencies... 2023-05-20T19:34:17.239028Z	▲  npm 2023-05-20T19:34:17.239372Z	▲  WARN config tmp This setting is no longer used.  npm stores temporary files in a special 2023-05-20T19:34:17.239564Z	▲  npm WARN 2023-05-20T19:34:17.239705Z	▲  config location in the cache, and they are managed by 2023-05-20T19:34:17.23982Z	▲  npm WARN config 2023-05-20T19:34:17.240219Z	▲  [cacache](http://npm.im/cacache). 2023-05-20T19:34:19.203141Z	▲  up to date in 2s 2023-05-20T19:34:19.203632Z	▲  264 packages are looking for funding 2023-05-20T19:34:19.203799Z	▲  run npm fundfor details 2023-05-20T19:34:19.217253Z	▲  Detected Next.js version: 13.4.2 2023-05-20T19:34:19.228098Z	▲  Detectedpackage-lock.json generated by npm 7+... 2023-05-20T19:34:19.228607Z	▲  Running "npm run build" 2023-05-20T19:34:19.878461Z	▲  npm 2023-05-20T19:34:19.878832Z	▲   2023-05-20T19:34:19.87909Z	▲  WARN config tmp This setting is no longer used.  npm stores temporary files in a special 2023-05-20T19:34:19.879293Z	▲  npm WARN config location in the cache, and they are managed by 2023-05-20T19:34:19.87944Z	▲  npm 2023-05-20T19:34:19.879584Z	▲  WARN config     [cacache](http://npm.im/cacache). 2023-05-20T19:34:19.898122Z	▲  ><EMAIL_ADDRESS>build 2023-05-20T19:34:19.898402Z	▲  > next build 2023-05-20T19:34:20.340436Z	▲  - info Loaded env from /opt/buildhome/repo/.env 2023-05-20T19:34:20.635348Z	▲  - warn Invalid next.config.js options detected: 2023-05-20T19:34:20.635777Z	▲  - warn     The root value has an unexpected property, future, which is not in the list of allowed properties (amp, analyticsId, assetPrefix, basePath, cleanDistDir, compiler, compress, configOrigin, crossOrigin, devIndicators, distDir, env, eslint, excludeDefaultMomentLocales, experimental, exportPathMap, generateBuildId, generateEtags, headers, httpAgentOptions, i18n, images, modularizeImports, onDemandEntries, optimizeFonts, output, outputFileTracing, pageExtensions, poweredByHeader, productionBrowserSourceMaps, publicRuntimeConfig, reactStrictMode, redirects, rewrites, sassOptions, serverRuntimeConfig, skipMiddlewareUrlNormalize, skipTrailingSlashRedirect, staticPageGenerationTimeout, swcMinify, target, trailingSlash, transpilePackages, typescript, useFileSystemPublicRoutes, webpack). 2023-05-20T19:34:20.636055Z	▲  - warn See more info here: https://nextjs.org/docs/messages/invalid-next-config 2023-05-20T19:34:20.636526Z	▲  - warn You have enabled experimental feature (serverComponentsExternalPackages) in next.config.js. 2023-05-20T19:34:20.636715Z	▲  - warn Experimental features are not covered by semver, and may cause unexpected or broken application behavior. Use at your own risk. 2023-05-20T19:34:20.636897Z	▲   2023-05-20T19:34:20.673864Z	▲  Attention: Next.js now collects completely anonymous telemetry regarding usage. 2023-05-20T19:34:20.674356Z	▲  This information is used to shape Next.js' roadmap and prioritize features. 2023-05-20T19:34:20.674756Z	▲  You can learn more, including how to opt-out if you'd not like to participate in this anonymous program, by visiting the following URL: 2023-05-20T19:34:20.674961Z	▲  https://nextjs.org/telemetry 2023-05-20T19:34:20.816745Z	▲  - info Creating an optimized production build... 2023-05-20T19:34:42.948063Z	▲  Failed to compile. 2023-05-20T19:34:42.948774Z	▲  ./node_modules/next-auth/core/init.js:10:14 2023-05-20T19:34:42.948955Z	▲  Module not found: Can't resolve 'crypto' 2023-05-20T19:34:42.949098Z	▲   2023-05-20T19:34:42.949211Z	▲  https://nextjs.org/docs/messages/module-not-found 2023-05-20T19:34:42.949341Z	▲   2023-05-20T19:34:42.949562Z	▲  Import trace for requested module: 2023-05-20T19:34:42.949695Z	▲  ./node_modules/next-auth/core/index.js 2023-05-20T19:34:42.94981Z	▲  ./node_modules/next-auth/next/index.js 2023-05-20T19:34:42.949917Z	▲  ./node_modules/next-auth/index.js 2023-05-20T19:34:42.950022Z	▲  ./src/app/api/auth/[...nextauth]/route.js 2023-05-20T19:34:42.950211Z	▲  ./node_modules/next/dist/build/webpack/loaders/next-edge-app-route-loader/index.js?absolutePagePath=private-next-app-dir%2Fapi%2Fauth%2F%5B...nextauth%5D%2Froute.js&page=%2Fapi%2Fauth%2F%5B...nextauth%5D%2Froute&appDirLoader=bmV4dC1hcHAtbG9hZGVyP25hbWU9YXBwJTJGYXBpJTJGYXV0aCUyRiU1Qi4uLm5leHRhdXRoJTVEJTJGcm91dGUmcGFnZT0lMkZhcGklMkZhdXRoJTJGJTVCLi4ubmV4dGF1dGglNUQlMkZyb3V0ZSZwYWdlUGF0aD1wcml2YXRlLW5leHQtYXBwLWRpciUyRmFwaSUyRmF1dGglMkYlNUIuLi5uZXh0YXV0aCU1RCUyRnJvdXRlLmpzJmFwcERpcj0lMkZvcHQlMkZidWlsZGhvbWUlMkZyZXBvJTJGc3JjJTJGYXBwJmFwcFBhdGhzPSUyRmFwaSUyRmF1dGglMkYlNUIuLi5uZXh0YXV0aCU1RCUyRnJvdXRlJnBhZ2VFeHRlbnNpb25zPXRzeCZwYWdlRXh0ZW5zaW9ucz10cyZwYWdlRXh0ZW5zaW9ucz1qc3gmcGFnZUV4dGVuc2lvbnM9anMmYmFzZVBhdGg9JmFzc2V0UHJlZml4PSZuZXh0Q29uZmlnT3V0cHV0PSZwcmVmZXJyZWRSZWdpb249IQ%3D%3D&nextConfigOutput=&preferredRegion=! 2023-05-20T19:34:42.950389Z	▲   2023-05-20T19:34:42.950593Z	▲  ./node_modules/next-auth/core/lib/csrf-token.js:8:14 2023-05-20T19:34:42.950727Z	▲  Module not found: Can't resolve 'crypto' 2023-05-20T19:34:42.95084Z	▲   2023-05-20T19:34:42.95095Z	▲  https://nextjs.org/docs/messages/module-not-found 2023-05-20T19:34:42.951079Z	▲   2023-05-20T19:34:42.951242Z	▲  Import trace for requested module: 2023-05-20T19:34:42.951367Z	▲  ./node_modules/next-auth/core/init.js 2023-05-20T19:34:42.951481Z	▲  ./node_modules/next-auth/core/index.js 2023-05-20T19:34:42.951705Z	▲  ./node_modules/next-auth/next/index.js 2023-05-20T19:34:42.951829Z	▲  ./node_modules/next-auth/index.js 2023-05-20T19:34:42.951936Z	▲  ./src/app/api/auth/[...nextauth]/route.js 2023-05-20T19:34:42.95205Z	▲  ./node_modules/next/dist/build/webpack/loaders/next-edge-app-route-loader/index.js?absolutePagePath=private-next-app-dir%2Fapi%2Fauth%2F%5B...nextauth%5D%2Froute.js&page=%2Fapi%2Fauth%2F%5B...nextauth%5D%2Froute&appDirLoader=bmV4dC1hcHAtbG9hZGVyP25hbWU9YXBwJTJGYXBpJTJGYXV0aCUyRiU1Qi4uLm5leHRhdXRoJTVEJTJGcm91dGUmcGFnZT0lMkZhcGklMkZhdXRoJTJGJTVCLi4ubmV4dGF1dGglNUQlMkZyb3V0ZSZwYWdlUGF0aD1wcml2YXRlLW5leHQtYXBwLWRpciUyRmFwaSUyRmF1dGglMkYlNUIuLi5uZXh0YXV0aCU1RCUyRnJvdXRlLmpzJmFwcERpcj0lMkZvcHQlMkZidWlsZGhvbWUlMkZyZXBvJTJGc3JjJTJGYXBwJmFwcFBhdGhzPSUyRmFwaSUyRmF1dGglMkYlNUIuLi5uZXh0YXV0aCU1RCUyRnJvdXRlJnBhZ2VFeHRlbnNpb25zPXRzeCZwYWdlRXh0ZW5zaW9ucz10cyZwYWdlRXh0ZW5zaW9ucz1qc3gmcGFnZUV4dGVuc2lvbnM9anMmYmFzZVBhdGg9JmFzc2V0UHJlZml4PSZuZXh0Q29uZmlnT3V0cHV0PSZwcmVmZXJyZWRSZWdpb249IQ%3D%3D&nextConfigOutput=&preferredRegion=! 2023-05-20T19:34:42.952176Z	▲   2023-05-20T19:34:42.952281Z	▲  ./node_modules/next-auth/core/lib/email/signin.js:8:14 2023-05-20T19:34:42.952382Z	▲  Module not found: Can't resolve 'crypto' 2023-05-20T19:34:42.952485Z	▲   2023-05-20T19:34:42.952623Z	▲  https://nextjs.org/docs/messages/module-not-found 2023-05-20T19:34:42.952734Z	▲   2023-05-20T19:34:42.952837Z	▲  Import trace for requested module: 2023-05-20T19:34:42.952939Z	▲  ./node_modules/next-auth/core/routes/signin.js 2023-05-20T19:34:42.95304Z	▲  ./node_modules/next-auth/core/routes/index.js 2023-05-20T19:34:42.953166Z	▲  ./node_modules/next-auth/core/index.js 2023-05-20T19:34:42.95327Z	▲  ./node_modules/next-auth/next/index.js 2023-05-20T19:34:42.953371Z	▲  ./node_modules/next-auth/index.js 2023-05-20T19:34:42.953471Z	▲  ./src/app/api/auth/[...nextauth]/route.js 2023-05-20T19:34:42.953599Z	▲  ./node_modules/next/dist/build/webpack/loaders/next-edge-app-route-loader/index.js?absolutePagePath=private-next-app-dir%2Fapi%2Fauth%2F%5B...nextauth%5D%2Froute.js&page=%2Fapi%2Fauth%2F%5B...nextauth%5D%2Froute&appDirLoader=bmV4dC1hcHAtbG9hZGVyP25hbWU9YXBwJTJGYXBpJTJGYXV0aCUyRiU1Qi4uLm5leHRhdXRoJTVEJTJGcm91dGUmcGFnZT0lMkZhcGklMkZhdXRoJTJGJTVCLi4ubmV4dGF1dGglNUQlMkZyb3V0ZSZwYWdlUGF0aD1wcml2YXRlLW5leHQtYXBwLWRpciUyRmFwaSUyRmF1dGglMkYlNUIuLi5uZXh0YXV0aCU1RCUyRnJvdXRlLmpzJmFwcERpcj0lMkZvcHQlMkZidWlsZGhvbWUlMkZyZXBvJTJGc3JjJTJGYXBwJmFwcFBhdGhzPSUyRmFwaSUyRmF1dGglMkYlNUIuLi5uZXh0YXV0aCU1RCUyRnJvdXRlJnBhZ2VFeHRlbnNpb25zPXRzeCZwYWdlRXh0ZW5zaW9ucz10cyZwYWdlRXh0ZW5zaW9ucz1qc3gmcGFnZUV4dGVuc2lvbnM9anMmYmFzZVBhdGg9JmFzc2V0UHJlZml4PSZuZXh0Q29uZmlnT3V0cHV0PSZwcmVmZXJyZWRSZWdpb249IQ%3D%3D&nextConfigOutput=&preferredRegion=! 2023-05-20T19:34:42.953736Z	▲   2023-05-20T19:34:42.953842Z	▲  ./node_modules/next-auth/core/lib/utils.js:10:14 2023-05-20T19:34:42.953944Z	▲  Module not found: Can't resolve 'crypto' 2023-05-20T19:34:42.954044Z	▲   2023-05-20T19:34:42.954144Z	▲  https://nextjs.org/docs/messages/module-not-found 2023-05-20T19:34:42.95433Z	▲   2023-05-20T19:34:42.954436Z	▲  Import trace for requested module: 2023-05-20T19:34:42.954655Z	▲  ./node_modules/next-auth/core/init.js 2023-05-20T19:34:42.954795Z	▲  ./node_modules/next-auth/core/index.js 2023-05-20T19:34:42.954912Z	▲  ./node_modules/next-auth/next/index.js 2023-05-20T19:34:42.955057Z	▲  ./node_modules/next-auth/index.js 2023-05-20T19:34:42.955167Z	▲  ./src/app/api/auth/[...nextauth]/route.js 2023-05-20T19:34:42.955272Z	▲  ./node_modules/next/dist/build/webpack/loaders/next-edge-app-route-loader/index.js?absolutePagePath=private-next-app-dir%2Fapi%2Fauth%2F%5B...nextauth%5D%2Froute.js&page=%2Fapi%2Fauth%2F%5B...nextauth%5D%2Froute&appDirLoader=bmV4dC1hcHAtbG9hZGVyP25hbWU9YXBwJTJGYXBpJTJGYXV0aCUyRiU1Qi4uLm5leHRhdXRoJTVEJTJGcm91dGUmcGFnZT0lMkZhcGklMkZhdXRoJTJGJTVCLi4ubmV4dGF1dGglNUQlMkZyb3V0ZSZwYWdlUGF0aD1wcml2YXRlLW5leHQtYXBwLWRpciUyRmFwaSUyRmF1dGglMkYlNUIuLi5uZXh0YXV0aCU1RCUyRnJvdXRlLmpzJmFwcERpcj0lMkZvcHQlMkZidWlsZGhvbWUlMkZyZXBvJTJGc3JjJTJGYXBwJmFwcFBhdGhzPSUyRmFwaSUyRmF1dGglMkYlNUIuLi5uZXh0YXV0aCU1RCUyRnJvdXRlJnBhZ2VFeHRlbnNpb25zPXRzeCZwYWdlRXh0ZW5zaW9ucz10cyZwYWdlRXh0ZW5zaW9ucz1qc3gmcGFnZUV4dGVuc2lvbnM9anMmYmFzZVBhdGg9JmFzc2V0UHJlZml4PSZuZXh0Q29uZmlnT3V0cHV0PSZwcmVmZXJyZWRSZWdpb249IQ%3D%3D&nextConfigOutput=&preferredRegion=! 2023-05-20T19:34:42.955391Z	▲   2023-05-20T19:34:42.955494Z	▲  ./node_modules/oauth/lib/oauth.js:1:12 2023-05-20T19:34:42.955627Z	▲  Module not found: Can't resolve 'crypto' 2023-05-20T19:34:42.955733Z	▲   2023-05-20T19:34:42.955834Z	▲  https://nextjs.org/docs/messages/module-not-found 2023-05-20T19:34:42.955934Z	▲   2023-05-20T19:34:42.956036Z	▲  Import trace for requested module: 2023-05-20T19:34:42.956135Z	▲  ./node_modules/oauth/index.js 2023-05-20T19:34:42.956235Z	▲  ./node_modules/next-auth/core/lib/oauth/client-legacy.js 2023-05-20T19:34:42.956337Z	▲  ./node_modules/next-auth/core/lib/oauth/authorization-url.js 2023-05-20T19:34:42.956438Z	▲  ./node_modules/next-auth/core/routes/signin.js 2023-05-20T19:34:42.956558Z	▲  ./node_modules/next-auth/core/routes/index.js 2023-05-20T19:34:42.956666Z	▲  ./node_modules/next-auth/core/index.js 2023-05-20T19:34:42.956777Z	▲  ./node_modules/next-auth/next/index.js 2023-05-20T19:34:42.956885Z	▲  ./node_modules/next-auth/index.js 2023-05-20T19:34:42.956987Z	▲  ./src/app/api/auth/[...nextauth]/route.js 2023-05-20T19:34:42.957307Z	▲  ./node_modules/next/dist/build/webpack/loaders/next-edge-app-route-loader/index.js?absolutePagePath=private-next-app-dir%2Fapi%2Fauth%2F%5B...nextauth%5D%2Froute.js&page=%2Fapi%2Fauth%2F%5B...nextauth%5D%2Froute&appDirLoader=bmV4dC1hcHAtbG9hZGVyP25hbWU9YXBwJTJGYXBpJTJGYXV0aCUyRiU1Qi4uLm5leHRhdXRoJTVEJTJGcm91dGUmcGFnZT0lMkZhcGklMkZhdXRoJTJGJTVCLi4ubmV4dGF1dGglNUQlMkZyb3V0ZSZwYWdlUGF0aD1wcml2YXRlLW5leHQtYXBwLWRpciUyRmFwaSUyRmF1dGglMkYlNUIuLi5uZXh0YXV0aCU1RCUyRnJvdXRlLmpzJmFwcERpcj0lMkZvcHQlMkZidWlsZGhvbWUlMkZyZXBvJTJGc3JjJTJGYXBwJmFwcFBhdGhzPSUyRmFwaSUyRmF1dGglMkYlNUIuLi5uZXh0YXV0aCU1RCUyRnJvdXRlJnBhZ2VFeHRlbnNpb25zPXRzeCZwYWdlRXh0ZW5zaW9ucz10cyZwYWdlRXh0ZW5zaW9ucz1qc3gmcGFnZUV4dGVuc2lvbnM9anMmYmFzZVBhdGg9JmFzc2V0UHJlZml4PSZuZXh0Q29uZmlnT3V0cHV0PSZwcmVmZXJyZWRSZWdpb249IQ%3D%3D&nextConfigOutput=&preferredRegion=! 2023-05-20T19:34:42.957445Z	▲   2023-05-20T19:34:42.957577Z	▲  > Build failed because of webpack errors 2023-05-20T19:34:43.028501Z	▲  Error: Command "npm run build" exited with 1 2023-05-20T19:34:43.065641Z	 2023-05-20T19:34:43.065963Z	⚡ The Vercel build (npx vercel build) command failed. For more details see the Vercel logs above. 2023-05-20T19:34:43.066148Z	⚡ If you need help solving the issue, refer to the Vercel or Next.js documentation or their repositories. 2023-05-20T19:34:43.066296Z	 2023-05-20T19:34:43.11737Z	Failed: build command exited with code: 1 2023-05-20T19:34:43.964072Z	Failed: error occurred while running build command

2023-05-20T19:34:42.948774Z	▲  ./node_modules/next-auth/core/init.js:10:14
2023-05-20T19:34:42.948955Z	▲  Module not found: Can't resolve 'crypto'

That is a build error coming from the Vercel CLI when trying to build your Next.js project. It is caused by next-auth trying to import the Node.js crypto module. The edge runtime uses WebCrypto, which is different, and we have no control over the errors that occur when Vercel builds your Next.js app.
Next Auth is notoriously not compatible with the edge runtime, so I'm afraid you probably won't have much luck building a Next.js app targetting the edge runtime if you use Next Auth. ☹ You could try migrating to their new Auth.js library from the same team.

2023-05-20T19:34:42.948774Z	▲  ./node_modules/next-auth/core/init.js:10:14
2023-05-20T19:34:42.948955Z	▲  Module not found: Can't resolve 'crypto'

That is a build error coming from the Vercel CLI when trying to build your Next.js project. It is caused by next-auth trying to import the Node.js crypto module. The edge runtime uses WebCrypto, which is different, and we have no control over the errors that occur when Vercel builds your Next.js app.
Next Auth is notoriously not compatible with the edge runtime, so I'm afraid you probably won't have much luck building a Next.js app targetting the edge runtime if you use Next Auth. ☹ You could try migrating to their new Auth.js library from the same team.

hours I am googling and trying to solve it, you make it short, Thanks, buddy

Closing this as I believe it's been solved (@karapy feel free to reopen it if you think that it's not actually solved)
Thanks for the support @james-elicx ❤

Do you guys plan to fix this, running in the same issue?


Add tests for nonexistent channels

These duly fail if oragono/oragono#165 is reverted.

Nice, these are awesome!


Want version 4 Ukraine:)

This program does not bound to any specific country. Ukrainian ISP mostly use IP-based blocks, not DPI.


feat: standardize params/query api

BREAKING CHANGE: query is an instance of URLSearchParams (search querystrings)
Standardizes params and query for Request handlers, Document Head, and useLocation()
params is a Record<string,string> (pathname slugs)
Catchall routes will not have a trailing slash, even if there is one

Closes #2351
Closes #2290
Closes #2293

useLocation hook query doesn't have anything in production mode. It just has a {} value. I'm not sure what the problem is but it's working in dev mode. All trailingHash and configurations are the same.


[Schema Registry] Fix release date

Fixes date format in changelog entry.

/check-enforcer override


Public contiguity checking

This PR contains:
plot.py:

minor changes to function names, just for clarity
if a user tries to plot an unmasked discontiguous array, they now get a warning with advice on how to fix this rather than an error

test_2d_coords.py:

changed a class name to something more appropriate
moved some tests from Test_2d_coords_bound_mode to new class TestContiguityChecking
Added minimal set of tests to TestContiguityChecking

util.py:

new function find_discontiguity()
new_function mask_discontiguity()

Enjoy!

I can already see that I could do with making these changes:

change test_2d_coords.py class name 'Test_2d_coords_bound_mode' to camel case
add test for multiple discontiguities (as stated in TODO which is left in there)

@lbdreyer The changes I made for the last commit prompted numpy to give me this warning:
"FutureWarning: Using a non-tuple sequence for multidimensional indexing is deprecated; use arr[tuple(seq)] instead of arr[seq]. In the future this will be interpreted as an array index, arr[np.array(seq)], which will result either in an error or a different result."
I'm not exactly sure what it's referring to, I have a horrible feeling it's something to do with the zip output, and that's been a really horrible nightmare to put into a user-friendly return format.
We will obviously have to address this at some point, but I could do with your help with it I think.

Changes following last review:

find_discontiguities now returns a boolean array, not a dictionary (although it was not simple, thank you very much)
make_bounds_discontiguous_at_point now broadcasts the discontiguity mask properly to handle cubes with more than 2 dimensions
mask_discontiguities also broadcasts the 2d mask to data arrays with more than 2 dimensions
temporary tests have been updated to check that the broadcasting works

@lbdreyer All tests passed.  What do you think?

Had some trouble with make_bounds_discontiguous_at_point here.  If you use full2d_global (which is just sample_2d_latlons(transformed=True), some of the points become miniscule and therefore the differences between bottom-left bound and bottom-right bound are also miniscule.
I have been finding that many coordinate points from full2d_global (such as (0, 0) and (3, 2)) are so small that the discontiguity created by make_bounds_discontiguous_at_point is well below the default absolute tolerance in find_discontiguities_in_bounds.
This is possibly a good test for a relative tolerance option though...

@lbdreyer I'm slightly worried about bits still being a problem, particularly test data.  But for now, I'm afraid this is the best you're gonna get.  Thanks for all your help and good luck getting to the finish with this.

Hi @corinnebosley @lbdreyer
:+1: for good stuff + progress made
However, discussing today with @lbdreyer I'm still not very sure about the API.
We could easily combine these two functions now.
Or, we could make the 'apply fixes' one into a more general "apply_mask" operation.  But in that case it should work with a general mask input, for which purpose a boolean array is not good because the dimensions to apply it to are unknown.
So actually, ideally, I think that result should be wrapped as a cube containing coords, so that the 2d mask can be mapped to the dimensions it applies to.
It also seems to me that this should be automatically checking the x- and y-coords of a given cube, or every use will be calling it twice ??
Rather more seriously ... I'm wondering now where + why we need this ??
If we haven't an immediate use within the collected test data, then I'm not interested + this gets low priority.
I'll go looking ...

@pp-mo Rather more seriously ... I'm wondering now where + why we need this

Forget that -- I found out why today !

... and consider #3105 while getting this fixed.

Stuff still to do:

Add a sentence to the iris.plot._check_bounds_contiguity_and_mask error message recommending usage of iris.util.find_discontiguities
Check appropriateness of examples in docstring for iris.util.find_discontiguities
Add test for iris.util.mask_discontiguities y-direction discontiguity
Get rtol test passing in iris.tests.unit.util.test_find_discontiguities

@pp-mo Still have to remove all references to discontiguity from iris.util.mask_cube.  Sorry, forgot...

@pp-mo I have now removed all references to discontiguity in iris.util.mask_cube, but I'd like you to check the words in the docstring for me please because I'm not sure if they're quite right.
Thanks!

iris.util.mask_cube ... I'd like you to check the words in the docstring

Looks fine to me :smiley: !


implement Base-compatible download API

Codecov Report

Merging #14 into master will decrease coverage by 7.11%.
The diff coverage is 61.76%.

@@            Coverage Diff             @@
##           master      #14      +/-   ##
==========================================
- Coverage   96.29%   89.17%   -7.12%
==========================================
  Files           5        5
  Lines         216      231      +15
==========================================
- Hits          208      206       -2
- Misses          8       25      +17

Impacted Files
Coverage Δ

src/Download.jl
71.42% <61.76%> (-19.75%)
:arrow_down:

src/Curl/utils.jl
68.18% <0.00%> (-27.28%)
:arrow_down:

Continue to review full report at Codecov.

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


[chore](Java UDF)remove the error code and add the copy jar

Proposed changes
Issue Number: close #xxx
Problem summary
Describe your changes.
Checklist(Required)

[ ] Does it affect the original behavior
[ ] Has unit tests been added
[ ] Has document been added or modified
[ ] Does it need to update dependencies
[ ] Is this PR support rollback (If NO, please explain WHY)

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

run buildall

TeamCity pipeline, clickbench performance test result:
the sum of best hot time: 33.95 seconds
stream load tsv:          432 seconds loaded<PHONE_NUMBER>9 Bytes, about 165 MB/s
stream load json:         21 seconds loaded<PHONE_NUMBER> Bytes, about 107 MB/s
stream load orc:          60 seconds loaded<PHONE_NUMBER> Bytes, about 17 MB/s
stream load parquet:          31 seconds loaded 861443392 Bytes, about 26 MB/s
https://doris-community-test-1308700295.cos.ap-hongkong.myqcloud.com/tmp/20230510095620_clickbench_pr_141694.html


[proposal] Request for roadmap to support W3C V2 Verifiable Credential Data Model

Is your feature request related to a problem? Please describe.
As I understand it, Veramo currently only supports the W3C V1 Verifiable Credential Data Model (VCDM) via the credential-w3c package. Is there or will there be intent to support the V2 VCDM?
Describe the solution you'd like
We would like to see support for the W3C V2 Verifiable Credential Data Model in Veramo, either through an update to the existing credential-w3c package or by creating a new package specifically for V2 VCDM support.
Describe alternatives you've considered
As an alternative, we are considering creating our own plugin to support the V2 VCDM and maintaining it ourselves. However, we believe it would be beneficial for the Veramo community to have native support for the latest W3C standards.
Additional context
While the V2 VCDM is still in draft, we believe it would be beneficial for the Veramo community to have a roadmap for supporting the W3C V2 Verifiable Credential Data Model once it is finalised. This will help keep Veramo up-to-date with the latest standards and ensure compatibility with other systems and libraries that will likely adopt the new model.

Great you brought up this subject @ashleythedeveloper 🙌
I'm a software engineer of the Gaia-X Lab team and we are basing most of our work on verifiable data.
We use Sphereon's SSI-SDK to implement OpenID Connect for Verifiable Credentials compatibility and this relies on the Veramo Framework. As this issue states, we are using VCDM v2.0 but Veramo isn't compatible with it at the moment.
I think that supporting this data model is something that would be interesting to have out-of-the-box for the community so I will try to raise a pull request about this 😊 (Note to self) We mustn't forget that the project documentation needs to be updated too.

Thanks @vincentkelleher,
Our team is currently in the process of extending Veramo to facilitate the issuance of compliant W3C V2 Verifiable Credentials.
I believe the only thing we have left to do is to update the Data Integrity Cryptographic Suite to support eddsa-rdfc-2022 suite.
Once we have, we can document the changes we have made and point you to a reference implementation.

That's awesome @ashleythedeveloper 👍
I'm just wondering if the remaining updates should be done separately they are not critical to using VCDM v2.0 ? For example, in our case we use VC-JWT as an enveloping proof 😇

Good point @vincentkelleher.
Let's aim to have the changes we have made document by the end of next week, along with a link to the reference implementation for the community to review.
We would also be interested in knowing about your approach to facilitating the enveloping proof mechanism as this is also something we would like to support but based on our research, we will need to modify some libraries, which we plan to do within the month.

@ashleythedeveloper don't hesitate to contact me if you need some help on this task 😉
About the enveloping proof, we are currently just making sure everything works correctly between our modules and we will then externalize everything in a specific library to facilitate VC-JWT creation and verification through DIDs 😊

@vincentkelleher, sorry for the delay. This fell off my radar...
I will have the changes documented by the end of the week.

Changes made to Veramo core and dependencies to support W3C v2 VCDM:

Dependency
Original repo
Forked repo
Justification for the modifications
Explanation of changes
Commit link

digitalcredentials/vc
https://github.com/digitalcredentials/vc
https://github.com/gs-gs/vc
The library force using the VCDM V1
- Add VCDM V2 context  Update validation of context must contain VCDM V1 or VCDM V2 context  - Update validation of status to suitable with V1 and V2
- https://github.com/gs-gs/vc/commit/345624c69a90e7bfbd5f0833d26c8e12549b33f1  - https://github.com/gs-gs/vc/commit/bfad762b7eca4de7a035d7c159f7a719b1480e27  - https://github.com/gs-gs/vc/commit/f3fef99cf77945ea4252dea362112c05383529dc

credential-status
https://github.com/uport-project/credential-status
https://github.com/gs-gs/credential-status
The library can't adapt with credentialStatus V2 data model
- Update to adapt with the credentialStatus V1 and V2 data model  - Add the logic to validate the credentialStatus as an array
- https://github.com/gs-gs/credential-status/commit/e2d96f54799fce33df70981b0dc67b9af69c5bfe  - https://github.com/gs-gs/credential-status/commit/d7dcd114d1df36747a924aeef4f3f9972b722309

veramo
https://github.com/decentralized-identity/veramo
https://github.com/gs-gs/veramo
The credential-w3c plugin force using the VCDM V1
- Update the credential-w3c plugin to adapt with the VCDM V1 and VCDM V2  - Update the credential-ld plugin to allow using the VCDM V2 context or VCDM V1 context  - Update dependency for credential-status
- https://github.com/gs-gs/veramo/commit/304aee59d9d2bb713f3387126ca42a28eac9905b  - https://github.com/gs-gs/veramo/commit/2749bae3aecdf53519f672990e321998b07fdf99  - https://github.com/gs-gs/veramo/commit/4c3f38f95d5f4739a7262a8d1d4a02380e923a38

Plugins created to support issuing compliant v2 VCDM credentials:

Credential router - TBA
API validation - TBA
Credential status (bitstring status)
DI proof crypto suite - TBA
KMS (enveloping proof) - TBA

Reference implementation to issue compliant W3C v2 VCDM credentials (In progress) - VCkit


Add env command

jmundrawala@seamundrawala01 ~/workspace/chef-dk (jdm/chef-env●●)$ bundle exec chef env
---
ChefDK Environment:
  ChefDK Home: "/Users/jmundrawala/.chefdk"
  Path:
  - "/opt/chefdk/"
  - "/Users/jmundrawala/.gem/ruby/2.1.0/bin"
  - "/opt/chefdk/"
  - "/Users/jmundrawala/.rbenv/versions/2.1.2/lib/ruby/gems/2.1.0/bin"
  - "/Users/jmundrawala/.rbenv/versions/2.1.2/bin"
  - "/usr/local/Cellar/rbenv/0.4.0/libexec"
  - "/Users/jmundrawala/.local/bin"
  - "/Users/jmundrawala/go/bin"
  - "/Users/jmundrawala/.rbenv/shims"
  - "/usr/local/bin"
  - "/usr/local/sbin"
  - "/usr/bin"
  - "/bin"
  - "/usr/sbin"
  - "/sbin"
  - "/opt/X11/bin"
  - "/Users/jmundrawala/.yadr/bin"
  - "/Users/jmundrawala/.yadr/bin/yadr"
  Gem Environment:
    GEM ROOT: "/Users/jmundrawala/.rbenv/versions/2.1.2/lib/ruby/gems/2.1.0"
    GEM HOME: "/Users/jmundrawala/.gem/ruby/2.1.0"
    GEM PATHS:
    - "/Users/jmundrawala/.rbenv/versions/2.1.2/lib/ruby/gems/2.1.0"
    - "/Users/jmundrawala/.gem/ruby/2.1.0"
  Policyfile Config:
    Cache Path: "/Users/jmundrawala/.chefdk/cache"
    Storage Path: "/Users/jmundrawala/.chefdk/cache/cookbooks"

cc @danielsdeleo

This is pretty rad. Only thing maybe to add would be versions of ruby, gems, and chef-dk, possibly some platform data, like in gem env:
  - RUBYGEMS VERSION: 2.4.6
  - RUBY VERSION: 2.1.5 (2014-11-13 patchlevel 273) [x86_64-darwin14.0]
# snip..
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86_64-darwin-14

Just trying to think if this might be more useful as a debug tool with that stuff (?)

This looks good. Probably don't have to go overboard with testing, but it would be good to make sure it at least doesn't throw an exception when you run it.

Added more info, did some reorganizing, and added a spec.
new output:
---
Chef Development Kit:
  ChefDK:
    ChefDK Version: 0.6.0
    ChefDK Home: "/Users/jmundrawala/.chefdk"
    Policyfile Config:
      Cache Path: "/Users/jmundrawala/.chefdk/cache"
      Storage Path: "/Users/jmundrawala/.chefdk/cache/cookbooks"
  Ruby:
    Ruby Executable: "/Users/jmundrawala/.rbenv/versions/2.1.2/bin/ruby"
    Ruby Version: 2.1.2
    RubyGems:
      RubyGems Version: 2.4.4
      RubyGems Platforms:
      - ruby
      - x86_64-darwin-13
      Gem Environment:
        GEM ROOT: "/Users/jmundrawala/.rbenv/versions/2.1.2/lib/ruby/gems/2.1.0"
        GEM HOME: "/Users/jmundrawala/.gem/ruby/2.1.0"
        GEM PATHS:
        - "/Users/jmundrawala/.rbenv/versions/2.1.2/lib/ruby/gems/2.1.0"
        - "/Users/jmundrawala/.gem/ruby/2.1.0"
  Path:
  - "/opt/chefdk"
  - "/Users/jmundrawala/.gem/ruby/2.1.0/bin"
  - "/opt/chefdk"
  - "/Users/jmundrawala/.rbenv/versions/2.1.2/lib/ruby/gems/2.1.0/bin"
  - "/Users/jmundrawala/.rbenv/versions/2.1.2/bin"
  - "/usr/local/Cellar/rbenv/0.4.0/libexec"
  - "/Users/jmundrawala/.local/bin"
  - "/Users/jmundrawala/go/bin"
  - "/Users/jmundrawala/.rbenv/shims"
  - "/usr/local/bin"
  - "/usr/local/sbin"
  - "/usr/bin"
  - "/bin"
  - "/usr/sbin"
  - "/sbin"
  - "/opt/X11/bin"
  - "/Users/jmundrawala/.yadr/bin"
  - "/Users/jmundrawala/.yadr/bin/yadr"

:100: :+1: :stars: :star2:

What about ChefDK Install Directory?  Useful?

moving to https://github.com/chef/chef-dk/pull/423


Question about AOT sections used in App Manager

Hi everyone!
When reading Zephyr LVGL example, I noticed that to install the app, the example uses host-tool to send the AOT binary as a request_t (wrapped using init_request) to App Manager.
In target app manager, wasm_app_module_install is eventually called and try to load the payload with wasm_runtime_load_from_sections.
I tried to mimic this flow by generating an AOT version of my WASM code (which runs fine if I use wasm_runtime_load to load the file directly), wrap that using init_request, then call am_dispatch_request() to push the app to App Manager. However, that didn't work out - it reports "AOT module load failed: section missing.".
After inspecting the payload, looks like version and magic number are there, but sections doesn't contain anything.
Looks like there is one step in wasm_runtime_load that actually creates the section_list. Do I need to manually generate the section_list when sending to the App Manager?
Any hint/suggestions would be great!

Hi, the app manager receives WASM file or AOT file which contains sections, the section link list is created by app manager when handing bytes received (ref to wasm_app_module_on_install_request_byte_arrive()), you don't need to create the section list by yourself, but just send the whole WASM file or AOT file as payload to app manager.

Ah okay - I was not sending the AOT file through wasm_app_module_on_install_request_byte_arrive, that's what was missing. Thanks for the reply!


Proto File

Your *.pb.go file is missing.

It isn't missing. This file will be generated by protoc during build. You also can generate it using make protoc command

Just for comparison purpose i am asking you for proto file.

By the way nice example...

I don't get it. There is the only file you need https://github.com/pahanini/go-grpc-bidirectional-streaming-example/blob/master/src/proto/math.proto


[TASK] Decide whether missing dependencies during download should cause warn or error & skip or download / CSCLSROZ-546

ERROR:

importFile:

automation

WARN:

emailSendDefinition:

dataExtension:

triggeredSendDefinition:

query

this was decided and hence closed by #17 which required this decision to be made. missing dependencies are a warning during retrieve and an error during deploy


Regarding the test results of ETH3D

When I used the ETH3D preprocessed dataset provided by PatchMatchNet for measurement, the generated point cloud was extremely sparse. What could be the reason? Is it because of the dataset? Could you provide the ETH3D dataset that you used during testing?

It seems to caused by the incorrect depth range. The last line of the cams.txt provided by PathmatchNet is depth_min depth_max, while the last line of the cams.txt we used is depth_min depth_interval depth_num depth_max. You need to modify the function read_cam_file()  in datasets/eth_ eval.py to read the correct depth range for MVS.

Thank you very much for your reply. I used the colmap2mvsnet.py file in the CasMVSNet network to generate the poses of eth3d. However, it seems that there is a deviation in the position of the generated point cloud, resulting in zero accuracy and completeness for the evaluation results. So could you please provide the corresponding scripts for generating poses?
1228711396
@.***

------------------ 原始邮件 ------------------
发件人:                                                                                "susuwj/EPNet"                                                                                @.>;
发送时间: 2024年11月13日(星期三) 下午4:03
@.>;
<EMAIL_ADDRESS>主题: Re: [susuwj/EPNet] Regarding the test results of ETH3D (Issue #2)
It seems to caused by the incorrect depth range. The last line of the cams.txt provided by PathmatchNet is depth_min depth_max, while the last line of the cams.txt we used is depth_min depth_interval depth_num depth_max. You need to modify the function read_cam_file()  in datasets/eth_ eval.py to read the correct depth range for MVS.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>


Addresses #639

Signed-off-by: Laird Nelson<EMAIL_ADDRESS>

As you can see, this is a draft pull request.


BUG: scipy.sparse.lil_matrix division by complex number leads to inconsistent behavior

Describe your issue.
When dividing a scipy.sparse.lil_array by a complex number, and subsequently trying to convert it to scipy.sparse.csr_array, a TypeError is raised during the conversion.
The same does not happen for other sparse matrix types.
Reproducing Code Example
from scipy import sparse

matrix = sparse.random(10, 10, 0.1, format="lil")
matrix = matrix / 1j
matrix.tocsr()

The above example results in an error, while with format="coo" the following works as expected:
from scipy import sparse

matrix = sparse.random(10, 10, 0.1, format="coo")
matrix = matrix / 1j
matrix.tocsr()

Error message
File ~/.conda/envs/ntcad/lib/python3.11/site-packages/scipy/sparse/_lil.py:474, in lil_matrix.tocsr(self, copy)
    472 data = np.empty(nnz, dtype=self.dtype)
    473 _csparsetools.lil_flatten_to_array(self.rows, indices)
--> 474 _csparsetools.lil_flatten_to_array(self.data, data)
    476 # init csr matrix
    477 return self._csr_container((data, indices, indptr), shape=self.shape)

File _csparsetools.pyx:135, in scipy.sparse._csparsetools.lil_flatten_to_array()

File _csparsetools.pyx:244, in scipy.sparse._csparsetools._lil_flatten_to_array_float64()

TypeError: must be real number, not complex

SciPy/NumPy/Python version and system information
1.10.1 1.23.5 sys.version_info(major=3, minor=11, micro=3, releaselevel='final', serial=0)
lapack_armpl_info:
  NOT AVAILABLE
lapack_mkl_info:
    libraries = ['mkl_rt', 'pthread']
    library_dirs = ['/home/vetschn/.conda/envs/ntcad/lib']
    define_macros = [('SCIPY_MKL_H', None), ('HAVE_CBLAS', None)]
    include_dirs = ['/home/vetschn/.conda/envs/ntcad/include']
lapack_opt_info:
    libraries = ['mkl_rt', 'pthread']
    library_dirs = ['/home/vetschn/.conda/envs/ntcad/lib']
    define_macros = [('SCIPY_MKL_H', None), ('HAVE_CBLAS', None)]
    include_dirs = ['/home/vetschn/.conda/envs/ntcad/include']
blas_armpl_info:
  NOT AVAILABLE
blas_mkl_info:
    libraries = ['mkl_rt', 'pthread']
    library_dirs = ['/home/vetschn/.conda/envs/ntcad/lib']
    define_macros = [('SCIPY_MKL_H', None), ('HAVE_CBLAS', None)]
    include_dirs = ['/home/vetschn/.conda/envs/ntcad/include']
blas_opt_info:
    libraries = ['mkl_rt', 'pthread']
    library_dirs = ['/home/vetschn/.conda/envs/ntcad/lib']
    define_macros = [('SCIPY_MKL_H', None), ('HAVE_CBLAS', None)]
    include_dirs = ['/home/vetschn/.conda/envs/ntcad/include']
Supported SIMD extensions in this NumPy install:
    baseline = SSE,SSE2,SSE3
    found = SSSE3,SSE41,POPCNT,SSE42,AVX,F16C,FMA3,AVX2
    not found = AVX512F,AVX512CD,AVX512_KNL,AVX512_KNM,AVX512_SKX,AVX512_CLX,AVX512_CNL,AVX512_ICL

Thanks for reporting this!
I can verify that the lil_array code for __truediv__ stores the values in an array that is a copy of the original array. So, the dtype is still real and the complex parts get lost when the new value is stored in the real array.
A quick hack-y workaround while we fix this is to make a new complex data array for matrix and then use the in-place division operator on that. It is two steps, but shorter than converting to csr and back again with a matrix.astype call.
matrix.data = matrix.data.astype(np.complex128)  # inplace conversion hack -- so need to fix A._dtype
matrix._dtype = np.complex128
matrix /= 1j

The long term SciPy fix [while avoiding replacing `new = self.copy()` with `new = self.astype(...)` because `astype` converts to `csr format and then back again] could be to use `self.copy()` and then replace the `new.data` array. Something like:
            new = self.copy()
            new_dtype = np.return_type(self.dtype, np.array(other).dtype)
            if new_dtype != self.dtype:
                new.data = new.data.astype(new_dtype)
                new._dtype = new_dtype

If  that feels too hack-y we can go through astype and all its conversions: on line 289 replace new = self.copy() with:
            new = self.astype(np.return_type(self.dtype, np.array(other).dtype))

Preferences?

Hi @dschult!
Thanks for the quick reply and the proposed solutions. IMO the first option seems alright and avoids unnecessary conversions to and from CSR.
I'll open a PR with your proposed changes.


Can't construct TRACKMOUSEEVENT

Does winsafe support creating TRACKMOUSEEVENT?
I get an error related to private fields.
let mut mouse_event = winsafe::TRACKMOUSEEVENT {
  dwFlags: winsafe::co::TME::HOVER | winsafe::co::TME::LEAVE,
  hwndTrack: self.lbl.hwnd(),
  dwHoverTime: 0,
  ..Default::default()
//^^^^^^^^^^^^^^^^^^^^ field `cbSize` is private
};
winsafe::TrackMouseEvent(&mut mouse_event);

let label_events = self.lbl.on_subclass();
label_events.wm_mouse_hover({
  move |params| {
    println!("{},{}", params.coords.x, params.coords.y);
  }
});

I edited my local clone of winsafe to make cbSize public:
#[repr(C)]
pub struct TRACKMOUSEEVENT {
	pub cbSize: u32,
	pub dwFlags: co::TME,
	pub hwndTrack: HWND,
	pub dwHoverTime: u32,
}

This prevented the error, but when I hover the label, the coords are not printed.

You can't use ..Default::default() because there is at least 1 field which doesn't implement the Default trait. Most simple structs will work without problem, but more complex structs need to be initialized with ::default() and then have its fields set:
let mut mouse_event = TRACKMOUSEEVENT::default();
mouse_event.dwFlags = co::TME::HOVER | co::TME::LEAVE;
mouse_event.hwndTrack = self.lbl.hwnd();
mouse_event.dwHoverTime = 0;

This design is intentional. It makes it impossible to have the struct without its cbSize initialized. Also, there are more extreme cases like TASKDIALOGCONFIG – which has mixed fields and two unions, a total nightmare! – where you can't even set the fields directly: you need to use getter and setter methods. All that stuff is needed to keep the struct "safe", in a valid state, which is idiomatic Rust.
As for the mouse tracking thing, see if this example helps you.

I see.  My limited knowledge of Rust was the issue then.
I did check out that example, and it suggests the following code should print "Hovering!" the first time the cursor enters the window, and then stop (until TRACKMOUSEEVENT is called again).
But, nothing happens.
Why?
self.wnd.on().wm_create({
  let self2 = self.clone();
  move |_| {
    let mut mouse_event = TRACKMOUSEEVENT::default();
    mouse_event.dwFlags = co::TME::HOVER | co::TME::LEAVE;
    mouse_event.hwndTrack = self2.wnd.hwnd();
    mouse_event.dwHoverTime = 0;
    winsafe::TrackMouseEvent(&mut mouse_event);
    1
  }
});

self.wnd.on().wm_mouse_hover({
  move |_| {
    println!("Hovering!");
  }
});

Your code is different from the example. The tracking should start in wm_mouse_move, and end in wm_mouse_leave and wm_mouse_hover.
I didn't test the example, but since it's from the official docs, I assume it's correct.

Here is my attempt as replicating that example.
It doesn't work for the label (nothing is printed), using the current winsafe respository.
But it does work for the window, if let label_events = self.lbl.on_subclass(); is erased and all occurences of label_events is replaced with self.wnd.on().
use lazy_static::lazy_static;
use std::sync::Mutex;
use winsafe::{co::TME, gui, TrackMouseEvent, TRACKMOUSEEVENT};

const HOVER_DEFAULT: u32 = 400;

lazy_static! {
    static ref TRACKING: Mutex<bool> = Mutex::new(false);
}

fn main() {
    let my = MyWindow::new();
    my.wnd.run_main(None).unwrap();
}

#[derive(Clone)]
pub struct MyWindow {
    wnd: gui::WindowMain,
    lbl: gui::Label,
}

impl MyWindow {
    pub fn new() -> MyWindow {
        let wnd = gui::WindowMain::new(gui::WindowMainOpts {
            ..Default::default()
        });

        let lbl = gui::Label::new(
            &wnd,
            gui::LabelOpts {
                text: "Hover me!".to_string(),
                ..Default::default()
            },
        );

        let new_self = Self { wnd, lbl };

        new_self.events();
        new_self
    }

    fn track(&self) -> () {
        *TRACKING.lock().unwrap() = true;
    }

    fn reset(&self) -> () {
        *TRACKING.lock().unwrap() = false;
    }

    fn events(&self) {
        let label_events = self.lbl.on_subclass();

        label_events.wm_mouse_move({
            let self2 = self.clone();
            move |_| {
                if !*TRACKING.lock().unwrap() {
                    let mut mouse_event = TRACKMOUSEEVENT::default();
                    mouse_event.dwFlags = TME::HOVER | TME::LEAVE;
                    mouse_event.hwndTrack = self2.wnd.hwnd();
                    mouse_event.dwHoverTime = HOVER_DEFAULT;
                    TrackMouseEvent(&mut mouse_event).unwrap();
                    self2.track();
                }
            }
        });

        label_events.wm_mouse_leave({
            let self2 = self.clone();
            move || {
                println!("Left!");
                self2.reset();
            }
        });

        label_events.wm_mouse_hover({
            let self2 = self.clone();
            move |_| {
                println!("Hovering!");
                self2.reset();
            }
        });
    }
}

Your code is still different from the example. The tracking should start in wm_mouse_move, and end in wm_mouse_leave and wm_mouse_hover.
I'm currently on vacation and away from my computer. I'll be back next week, then I'll try to translate the code from C++ to Rust.

Check this out...
#![cfg_attr(not(debug_assertions), windows_subsystem = "windows")]

use winsafe::{self as w, co, gui};

fn main() {
	let my = MyWindow::new();
	if let Err(e) = my.wnd.run_main(None) {
		eprintln!("{}", e);
	}
}

#[derive(Clone)]
pub struct MyWindow {
	wnd: gui::WindowMain,
	lbl: gui::Label,
}

impl MyWindow {
	pub fn new() -> Self {
		let wnd = gui::WindowMain::new(
			gui::WindowMainOpts {
				class_bg_brush: w::HBRUSH::from_sys_color(co::COLOR::WINDOW),
				..Default::default()
			},
		);

		let lbl = gui::Label::new(
			&wnd,
			gui::LabelOpts {
				text: "Hover me!".to_owned(),
				position: w::POINT::new(50, 50),
				..Default::default()
			},
		);

		let new_self = Self { wnd, lbl };
		new_self.events();
		new_self
	}

	fn events(&self) {
		self.lbl.on_subclass().wm_mouse_move({
			let self2 = self.clone();
			move |p| {
				println!("Hovering {} {}", p.coords.x, p.coords.x);
			}
		});
	}
}


Is there/what is the file extension for the LDA and HDP models?

Just that: is there an extension, and what is it?

There is no official file extension for topic model in tomotopy.
Do we need a file extension? Which one would you like if it is necessary?


is_submitted with multiple forms?

I'm having an issue (maybe related to #140 ) but I'll phrase it as a question.
If I have multiple forms on the same page, how does flask-wtf know which form was submitted and which one wasn't? Basically, I get an error that the form that wasn't submitted complains about a missing CSRF (as the CSRF for that form never came across because it wasn't submitted). While validate_on_submit() doesn't run true, is_submitted() returns true. This leads to two problems:

It tries to validate a form that wasn't submitted (thus complaining about missing fields)
If a form is populated with an initial object, it no longer displays that data as the form thinks it was submitted when it wasn't.

I think a possible solution would be to make the is_submitted() actually know if a form was submitted by checking more than just if the request has a POST or PUT. It could check to make sure that the submit field was present, or even add a hidden field which a unique name and see if that came across.

Is there a fix or workaround for this issue? (or how did you manage the problem? )
I have stumbled on the exact same problem for 2 days!

The best solution is one form one action URL. But if you must submit two forms to one action URLs, you should detect which form are you using yourself. e.g.
Here is an example:
<form>
  <input type="hidden" name="form-name" value="form1">
</form>

<form>
  <input type="hidden" name="form-name" value="form2">
</form>

def some_view():
    form1 = SomeForm()
    form2 = AnotherForm()
    if request.method == 'POST':
        form_name = request.form['form-name']
        if form_name == 'form1':
            form1.validate()
            ...
    ...

@harrisonmetz - I have a use case for multiple forms in a single view too.
I am working on a solution that would be elegant and correct if possible.
Probably going to end up as external library subclassing over flask_wtf.Form.
I will give update on my progress.
If you already have a solution that would require less boilerplate code placed directly in the view than @lepture's, I'd be thankful if you could share it somewhere. :)

Here's my solution for having two forms on one page.
def some_view():     form1 = SomeForm()     form2 = AnotherForm()     submitted = form1 if form1.field.data else form2     if(submitted.validate_on_submit()):         # do some stuff here
Hope this is what you're looking for.


Release 1.5.2

Hey @brucealdridge,
Would it be possible to create release 1.5.2 to publish latest changes?
Thanks!

done

Thanks @brucealdridge