Unable to start itorch session

I installed iTorch as per instructions here https://github.com/facebook/iTorch
But whenever I try to start a kernel I get the following error
gtm2122@GABRIEL:~/distro/iTorch$ itorch
Torch 7.0  Copyright (C) 2001-2011 Idiap, NEC Labs, NYU
Invalid argument (tcp_address.cpp:161)
/home/gtm2122/distro/install/bin/itorch_launcher: line 24:  8582 Aborted                 (core dumped) "$LUA" -e "arg={'$1','$IO_STDO','$IO_PORTNUM'};require 'itorch.IOHandler'"
Invalid argument (tcp_address.cpp:161)
Traceback (most recent call last):
File "/usr/local/bin/jupyter-console", line 11, in
sys.exit(main())
File "/usr/local/lib/python2.7/dist-packages/jupyter_core/application.py", line 267, in launch_instance
return super(JupyterApp, cls).launch_instance(argv=argv, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/traitlets/config/application.py", line 657, in launch_instance
app.initialize(argv)
File "", line 2, in initialize
File "/usr/local/lib/python2.7/dist-packages/traitlets/config/application.py", line 87, in catch_config_error
return method(app, *args, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/jupyter_console/app.py", line 137, in initialize
self.init_shell()
File "/usr/local/lib/python2.7/dist-packages/jupyter_console/app.py", line 110, in init_shell
client=self.kernel_client,
File "/usr/local/lib/python2.7/dist-packages/traitlets/config/configurable.py", line 412, in instance
inst = cls(*args, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/jupyter_console/ptshell.py", line 251, in init
self.init_kernel_info()
File "/usr/local/lib/python2.7/dist-packages/jupyter_console/ptshell.py", line 305, in init_kernel_info
raise RuntimeError("Kernel didn't respond to kernel_info_request")
RuntimeError: Kernel didn't respond to kernel_info_request

fixed

Fixed where? I am facing the same issue, and the last commit on the public GitHub repo ist from October 2016, but your fix is from December 2016.


Stack with Repository doesnt rebuild Dockerfile with

Before you start please confirm the following.

[X] Yes, I've searched similar issues on GitHub.
[X] Yes, I've checked whether this issue is covered in the Portainer documentation or knowledge base.

Problem Description

[2.19.0] Private git repository stack update webhook failing #10235
After successfully creating a stack from a private git repo, trying to pull and redeploy the stack using the GitOps webhook URL results in an authentication error despite the git credentials previously working to create the stack.

Problem with relative path deployment and the use of webhooks #11083
Im deploying my project using relative paths (building the image directly from composer "in real time" using my repo src code what is awesome), but when I try to use any GitOps updated (webhooks / fetch interval) on this stack (to force rebuild [...]

Additionally I can't even use Pull & Redeoploy to update the docker image and yes i have enabled Re-pull image and redeploy
The commit is up to date, but the docker image isn't
I need to kill the container and remove the image.
docker-compose.yml
version: "3.8"
services:
  db:
    restart: unless-stopped
    pull_policy: always
    image: postgres:16
    volumes:
      - bowling-db:/var/lib/postgresql/data
    environment:
      POSTGRES_PASSWORD: ${DATABASE_PASSWORD}
      POSTGRES_USER: ${DATABASE_USER}

  next:
    restart: unless-stopped
    build:
      context: .
    pull_policy: always
    env_file:
      - stack.env
    depends_on:
      - db

volumes:
  bowling-db:
    driver: local

Expected Behavior
The Image should be rebuild.
Actual Behavior
After initialization an image is created and after each update
Steps to Reproduce

Create NextApp npx create-next-app --example with-docker nextjs-docker
Add Docker Compose with DB (Like in Problem Description)
git add, commit
git push to a private repos
portainer add stack
Build Method: Repository
Add Authentication
Change Content of pages/index.js
git add, commit, push
Pull & Redeploy

Nothing changed
FYI: I don't use this templete from nextJS, but I have a modifed version from their docker file
Portainer logs or screenshots
No response
Portainer version
2.19.4
Portainer Edition
Business Edition (BE/EE) with Starter license
Platform and Version
Docker 25.0.3
OS and Architecture
Ubuntu 22.04.3 LTS (GNU/Linux 5.15.0-92-generic x86_64)
Browser
Brave (Chromium) private Tab
What command did you use to deploy Portainer?
version: "3"
services:
  portainer:
    image: portainer/portainer-ee:latest
    container_name: portainer
    volumes:
      - portainer_data:/data
      - /var/run/docker.sock:/var/run/docker.sock
    restart: unless-stopped

volumes:
  portainer_data:

Additional Information
No response

Hi,
I have just installed the latest Portainer.io update (portainer-ee:2.22.0) on Ubuntu 22.04.4 LTS, and this issue still occurs.
Here are my steps to reproduce the issue:

Create a private GitHub repository

A) Add a Dockerfile with the following content:
FROM ubuntu:latest
RUN apt-get update && apt-get install -y bash
RUN touch test1.txt
CMD ["/bin/bash"]

B) Add a docker-compose.yml:
services:
  mon_service:
    build: .
    container_name: mon_conteneur_bash
    stdin_open: true
    tty: true

Add the repository as a Stack on Portainer.io, with the Enable relative path volumes option checked. (No GitOps updates checked)
Connect to the console of the newly created container, type ls, and confirm that test1.txt is present.
Edit the Dockerfile, changing test1.txt to test2.txt, and push the changes to Git.
In Portainer.io, select the stack, 'pull and redeploy' with the Re-pull image and redeploy option checked.
Reconnect to the console of the redeployed container, type ls, and notice that test2.txt has not been created.

Holy shit this is way to complecated and a bit too hacky
I solved it without a repos
First i build my app with github actions and deploy it to docker
I added the private registry to portainer
Added a stack with online editor
Added watchtower with auth (need to login on the host) which updates my app


ability to validate mnemonics

Hi,
At the moment there is no way to validate individual mnemonics before trying to recover the seed and decodeMnemonic is not available outside the module.
Therefore i am suggesting a public slip39.validateMnemonic(mnemonic: String, wordlist=DEFAULT_WORDLIST) => boolean function similar to the one available in bip39 https://github.com/bitcoinjs/bip39/blob/master/src/index.js#L133. A common (and also my current use case for it) is the ability to validate user input before allowing them to enter the next share.
I could push a pull request to this repo if you like but due to the fact that your dart implementation is the primary one i think this new feature should land there too.

Hi,
You can create a PR and I will implement in the dart code.
Cheers,
Pal

closed via 797b1f80350a1962adfff9c3acf1b10e5ca36576


iOS devices

Hello, does this lib works on ios devices?
Thanks

Not on an iphone until safari 18 (like from a few months ago)
https://webkit.org/blog/15865/webkit-features-in-safari-18-0/


Support NextJS 13

Hello,
I am upgrading a project from NextJS12 to NextJs13 and there is an error concerning this package.
When I add a new Icon the application throws an error
<Icon icon="mdi:facebook" className="w-5 h-5"/>
error -<EMAIL_ADDRESS>(1795:54) @ eval error - TypeError: Class extends value undefined is not a constructor or null     at eval (webpack-internal:///(sc_server)/./node_modules/@iconify/react/dist/iconify.js:1643:55)     at<EMAIL_ADDRESS>(E:\JEEBIE.ME\Projets\OCLR\oc-lr.com - V2\.next\server\app\sites\[subdomain]\page.js:828:1)     at __webpack_require__ (E:\JEEBIE.ME\Projets\OCLR\oc-lr.com - V2\.next\server\webpack-runtime.js:33:42)     at eval (webpack-internal:///(sc_server)/./components/common/Footer.tsx:6:72)     at Object.(sc_server)/./components/common/Footer.tsx (E:\JEEBIE.ME\Projets\OCLR\oc-lr.com - V2\.next\server\app\sites\[subdomain]\page.js:764:1)     at __webpack_require__ (E:\JEEBIE.ME\Projets\OCLR\oc-lr.com - V2\.next\server\webpack-runtime.js:33:42)     at eval (webpack-internal:///(sc_server)/./app/sites/[subdomain]/layout.tsx:13:83)     at Object.(sc_server)/./app/sites/[subdomain]/layout.tsx (E:\JEEBIE.ME\Projets\OCLR\oc-lr.com - V2\.next\server\app\sites\[subdomain]\page.js:742:1)            at __webpack_require__ (E:\JEEBIE.ME\Projets\OCLR\oc-lr.com - V2\.next\server\webpack-runtime.js:33:42)     at Object.layout (webpack-internal:///(sc_server)/./node_modules/next/dist/build/webpack/loaders/next-app-loader.js?name=app%2Fsites%2F%5Bsubdomain%5D%2Fpage&appPaths=%2Fsites%2F%5Bsubdomain%5D%2Fpage&pagePath=private-next-app-dir%2Fsites%2F%5Bsubdomain%5D%2Fpage.tsx&appDir=E%3A%5CJEEBIE.ME%5CProjets%5COCLR%5Coc-lr.com%20-%20V2%5Capp&pageExtensions=tsx&pageExtensions=ts&pageExtensions=jsx&pageExtensions=js&rootDir=E%3A%5CJEEBIE.ME%5CProjets%5COCLR%5Coc-lr.com%20-%20V2&isDev=true&tsconfigPath=tsconfig.json!:28:129) {   type: 'TypeError',   page: '/sites/[subdomain]' }
I am using

"next": "^13.0.2"
"react": "^18.2.0"
"@iconify/react": "^4.0.0"

Thanks for reporting!
I think I found what's causing conflict. Try installing @iconify/react@next, please tell me if it solves issue.

Hello,
I just upgraded to @latest version.
There is still the same error but not at the same line on the iconify.mjs file ;)
error -<EMAIL_ADDRESS>(1791:28) @ eval error - TypeError: Class extends value undefined is not a constructor or null     at eval (webpack-internal:///(sc_server)/./node_modules/@iconify/react/dist/iconify.mjs:1657:64)     at<EMAIL_ADDRESS>(E:\JEEBIE.ME\Projets\OCLR\oc-lr.com - V2\.next\server\app\sites\[subdomain]\page.js:3940:1)     at __webpack_require__ (E:\JEEBIE.ME\Projets\OCLR\oc-lr.com - V2\.next\server\webpack-runtime.js:33:42)     at eval (webpack-internal:///(sc_server)/./components/common/Footer.tsx:6:72)     at Object.(sc_server)/./components/common/Footer.tsx (E:\JEEBIE.ME\Projets\OCLR\oc-lr.com - V2\.next\server\app\sites\[subdomain]\page.js:775:1)     at __webpack_require__ (E:\JEEBIE.ME\Projets\OCLR\oc-lr.com - V2\.next\server\webpack-runtime.js:33:42)     at eval (webpack-internal:///(sc_server)/./app/sites/[subdomain]/layout.tsx:13:83)     at Object.(sc_server)/./app/sites/[subdomain]/layout.tsx (E:\JEEBIE.ME\Projets\OCLR\oc-lr.com - V2\.next\server\app\sites\[subdomain]\page.js:753:1)            at Function.__webpack_require__ (E:\JEEBIE.ME\Projets\OCLR\oc-lr.com - V2\.next\server\webpack-runtime.js:33:42)     at processTicksAndRejections (node:internal/process/task_queues:96:5) {   type: 'TypeError',   page: '/sites/[subdomain]' }

Edit: I just labeled the component using the Icons with "use client" and there is no error anymore.
The problem was the component was a server component and rendered on the server, which is incompatible with @iconify in it's basic usage as I understand.

I think you've misread my message. Please try @next, not @latest. It includes a possible fix for that error message.
Though error about .mjs file is weird. That should not be happening at all.

I have this version installed
"@iconify/react": "^4.0.1-beta.1"
The error message still appears when I do not add "use client" on top of component.
I created a wrapper component to use the Icon like before
"use client"
import { Icon as BaseIcon, IconProps } from "@iconify/react";

const Icon:React.FunctionComponent<IconProps> = (props) => <BaseIcon {...props} />
export default Icon

Thanks. This is weird error message. In .js file Rollup created wrapper for require(), which could have been causing issues, but in .mjs file there is nothing that could trigger error: imports are all correct. I'll debug it.

I've debugged this. Component works correctly with NextJS 13 without any issues.
I've also reverted change to see if I'll get that error message, didn't get it. So I can't replicate issue. Using basic app created with pnpm create next-app, which created package with NextJS 13.0.3

I created a repository to show you the bug :
https://github.com/bfourgeaud/iconify-next13-bug
It has two pages /error and /success to show you how this error occurs

Thanks a lot!
Now I'm seeing that bug and can debug it. This is very helpful!

I'm very confused. In your code React.Component does not exist.
Icon component is fine. It uses React in intended way, but something else is messing with it. Somewhere in build process React package seem to be reduced.
These is everything that is exported from React using import React from 'react'; console.log(Object.keys(React));:
[
  'Children',
  'Fragment',
  'Profiler',
  'StrictMode',
  'Suspense',
  '__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED',
  'cache',
  'cloneElement',
  'createElement',
  'createRef',
  'createServerContext',
  'forwardRef',
  'isValidElement',
  'lazy',
  'memo',
  'startTransition',
  'use',
  'useCallback',
  'useContext',
  'useDebugValue',
  'useId',
  'useMemo',
  'version'
]

These are keys I get when importing React in my demo app:
[
  'Children',
  'Component',
  'Fragment',
  'Profiler',
  'PureComponent',
  'StrictMode',
  'Suspense',
  '__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED',
  'cloneElement',
  'createContext',
  'createElement',
  'createFactory',
  'createRef',
  'forwardRef',
  'isValidElement',
  'lazy',
  'memo',
  'startTransition',
  'unstable_act',
  'useCallback',
  'useContext',
  'useDebugValue',
  'useDeferredValue',
  'useEffect',
  'useId',
  'useImperativeHandle',
  'useInsertionEffect',
  'useLayoutEffect',
  'useMemo',
  'useReducer',
  'useRef',
  'useState',
  'useSyncExternalStore',
  'useTransition',
  'version'
]

It is missing the following keys:
[
  'Component',
  'PureComponent',
  'createContext',
  'createFactory',
  'unstable_act',
  'useDeferredValue',
  'useEffect',
  'useImperativeHandle',
  'useInsertionEffect',
  'useLayoutEffect',
  'useReducer',
  'useRef',
  'useState',
  'useSyncExternalStore',
  'useTransition'
]

So something is messing with React in your code. I don't know what is doing that.

One more weird thing: I've installed React 18.2.0. It is installed correctly, I've checked files. However, in component when logging React.version, it returns 18.3.0-next-4bd245e9e-20221104. So there seem to be a second React instance somewhere, probably that's the bugged one.

React is imported from this file: node_modules/next/dist/compiled/react/index.js, however, that file contains everything, including Component, but for some reason it does not exist in imported file.
I suspect Webpack is to blame here.

The missing keys seems to be the one that you can't use anymore in Server Components, but only in Client Components (marked with "use client" at the top). That's just an idea.
Fyi, the project was simply created with npx create-next-app@latest

added the app/ and components/ folders
Edited next.config.js to use the new appDir
deleted unused files in pages/ folder
Created the files and folders in app/ and components/

I can't find anything in Next documentation that states that class components are not allowed.

When I console log React keys from IconWrapper.tsx it shows all the correct keys
"use client"
import { Icon as BaseIcon, IconProps } from "@iconify/react";

import React from 'react';

const Icon:React.FunctionComponent<IconProps> = (props) => {
  console.log(Object.keys(React));
  return <BaseIcon {...props} />
}
export default Icon

[
    "Children",
    "Component",
    "Fragment",
    "Profiler",
    "PureComponent",
    "StrictMode",
    "Suspense",
    "__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED",
    "cache",
    "cloneElement",
    "createContext",
    "createElement",
    "createFactory",
    "createRef",
    "createServerContext",
    "forwardRef",
    "isValidElement",
    "lazy",
    "memo",
    "startTransition",
    "unstable_act",
    "unstable_useCacheRefresh",
    "use",
    "useCallback",
    "useContext",
    "useDebugValue",
    "useDeferredValue",
    "useEffect",
    "useId",
    "useImperativeHandle",
    "useInsertionEffect",
    "useLayoutEffect",
    "useMemo",
    "useReducer",
    "useRef",
    "useState",
    "useSyncExternalStore",
    "useTransition",
    "version"
]

Indeed. Same when importing it in console. But add this to top of<EMAIL_ADDRESS>console.log('Imported React. Keys:', Object.keys(React));

and it will show short list.

Only Client Components seem to be able to use React.Component.
And for that you have to add "use client" at top of component.
I don't know how to handle that with @iconify package ...
Maybe put IconComponent in a separate file labeled with "use client" ?

With "use client" in component, it throws errors about missing "private-next-rsc-mod-ref-proxy" module.

So it is not Webpack's fault. Found where stuff is missing: React is not being imported from file I've mentioned above, but from ./node_modules/next/dist/compiled/react/cjs/react.shared-subset.development.js and it is missing Component.
Looks like it is by design. But why?

I've reported this as bug to Next repository, including your demo repository: https://github.com/vercel/next.js/issues/43051

Oh well, got response from NextJS team, missing support for class components is by design.
Looks like for now your solution with wrapper component is the only way to make it work.
Another option is to use @iconify-icon/react, but that seems to be bugged too. If I replace all references to @iconify/react to @iconify-icon/react, change wrapper code to this:
"use client";
import { Icon } from "@iconify-icon/react";

export default Icon;

It no longer throws errors. However, is still an issue:

Visiting http://localhost:3000/success works.
Visiting http://localhost:3000/error does not render anything because web component is not bundled.
Visiting http://localhost:3000/, then clicking "Working Wrapper", then clicking back, then clicking "Error Icon" works because web component is provided in /success.

So now there is a different bug: web component not being bundled unless it is wrapped in client-only component.
What a clusterfuck Next13 is.

Reported issue for web component not being bundled, based on your repo: https://github.com/vercel/next.js/issues/43068

Hey! Any updates on this? Are we waiting for the issue to be resolved on their side?

Depends on which part of issue you are referring to.
If using @iconify/react, that is intended by NextJS design. It needs to be wrapped in client side component like in 6th post in this thread.
If using @iconify-icon/react, web component not being bundled is a bug in NextJS and waiting for fix.

I am also facing this issue in my project. By design, NextJS 13 does not support class components when a page is rendered on the server. You need to force the icon component to render on the client, which in my opinion is not a very good thing.

It won't render anything on server side anyway, so forcing it to render on client side doesn't make any difference.
This component works by loading data dynamically from API, which means on first render icon data might not be available, so it doesn't render anything. Data is loaded only on client side.
If you need to render component immediately and on server side, there are different solutions:
unplugin-icons works by rendering it instantly and bundling data at build time.
If you do need dynamic icon data, iconify-icon is a web component that should work fine with NextJS. It renders icon independently from React, so doesn't have to deal with server/client side component shenanigans.

Facing problem with Nextjs 14.
my component code is
            <button className="border-[2px] px-5 py-4 rounded-lg">
              Explore Now <Icon icon="solar:arrow-right-outline" />
            </button>

I found  <iconify-icon icon="solar:arrow-right-outline"></iconify-icon> in element devtool.. but no shadow dom inside web component.
this tread also going for a long... if there any possible solution which gonna work ?

You probably forgot to import iconify-icon (or @iconify-icon/react if you are using React wrapper), so web component didn't get bundled.

In browser console type customElements.get('iconify-icon')
It should return class for web component. If it doesn't return it, web component is not bundled.

Did some more testing, found a possible issue why it might not always work in Next, published @iconify-icon/react version 2.0.1 with potential fix.

Did some more testing, found a possible issue why it might not always work in Next, published @iconify-icon/react version 2.0.1 with potential fix.

Thank you good sir. "@iconify-icon/react": "^2.1.0" works with  "next": "14.2.1" flawlessly.

Published new version of @iconify/react that is compatible with Next.js.
Currently available as @iconify/react@next. It is a full rewrite of icon component, so need to do more testing before can mark it as stable, but so far works fine in my tests.
Long overdue.

Completed. Version 5 works correctly with Next


Fix typo (Jetbrains to JetBrains)

Issue

N/A

Overview (Required)

Fix typo "Jetbrains"

Links

https://www.jetbrains.com/

Screenshot
N/A

eagle eyes :eagle: LGTM!

Thanks 🤗

you're welcome 🤗


Make logs easy for users

We don't want logs to become a stumbling block for user's trying to evaluate the software. We've seen a few people w AWS (in particular) run w the default cluster only to have logs fill up their disks and cause problems.
So, this is a beacon issue to make sure we make this as easy as possible.
Some ideas we have:

Instructions / configuration scripts for enabling logging w vendor toolchains (e.g. GCP cloud logging, AWS ???)

This depends on the availability of these tools (I'm not familiar w the AWS version for instance) and the amount we can configure them on behalf of our users. Or if we can't configure them, we can at least document how to enable these services.
There is some concern that not all providers will have this tooling.

Optionally provide our own logging service module (as part of our k8s manifest) to spin up a logging service that is cloud provider independent

This would have the advantage that it would be provider agnostic. However, the logs do need to get stored somewhere, so we'd probably want to make sure they're in a RRD or something.
The downside to this is that we don't want to be in the business of maintaining / debugging / scaling logging services.

Tactical improvements for users to control the size of the logs
#987
#988

We now have our logging module which can be spun up with make logging in our repo.
It deploys a number of manifests to whatever kubernetes cluster it finds with kubectl, adding this into pachctl would make things even easier for users since they wouldn't have to clone our repo to get the stack.

Additionally, we discussed how the UI would consume logs either via the pachctl get-logs API or a logging service.

stale


feat(pkg/console): support interactive console

This PR introduces the support for interactive console
requires teamhephy/controller#148
Using a github.com/gorilla/websocket we access the k8s API in order to create an interactive console with a container like so:
deis apps:create testadminapp5 --no-remote
Creating Application... done, created testadminapp5
If you want to add a git remote for this app later, use `deis git:remote -a testadminapp5`

deis config:set PORT=5000 --app=testadminapp5
Creating config... done

=== testadminapp5 Config
PORT      5000

deis builds:create igiannoulas/sample-flask-app:v0.1.2 --procfile="{web: python3 app/app.py}" --app=testadminapp5
Creating build... done

deis ps:list -a testadminapp5
=== testadminapp5 Processes
--- web:
testadminapp5-web-6f5b688cb9-jw2wb up (v3)

deis ps:console testadminapp5-web-6f5b688cb9-jw2wb web testadminapp5 /bin/sh --debug=true
Starting console session with command /bin/sh for pod testadminapp5-web-6f5b688cb9-jw2wb for application testadminapp5
INFO[0000] [Start] Container name: testadminapp5-web
INFO[0000] [RoundTrip] Url: wss://<IP_ADDRESS>:8443/api/v1/namespaces/testadminapp5/pods/testadminapp5-web-6f5b688cb9-jw2wb/exec?stdout=true&tty=true&command=/bin/sh&container=testadminapp5-web&stdin=true
INFO[0000] [RoundTrip] Decoded token: eyJhbGciOi ... 4vekvJFY_w
# ls
Dockerfile  bin   etc   lib64  opt               root  srv  usr
Procfile    boot  home  media  proc              run   sys  var
app         dev   lib   mnt    requirements.txt  sbin  tmp
# ps faux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root        28  0.0  0.0   4504   704 pts/0    Ss   14:20   0:00 /bin/sh
root       106  0.0  0.0  34424  2840 pts/0    R+   14:25   0:00  \_ ps faux
root         1  0.0  0.3  76128 25892 ?        Ss   14:18   0:00 python3 app/app
root         8  0.3  0.3<PHONE_NUMBER>4 ?        Sl   14:18   0:01 /usr/bin/python

The console package introduced required the token that is obtained via teamhephy/controller#148
The console is not as reliable as e.g. an ssh client as controls are not passed (e.g. CTR+D, arrow keys etc) and it requires to type exit and hit enter to quit, but it provides a way of accessing the containers without the kubectl superpowers.

This looks good. See comment in the other PR:  https://github.com/teamhephy/controller/pull/148#issuecomment-880334521
Let me know your thoughts.


Is it possible a malicious app to steal user app private key via deep links?

Hi,
I'm worried about the scenario below and would like to get your help. I'm not sure it's possible and how to prevent it.

A user installs a malicious app and click sign in from it.
The malicious app sends an auth request to an authenticator app with an app domain name it wants to steal the app private key. Also the malicious app declares support opening a link of the app domain name via deep links.
The user doesn't notice/aware differences in logo and name on sign in page and proceed further.
The authenticator app redirects an auth response to the app domain name. As a genuine app is not installed, there is a popup for user to choose how to open the link between a web browser app and the malicious app. As user's not aware, they choose the malicious app.
The malicious app who also has a corresponding transit key can decrypt the auth response and get user's app private key and user's app data.

This scenario wouldn't happen on web authentication because only on mobile, any apps can declare support opening any links. So always redirect to the app domain name is not guarantee that only the genuine app will get the auth response.
In the other hand, if it's not a malicious app and a user really knows about it, I guess, this is a feature. It's user's data so it's user's choice. They can allow any apps to access their any app private keys and their data.
I don't know if we can prevent it while allowing between-app communication. I can't find any other ways.
Any thoughts would be appreciated. Thank you very much.

Hi @witwitchayakarn,
sadly the scenario you described is indeed possible.
Since Circles is new we had to make sure we had retro-compatibility with all existing apps otherwise we would not be supporting any app at all, this (sadly) can create vulnerabilities that can be exploited. But those always existed, a rooted phone even web authentication is not safe, a malicious authenticator can also be created...
There's also the argument that it can be seen as a feature, non-official Android apps for popular web-apps can start emerge for instance. In the scenario you described there's at least 2 instances where the user can stop and make sure what is doing is safe and he/she is comfortable with that decision, and while we can make sure we disclaim this more information more visibly, it can happen.
In our grant we suggested "Become a third-party Android app store" to avoid malicious apps, we also would like to have a way for users to register their official app packages in their manifests but its something we need to discuss with the community. If you want to address this or other concerns maybe you can a look at https://github.com/blockstack/ux/issues/961 and helps us creating the most secure solution.

"I don't know if we can prevent it while allowing between-app communication."

Yes we can, and intend to allow more secure ways when using the Android-SDK. But those will not have retro-compatibility and for that reason are in future goals.

Hi @Filmaluco,
Thanks a lot for the reply. It's very unfortunate, indeed.
I'll close this issue and keep watching this repo and those two repos you mentioned.
If I can be of any help, please let me know. Thank you again. :pray:


No video in Bacterial Growth

https://juliadynamics.github.io/AgentsExampleZoo.jl/dev/examples/growing_bacteria/

Relevant error in doc build
┌ Warning: failed to run `@example` block in src/examples/growing_bacteria.md:234-241
│ ```@example growing_bacteria
│ abm_video(
│     "bacteria.mp4", model, agent_step!, model_step!;
│     am = cassini_oval, ac = bacteria_color,
│     spf = 50, framerate = 30, frames = 200,
│     title = "Growing bacteria"
│ )
│ ```
│   c.value =
│    MethodError: no method matching length(::Observables.Observable{Vector{Polygon{2, Float32, GeometryBasics.Point{2, Float32}, GeometryBasics.LineString{2, Float32, GeometryBasics.Point{2, Float32}, Base.ReinterpretArray{GeometryBasics.Line{2, Float32}, 1, Tuple{GeometryBasics.Point{2, Float32}, GeometryBasics.Point{2, Float32}}, GeometryBasics.TupleView{Tuple{GeometryBasics.Point{2, Float32}, GeometryBasics.Point{2, Float32}}, 2, 1, Vector{GeometryBasics.Point{2, Float32}}}, false}}, Vector{GeometryBasics.LineString{2, Float32, GeometryBasics.Point{2, Float32}, Base.ReinterpretArray{GeometryBasics.Line{2, Float32}, 1, Tuple{GeometryBasics.Point{2, Float32}, GeometryBasics.Point{2, Float32}}, GeometryBasics.TupleView{Tuple{GeometryBasics.Point{2, Float32}, GeometryBasics.Point{2, Float32}}, 2, 1, Vector{GeometryBasics.Point{2, Float32}}}, false}}}}}})
│    Closest candidates are:
│      length(!Matched::Union{Base.KeySet, Base.ValueIterator}) at /opt/hostedtoolcache/julia/1.7.1/x64/share/julia/base/abstractdict.jl:58
│      length(!Matched::Union{Tables.AbstractColumns, Tables.AbstractRow}) at ~/.julia/packages/Tables/M26tI/src/Tables.jl:175
│      length(!Matched::Union{DataStructures.OrderedRobinDict, DataStructures.RobinDict}) at ~/.julia/packages/DataStructures/vSp4s/src/ordered_robin_dict.jl:86
│      ...
└ @ Documenter.Expanders ~/.julia/packages/Documenter/qdbx6/src/Expanders.jl:591

I also just encountered this error. The abmvideo seems to work well with only the am = cassini_oval option or ac = bacteria_color option, but using both am = cassini_oval, ac = bacteria_color gives an error.

I ran into the exact same issue too!

I've removed the example from the docs until we fix this.

@Datseris Lots of references/links to this example in the docs and I didn't realize until now that it's not just that the links were broken, but that the example was completely removed. Maybe the page that the links direct to should have a note there that the example was temporarily removed to fix some bugs?

Oh yeah, well, maybe its a good time to try and actually fix this. Can you open a PR that re-enables this example? And maybe try to see if locally it works for you?


Remove support of Amazon Dynamo DB

Unfortunately usage of https://s3-us-west-2.amazonaws.com/dynamodb-local/release Maven repository became problematic because of following reasons:

Amazon blocks users from Russia.
Roscomnadzor periodically blocks Amazon's resources by widely diaps.

It makes builds problematic.

done


Make activation response truncation length configurable

Description
By default activation responses can be 1MB in size and they will be truncated to 1MB in case the size is bigger.
This PR makes the truncation length configurable too. This means that the response size could be configured to 1MB for example, but the truncation length can be 512KB.
The reason for this change is the fact that once the response is truncated, it does not make a lot of sense to store the entire payload to the database.
As an example, for the following configuration:
whisk {
    activation {
        payload {
            max = 512
            truncation = 10
        }
    }
}

the response of a truncated activation result will have the following format:
{
    "error": "The action produced a response that exceeded the allowed length: 600 > 512 bytes. The truncated response was: {\"body\":\"H"
}

and the database will store only 10 bytes of the response.
My changes affect the following components

[ ] API
[ ] Controller
[ ] Message Bus (e.g., Kafka)
[ ] Loadbalancer
[ ] Invoker
[ ] Intrinsic actions (e.g., sequences, conductors)
[x] Data stores (e.g., CouchDB)
[ ] Tests
[ ] Deployment
[ ] CLI
[ ] General tooling
[ ] Documentation

Types of changes

[ ] Bug fix (generally a non-breaking change which closes an issue).
[x] Enhancement or new feature (adds new functionality).
[ ] Breaking change (a bug fix or enhancement which changes existing behavior).

Checklist:

[x] I signed an Apache CLA.
[x] I reviewed the style guides and followed the recommendations (Travis CI will check :).
[x] I added tests to cover my changes.
[ ] My changes require further changes to the documentation.
[ ] I updated the documentation where necessary.

Codecov Report

Merging #4909 into master will decrease coverage by 5.95%.
The diff coverage is 78.26%.

@@            Coverage Diff             @@
##           master    #4909      +/-   ##
==========================================
- Coverage   83.24%   77.28%   -5.96%
==========================================
  Files         201      201
  Lines        9356     9455      +99
  Branches      392      403      +11
==========================================
- Hits         7788     7307     -481
- Misses       1568     2148     +580

Impacted Files
Coverage Δ

...whisk/core/containerpool/AkkaContainerClient.scala
78.72% <50.00%> (ø)

.../containerpool/ApacheBlockingContainerClient.scala
71.66% <50.00%> (+0.48%)
:arrow_up:

...sk/core/containerpool/docker/DockerContainer.scala
95.60% <85.71%> (-0.87%)
:arrow_down:

...pache/openwhisk/core/containerpool/Container.scala
88.50% <100.00%> (+0.85%)
:arrow_up:

.../openwhisk/core/entity/ActivationEntityLimit.scala
100.00% <100.00%> (ø)

...core/database/cosmosdb/RxObservableImplicits.scala
0.00% <0.00%> (-100.00%)
:arrow_down:

...ore/database/cosmosdb/cache/CacheInvalidator.scala
0.00% <0.00%> (-100.00%)
:arrow_down:

...e/database/cosmosdb/cache/ChangeFeedConsumer.scala
0.00% <0.00%> (-100.00%)
:arrow_down:

...core/database/cosmosdb/CosmosDBArtifactStore.scala
0.00% <0.00%> (-96.23%)
:arrow_down:

...sk/core/database/cosmosdb/CosmosDBViewMapper.scala
0.00% <0.00%> (-93.90%)
:arrow_down:

... and 20 more

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 97c9f7a...3d55acc. Read the comment docs.

This is OK but a better approach is to reduce the log limit units from MB to B and then apply lower defaults. We've done this and will open a PR. At which point, I think this knob becomes obsolete in the future (which is OK, just make a note of it).

This is OK but a better approach is to reduce the log limit units from MB to B and then apply lower defaults. We've done this and will open a PR. At which point, I think this knob becomes obsolete in the future (which is OK, just making a note of it).

@rabbah log limits have not been changed, this only refers to truncation for the large activation responses that need to be stored in the database. But even better if log limits and activation payload limits are being take care of in a separate PR 👍


Add citation file

Add a citation file of format CITATION.cff to address issue #691.

How to review
To review, please

Check that the information in the file is corrected
Check that it is formatted correctly (i.e. behaves as is intended)

PR checklist

[x] Continuous integration checks all ✅

~Add or expand tests; coverage checks both~ No change in behaviour.

[ ] Add, expand, or update documentation.

[ ] Update release notes.

Do we need to update https://docs.messageix.org/en/stable/notice.html or the corresponding NOTICE.rst in the main repo? The information there is still correct, we might still want to add a section about using our new file for citation. I don't yet know how to do that, but I could read up on it. However, if you want it done asap and have worked with cff files before, you might want to take on that part.

Good idea @glatterf42! I suggest to add a reference/link to the citation file as an item in the list of section 2.

I think it might be useful to include some version information. Future versions might not be able to reproduce results, so project scientists might want to pinpoint specific versions as the ones that worked for them. On that regard, I've found a Github Action to automatically update the citation file, so we should be able to include this information without needing to worry about manual updates. The only downside is that I haven't really worked with Github Actions yet, so I'll have to spend some time understanding how they work, but then I should be able to adapt this workflow to our needs.
The question would then be: do we want a whole version only or also single commits as they are more accurate?

But the version-information is already included in your workflow/script simply by doing message_ix.version (including the commit hash if you're in a non-release state) - I'm very skeptical of duplicating this information.

On that note, the pyam citation file also contains a version keyword, referencing version 1.0.
I think this is again a matter of what the use case is: I thought we wanted to include this citation file so that people can simply cite MESSAGEix correctly from the main repo e.g. by extracting a Bibtex entry. This entry will only include version information if we put it in the citation file, if I understand correctly.

On that note, the pyam citation file also contains a version keyword, referencing version 1.0.

True, but the pyam-citation refers to the manuscript in Open Research Europe, which is specifically linked to v1.0 of the package. But this could obviously lead to some confusion there, too...

So: in part, I just wanted to see if I could do it. Even if we don't end up using what I cooked up here, I have learned a lot about Github Actions in the process :)
Despite your explanation above, I still think we should include the version information in the citation file. Since we are going to provide one either way, I think this will make citing MESSAGEix much more comfortable. However, in order to be accurate, we then also need to include the commit that the citation is referring to. A current example is that pandas 2.0.0 will abandon some features that are still in use in version 3.6.0 of MESSAGEix, but have been fixes by a more recent commit. Thus, citing version 3.6.0 of MESSAGEix will lead to people being unable to reproduce results because they won't have the fixes included that every recent clone of the main repo has.
Updating the version and commit manually would be tedious, which is why I have written a Github workflow to automatically update them. With this workflow, every new release would trigger another commit that updates the citation file to include the newest version. Each push to the main branch would update the latest commit.
As @phackstock pointed out, this would lead to people not having the latest version of the citation file locally available even if they just pushed to the main branch without running git pull. So, if they were to use the local contents of the file, they might produce an incorrect citation. However, I don't know how frequently this would actually happen. If I understand correctly, the main purpose of CITATION.cff is to provide a citation option directly in the main Github repo. Anyone wanting to cite MESSAGEix might therefore visit our main repo and create e.g. a Bibtex entry with the up-to-date information from there. Furthermore, I think git pull is a quicker alternative. If people want to cite the code locally (and don't already have a script using message_ix.version), they'd either have to write such a script or simply run git pull. And if they already have such a script, the information in there will still be correct.
All in all, I think providing the version and commit information is comfortable, accurate, and not much work with the addition of the workflow.
cc @khaeru

Together with @khaeru, I just noticed that the automatically created Bibtex entry does not contain a lot of information. For starters, it's just one entry, so we can choose for it to be the software entry or the paper entry. Even if we choose the software entry, the only versioning information would be month and year of the "date-released" entry. So I also don't think there's a point to keep them automatically up-to-date for this feature. Maybe some of the other tools could make use of the data, but for now, I removed them from the citation file.
Since I still think the version and commit should be mentioned when citing software, I will adapt the corresponding docs section with how to do that.


GUI - Map Visualization - How to identify the mode (map, hibrid, sattelite) in use?

Why not to distinguish the current map mode is being used? When you click on the icon to change the mode, nothing allows to identify the current mode.

Added radio button to identify the current map mode.


Enable LoRA for DPO

What does this PR do ?
Enable LoRA for DPO
Changelog

Please update the CHANGELOG.md under next version with high level changes in this PR.

Usage

You can potentially add a usage example below

# Add a code snippet demonstrating how to use this

Before your PR is "Ready for review"
Pre checks:

[ ] Make sure you read and followed Contributor guidelines
[ ] Did you write any new necessary tests?
[ ] Did you add or update any necessary documentation? Make sure to also update the NeMo Framework User Guide which contains the tutorials

Checklist when contributing a new algorithm

[ ] Does the trainer resume and restore model state all states?
[ ] Does the trainer support all parallelism techniques(PP, TP, DP)?
[ ] Does the trainer support max_steps=-1 and validation?
[ ] Does the trainer only call APIs defined in alignable_interface.py?
[ ] Does the trainer have proper logging?

Additional Information

Related to # (issue)

@gshennvm Have we tested this PR with our CI to ensure that adding the LoRA code doesn't break the existing DPO tests?

@gshennvm Have we tested this PR with our CI to ensure that adding the LoRA code doesn't break the existing DPO tests?

no -- currently CI is down. But once this PR is good to go I can run it before merge early next week

@gshennvm Have we tested this PR with our CI to ensure that adding the LoRA code doesn't break the existing DPO tests?

no -- currently CI is down. But once this PR is good to go I can run it before merge early next week

Okay sounds good. I'm away next week, but feel free to approve+merge once the CI passes successfully. The code changes in this PR LGTM


feat(Auth): Remove options from API's that are not needed

Description
Removing options parameters when there are no plugin options that exist.
General Checklist

[ ] Added new tests to cover change, if needed
[x] Build succeeds with all target using Swift Package Manager
[x] All unit tests pass
[x] All integration tests pass
[x] Security oriented best practices and standards are followed (e.g. using input sanitization, principle of least privilege, etc)
[ ] Documentation update for the change if required
[ ] PR title conforms to conventional commit style
[ ] New or updated tests include Given When Then inline code documentation and are named accordingly testThing_condition_expectation()
[ ] If breaking change, documentation/changelog update with migration instructions

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

All integration tests passing: https://github.com/aws-amplify/amplify-swift/actions/runs/5479714738


Allow sending FCM notification messages

FCM allows sending "notification messages" and "data messages". These two types of message behave differently when received by a device.
See: Firebase documentation -> Guides -> Cloud Messaging -> About FCM Messages -> Message types
(https://firebase.google.com/docs/cloud-messaging/concept-options#notifications_and_data_messages)
Uniqush should be able to send both types. Right now, only data messages are sent (See function ToCMPayload in https://github.com/uniqush/uniqush-push/blob/master/srv/cloud_messaging/cloud_messaging.go#L165)
Also, it's possible to send hybrid push messages, containing both data and notification information.
=> Add some parameters to /push to handle all types.

FCM notification messages seem to be the same as GCM notification messages. See https://developers.google.com/cloud-messaging/concept-options#notifications_and_data_messages
Doing this in a way that provides a consistent and easy to use API for GCM/FCM and APNS may require some thought, so this fully doing this may or may not be time consuming. (GCM "data" doesn't seem to have special fields, and I haven't yet checked if APNS would have special fields
A good first step would be to support uniqush.data.gcm and uniqush.data.fcm in API calls to /push, which would be similar to uniqush.payload.gcm (name to be determined. uniqush.silent_notification.gcm? uniqush.silent_notification.cloud_messaging?). See https://github.com/uniqush/uniqush-push/blob/317b0884f85080d67da73cb7b8a99551bc02c40a/srv/gcm_test.go#L39-L43

My earlier comment mixed those up. Supported fields are https://firebase.google.com/docs/cloud-messaging/http-server-ref#notification-payload-support
Currently, client apps work around this by creating a notification handler to render the notifications programmatically based on the data.
In the future, it may make sense to change how uniqush handles msg, etc, to be more consistent (e.g. uniqush.version=2 in /push and/or the config). The consistent way would be rendering immediately.

The support for uniqush.notification.gcm and uniqush.notification.fcm (optional fields for /push with rawJSON blobs as values) are documented at https://github.com/uniqush/uniqush-push/pull/185.
Those are merged to master. I'll spot check them before updating the go1 tags and publishing a 2.4.0 release to github.
It isn't documented on uniqush.org yet, I haven't written the changes to uniqush-www yet.

I've built the version and tried it.
The first tests indicate that it's working well. Good job!
We're going to use it in production in the next few days.
I'll let you know if we find any issue. Reading the code, I don't think we will.


US 1583733 Add missing language IDs - 42

US 1583733 - Fix CATS P1 issues by adding missing language IDs to code blocks.

Used "console" for program output displayed on the console.
Used "console" for command-line tool examples.
Used single-tick for Regular Expression pattern examples.

Contributes to #2192

@mairaw I implemented your suggestions in a separate commit. Thanks!

@mairaw All suggested changes have been addressed. This should be ready to merge. Thanks!

Just resolved some merge conflicts. Will re-review soon.

One more thing to address @v-thpra and we're good to merge this one.

@mairaw I added a table to docs/spark/tutorials/databricks-deployment.md  - is that what was intended?

@v-thpra - the table looks good to me. thank you.


Add Kubernetes deployment

Implement Helm charts for easy deployment of Guac on Kubernetes platforms.

I believe @sunnyyip is starting on this!

confirmed!  We are actively working on this.

@sunnyyip Can you update this issue with the work and link to the new helm charts? We can also this issue if that is all done.

GUAC Helm Chart is available at https://github.com/kusaridev/helm-charts/tree/main/charts/guac


[gcov] Fix invalid gcda files

Previously, a null file was created to cover cases where tests were not performed. From the latest gcov version (gcov14), this is treated as an invalid gcda file, resulting in an error. Change to merge the initialized info and test result info.

Origin: https://github.com/nnstreamer/api/commit/d139a4ce812c2210bd6324ab99466c9a6ddbfcd2

:memo: TAOS-CI Version: 1.5.20200925. Thank you for submitting PR #578. Please a submit 1commit/1PR (one commit per one PR) policy to get comments quickly from reviewers. Your PR must pass all verificiation processes of cibot before starting a review process from reviewers. If you are new member to join this project, please read manuals in documentation folder and wiki page. In order to monitor a progress status of your PR in more detail, visit http://ci.nnstreamer.ai/.

:octocat: cibot: @again4you, A builder checker could not be completed because one of the checkers is not completed. In order to find out a reason, please go to http://ci.nnstreamer.ai/nnstreamer-api/ci/repo-workers/pr-checker/578-202411121606090.15475797653198-ae2f690f8606f80b37bb993c690276df8c3921fd/.


Introduction to Numpy

Description 📜
Numpy(numeric python) is a library that consists of multidimensional array objects and a set of routines for processing them. This documentation walks you through the fundamentals of NumPy, including its design and architecture. It also covers array features, creating,indexing , and other topics.
Fixes #434

Type of change 📝

[x] Documentation (Content Creation in the form of codes or tutorials)

Domain of Contribution 📊

[x] Datascience with Python

Checklist ✅

[x] I follow Contributing Guidelines & Code of conduct of this project.
[x] I have performed a self-review of my own code or work.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] My changes generates no new warnings.
[x] I'm GWOC'21 contributor

Screenshots / Gif (Optional) 📸

@prathimacode-hub mam do review this and let me know if it needs any changes or adding more info

@Jivitesh Jain @Arya Patel do review this

@tavneetgill I went through the file and you have put great efforts in compiling the resources for explanation of the Numpy but somethings here and there need to be fixed such as the first cell where you are explaining the installation of Numpy. For example, you could have instead given !pip install numpy --upgrade just in case the user has the library installed then it will check for the update as well. Once make the change I mentioned and figure out rest.

@prathimacode-hub @AryaPatel1111 Please close this pull request as it has lot of conflicts. I have created a new PR #1678 hich contains updated file.


Use MergeTree key when locating rows on key_column IN (subquery) conditions

The issue
Let the following MergeTree table exist:
CREATE TABLE events (
    EventID UInt8,
    EventDate Date,
    ClientID UInt32,
    Payload String
) Engine = MergeTree(EventDate, (EventID, EventDate, ClientID), 8192);

Clickhouse successfully uses MergeTree key for key_column IN (static_list) conditions if key_column belongs to the key:
SELECT ClientID, count(*) FROM events WHERE ClientID IN (1,2,3,4)

But key_column IN (subquery) or key_column GLOBAL IN (subquery) disables key usage and leads to full scan:
SELECT
    ClientID,
    count(*)
FROM events
WHERE
    ClientID IN (
        SELECT DISTINCT ClientID
        FROM events WHERE ClientID IN (1,2,3,4) AND EventDate = today()
    )

SELECT
    ClientID,
    count(*)
FROM events_distributed
WHERE
    ClientID GLOBAL IN (
        SELECT DISTINCT ClientID
        FROM events_distributed WHERE ClientID IN (1,2,3,4) AND EventDate = today()
    )

Expected behavior
It would be great if clickhouse could use MergeTree key when locating rows for key_column IN (subquery) conditions.

Yes, that would be great! Unfortunately this feature requires substantial reworking of the query execution engine. The good news is that we actually plan to do it so stay tuned.

I have created duplicate: https://github.com/yandex/ClickHouse/issues/932

Any updates on this?

Implemented.


CSS and Version always show Default

Just a small bug.
Whenever I switch to a different skin to check them out both CSS and Version show Default.
So I never know exactly which skin I'm on.
Would be handy if they displayed  which skin you are on and which version you chose.  Some of us have bad memories. :)
This could be a Firefox issue maybe?
Great plugin.  Thanks!

Hi, currently the plugin is not saving which option did you choose. Maybe in the next version could be possible to implement it but it might be a little bit tricky. I will try!
Thanks for the suggestion!


[10.x] Adding a Str::initials() method

Adding an initials() method to Illuminate\Support\Str that receives a string and returns an initials representation of that string.
Example:
Joe Pistachio
Joe_Pistachio
Joe-Pistachio
returns
JP
This is especially helpful for things like avatars, user profiles, etc.

This assumes people have two words in their names.
People don't have N names, for any value of N.
https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/

What would happen if a null value or empty string was passed? In other scenarios, what if it wasn't a text string?
On the other hand, you need to create the fluent method inside the Stringable class.

Thanks for your pull request to Laravel!
Unfortunately, I'm going to delay merging this code for now. To preserve our ability to adequately maintain the framework, we need to be very careful regarding the amount of code we include.
If possible, please consider releasing your code as a package so that the community can still take advantage of your contributions!
If you feel absolutely certain that this code corrects a bug in the framework, please "@" mention me in a follow-up comment with further explanation so that GitHub will send me a notification of your response.


casting kernel can combine multi-match patterns

Which issue does this PR close?

Closes #.
Rationale for this change

What changes are included in this PR?

Are there any user-facing changes?

Codecov Report

Merging #883 (63cd2a0) into master (898924f) will decrease coverage by 0.00%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #883      +/-   ##
==========================================
- Coverage   82.45%   82.44%   -0.01%
==========================================
  Files         168      168
  Lines       48231    48138      -93
==========================================
- Hits        39767    39686      -81
+ Misses       8464     8452      -12

Impacted Files
Coverage Δ

arrow/src/compute/kernels/cast.rs
95.08% <100.00%> (+0.45%)
:arrow_up:

arrow/src/datatypes/datatype.rs
65.36% <0.00%> (-0.44%)
:arrow_down:

parquet/src/arrow/array_reader.rs
77.72% <0.00%> (-0.09%)
:arrow_down:

arrow/src/ipc/writer.rs
84.28% <0.00%> (+0.18%)
:arrow_up:

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 898924f...63cd2a0. Read the comment docs.

not backporting as it needs newer rust edition


Create a code style page for contributors

It's always handy for new contributors to have a set of guidelines on how code should be laid out. Everyone has their own personal style and it avoids any difficult conversations being able to point at the guide.

Docstrings, use Google Style, NumPy Style, or just PEP257 + comments - Perhaps leverage napoleon (http://sphinxcontrib-napoleon.readthedocs.io/en/latest/index.html)
Use double quotes in docstrings, start with a line break for multi-line
Method argument naming and casing, e.g. https://github.com/pybee/toga/blob/master/src/core/toga/interface/app.py#L69
PEP8 compliance
Use of linters like pylint
Expectations for unit tests
Specification of __all__ required?
Preference of relative imports v.s. absolute. I can see you prefer relative.
Other pet peeves

Ref #98

FYI we have a yak to try and address some of these things by using https://github.com/pybee/beefore

We also have default PEP8 settings in other BeeWare projects, so we could potentially turn on CI for the sole purpose of running code style checks (until, of course, we actually get unit tests...)

We now enforce PEP8 style with BeeFore, so this should be a non-issue.


Collect memory in the performance script

See each commit for details.

Merging since it's just a helper script to perform a performance test. It's not an automated test and rarely used.


kedro-airflow: Allow passing conf_source to the created DAG

Description
Add --conf-source flag to kedro airflow create which will pass this on to the Jinja template used to generate the DAGs airflow_dag_template.j2
Context
To run a Kedro project as a DAG on airflow currently -

You should package and install your kedro project in the executor env
Copy the config from the Kedro project to the Airflow project folder https://docs.kedro.org/en/stable/deployment/airflow.html#create-prepare-and-package-example-kedro-project
If something changes in the conf, one must also remember to copy over the changes

Additionally,

KedroSession.create() now allows passing conf_source path
kedro package creates a .whl file for the project pipelines etc and a .tar.gz file for the conf/ folder of the project which can be saved elsewhere

Possible Implementation

Add --conf-source to the CLI command which passes this info the Jinja template airflow_dag_template.j2

Possible Alternatives
(Optional) Describe any alternative solutions or features you've considered.

@DimedS: "This change would be quite useful to deploy Kedro to some cloud Airflow because it's sometimes impossible to put configuration in the working directory" (paraphrasing)


The allowlist page of the argoCD does not match the design.

Describe the Bug
A clear and concise description of what the bug is.
The allowlist page of the argoCD does not match the design.
The design is as follow:

For UI issues please also add a screenshot that shows the issue.

Versions Used
KubeSphere: 3.3.0 alpha1

hi @VioZhang , @wenxin-01 is this still a problem now?

hi @VioZhang , @wenxin-01 is this still a problem now?

No, It work well in v3.3.0-rc.0, I will close this issue.


Allow hotkey Ctrl + Enter in SaveDatasetModal

Description
When users are trying to create a new dataset or overwrite a dataset, we should allow them to save via Ctrl + Enter

Closing since it's not a bug, but happy to take up the discussion elsewhere if needed :)


NodePath::get_parent has no function definition

Godot version:

All versions.
(3.3, master c7b97f0)
OS/device including version:

N/A
Issue description:

In node_path.h, there is an unimplemented function:
NodePath get_parent() const;

I expect this function to return the nodepath one node above (Some/Node/Path → Some/Node), but this is not implemented. It should either be implemented or removed.
I believe this is the code to achieve this behavior:
Vector<StringName> names = nodepath.get_names();
names.resize(names.size() - 1);
NodePath parent_path = NodePath(names, nodepath.is_absolute());

And it's like this since forever:

path_db.h,
path_db.cpp.


use_callback should take a closure that accepts an argument

Feature Request
Currently there's no way to pass in an argument to the closure that use_callback wraps. This should be easy enough to add. I think the only reason we didn't add it is to make the type signature of UseCallback a bit more compact, but that's not so important.

since I needed this I've hacked together something that appears to work for me. Let me know if this looks plausible and if so I'll create a PR!

pub fn use_callback1<T, O>(f: impl FnMut(T) -> O + 'static) -> UseCallback1<O, T> {
    // Create a copyvalue with no contents
    // This copyvalue is generic over F so that it can be sized properly
    let mut inner = use_hook(|| CopyValue::new(None));

    // Every time this hook is called replace the inner callback with the new callback
    inner.set(Some(f));

    // And then wrap that callback in a boxed callback so we're blind to the size of the actual callback
    use_hook(|| {
        let cur_scope = current_scope_id().unwrap();
        let rt = Runtime::current().unwrap();

        UseCallback1 {
            inner: CopyValue::new(Box::new(move |arg1| {
                // run this callback in the context of the scope it was created in.
                let run_callback = || inner.with_mut(|f: &mut Option<_>| f.as_mut().unwrap()(arg1));
                rt.on_scope(cur_scope, run_callback)
            })),
        }
    })
}

/// This callback is not generic over a return type so you can hold a bunch of callbacks at once
///
/// If you need a callback that returns a value, you can simply wrap the closure you pass in that sets a value in its scope
#[derive(PartialEq)]
pub struct UseCallback1<O: 'static + ?Sized, T: 'static> {
    inner: CopyValue<Box<dyn FnMut(T) -> O>>,
}

impl<O: 'static + ?Sized, T> Clone for UseCallback1<O, T> {
    fn clone(&self) -> Self {
        Self { inner: self.inner }
    }
}
impl<O: 'static, T: 'static> Copy for UseCallback1<O, T> {}

impl<O, T> UseCallback1<O, T> {
    /// Call the callback
    pub fn call(&self, arg1: T) -> O {
        (self.inner.write_unchecked())(arg1)
    }
}

// This makes UseCallback callable like a normal function
impl<O, T> std::ops::Deref for UseCallback1<O, T> {
    type Target = dyn Fn(T) -> O;

    fn deref(&self) -> &Self::Target {
        // https://github.com/dtolnay/case-studies/tree/master/callable-types

        // First we create a closure that captures something with the Same in memory layout as Self (MaybeUninit<Self>).
        let uninit_callable = MaybeUninit::<Self>::uninit();
        // Then move that value into the closure. We assume that the closure now has a in memory layout of Self.
        let uninit_closure = move |arg1| Self::call(unsafe { &*uninit_callable.as_ptr() }, arg1);

        // Check that the size of the closure is the same as the size of Self in case the compiler changed the layout of the closure.
        let size_of_closure = std::mem::size_of_val(&uninit_closure);
        assert_eq!(size_of_closure, std::mem::size_of::<Self>());

        // Then cast the lifetime of the closure to the lifetime of &self.
        fn cast_lifetime<'a, T>(_a: &T, b: &'a T) -> &'a T {
            b
        }
        let reference_to_closure = cast_lifetime(
            {
                // The real closure that we will never use.
                &uninit_closure
            },
            // We transmute self into a reference to the closure. This is safe because we know that the closure has the same memory layout as Self so &Closure == &Self.
            unsafe { std::mem::transmute(self) },
        );

        // Cast the closure to a trait object.
        reference_to_closure as &_
    }
}


Non PDF Formulas of Wikipedia

https://en.wikipedia.org/w/index.php?title=Convex_hull&action=edit

In fact, according to [[Carathéodory's theorem (convex hull)|Carathéodory's theorem]], if X is a subset of a d-dimensional Euclidean space, every convex combination of finitely many points from X is also a convex combination of at most d+1 points in X. The set of convex combinations of a (d+1)-tuple of points is a [[simplex]]; in the plane it is a [[triangle]] and in three-dimensional space it is a tetrahedron. Therefore, every convex combination of points of X belongs to a simplex whose vertices belong to X, and the third and fourth definitions are equivalent.


Teamdrive support

Hi, I recently found that google add teamdrive support in api v2.
Only several additional parameters are needed in each function.
I have tested the upload and download functions and it works well.
I hope the teamdrive can be support in future version of PyDrive.

I signed it!

Please make sure the Upload function (line 286) of pydrive's files.py file has a self.content.close() in it - if you have a list of files you are uploading, it won't let go of the last one without it.

Hi @rexvt. I can try to get this package published. Would you mind giving me instructions on how to do this via the command line? I'll try to test and publish the latest repo.
@aliafshar As a maintainer of https://pypi.org/project/PyDrive/, can you give https://pypi.org/user/granttimmerman/ (me) maintainer rights?


Goals of project

The first step is to make script to get trace data of collect and share the traces.
I may find ways to provide more traces.

@frodrigo we have a PR in progress to add support for pulling traces from mapillary: https://github.com/OpenStreetMapSpeeds/conflation/pull/1 i suspect we'll get it cleaned up and merged in the next day or two. if you have other sources of traces you should be able to modify the script to add more providers.


Control not rendering during record creation (before first save)

Hi Shivakumar,
Greetings! hope you are doing good.
I tried alot from  my side for fixing the control on create , but couldnt resolve it. Below is the screenshot that describes the exact error I am facing.

can you please help me on the issue.
Regards,
G lakshmi priyanka

Hi,
This is fixed now. Please try with the latest solution and associated code change.
Thanks and regards,
Shivakumar


Proposal: feature flag for float support

Floating point operations are known to be problematic when it comes to determinism. In the blockchain space, we tend to avoid them (and rather use decimal types). At https://github.com/CosmWasm/serde-json-wasm we maintain a fork of this repo that is specialized on WebAssembly and blockchain. I think it would be cool to be able to keep the repos in sync as much as possible.
Since we check all the WebAssembly instructions in the blockchain, they need to be non-existent in the compilation result (no matter if used or not). Would you accept a PR adding a floats feature flag (turned on by default)? This is for sure not a general purpose request. But maybe it is interesting for other users as well that either worry about code size or determinism.

Thinking about this more, it turns out both projects have too different goals to invest in compatibility.
serde-json-wasm's goals:

deterministic serialization (which makes things like maps non-trivial)

serde-json-wasm's non-goals:

no_std compatibility
heaplessness

Very thoughtful proposal, it should be reconsidered.


[flac] Disable stack smash protection and FORTIFY_SOURCE for mingw

Describe the pull request

What does your PR fix? Fixes #
This disables stack protection and FORTIFY_SOURCE on mingw, since it depends on libssp from GCC, which can cause licensing problems since libssp is GPL
Which triplets are supported/not supported? Have you updated the CI baseline?
All mingw triplets
Does your PR follow the maintainer guide?
Yes

Could you please update
file(COPY ${SOURCE_PATH}/COPYING.Xiph DESTINATION ${CURRENT_PACKAGES_DIR}/share/libflac)
file(RENAME ${CURRENT_PACKAGES_DIR}/share/libflac/COPYING.Xiph ${CURRENT_PACKAGES_DIR}/share/libflac/copyright)

as
file(INSTALL ${SOURCE_PATH}/COPYING.Xiph DESTINATION ${CURRENT_PACKAGES_DIR}/share/${PORT} RENAME copyright)?

Done


Update Plot.php

[x] This PR actually submits something - don't use this system as a messaging service!
[x] This PR isn't duplicated - you can check if it is by scanning the small list - link is on the navigation bar for this repository.
[x] This PR includes appropriate markdown for sections - e.g. code blocks for suggested code.
[x] This PR description and comments in code is understandable - feel free to use your native language to write if you are not comfortable with English.
[x] This PR has a single branch for itself in your fork - don't just commit to the master branch of your repository!
[x] This PR has comments written in clear English - please don't write unreadable comments just for your eyes.

Pull Request description
{Type something here}

Optional information
{Type something here}

... no. This isn't how code works at all...


On half of the apps I tried to login with Google, I was met with the error "your browser is not allowed to show popups" and then there's no setting for that anywhere.
Google Meet doesn't work at all, it shows an error and never starts the meeting.
No dark theme in 2023?


Add an opportunity to retry stages several times if it fails

It would be nice to have a retry: property which could specify a number of attempts after stage failure, for example:
  upload-to-github-releases:
    # ...
    retry: 3  # 3 attempts will be made if there are any issues (network, github infra, etc)

This is something we explored in the past, but there are too many technical hurdles to implement which would require significant development effort. I agree it would add some value to Drone, however, I have determined this value is not sufficient enough to justify the implementation cost (in terms of man hours, etc). After careful consideration I have decided to decline this request.


Fix: [Placeholder] Message for simultaneous logins logout on web app

Description
notion card: https://www.notion.so/jwplayer/Placeholder-Message-for-simultaneous-logins-logout-on-web-app-4328d1f4287d4291ab091e79bf49e126
This PR solves # .

Steps completed:

According to our definition of done, I have completed the following steps:

[ ] Acceptance criteria met
[ ] Unit tests added
[ ] Docs updated (including config and env variables)
[ ] Translations added
[ ] UX tested
[ ] Browsers / platforms tested
[ ] Rebased & ready to merge without conflicts
[ ] Reviewed own code

We can go back and forth about the pros and cons of the sequential tests for days, but what I really want to understand is what were the actual bug fixes for the tests that were failing?
Let's scale this PR down to just those and we can take the conversation for how we might make the test scenarios more developer friendly to another forum.

Can you please try to figure out what happened with the snapshots? I can't really review this efficiently with all the no-op changes there. If it's something that the newest version of vitest is adding, please only regenerate the ones that you've actually changed and revert the others, or update all of them and submit that as a separate chore PR.

I reverted the changes 6656ad790806a97b96a1d755a6c8d4c62b0eb497 and i will make new chore pr with updated snapshots.

@borkopetrovicc can you do a quick merge from develop into this branch? I'm still seeing all the test files as having changed.

snapshots?

This has been fixed, and it is still in change request.


Add a newline to a Javadoc sample in KafkaConsumer

This PR simply adds a newline to a Javadoc sample in KafkaConsumer to flush the outputs.

LGTM, thanks!


We need more reviewers

In order for unsandboxed extensions to thrive, we're going to need more people involved in reviewing the extensions. Having everything be bottlenecked on me will not scale.

i will watch the repo (everything ), and help with this

I can provide help, I can do some review, discuss issues, suggest code, just what I've been doing. The only problem is I'm still getting familiar with scratch's internals and vm, so I can't really review something that is closely related to it.

I'll help. however I'm not available most of the time FYI

I can help too. I am familiar with JS and I already developed some extensions. I am actually working on adacraft, but I can help and correct extension.

can i review?

I can help!

There is no need to proclaim yourself as a helper. If you want to help, then do things like test extensions and report any issues, etc. That's how you can actually help.

ah

There is no need to proclaim yourself as a helper. If you want to help, then do things like test extensions and report any issues, etc. That's how you can actually help.

Ok. I will do it.

me

you could make a system where there's a queue for the custom extensions, and all of the custom extensions that are going to get in the queue get checked by some algorithm before letting it in the queue, and once the extension becomes first in the queue, then it gets checked by you and gets uploaded. this should make it so that there are less extensions being moderated by you, as they should have been catched by the algorithm or AI (whatever you want to use). and if you find one that didn't get moderated by the AI correctly, then you can just improve the algorithm and maybe add the extension hash to a blacklist.
And optionally, you can make another section in the extension area saying "Potentially dangerous extensions that are currently being reviewed" which will show all of the extensions that are in the queue and passed the AI test, and will be reviewed by you and the other moderators if there are

you could make a system where there's a queue for the custom extensions, and all of the custom extensions that are going to get in the queue get checked by some algorithm before letting it in the queue, and once the extension becomes first in the queue, then it gets checked by you and gets uploaded. this should make it so that there are less extensions being moderated by you, as they should have been catched by the algorithm or AI (whatever you want to use). and if you find one that didn't get moderated by the AI correctly, then you can just improve the algorithm and maybe add the extension hash to a blacklist. And optionally, you can make another section in the extension area saying "Potentially dangerous extensions that are currently being reviewed" which will show all of the extensions that are in the queue and passed the AI test, and will be reviewed by you and the other moderators if there are

Can you even do that in github?

you could make a system where there's a queue for the custom extensions, and all of the custom extensions that are going to get in the queue get checked by some algorithm before letting it in the queue, and once the extension becomes first in the queue, then it gets checked by you and gets uploaded. this should make it so that there are less extensions being moderated by you, as they should have been catched by the algorithm or AI (whatever you want to use). and if you find one that didn't get moderated by the AI correctly, then you can just improve the algorithm and maybe add the extension hash to a blacklist. And optionally, you can make another section in the extension area saying "Potentially dangerous extensions that are currently being reviewed" which will show all of the extensions that are in the queue and passed the AI test, and will be reviewed by you and the other moderators if there are

Can you even do that in github?

If you are able to automatically edit files or just have it done manually, then yes, it should be possible
(also, now that i have more knowledge of how to make extensions, you could make it so that the "Potentially dangerous extensions" thing includes sandboxed extensions)

I will review extensions for you! I'd love to! I use turbowarp.org a lot, even though I am a web developer (I love the art editor and ease of use for animating). Just let me know and I'd be glad to do it.

I will review extensions for you! I'd love to! I use turbowarp.org a lot, even though I am a web developer (I love the art editor and ease of use for animating). Just let me know and I'd be glad to do it.

There is no need to proclaim yourself as a helper. If you want to help, then do things like test extensions and report any issues, etc. That's how you can actually help.

- https://github.com/TurboWarp/extensions/issues/41#issuecomment-1575246381


don't expect to merge this but want some feedback

Adding some tests to help understand the API and document workings. To run them you'll need a .env file in the root (which will be .gitignored) that has the following:
TOKEN=ur-slack-token-here

You can get a token from the bottom of https://api.slack.com/web
From there you just run npm test to run the tests. (Don't forget to `npm i to get the dev deps.) Things work as you'd expect…but I'm not sure how to close an RTM session. Any help appreciated!

opening a new PR w/ a fix!


test(client): Logging queries using binary engine with mongodb

Integrates: https://github.com/prisma/prisma-engines/pull/3310

Hey @danstarns, I merged https://github.com/prisma/prisma/pull/15957. You can pull the latest changes to the engine and update your branch. Thank you!


[firebase_messaging] pub get fails on v7.0.3 because it depends on an older firebase_core version

Hi please fix the dependency for firebase_messaging on firebase_core, I am currently getting this when I do pub get the newest version:
Because firebase_messaging 7.0.3 depends on firebase_core ^0.5.0+1 and no versions of firebase_messaging match >7.0.3 <8.0.0, firebase_messaging ^7.0.3 requires firebase_core ^0.5.0+1.
So, because 'xxx' depends on both firebase_core ^0.7.0 and firebase_messaging ^7.0.3, version solving failed

in my pubspec i have this :
  cloud_firestore: ^0.16.0
  firebase_auth: ^0.20.0
  firebase_core: ^0.7.0
  firebase_analytics: ^7.0.1
  firebase_crashlytics: ^0.4.0
  firebase_messaging: ^7.0.3

I can confirm this too, I'm seeing the same output after trying to upgrade:
Because firebase_messaging 7.0.3 depends on firebase_core ^0.5.0+1 and no versions of firebase_messaging match >7.0.3 <8.0.0, firebase_messaging ^7.0.3 requires firebase_core ^0.5.0+1.
So, because addiction_counter depends on both firebase_core ^0.7.0 and firebase_messaging ^7.0.3, version solving failed.
pub get failed (1; So, because addiction_counter depends on both firebase_core ^0.7.0 and firebase_messaging ^7.0.3, version solving failed.)

I can confirm this too, I'm seeing the same output after trying to upgrade:
Because firebase_messaging 7.0.3 depends on firebase_core ^0.5.0+1 and no versions of firebase_messaging match >7.0.3 <8.0.0, firebase_messaging ^7.0.3 requires firebase_core ^0.5.0+1.
So, because addiction_counter depends on both firebase_core ^0.7.0 and firebase_messaging ^7.0.3, version solving failed.
pub get failed (1; So, because addiction_counter depends on both firebase_core ^0.7.0 and firebase_messaging ^7.0.3, version solving failed.)

I have the same problem

firebase_core: ^0.7.0
firebase_crashlytics: ^0.4.0
firebase_performance: ^0.5.0+1
firebase_messaging: ^7.0.3
firebase_analytics: ^7.0.1

Because firebase_messaging 7.0.3 depends on firebase_core ^0.5.0+1 and no versions of firebase_messaging match >7.0.3 <8.0.0, firebase_messaging ^7.0.3 requires firebase_core ^0.5.0+1.
So, because x-x-x depends on both firebase_core ^0.7.0 and firebase_messaging ^7.0.3, version solving failed.

I have the same problem

firebase_core: ^0.7.0
firebase_crashlytics: ^0.4.0
firebase_performance: ^0.5.0+1
firebase_messaging: ^7.0.3
firebase_analytics: ^7.0.1

Because firebase_messaging 7.0.3 depends on firebase_core ^0.5.0+1 and no versions of firebase_messaging match >7.0.3 <8.0.0, firebase_messaging ^7.0.3 requires firebase_core ^0.5.0+1.
So, because x-x-x depends on both firebase_core ^0.7.0 and firebase_messaging ^7.0.3, version solving failed.

@erolasan I used this version:   firebase_messaging: 8.0.0-dev.14 and it worked for me.
But now I have another problem, pod install doesn't work:
[!] CocoaPods could not find compatible versions for pod "Firebase/CoreOnly":
  In Podfile:
    Firebase/MLVisionFaceModel was resolved to 5.0.0, which depends on
      Firebase/CoreOnly (= 5.0.0)

    firebase_core (from `.symlinks/plugins/firebase_core/ios`) was resolved to 0.7.0, which depends on
      Firebase/CoreOnly (= 7.3.0)

CocoaPods could not find compatible versions for pod "FirebaseCore":
  In Podfile:
    firebase_core (from `.symlinks/plugins/firebase_core/ios`) was resolved to 0.7.0, which depends on
      Firebase/CoreOnly (= 7.3.0) was resolved to 7.3.0, which depends on
        FirebaseCore (= 7.3.0)

    firebase_storage (from `.symlinks/plugins/firebase_storage/ios`) was resolved to 7.0.0, which depends on
      Firebase/Storage (= 7.3.0) was resolved to 7.3.0, which depends on
        FirebaseStorage (~> 7.3.0) was resolved to 7.3.0, which depends on
          FirebaseCore (~> 7.0)

CocoaPods could not find compatible versions for pod "GoogleDataTransport":
  In Podfile:
    firebase_crashlytics (from `.symlinks/plugins/firebase_crashlytics/ios`) was resolved to 0.4.0, which depends on
      Firebase/Crashlytics (= 7.3.0) was resolved to 7.3.0, which depends on
        FirebaseCrashlytics (~> 7.3.0) was resolved to 7.3.0, which depends on
          GoogleDataTransport (~> 8.0)

    firebase_performance (from `.symlinks/plugins/firebase_performance/ios`) was resolved to 0.5.0-1, which depends on
      Firebase/Performance (= 7.3.0) was resolved to 7.3.0, which depends on
        FirebasePerformance (~> 7.3.0) was resolved to 7.3.0, which depends on
          GoogleDataTransport (~> 8.1)

CocoaPods could not find compatible versions for pod "nanopb":
  In Podfile:
    firebase_core (from `.symlinks/plugins/firebase_core/ios`) was resolved to 0.7.0, which depends on
      Firebase/CoreOnly (= 7.3.0) was resolved to 7.3.0, which depends on
        FirebaseCore (= 7.3.0) was resolved to 7.3.0, which depends on
          FirebaseCoreDiagnostics (~> 7.0) was resolved to 7.4.0, which depends on
            nanopb (~> 2.30907.0)

    firebase_crashlytics (from `.symlinks/plugins/firebase_crashlytics/ios`) was resolved to 0.4.0, which depends on
      Firebase/Crashlytics (= 7.3.0) was resolved to 7.3.0, which depends on
        FirebaseCrashlytics (~> 7.3.0) was resolved to 7.3.0, which depends on
          nanopb (~> 2.30906.0)

@erolasan I used this version:   firebase_messaging: 8.0.0-dev.14 and it worked for me.
But now I have another problem, pod install doesn't work:
[!] CocoaPods could not find compatible versions for pod "Firebase/CoreOnly":
  In Podfile:
    Firebase/MLVisionFaceModel was resolved to 5.0.0, which depends on
      Firebase/CoreOnly (= 5.0.0)

    firebase_core (from `.symlinks/plugins/firebase_core/ios`) was resolved to 0.7.0, which depends on
      Firebase/CoreOnly (= 7.3.0)

CocoaPods could not find compatible versions for pod "FirebaseCore":
  In Podfile:
    firebase_core (from `.symlinks/plugins/firebase_core/ios`) was resolved to 0.7.0, which depends on
      Firebase/CoreOnly (= 7.3.0) was resolved to 7.3.0, which depends on
        FirebaseCore (= 7.3.0)

    firebase_storage (from `.symlinks/plugins/firebase_storage/ios`) was resolved to 7.0.0, which depends on
      Firebase/Storage (= 7.3.0) was resolved to 7.3.0, which depends on
        FirebaseStorage (~> 7.3.0) was resolved to 7.3.0, which depends on
          FirebaseCore (~> 7.0)

CocoaPods could not find compatible versions for pod "GoogleDataTransport":
  In Podfile:
    firebase_crashlytics (from `.symlinks/plugins/firebase_crashlytics/ios`) was resolved to 0.4.0, which depends on
      Firebase/Crashlytics (= 7.3.0) was resolved to 7.3.0, which depends on
        FirebaseCrashlytics (~> 7.3.0) was resolved to 7.3.0, which depends on
          GoogleDataTransport (~> 8.0)

    firebase_performance (from `.symlinks/plugins/firebase_performance/ios`) was resolved to 0.5.0-1, which depends on
      Firebase/Performance (= 7.3.0) was resolved to 7.3.0, which depends on
        FirebasePerformance (~> 7.3.0) was resolved to 7.3.0, which depends on
          GoogleDataTransport (~> 8.1)

CocoaPods could not find compatible versions for pod "nanopb":
  In Podfile:
    firebase_core (from `.symlinks/plugins/firebase_core/ios`) was resolved to 0.7.0, which depends on
      Firebase/CoreOnly (= 7.3.0) was resolved to 7.3.0, which depends on
        FirebaseCore (= 7.3.0) was resolved to 7.3.0, which depends on
          FirebaseCoreDiagnostics (~> 7.0) was resolved to 7.4.0, which depends on
            nanopb (~> 2.30907.0)

    firebase_crashlytics (from `.symlinks/plugins/firebase_crashlytics/ios`) was resolved to 0.4.0, which depends on
      Firebase/Crashlytics (= 7.3.0) was resolved to 7.3.0, which depends on
        FirebaseCrashlytics (~> 7.3.0) was resolved to 7.3.0, which depends on
          nanopb (~> 2.30906.0)

Same for me
Because firebase_messaging 7.0.3 depends on firebase_core ^0.5.0+1 and no versions of firebase_messaging match >7.0.3 <8.0.0, firebase_messaging ^7.0.3 requires firebase_core ^0.5.0+1.
You upgraded all packages but forgot to update firebase_messaging.
Please do it,  otherwise there is no point in this upgrade.

Same for me
Because firebase_messaging 7.0.3 depends on firebase_core ^0.5.0+1 and no versions of firebase_messaging match >7.0.3 <8.0.0, firebase_messaging ^7.0.3 requires firebase_core ^0.5.0+1.
You upgraded all packages but forgot to update firebase_messaging.
Please do it,  otherwise there is no point in this upgrade.

Hi please fix the dependency for firebase_messaging on firebase_core, I am currently getting this when I do pub get the newest version:
Because firebase_messaging 7.0.3 depends on firebase_core ^0.5.0+1 and no versions of firebase_messaging match >7.0.3 <8.0.0, firebase_messaging ^7.0.3 requires firebase_core ^0.5.0+1.
So, because 'xxx' depends on both firebase_core ^0.7.0 and firebase_messaging ^7.0.3, version solving failed

in my pubspec i have this :
  cloud_firestore: ^0.16.0
  firebase_auth: ^0.20.0
  firebase_core: ^0.7.0
  firebase_analytics: ^7.0.1
  firebase_crashlytics: ^0.4.0
  firebase_messaging: ^7.0.3
``

Same for me

Hi please fix the dependency for firebase_messaging on firebase_core, I am currently getting this when I do pub get the newest version:
Because firebase_messaging 7.0.3 depends on firebase_core ^0.5.0+1 and no versions of firebase_messaging match >7.0.3 <8.0.0, firebase_messaging ^7.0.3 requires firebase_core ^0.5.0+1.
So, because 'xxx' depends on both firebase_core ^0.7.0 and firebase_messaging ^7.0.3, version solving failed

in my pubspec i have this :
  cloud_firestore: ^0.16.0
  firebase_auth: ^0.20.0
  firebase_core: ^0.7.0
  firebase_analytics: ^7.0.1
  firebase_crashlytics: ^0.4.0
  firebase_messaging: ^7.0.3
``

Same for me

Same here

Same here

Also having this problem.

Also having this problem.

Also having this problem.

Also having this problem.

this will help
https://firebase.flutter.dev/docs/migration/

this will help
https://firebase.flutter.dev/docs/migration/

@mohammadsm220 it did help thanks! Closing the issue

@mohammadsm220 it did help thanks! Closing the issue

I have this error
Because cloud_firestore >=0.16.0 depends on firebase_core ^0.7.0 and flash_chat depends on firebase_core ^0.6.0, cloud_firestore >=0.16.0 is forbidden.
So, because flash_chat depends on cloud_firestore ^0.16.0, version solving failed.
pub get failed (1; So, because flash_chat depends on cloud_firestore ^0.16.0, version solving failed.)

I have this error
Because cloud_firestore >=0.16.0 depends on firebase_core ^0.7.0 and flash_chat depends on firebase_core ^0.6.0, cloud_firestore >=0.16.0 is forbidden.
So, because flash_chat depends on cloud_firestore ^0.16.0, version solving failed.
pub get failed (1; So, because flash_chat depends on cloud_firestore ^0.16.0, version solving failed.)

i have the same error

i have the same error

So the solution is to install a dev branch (^8.0.0-dev.14) for firebase_messaging? Isn't that a really bad idea?

So the solution is to install a dev branch (^8.0.0-dev.14) for firebase_messaging? Isn't that a really bad idea?

So the solution is to install a dev branch (^8.0.0-dev.14) for firebase_messaging? Isn't that a really bad idea?

indeed it's very bad for who seeking to stability

So the solution is to install a dev branch (^8.0.0-dev.14) for firebase_messaging? Isn't that a really bad idea?

indeed it's very bad for who seeking to stability

So the solution is to install a dev branch (^8.0.0-dev.14) for firebase_messaging? Isn't that a really bad idea?

For me, it fails even if I install ^8.0.0-dev.14.
Error message:
Because firebase_messaging >=8.0.0-dev.13 depends on firebase_core_platform_interface ^3.0.1 and firebase_crashlytics >=0.5.0-1.0.nullsafety.1 depends on firebase_core_platform_interface >=4.0.0-1.0.nullsafety.0 <4.0.0-2.0.nullsafety.0, firebase_messaging >=8.0.0-dev.13 is incompatible with firebase_crashlytics >=0.5.0-1.0.nullsafety.1.

firebase_core: ^0.8.0-nullsafety.1
firebase_crashlytics: ^0.5.0-1.0.nullsafety.1
firebase_messaging: ^8.0.0-dev.14

This versions setup is from https://firebase.flutter.dev/docs/migration/

So the solution is to install a dev branch (^8.0.0-dev.14) for firebase_messaging? Isn't that a really bad idea?

For me, it fails even if I install ^8.0.0-dev.14.
Error message:
Because firebase_messaging >=8.0.0-dev.13 depends on firebase_core_platform_interface ^3.0.1 and firebase_crashlytics >=0.5.0-1.0.nullsafety.1 depends on firebase_core_platform_interface >=4.0.0-1.0.nullsafety.0 <4.0.0-2.0.nullsafety.0, firebase_messaging >=8.0.0-dev.13 is incompatible with firebase_crashlytics >=0.5.0-1.0.nullsafety.1.

firebase_core: ^0.8.0-nullsafety.1
firebase_crashlytics: ^0.5.0-1.0.nullsafety.1
firebase_messaging: ^8.0.0-dev.14

This versions setup is from https://firebase.flutter.dev/docs/migration/

When I remove the versions  behind messaging  and core, it works :
firebase_auth: ^0.20.0+1
google_sign_in: ^4.5.9
cloud_firestore: ^0.16.0
cloud_functions:  ^0.9.0
firebase_messaging:
firebase_core:
firebase_storage: ^7.0.0

When I remove the versions  behind messaging  and core, it works :
firebase_auth: ^0.20.0+1
google_sign_in: ^4.5.9
cloud_firestore: ^0.16.0
cloud_functions:  ^0.9.0
firebase_messaging:
firebase_core:
firebase_storage: ^7.0.0

Same problem

Same problem

Not working for me. I'm getting the following error.
Because firebase_analytics 7.0.1 depends on firebase_core ^0.7.0 and no versions of firebase_analytics match >7.0.1 <8.0.0, firebase_analytics ^7.0.1 requires firebase_core ^0.7.0.
So, because scorebud depends on both firebase_core ^0.8.0-nullsafety.1 and firebase_analytics ^7.0.1, version solving failed.
pub get failed (1; So, because scorebud depends on both firebase_core ^0.8.0-nullsafety.1 and firebase_analytics ^7.0.1, version solving failed.)
My pubspec.yml has the following firebase section copied from the migration guide:
environment:
sdk: ">=2.12.0-0 <3.0.0"
firebase_core: "^0.8.0-nullsafety.1"
Newly reworked plugins covered by this migration guide:
firebase_auth: "^0.21.0-nullsafety.0"
firebase_crashlytics: "^0.5.0-1.0.nullsafety.1"
cloud_firestore: "^0.16.0"
firebase_storage: "^7.0.0"
firebase_messaging: "^8.0.0-dev.14"
firebase_remote_config: "^0.8.0-dev.0"
Updated to work with new core only plugins (no new changes):
firebase_admob: "^0.11.0+1"
firebase_analytics: "^7.0.1"

[✓] Flutter (Channel beta, 1.25.0-8.3.pre, on macOS 11.1 20C69 darwin-x64)
• Flutter version 1.25.0-8.3.pre at /Volumes/DataDev/flutter/flutter
• Framework revision 5d36f2e7f5 (2 weeks ago), 2021-01-14 15:57:49 -0800
• Engine revision 7a8f8ca02c
• Dart version 2.12.0 (build 2.12.0-133.7.beta)

Not working for me. I'm getting the following error.
Because firebase_analytics 7.0.1 depends on firebase_core ^0.7.0 and no versions of firebase_analytics match >7.0.1 <8.0.0, firebase_analytics ^7.0.1 requires firebase_core ^0.7.0.
So, because scorebud depends on both firebase_core ^0.8.0-nullsafety.1 and firebase_analytics ^7.0.1, version solving failed.
pub get failed (1; So, because scorebud depends on both firebase_core ^0.8.0-nullsafety.1 and firebase_analytics ^7.0.1, version solving failed.)
My pubspec.yml has the following firebase section copied from the migration guide:
environment:
sdk: ">=2.12.0-0 <3.0.0"
firebase_core: "^0.8.0-nullsafety.1"
Newly reworked plugins covered by this migration guide:
firebase_auth: "^0.21.0-nullsafety.0"
firebase_crashlytics: "^0.5.0-1.0.nullsafety.1"
cloud_firestore: "^0.16.0"
firebase_storage: "^7.0.0"
firebase_messaging: "^8.0.0-dev.14"
firebase_remote_config: "^0.8.0-dev.0"
Updated to work with new core only plugins (no new changes):
firebase_admob: "^0.11.0+1"
firebase_analytics: "^7.0.1"

[✓] Flutter (Channel beta, 1.25.0-8.3.pre, on macOS 11.1 20C69 darwin-x64)
• Flutter version 1.25.0-8.3.pre at /Volumes/DataDev/flutter/flutter
• Framework revision 5d36f2e7f5 (2 weeks ago), 2021-01-14 15:57:49 -0800
• Engine revision 7a8f8ca02c
• Dart version 2.12.0 (build 2.12.0-133.7.beta)

Please fix this issue, same error following the migration guide.
Dependencies:
firebase_core: ^0.8.0-nullsafety.1
firebase_messaging: ^8.0.0-dev.14

Error:
Because firebase_messaging >=8.0.0-dev.13 depends on firebase_core ^0.7.0 and test depends on firebase_core ^0.8.0-nullsafety.1, firebase_messaging >=8.0.0-dev.13 is forbidden.

Please fix this issue, same error following the migration guide.
Dependencies:
firebase_core: ^0.8.0-nullsafety.1
firebase_messaging: ^8.0.0-dev.14

Error:
Because firebase_messaging >=8.0.0-dev.13 depends on firebase_core ^0.7.0 and test depends on firebase_core ^0.8.0-nullsafety.1, firebase_messaging >=8.0.0-dev.13 is forbidden.

same error
Because firebase_admob >=0.11.0+1 depends on firebase_core ^0.7.0 and ... depends on firebase_core ^0.8.0-nullsafety.1, firebase_admob >=0.11.0+1 is forbidden.

 cloud_firestore:	^0.16.0
  cloud_functions:	^0.9.1-nullsafety.1
  firebase_auth:	^0.21.0-nullsafety.0
  firebase_core:	^0.8.0-nullsafety.1
  firebase_crashlytics:	^0.5.0-1.0.nullsafety.1
  firebase_storage:	^7.0.0
  firebase_messaging:	^8.0.0-dev.14
  firebase_remote_config:	^0.8.0-dev.0
  firebase_admob: ^0.11.0+1

same error
Because firebase_admob >=0.11.0+1 depends on firebase_core ^0.7.0 and ... depends on firebase_core ^0.8.0-nullsafety.1, firebase_admob >=0.11.0+1 is forbidden.

 cloud_firestore:	^0.16.0
  cloud_functions:	^0.9.1-nullsafety.1
  firebase_auth:	^0.21.0-nullsafety.0
  firebase_core:	^0.8.0-nullsafety.1
  firebase_crashlytics:	^0.5.0-1.0.nullsafety.1
  firebase_storage:	^7.0.0
  firebase_messaging:	^8.0.0-dev.14
  firebase_remote_config:	^0.8.0-dev.0
  firebase_admob: ^0.11.0+1

copy-paste from the guide and it's not working, keeps saying errors that they're not compatible with each others. Really annoying!

copy-paste from the guide and it's not working, keeps saying errors that they're not compatible with each others. Really annoying!

Opened #4885 because documentation doesn't work

Opened #4885 because documentation doesn't work

the same problem continues with me
  firebase_core: ^0.8.0-nullsafety.1
  firebase_auth: ^0.21.0-nullsafety.0
  firebase_crashlytics: ^0.5.0-1.0.nullsafety.1
  firebase_messaging: ^8.0.0-dev.14
  firebase_database: ^6.0.0
  firebase_analytics: ^7.0.1

Because firebase_analytics >=7.0.1 depends on firebase_core ^0.7.0 and mafya depends on firebase_core ^0.8.0-nullsafety.1, firebase_analytics >=7.0.1 is forbidden.

So, because mafya depends on firebase_analytics ^7.0.1, version solving failed.
pub get failed (1; So, because mafya depends on firebase_analytics ^7.0.1, version solving failed.)
exit code 1

Why is this closed if the problem persists?
Having the same problem with copy and paste from the migration documentation.

Error persists on a brand new flutter project. Used these dependencies:
 firebase_auth: "^0.20.0+1"
 firebase_crashlytics: "^0.4.0+1"
 cloud_firestore: "^0.16.0"
 cloud_functions: "^0.9.0"
 firebase_storage: "^7.0.0"
 firebase_messaging: "^7.0.3"

Error message:
Running "flutter pub get" in flutter...
Because firebase_messaging >=7.0.3 <8.0.0-dev.7 depends on firebase_core ^0.5.0+1 and firebase_storage >=7.0.0 depends on firebase_core ^0.7.0, firebase_messaging >=7.0.3 <8.0.0-dev.7 is incompatible with firebase_storage >=7.0.0.

So, because sandbox depends on both firebase_storage ^7.0.0 and firebase_messaging ^7.0.3, version solving failed.
pub get failed (1; So, because sandbox depends on both firebase_storage ^7.0.0 and firebase_messaging ^7.0.3, version solving failed.)

I solved it by changing firebase_messaging version to ^8.0.0-dev.14

I solved it by changing firebase_messaging version to ^8.0.0-dev.14

Thanks, it worked, but it not a fix for the problem, you know what I mean? I could have stability issues. Will test it though.

Can anyone reopen the issue, cause it still persists

@mohammadsm220 it did help thanks! Closing the issue

Hello @erolasan , the issue still persists so could you please reopen the issue? I'd rather not open another issue for the same problem.

Here also having issues...

Same issue here

this will help
https://firebase.flutter.dev/docs/migration/

@mohammadsm220 @erolasan Could you please share what was helping you to resolve this issue in the migration guide? I still experience this although I believe I followed the migration guide. Thanks!

Also having this issue. What is the way forward please as I have a deadline to complete a project which currently heavily relies on firebase.

Also having this issue. What is the way forward please as I have a deadline to complete a project which currently heavily relies on firebase.

@melvinotieno the only way to go now would be to set firebase_messaging version to ^8.0.0-dev.14

I changed firebase_auth version to ^0.18.4+1, works for me.

I changed firebase_auth version to ^0.18.4+1, works for me.

I changed firebase_auth version to ^0.18.4+1, works for me.

Sure.

firebase_core: ^0.5.0+1
firebase_auth: ^0.18.4+1
firebase_messaging: ^7.0.3

Same issue here , But
when i removed version it worked without error
 firebase_messaging:

Following - please reopen until fix has landed in stable.

following, same issue migration docs not working, would prefer to stay on stable branch and not beta.

Having the same problem:
Because firebase_messaging >=7.0.3 <8.0.0-dev.7 depends on firebase_core ^0.5.0+1 and pewpewchat depends on firebase_core ^0.7.0, firebase_messaging >=7.0.3 <8.0.0-dev.7 is forbidden.
Current workaround: Leave firebase_messaging version to blank.
dependencies:
flutter:
sdk: flutter
provider: ^4.3.3
firebase_core: ^0.7.0
firebase_auth: ^0.20.0+1
cloud_firestore: ^0.16.0
firebase_storage: ^7.0.0
firebase_messaging:
Following for fix.

Same issue here , But
when i removed version it worked without error
 firebase_messaging:

for Me Android work fines but iOS error

Same issue here , But
when i removed version it worked without error
 firebase_messaging:

for Me Android work fines but iOS error

for me also getting this error on iOS

I am having same issue, any prevision to fix this (real fix, not adding a dev dependence) ? I think they need to release a stable version 8.0.0, but don't know when it will be launched...

The matching versions are:
firebase_core: ^0.7.0
firebase_messaging: 6.0.16

This works for me... 👍👌

I solved it by changing firebase_messaging version to ^8.0.0-dev.14

Thanks, it worked, but that's not a fix for the problem, if you know what I mean. I could have stability issues. Will test it though.

Indeed it's an issue, but Flutterfire is still an ongoing project and we will have to deal with those problems for a while.
I have tested this solution and it's working well so far.

Anyone already tried using firebase_messaging ^8.0.0-dev.14 on production? Especially on the iOS side. Any response would be appreciated, thanks in advance.

Same issue here

Yes I have the same issue here. Really hope that version ^8.0.0 stable can be released soon

hey @fauzyahmad can you look at this
https://t.co/T3yVelwSff?amp=1

Can anyone reopen the issue, cause it still persists

Issue still persists

same issue, I´m worried to try a dev-dependency on production.

@mohammadsm220 can you reopen this for us?