Ingress-Nginx IPv6 issues with K3S 1.22.3+

Environmental Info:
K3s Version: v1.22.3+k3s1
Node(s) CPU architecture, OS, and Version:
inux prometheus.example.net 3.10.0-1160.45.1.el7.x86_64 #1 SMP Wed Oct 13 17:20:51 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
Cluster Configuration: Single node cluster

Describe the bug:
Issues with Nginx Controller LoadBalancer obtaining IPv4 and IPv6 addresses with PreferDualStack
is configured in the ingress-nginx-controller service
Steps To Reproduce:

Installed K3s:

export INSTALL_K3S_VERSION="v1.22.3+k3s1"

curl -sfL https://get.k3s.io | sh -s - --disable traefik \
--cluster-cidr=<IP_ADDRESS>/16,fc15:1::/56 \
--service-cidr=<IP_ADDRESS>/16,fc15:2::/112 \
--node-ip=<IP_ADDRESS>,2001:500:110:604::110 \
--disable-network-policy \
--kube-controller-manager-arg="bind-address=::" \
--kube-proxy-arg="metrics-bind-address=::" \
--kube-scheduler-arg="address=::" \
--kube-scheduler-arg="bind-address=::"

Installed Ingress-Nginx Controller

helm repo add stable https://charts.helm.sh/stable
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update

cat <<EOF > /tmp/ingress-nginx-values.yml
---
controller:
  admissionWebhooks:
    enabled: false
  allowSnippetAnnotations: false
  config:
    use-forwarded-headers: "true"
    use-http2: "false"
  kind: DaemonSet
  metrics:
    enabled: true
    serviceMonitor:
      enabled: true
      namespace: monitoring
      additionalLabels:
        release: kube-prometheus-stack
  podAnnotations:
    prometheus.io/scrape: "true"
    prometheus.io/port: "10254"
  service:
    externalTrafficPolicy: Local
EOF

helm upgrade --install --atomic ingress-nginx ingress-nginx/ingress-nginx -n ingress-nginx --create-namespace \
-f /tmp/ingress-nginx-values.yml --version 4.0.6 --kubeconfig /etc/rancher/k3s/k3s.yaml

Updated the ingress-nginx-controller service to have ipFamilyPolicy set to  PreferDualStack

kubectl --namespace ingress-nginx edit services -o wide ingress-nginx-controller -o yaml

Expected behavior:
Both IPv4 and IPv6 address families are assigned as External-Addresses
Note: With version: v1.22.2+k3s2 I get the following without the need to set PreferDualStack
kubectl --namespace ingress-nginx get services -o wide ingress-nginx-controller

NAME                       TYPE           CLUSTER-IP    EXTERNAL-IP                         PORT(S)                      AGE   SELECTOR
ingress-nginx-controller   LoadBalancer   <IP_ADDRESS>   <IP_ADDRESS>,2001:500:110:604::110   80:30595/TCP,443:31971/TCP   46m   app.kubernetes.io/component=controller,app.kubernetes.io/instance=ingress-nginx,app.kubernetes.io/name=ingress-nginx

Actual behavior:
The ingress-nginx-controller never gets an address assigned form the LB (Klipper)
kubectl --namespace ingress-nginx get services -o wide ingress-nginx-controller

NAME                       TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGE   SELECTOR
ingress-nginx-controller   LoadBalancer   <IP_ADDRESS>   <pending>     80:32289/TCP,443:32522/TCP   15m   app.kubernetes.io/component=controller,app.kubernetes.io/instance=ingress-nginx,app.kubernetes.io/name=ingress-nginx

Additional context / logs:
When looking at the svclb-ingress-nginx-controller-*****  pod I see its in a CrashLoop
[root@prometheus ~]# kubectl get pods -A | grep 'svclb-ingress-nginx-controller'
ingress-nginx   svclb-ingress-nginx-controller-kqtqn     0/2     CrashLoopBackOff   14 (29s ago)   11m

Doing a describe I see the following
- containerID: containerd://f303a3f2d671ed844382b7529a3667793233b01327d3abc64e7e9db97c9d40dd
    image: docker.io/rancher/klipper-lb:v0.3.4
    imageID: docker.io/rancher/klipper-lb@sha256:d5ec8350ee1a80ec783effe95a2fefae371d1498ac04865cb6024499882f291c
    lastState:
      terminated:
        containerID: containerd://f303a3f2d671ed844382b7529a3667793233b01327d3abc64e7e9db97c9d40dd
        exitCode: 1
        finishedAt: "2021-11-04T16:46:29Z"
        reason: Error
        startedAt: "2021-11-04T16:46:29Z"
    name: lb-port-80
    ready: false
    restartCount: 6
    started: false
    state:
      waiting:
        message: back-off 5m0s restarting failed container=lb-port-80 pod=svclb-ingress-nginx-controller-62h7p_ingress-nginx(25012e75-42db-4d3f-a7d3-33c4db113468)
        reason: CrashLoopBackOff
  hostIP: <IP_ADDRESS>
  phase: Running
  podIP: <IP_ADDRESS>
  podIPs:
  - ip: <IP_ADDRESS>
  - ip: fd42::10
  qosClass: BestEffort
  startTime: "2021-11-04T16:40:34Z"

Broken off from https://github.com/k3s-io/k3s/issues/284#issuecomment-961280406

Could you please run:
kubectl logs svclb-ingress-nginx-controller-kqtqn -n ingress-nginx

Here is the output from the containers running within the pod svclb-ingress-nginx-controller-*****
[root@prometheus ~]# kubectl logs svclb-ingress-nginx-controller-dsxvl -n ingress-nginx --container lb-port-80
+ trap exit TERM INT
+ echo <IP_ADDRESS>
+ grep -Eq :
+ cat /proc/sys/net/ipv4/ip_forward
+ '[' 1 '!=' 1 ]
+ iptables -t nat -I PREROUTING '!' -s <IP_ADDRESS>/32 -p TCP --dport 80 -j DNAT --to <IP_ADDRESS>:80
+ iptables -t nat -I POSTROUTING -d <IP_ADDRESS>/32 -p TCP -j MASQUERADE
+ grep -Eq :
+ echo fc15:2::aae2
+ cat /proc/sys/net/ipv6/conf/all/forwarding
+ '[' 0 '!=' 1 ]
+ exit 1

[root@prometheus ~]# kubectl logs svclb-ingress-nginx-controller-dsxvl -n ingress-nginx --container lb-port-443
+ trap exit TERM INT
+ grep -Eq :
+ echo <IP_ADDRESS>
+ cat /proc/sys/net/ipv4/ip_forward
+ '[' 1 '!=' 1 ]
+ iptables -t nat -I PREROUTING '!' -s <IP_ADDRESS>/32 -p TCP --dport 443 -j DNAT --to <IP_ADDRESS>:443
+ iptables -t nat -I POSTROUTING -d <IP_ADDRESS>/32 -p TCP -j MASQUERADE
+ echo fc15:2::aae2
+ grep -Eq :
+ cat /proc/sys/net/ipv6/conf/all/forwarding
+ '[' 0 '!=' 1 ]
+ exit 1

mmmm apparently cat /proc/sys/net/ipv6/conf/all/forwarding is 0, even though it should be 1.  Apparently k3s is not detecting the dual-stack mode

@manuelbuil I've both performed in in-place upgrade from v1.22.2+k3s2 to v1.22.3+k3s1 and performed a "clean" install after issuing k3s-uninstall.sh. Both have the exact same outcome.
As noted in the snippet below the host has IPv6 forwarding on
[root@prometheus ~]# kubectl logs svclb-ingress-nginx-controller-rmlk7 -n ingress-nginx --container lb-port-80
+ trap exit TERM INT
+ echo <IP_ADDRESS>
+ grep -Eq :
+ cat /proc/sys/net/ipv4/ip_forward
+ '[' 1 '!=' 1 ]
+ iptables -t nat -I PREROUTING '!' -s <IP_ADDRESS>/32 -p TCP --dport 80 -j DNAT --to <IP_ADDRESS>:80
+ iptables -t nat -I POSTROUTING -d <IP_ADDRESS>/32 -p TCP -j MASQUERADE
+ echo fc15:2::9524
+ grep -Eq :
+ cat /proc/sys/net/ipv6/conf/all/forwarding
+ '[' 0 '!=' 1 ]
+ exit 1

[root@prometheus ~]# cat /proc/sys/net/ipv6/conf/all/forwarding
1

[root@prometheus ~]# kubectl logs svclb-ingress-nginx-controller-rmlk7 -n ingress-nginx --container lb-port-443
+ trap exit TERM INT
+ echo <IP_ADDRESS>
+ grep -Eq :
+ cat /proc/sys/net/ipv4/ip_forward
+ '[' 1 '!=' 1 ]
+ iptables -t nat -I PREROUTING '!' -s <IP_ADDRESS>/32 -p TCP --dport 443 -j DNAT --to <IP_ADDRESS>:443
+ iptables -t nat -I POSTROUTING -d <IP_ADDRESS>/32 -p TCP -j MASQUERADE
+ grep -Eq :
+ echo fc15:2::9524
+ cat /proc/sys/net/ipv6/conf/all/forwarding
+ '[' 0 '!=' 1 ]
+ exit 1
[root@prometheus ~]# k3s -version
k3s version v1.22.3+k3s1 (61a2aab2)
go version go1.16.8

Can you please show me the output of:
kubectl get nodes -o yaml | grep podCIDRs -n4

And:
kubectl get nodes -o yaml | grep node-args

Thanks!

No problem, here is the output
[root@prometheus ~]# kubectl get nodes -o yaml | grep podCIDRs -n4
34-    resourceVersion: "641"
35-    uid: 56688d17-7127-4777-89c4-3b828093ef03
36-  spec:
37-    podCIDR: <IP_ADDRESS>/24
38:    podCIDRs:
39-    - <IP_ADDRESS>/24
40-    - fc15:1::/64
41-    providerID: k3s://prometheus.stage.arin.net
42-  status:

[root@prometheus ~]# kubectl get nodes -o yaml | grep node-args
      k3s.io/node-args: '["server","--disable","traefik","--cluster-cidr","<IP_ADDRESS>/16,fc15:1::/56","--service-cidr","<IP_ADDRESS>/16,fc15:2::/112","--node-ip","<IP_ADDRESS>,2001:500:110:604::110","--disable-network-policy","--kube-controller-manager-arg","bind-address=::","--kube-proxy-arg","metrics-bind-address=::","--kube-scheduler-arg","address=::","--kube-scheduler-arg","bind-address=::"]'

I also doubled check to make sure that the host OS looks to have all the correct forwarding setup
[root@prometheus ~]# sysctl -a --ignore 2>&1 | grep "net.ipv6.conf.all.forwarding\|net.ipv4.ip_forward\|net.bridge.bridge-nf-call-iptables\|net.bridge.bridge-nf-call-ip6tables\|bridge-nf-call-iptables"
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1
net.ipv4.ip_forward_use_pmtu = 0
net.ipv6.conf.all.forwarding = 1

[root@prometheus ~]# sudo sysctl net.bridge.bridge-nf-call-iptables=1
net.bridge.bridge-nf-call-iptables = 1

[root@prometheus ~]# lsmod | grep br_netfilter
br_netfilter           22256  1 xt_physdev
bridge                151336  1 br_netfilter

The ingress-nginx controller service also has an IPv6 address assigned
[root@prometheus ~]# kubectl --namespace ingress-nginx get services -o wide ingress-nginx-controller -o go-template --template='{{range .spec}}{{printf "%s\n" .}}{{end}}'
%!s(bool=true)
<IP_ADDRESS>
[<IP_ADDRESS> fc15:2::37e3]
Local
%!s(int64=30845)
Cluster
[IPv4 IPv6]
PreferDualStack
[map[appProtocol:http name:http nodePort:%!s(int64=31480) port:%!s(int64=80) protocol:TCP targetPort:http] map[appProtocol:https name:https nodePort:%!s(int64=31777) port:%!s(int64=443) protocol:TCP targetPort:https]]
map[app.kubernetes.io/component:controller app.kubernetes.io/instance:ingress-nginx app.kubernetes.io/name:ingress-nginx]
None
LoadBalancer

As well as the metrics server POD, so IPv6 dual stack seems to be working in the cluster
[root@prometheus ~]# kubectl get pods metrics-server-9cf544f65-x4wcm --namespace kube-system -o go-template --template='{{range .status.podIPs}}{{printf "%s\n" .ip}}{{end}}'
<IP_ADDRESS>
fc15:1::3

Thanks for the output. Can you verify the following sysctl:
net.core.devconf_inherit_init_net = 1?

I don't see net.core.devconf_inherit_init_net (devconf_inherit_init_net), set or available on my system. I'm running CentOS 7 which is running kernel 3.10.0-1160.45.1.el7.x86_64. From a quick google this looks to be a setting in the newer kernel versions.
However, net.ipv6.conf.all.forwarding is set to 1. I noted that in the comment above but its a little hard to read
# sysctl -a --ignore 2>&1 | grep "net.ipv6.conf.all.forwarding"
net.ipv6.conf.all.forwarding = 1

I don't see net.core.devconf_inherit_init_net (devconf_inherit_init_net), set or available on my system. I'm running CentOS 7 which is running kernel 3.10.0-1160.45.1.el7.x86_64. From a quick google this looks to be a setting in the newer kernel versions.
However, net.ipv6.conf.all.forwarding is set to 1. I noted that in the comment above but its a little hard to read
# sysctl -a --ignore 2>&1 | grep "net.ipv6.conf.all.forwarding"
net.ipv6.conf.all.forwarding = 1

You showed net.ipv6.conf.all.forwarding in the root network namespace. We need that parameter to be 1 in the svclb network namespace. net.core.devconf_inherit_init_net = 1 guarantees that the new network namespaces inherit the parameters from the root network namespace. Without it, the default for ipv6 is 0 [1]
[1] - https://www.kernel.org/doc/html/v5.4/admin-guide/sysctl/net.html#devconf-inherit-init-net

After investigating, the problem appears in centos 7 and centos 8 because they use old kernels and don't have the parameter net.core.devconf_inherit_init_net

Due to the bug, services are not available via the external ipv6 address created by svclb. In other words, services will still be reachable via their clusterIPs, both ipv4 and ipv6.


update jira in promote job

Think this needs to be one of the last steps. Think we can call this step done if release is signed, PR to cincinnatti-graph-data is opened, etc.

OK, updated

/lgtm
Let's try it this week :)


Malicious extension prevention

Rationale
Even thought there is already a deny list that tries to prevent malicious extensions from running on the user's machines, after an extension is installed third parties can just update the extension at any given time with malicious code without oversight.
This brings tremendous risk as it has been proven in the industry that it can happen.
Proposed solution
Obviously we cannot guarantee full on security without manual checks, which is completely out of question. Therefore I recommend that we provide an option to disable automatic updates/a manual update section. This way users could always validate the extensions they are adding before doing so.

Ideas include: use a specific version/commit in the url. Save the commit ID in localstorage, and check the latest commit on load (in extension.js), and update that in localstorage as well. So we have a "version" and "latest version" or "update available" flag. That way we can show an update button.

Ideas include: use a specific version/commit in the url. Save the commit ID in localstorage, and check the latest commit on load (in extension.js), and update that in localstorage as well. So we have a "version" and "latest version" or "update available" flag. That way we can show an update button.

Maybe it would be safer to use the hash of the js file than the commit ID?

Maybe it would be safer to use the hash of the js file than the commit ID?
Then we would need to redownload and calculate the hash of anything installed every time it checks. Is there a reason why commit ID wouldn't be safe?

Ideas include: use a specific version/commit in the url. Save the commit ID in localstorage, and check the latest commit on load (in extension.js), and update that in localstorage as well. So we have a "version" and "latest version" or "update available" flag. That way we can show an update button.

Maybe it would be safer to use the hash of the js file than the commit ID?

Pretty sure that you can't forge a commit id, and it is definitely easier to implement vs calculating hashes imo.

Maybe we add a "this version has been manually reviewed by personA" to make sure the user knows the version has indeed been confirmed correct. If the review hasn't been performed, at that point we could inform the user that they're about to try software that has yet to be reviewed.

@FivePixels While I agree this would be cool, I feel like needing a GitHub file for each extension and theme as well as needing to review things kind of defeats the purpose of having the marketplace being so accessible to repo owners to add their stuff. Regardless, I'll keep this idea in mind but this would probably need to be implemented after we implement padsters idea. We could create an issue format for extension/theme owners to request a review with requirements for a description for how to navigate the code and a brief description of the functions and such, to make the reviewing process a bit easier. (Or if they have commented their code properly that works too, but I know for a fact that my extensions code tend to be super messy and personally I would not want to go near reviewing them..)

@CharlieS1103 I understand your point, but you don't need to evaluate anyone's code, you just need to check for malicious code, which is a far easier and simpler task in my view.

@CharlieS1103 @theRealPadster I've been thinking over this for a while and I think it is time that we move towards a centralised manifest point of view. That is, having a manifest in spicetify-marketplace that holds all extensions, custom-apps, or themes. This way we have more granular control of what we display to end-users.
The advantages are:

We can force submitters to have one repo per extension/theme -> Solving https://github.com/spicetify/spicetify-marketplace/issues/75
We can temporarily remove apps that have been broken for a while solving #111
There would be no problems in terms of migrations like in #137, since we would have full control of the whole flow.
Every time that an extension was submitted they only needed to submit a PR adding their extension and respective links to the manifest. If you prefer we can have this manifest in spicetify-cli to be more visible to extension and theme creators.
Extensions would be developed in their own branches giving more power to creators without having the need to make PRs to the "official" repos such as spicetify-themes or spicetify-cli.

Let me know what you think.

For things such as the spicetify themes repo and such, the concept of having one repo for every theme/extension is more or less just impossible without losing a lot of extensions to laziness. Therefore, it would probably be best if we continue multi-extension/theme manifest support.

Do you really think that people would not submit a PR out of laziness after dedicating a lot of work to creating said extension in the first place? I firmly disagree with this, especially because they already do it, except that it is within their repo. They add the manifest and the topic. If you weigh in the benefits vs disadvantages I think that a centralised manifest is better than centralised repos full of themes. Look at the Glaze theme for example, where the spicetify-themes version is severely out of date 👀

I agree and would like to get things converted to a single manifest at some point. Things are just way to up in the air right now with the jsx rewrite and the search feature that will need to be merged over as well.

I'm going to assign myself and try to tackle it then (or at least try to give it an initial push)!

@afonsojramos Didn't mean they wouldn't submit a PR, i meant that making them keep their extensions/themes in separate repos would probably be annoying for larger repos(spicetify-themes, my extension repo, and many others) So we probably shouldn't remove support for storing multiple extensions / themes in one repo.


help output implies functionality which is not present

In particular;
   start   Start service(s)
   stop    Stop service(s)

seem to imply you can supply them a list of services, which is not the case, the only plural case is --all, but that is only really made clear in the more man-style help text in the source code.
It seems like either the start and stop commands should accept a list (probably unlikely, given the "custom plist" functionality already present there!) or the help text should not imply plurality, or include the more helpful command signature from the header of the file.
I'd be happy to supply a PR if desired!

I'd be happy to supply a PR if desired!

I agree with your critique and a PR would be 🙇

I'm afraid due to the caveat noted I don't suspect multi-service functionality is something I can reasonably implement (I can't think of a reasonable way to do it without breaking existing usages in a backwards-incompatible manner! Maybe once Homebrew gets the versioning a little birdy suggested was approaching) but I'll polish the help output, for sure! 😄
Is there a style guide for such things (read: command help output) within Homebrew I should be following? Otherwise I guess I'll be searching for precedent 😜

but I'll polish the help output, for sure!

Sorry, yeh, this is all I was expecting here.

Is there a style guide for such things (read: command help output) within Homebrew I should be following?

Not really but https://github.com/Homebrew/brew/blob/master/share/doc/homebrew/Prose-Style-Guidelines.md and brew --help and man brew are probably your best examples. Thanks again!


[FEATURE]

Description
add hover effect to the products
Screenshots

Additional information
No response
🥦 Browser
Google Chrome
👀 Have you checked if this issue has been raised before?

[X] I checked and didn't find similar issue

🏢 Have you read the Contributing Guidelines?

[X] I have read the Contributing Guidelines

Are you willing to work on this issue ?
Yes I am willing to submit a PR!

@ShravaniAK

This issue is already been worked out by someone else at #447
Please always check before making a new issue
Please always give proper issue title instead of  [FEATURE] <description>


docs(changelog) correct contributor name

Correct contributor hbagdi's handle from hbadgi to hbagdi

This is a very minor change and may be doesn't need a commit...

Apologies! That's my bad.

@thibaultcha happens quite often with me. No problem!

@hbagdi Same with mine 😀


Shift the node build work to the Hydroshare image build (multi-stage …

…Docker build)

Pull Request Checklist:

[ ] Positive Test Case Written by Dev

[ ] Automated Testing

[ ] Sufficient User and Developer Documentation

[ ] Passing Jenkins Build

[ ] Peer Code review and approval

Positive Test Case

[Enter positive test case here]

Sorry I was wrong (and in trying to be helpful I was also heavy handed toying with your branch--apologies!).
Reverted removing the node_build from local-dev-first-start-only.sh because the host hs_discover is mounted for local dev anyway (and overwrites whatever gets built in the image). This means that running local-dev-first-start-only.sh can potentially run the node build twice which is slow but probably doesn't matter much since we don't do that very often.
Probably you already knew that but I didn't realize till now. Sorry, we can squash the funky git history!

@cbcunc not sure if you wanted to take a look at this.
I just resolved conflicts. Ready to squash and merge in my opinion.


loginUsingId not persistent, only works on the first request

Laravel Version: 5.3.4
PHP Version: 7.0.10
Database Driver & Version: mysql  Ver 14.14 Distrib 5.7.13, for Win32 (AMD64)

Description:
I am trying to implement a single signon on multiple domains (single instance). The concept is pretty simple i.e to send user from domain1 to domain2 with a unique user tokens and then verify these tokens against user and then if the token is found i manually log him in.
$loggedInUser = Auth::loginUsingId($user->id, true);
Now i also have a custom middleware where it checks for a logged in user, and then does some other stuff.
Auth::Check()
The above works fine for the first time. But on refresh Auth::check() is not validated. I have done a lot of diedumps and i am pretty sure that some how the login state is not persisting. I also tried using all different session drivers including file, cookie, db, redis but still it doesn't work.
I also came across lots of other users having the same issue. Here is one having an identical problem.
http://laravel.io/forum/10-20-2015-authloginusingid-and-authlogin-not-work-in-middleware
I have used a similar code on laravel 5.2, and it did work fine at the time. But on laravel 5.3 its not validating. My question is, is this how it was ment to be? Or is there something that i might be missing?
Anyhelp would be really appreciated.

I also came across lots of other users having the same issue. Here is one having an identical problem.
http://laravel.io/forum/10-20-2015-authloginusingid-and-authlogin-not-work-in-middleware

@omer414 Are you using the same database for login?

Well yes both use the same database. Just a different domain.

@omer414 I actually got around to get it working through multiple domains was by using a combination of api & web auth guard. It isn't a good solution, but here is what i did:

Created a route called verify in routes/web.php file. On this route, i apply the api middleware.

To login from domain A to domain B, i simply created an api token & passed to another URL using:
  http://domainB/verify?api_token=token

In my verify route code, i wrote:
  $auth = auth('api')->check();
  if ($auth) {
      $user = $auth->user;

      auth()->loginUsingId($user->id, true);

      return redirect(url('home'));
  }

Let me know if it works for you.

@srmklive Well this is exactly what i am doing but instead of the api token to find the user, i am using a custom generated token. Are you using laravel 5.3?

@omer414 yes i am using laravel 5.3.

Exactly which version is it?

5.3.6

@srmklive you seem to be able to identify the issue, can you please share what you think is the issue? :)

@themsaid I think that the auth guard implementation by @omer414 is not correct.

@srmklive  i mostly use middlewares and no guards. i have not modified AuthServiceProvider or any other guard. let me show you my code.
here is the route that domain1 points to
http://domain2.com/{{$role}}/{{$route}}/singlesignon/{{$token}}
This is then picked up by verifySingleSignOn method inside the loginController which takes in the role, route that the user came in from other domain and the token. The user is then redirected to the same routes, but on domain2. Here i can successfully recieve the user id before manually logging in.
public function verifySingleSignOn($role, $route, $token)
    {
        // Fetch Single Signon
        $userRepository = new UserRepository();
        $user = $userRepository->checkForSingleSignOnToken($token, ['id']);

        // Check if Token Exists
        if (isset($user->id) && is_int($user->id) && $user->id != 0) {

            // Manually Logging a user (Here is successfully recieve the user id)
            $loggedInUser = Auth::loginUsingId($user->id);

            if (!$loggedInUser) {
                // If User not logged in, then Throw exception
                throw new Exception('Single SignOn: User Cannot be Signed In');
            }
            $redirectTo = $role . '/' . $route;
            return redirect($redirectTo);
        } else {
            return Auth::logout();
        }
    }

Then i have this GlobalAdminAuth middleware
       // Check if logged in
        if( Auth::Check() ){
            $user = Auth::User();

            // Check if user is active and is a globaladmin
            if( !$user->isGlobalAdmin() || !$user->isActive() ){
                return redirect()->guest('login');
            }
        }else{
            return redirect()->guest('login');
        }

        return $next($request);

Now the first time everything works fine and the user moves through the middleware successfully . but the second time the else statement is triggered.

@omer414 The issue is with your middleware. Your middleware should simply check if the token being passed is valid or not. If its invalid, it should simply generate an error. You should create a custom auth guard. Refer to laravel documentation here.

issue is still actual in Laravel 9


Support for image output

I want to add a function to support outputting the image. So that I can use it in my notebook.

generally, some kind of export functionality would be nice

as far as I can tell the graph is a svg element. it should be rather straightforward to add an "export as svg" button that offers that part of the DOM for download.


treewide: remove global with lib; statements in pkgs/{audio,blockchain,editors}

I am trying to split #211241 into smaller changes to get it into a reviewable bulk and try to approach that in smaller groups by pkgs category.
This PR removes the global with lib; statements of pkgs/audio, pkgs/blockchain, pkgs/editors.
I tried to follow the rule to replace all with lib; with lib. but if its for the meta attr. For meta i replaced it with  meta = with lib; { if there was no other scoping before that. It there was other scoping i tried to follow that.
Description of changes

Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

evals and no rebuilds


Feature request : add a save to Gitlab|Github|Google Drive option

Hi,
What about adding a "Save to..." Gitlab/Github/Drive feature to foster collaboration on the files long term ?
I would like to have this (kinda same as draw.io feature).
WDYT ?

Duplicate of #2060


feat: add entry to build info

🔗 Linked issue
resolves #1650
❓ Type of change

[ ] 📖 Documentation (updates to the documentation, readme, or JSdoc annotations)
[ ] 🐞 Bug fix (a non-breaking change that fixes an issue)
[ ] 👌 Enhancement (improving an existing functionality like performance)
[x] ✨ New feature (a non-breaking change that adds functionality)
[ ] 🧹 Chore (updates to the build process or auxiliary tools and libraries)
[ ] ⚠ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description
While working on https://github.com/unjs/nitro/pull/1557, I noticed that for presets that can have multiple entries, like firebase, there's no straightforward way to identify which one has been used. This adds a reference to the preset used in the build info.
📝 Checklist

[ ] I have linked an issue or discussion.
[ ] I have updated the documentation accordingly.

Thanks for the PR @Hebilicious. I guess i would prefer to use current method for firebase preset at least to keep the preset implementations simplicity and decoupled as much as possible.
While current approach for firebase gen handling is not perfect, i am happy to discuss about some other alternative ideas once we migrated repo to a monorepo. Also we can use virtual chunks for entry or simply support dynamic entry based on user input config (it was absence by the time of implementing that PR...)


Make show_tabs_always option behave how it should

As of now, the show_tabs_always option does not influence the appearance of tabline at all, as everything is shown regardless. Maybe this was accidentally changed at some point, idk. This pull request aims to give the show_tabs_always option meaning.

Thanks for making a PR!

I had to revert this change unfortunately because it breaks default behavior. Maybe we can document that if users want this behavior, they can set enable=false and manually configure the tabline.
I'm open to other suggestions too.

Can we make it such that the show_tabs_always option only has meaning when the show_tabs_only option is enabled? This way default behaviour is preserved.

Or make show_tabs_always default to true and keep #36. That would also preserve the expected default behaviour.


[Bug] A user cannot be in more than 100 studies at a time

Describe the bug
If a user is in more than 100 studies as an admin or a user, the Studies page will fail to load for that user, giving a validation error from DynamoDB BatchGetItem in the returned JSON. From what I understand, the first query which finds which studies a user has access to, succeeds. Only the fetch of the details for these studies fails.
To Reproduce
Steps to reproduce the behavior:

Add a user as an admin to 100 studies
Try to load the Studies page

Expected behavior
As an administrator using SWB, I would expect the Studies page to be displayed.
Versions (please complete the following information):
We are using a fork from an earlier version, but the code responsible for this issue has not changed.
Additional context
I have been able to patch the issue on our deployment by breaking up the BatchGetItem requests into chunks of 100.
The code which performs the get batch get operation in your main branch:
https://github.com/awslabs/service-workbench-on-aws/blob/1d2fe14e04218070aa7034a9868002643da88bc6/addons/addon-base/packages/services/lib/db/getter.js#L121-L141
Our temporary patch for this:
  async get() {
    if (this.params.Key && this.params.Keys)
      throw new Error('DbGetter <== only key() or keys() may be called, not both');

    let data = [];
    if (this.params.Key) data = (await this.client.get(this.params).promise()).Item;
    else if (this.params.Keys) {
      // BatchGet supports a maximum of 100 keys, since this becomes
      // possible within HIC TRE, we want to break it up into chunks.
      for (let keySet of _.chunk([ ...this.params.Keys ], 100)) {
	this.params.Keys = keySet;

	const batchParams = { RequestItems: {} };
	batchParams.RequestItems[this.params.TableName] = { ...this.params };

	if (this.params.ReturnConsumedCapacity) {
          batchParams.RequestItems.ReturnConsumedCapacity = this.params.ReturnConsumedCapacity;
          delete batchParams.RequestItems[this.params.TableName].ReturnConsumedCapacity;
	}

	data.push(...(await this.client.batchGet(batchParams).promise()).Responses[this.params.TableName]);
      }
    }

    return unmarshal(data);
  }

I suspect BatchGetItem is the wrong approach and that a DynamoDB Scan might be more appropriate.
Thanks

Thank you for reaching out. Your request has been added to our backlog for research computing solutions. Our team curates these requests for fit with our solutions vision on a regular basis. Please watch this space for new updates. If you require immediate assistance, please reach out to your AWS account team. Please note that security issues should be reported directly to AWS Security at<EMAIL_ADDRESS>

Re the addition of tag 'closing-soon-if-no-response' - I'd rather it didn't close :smile:


Fix library prefixes

Should fix
https://github.com/GuilhermeGSousa/godot-motion-matching/issues/81
https://github.com/GuilhermeGSousa/godot-motion-matching-demo/issues/9


Platform-specific linker option ignored when specified using cfg syntax

Problem
When the following is placed in .cargo/config.toml, the linker option is respected (on an x86_64 Linux system):
[target.x86_64-unknown-linux-gnu]
linker = "clang"
rustflags = ["-C", "link-arg=-fuse-ld=lld"]

However, when the cfg syntax is used, as in the following, the linker option seems to be ignored (-C linker=clang isn't visible in cargo -vv output):
[target.'cfg(unix)']
linker = "clang"
rustflags = ["-C", "link-arg=-fuse-ld=lld"]

In either case, the rustflags option is respected.
Is the linker option being ignored here a bug?
Steps
No response
Possible Solution(s)
No response
Notes
No response
Version
cargo 1.71.1 (7f1d04c00 2023-07-29)
release: 1.71.1
commit-hash: 7f1d04c0053083b98fa50b69b6f56e339b0556a8
commit-date: 2023-07-29
host: x86_64-unknown-linux-gnu
libgit2: 1.6.4 (sys:0.17.1 vendored)
libcurl: 8.0.1-DEV (sys:0.4.61+curl-8.0.1 vendored ssl:OpenSSL/1.1.1t)
ssl: OpenSSL 1.1.1t  7 Feb 2023
os: Ubuntu 22.04 (jammy) [64-bit]

This section of [target] config lists all possible configurations and doesn't include target.<cfg>'.linker and target.<cfg>.<links>.
Delved into the history, it seems that just nobody requested for that.

For rustflags — https://github.com/rust-lang/cargo/pull/3854
For runner — https://github.com/rust-lang/cargo/pull/5959

However, the mechanisms of plain target-triple and cfg expression are different. May need some efforts to implement those configs. My guess is that they'll behave the same as target.<cfg>.runner: <triple> takes precedence over them, and errors out when multiple <cfg> of them found.
@ehuss the wise, was there any reason not supporting linker and link overridden with cfg expression?

I don't think there is a specific reason other than nobody needed it. If we add it, I suppose it should follow the same logic as runner.

Thanks for quick reply!
Here are pointers for people wanting to jump in on adding target.<cfg>.linker feature:

Basically as Eric said, it should follow the same logic as runner. Here is how runner find matched config: https://github.com/rust-lang/cargo/blob/7e9de3f4ec3708f500bec142317895b96131e47c/src/cargo/core/compiler/compilation.rs#L403-L406
A new linker field is required to be added to TargetCfgConfig: https://github.com/rust-lang/cargo/blob/7e9de3f4ec3708f500bec142317895b96131e47c/src/cargo/util/config/target.rs#L12
TargetConfig.linker is accessible through the field itself, as well as via BuildContext::linker. We should consolidate them into one place. By copying runner's logic, perhaps adding a target_links field to Compilation struct?

@rustbot label -S-needs-info +S-accepted +E-easy
Assumed it is not too hard, though I might be wron.

@rustbot claim


Snapshot file name

Also, currently the snapshots are generated with a name similar to "snapshot-oIcU812.jpg" and this can make the snapshots hard to sort in large installations. If the snapshot names could be either taken from the camera with "FrontCam" generating "FrontCam.jpg" for example, or be specified by the end user, that would be ideal.

In 0.0.4


Feature: On server deploy, persist settings file path at deploy time and reload at undeploy

Currently the settings file path chosen during a server deploy is not saved, so when the solution is undeployed, the original settings file path is unknown.  In some situations it would be helpful to use the same settings file again during undeployment.

The deploy can save the value of $(SettingsFilePath) to the registry, and reload the value during undeploy.
This work item was migrated from CodePlex
CodePlex work item ID: '7635'
Assigned to: 'tfabraham'
Vote count: '1'

[UnknownUser@5/9/2013]
Resolved with changeset 72823: Add Start menu shortcuts for Quick Deploy, Preprocess and Import Bindings, Terminate Service Instances; remember selected settings file from deploy for use in undeploy (#3858, 7635, 10095)


idea: startup dialog

instead of building many different init files, and picking them in UnityLauncherPro,
the editor script could display startup menu inside unity,
then you can click few options to customize initialization..
like:

webgl/mobile/vr template
import custom scripting templates
create folders (enabled by default)
other few click options and big "start" button (also skip init button)
keyboard shortcuts 1-9

(but need to save those settings somewhere globally, not per project or per editor..)

initial startup dialog is there, need to make it look nicer and save settings to EditorPrefs.


Memory shortage

What is your issue?
Hi,
As part of my project, I need to extract raster values in a one-kilometer buffer of many points.
I used "xarray.open_rasterio" function to open the GeoTIFF file. Then I used "ds.rio.clip" to clip the raster at the buffer.
My raster is 30*30 meters for the whole contiguous US (more than19 GB). I used Hight Performance Computing clusters with 192 GB of ram, but I kept receiving memory errors. Has anyone known an efficient way to clip over a raster?
Here is the code that I use:
`FPA_FOD_NLCD = geemap.csv_to_gdf(in_csv = 'file.csv', latitude = 'LATITUDE', longitude = 'LONGITUDE')
FPA_FOD_NLCD = FPA_FOD_NLCD.to_crs(crs = 'EPSG:26910')
FPA_FOD_NLCD['Land_Cover_buffer'] = None
NLCD = xr.open_rasterio(filename = 'NLCD.tif', masked = True)
buffer = FPA_FOD_NLCD.buffer(distance = 1000, resolution = 6)
buffer_crs = buffer.crs
buffer = buffer.geometry.apply(mapping)
for i in range(len(FPA_FOD_NLCD)):
buffer_NLCD = NLCD.rio.clip(buffer[i:i+1], crs = buffer_crs, drop = True, from_disk = True).mean()
FPA_FOD_NLCD.loc[i, 'Land_Cover_buffer'] = buffer_NLCD
del buffer_NLCD
FPA_FOD_NLCD = FPA_FOD_NLCD.drop(labels = 'geometry', axis = 1)
FPA_FOD_NLCD.to_csv(path_or_buf = f'NLCD/{year}_FPA_FOD_NLCD_buf.csv', sep = ',', index = False)`

I think you need to use dask.
Ask at the rioxarray Discussions for a better discussion.


travis-ci

We should set up continuous integration tests for jams.  Aside from being generally useful, it will specifically let us test and validate on a variety of different host configurations.

+1

Necessary pre-condition:

[ ] rewrite unit tests


BUG: API docs difficult to read in dark mode

Describe your issue.
Testing out the dark mode for a recent PR, I found (subjectively) that the API was difficult to read in dark mode due to the yellowish background. The actual parameter docs etc. look fine.
Examples:

While not being a designer I guess that another color would be better for the dark mode.
Reproducing Code Example
Browser: Chrome 103
Error message
Example Doc URL
SciPy/NumPy/Python version information
irrelevant

Ah right it's the highlights color. I will have a look 👀

I had a look and this is because we are using the same colours as NumPy for the body.
We want these 2 projects to have the same feel and this is why we originally went with the same colours. I could fix this by changing the contrast here and on NumPy (e.g. use #939393), but I am not a UX/UI/designer.
I propose to make a meeting with NumPy and SciPy to discuss what we want to do with colours and dark theme. This is not related to the theme itself as here we want to have our own colour scheme. Or you decide on a colour palette for NumPy and we follow here.
cc @seberg @isabela-pf @MarsBarLee @jarrodmillman

I'd personally prefer to use the theme defaults for SciPy, because the theme is getting wide adoption. NumPy probably should do the same, but that's for the NumPy issue tracker.

Just opened a PR. If there are design/colours concerns, we can address these on the theme side. We have a good working relationship with the theme, they would be happy to get feedbacks on all that and would be happy to make changes for us.


Typo "@replicate_ddl"→"@replicate_ddl"

Italic with escape characters
https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-addmergepublication-transact-sql?view=sql-server-2017

@hyoshioka0128 Thank you!


Remove now outdated paragraphs from Versions section

Fixes https://github.com/OAI/OpenAPI-Specification/issues/3195
Alternative to https://github.com/OAI/OpenAPI-Specification/pull/3214

The well-intended 3.0 rules clearly have joined the dinosaurs now, and retaining them in a document published after their demise is really confusing.

@MikeRalphson what about instead adding a note that this policy was changed in 3.1.0 and referring readers to that document for further details?  That would leave the policy as defined in place, but correctly set expectations that it has not been followed exactly.

It feels odd to me that a 3.0.x document 'knows about' a 3.1.x document, even if it post-dates it. I think that's my gut objection.

I think the important thing here is the UX more than forward knowledge.  The current text sets an incorrect expectation which is very bad UX.

Closed in favor of #3214 after discussion in TDC


Externalise factsets, fixes #90

PR to add support for externalised factsets:

remove all existing factsets
update documentation
change the directories being used for factsets to come from the puppet_factset gem
perform limited testing (use checked out onceover code from local path, tests execute and pass)

@GeoffWilliams can you please rebase this against the latest? I can then merge this PR

@beergeek I'm holding off this one for the moment - I didn't notice the facterdb gem when I wrote this PR, we should probably use that one instead (dontmerge).  If I get chance I'll have a go at rejigging this

@GeoffWilliams cool, happy for you to recommend what you think is better.

Hey mate facterdb in linked issue looks to be the way to go..it may need some extra facts loaded to test all the platforms we want.  This has fallen off my radar for the moment I've had a few other higher priority tasks
On 12 September 2017 4:45:55 PM AEST, beergeek<EMAIL_ADDRESS>wrote:

@GeoffWilliams cool, happy for you to recommend what you think is
better.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/dylanratcliffe/onceover/pull/91#issuecomment-328755190

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

abandoned in favour of leaving things alone or facterdb


GetSimilarityMapForModel returns 'TypeError: No registered converter was able to produce a C++ rvalue of type double from this Python object of type numpy.int64'

Describe the bug
I have a collection of simple XGB Classifier models that operate on morgan fingerprints. In some cases, the module GetSimilarityMapForModel returns the following error:
Traceback (most recent call last):
  File "make_similarity_map.py", line 78, in <module>
    res = plot_similarity_map(mol, CYP_model)
  File "make_similarity_map.py", line 55, in plot_similarity_map
    figure , max_weight = SimilarityMaps.GetSimilarityMapForModel(mol, SimilarityMaps.GetMorganFingerprint, lambda x : get_pred(x, model.predict), counterLines=0,step=0.001, draw2d=d)
  File "/home/user/miniconda3/envs/p36_bk/lib/python3.6/site-packages/rdkit/Chem/Draw/SimilarityMaps.py", line 254, in GetSimilarityMapForModel
    fig = GetSimilarityMapFromWeights(probeMol, weights, **kwargs)
  File "/home/user/miniconda3/envs/p36_bk/lib/python3.6/site-packages/rdkit/Chem/Draw/SimilarityMaps.py", line 175, in GetSimilarityMapFromWeights
    Draw.ContourAndDrawGaussians(draw2d,locs,weights,sigmas,nContours=contourLines,params=ps)
TypeError: No registered converter was able to produce a C++ rvalue of type double from this Python object of type numpy.int64

Other models produce the expected similarity map image. I don't think its an error with the model(s) themselves, as they are able to be loaded and make the appropriate predictions, but fail just at the SimilarityMap stage.
To Reproduce
Here is some simple code to reproduce the error. The code should work w/ model 'cyp1a2.h5' but not model 'cyp3a4.h5' (see attached @ bottom)
from rdkit import Chem
from rdkit.Chem import Draw
import numpy
from rdkit.Chem import AllChem
from rdkit.Chem.Draw import SimilarityMaps
from rdkit.Chem.Draw import rdMolDraw2D
import xgboost as xgb
import io
from PIL import Image

def show_png(data):
    bio = io.BytesIO(data)
    img = Image.open(bio)
    return img

def get_pred(fp, pred_function):
    fp = numpy.array([list(fp)])
    return pred_function(fp)[0]

def plot_similarity_map(mol, model):
    d = Draw.MolDraw2DCairo(900, 900)
    fig , maxweight = SimilarityMaps.GetSimilarityMapForModel(mol, SimilarityMaps.GetMorganFingerprint, lambda x : get_pred(x, model.predict), draw2d=d)
    d.FinishDrawing()
    return d

model = xgb.XGBClassifier()
model.load_model('cyp1a2.h5')

test_smiles = 'Nc5ncc(c2nc(N1CCOCC1)nc3c2CCC3c4ccncc4)cn5'
mol = Chem.MolFromSmiles(test_smiles)

test_fps = numpy.array(AllChem.GetMorganFingerprintAsBitVect(mol, 4, nBits=2048))
test_fps = test_fps.reshape(-1, 2048)

activity_prediction = model.predict(test_fps)[0]
print(f'The activity class is : {activity_prediction}')

res = plot_similarity_map(mol, model)
activity_sim_map = show_png(res.GetDrawingText())
activity_sim_map.save('SimMap.png')

Expected behavior
A SimilarityMap image should be produced, but the above Traceback Error is produced instead.
Configuration (please complete the following information):

RDKit version: '2020.09.1'
OS: Ubuntu 18.04
Python version : 3.6
Are you using conda? Yes
If you are using conda, which channel did you install the rdkit from? coda-forge

cyp1a2.zip
cyp3a4.zip

I found your issue. Numpy Array see all of your element is integer, thus declaring int64 datatype as default, the solution is just add 'dtype=np.float64'

For similarity maps you want to use the predicted probability of being in the class you're most interested in, not the class predictions themselves. Here's a blog post with some sample code which may help:
https://iwatobipen.wordpress.com/2020/05/06/compare-the-view-point-of-different-qsar-models-rdkit-visualize-chemoinformatics/

Thank you @greglandrum and @IchiruTake


Asynchronous requests with session does not work

Hi,
I tried to request multiple URLs at the same time. I have to authenticate against the API URLs therefor I have a opened session object. If I set this session object as kwargs argument to grequests.get() requests taking a long time.
What I have done:
import grequests
response = (grequests.get(url, session=api_session_obj) for url in urls)
grequests.map(response, size=50)
If I do not use session=api_session_obj the requests seems to be really fast but I do not get all information out of the api because I am not authenticated.
Maybe I am doing something wrong here.

Hi @dthielking thanks for the report. I'd like to do some more testing with this, but I am not sure that I'm convinced this is necessarily a problem with grequests.
There's a lot that could be going into play here... Consider that, in the case of not being authenticated, it doesn't take as much work for the webserver to return that response; it doesn't need to examine the content of your request, retrieve any data, or send any sizable content. It may even return a response without invoking any backend application.
On the other hand, if your request is otherwise successful, the webserver has a lot more work to do and presumably the response content will be much larger.  Also consider that, some authentication methods send credentials every single request, which can add overhead as well. The API itself may also be throttling your requests, among other considerations.
Can you quantify a long time? How long does a single authenticated synchronous request take compared to a nonauthenticated request? What happens if you just make 2 requests using grequests, do you still see the problem? How about 10, or 20; does the time seem to scale reasonably for the connection pool size?
Doing some brief testing with sessions and basic authentication, I haven't been able to reproduce this issue. Maybe if you can provide more details about the authentication method or service I can find a way to reproduce it.


[FIXED] Feat: Add the current header and footer in the blog page #1517

Related Issue
#1517

#1517

Fixes:  #1517
Description
The header and the footer of the page was fixed in order to make it look like that of the main landing page.  It fixes issue #1517

#1517
Type of PR

[ ] Bug fix
[X] Feature enhancement
[ ] Documentation update
[ ] Other (specify): _______________

Screenshots / videos (if applicable)
Before:

After:

Checklist:

[X] I have made this change from my own.
[X] My code follows the style guidelines of this project.
[X] I have performed a self-review of my own code.
[X] I have commented my code, particularly in hard-to-understand areas.
[X] I have made corresponding changes to the documentation.
[X] My changes generate no new warnings.
[X] I have tested the changes thoroughly before submitting this pull request.
[X] I have provided relevant issue numbers and screenshots after making the changes.

@PriyaGhosal Check this out

@PriyaGhosal @samarth-6 Check this out and it would be great if you could assign level 3, Thank you!


What version of cuda is suitable, i tried the 11.7 but failure.

The version of cuda does not affect the training, it may be the transformers version that causes the problem. You can try to reduce the version to 4.18, or use a newer version of the code: https://github.com/staoxiao/RetroMAE/tree/master/examples/pretrain


Adds backup integration function for computing Cls

This pull request aims at addressing #302 where it was realized that the computation of Cls could fail unexpectedly when changing the IA amplitude. At the root of the problem was that for some ell the gsl_integration_qag function in ccl_angular_cl failed due to round-off errors before reaching the desired relative accuracy. To try to recover from such failures, I have added a backup integration strategy based on another gsl function which will try to compute the integral if the first method fails. This alternative method, based on  gsl_integration_cquad is in principle slower than the default method but should be more robust.

One detail though, is there any mechanism in CCL to display warnings ? For instance to notify the user that the default integration failed?

I checked this out and used a jupyter notebook for computing Cl's for cosmic shear and gxy-gxy lensing including IA with amplitudes (bias_ia) ranging from 0 to 100 and for ells in the range [2,3000]. Everything worked well for me and checks pass in C and python. However, the same notebook worked fine for me in master as well, so I'd suggest for @joezuntz to check this PR solves his issue #302 specifically.

I've  opened a  new  PR for this, starting from a clean version of master, we should close this PR and continue with the other one: #406

This is now outdated and solved by another PR, closing this one.


Need to use in dart <2.10 so is there any way to do it?

I am using flutter 1.23. with one of my old projects due to very high dependency complications I can't switch to another so can you please help me that how can I configure it in dart<2.10?

Hi, Akash.
You can fork this package and move it to the flutter 1.23 and dart 2.9. I can't imagine another way to solve your problem :)

If possible can you please do it and commit so that I can directly
integrate it with my project and many other like me.
On Tue, 28 Dec, 2021, 5:52 pm Zemlaynikin Max, @.***>
wrote:

Hi, Akash.
You can fork this package and move it to the flutter 1.23 and dart 2.9. I
can't imagine another way to solve your problem :)
—
Reply to this email directly, view it on GitHub
https://github.com/Maksimka101/app_install_date/issues/1#issuecomment-1002070223,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AORMNPFECKPH3GGGPRN24HTUTGTXHANCNFSM5K4A6GBQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID:
@.***>

No, I can't do it, sorry
However it's easy and you can try to do it by yourself.

Ok, thanks for the reply.
On Tue, 28 Dec, 2021, 6:00 pm Zemlaynikin Max, @.***>
wrote:

No, I can't do it, sorry
However it's easy and you can try to do it by yourself.
—
Reply to this email directly, view it on GitHub
https://github.com/Maksimka101/app_install_date/issues/1#issuecomment-1002075358,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AORMNPDFNLVVD53PMB7NFNLUTGUUVANCNFSM5K4A6GBQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID:
@.***>


conditions certificate    status: "False"

Hi, I use cert-manager deploying with HELM in kubernetes version 1.9.7.  Actuality have a problem  as renew the certificate wildcard that use:
apiVersion: certmanager.k8s.io/v1alpha1
kind: Certificate
metadata:
  annotations:
  name: development-mysiste-com
  namespace: kube-system
  resourceVersion: "33868701"
  selfLink: /apis/certmanager.k8s.io/v1alpha1/namespaces/kube-system/certificates/development-mysite-com
  uid: bc8300ed-86a2-11e8-982f-126a067539fa
spec:
  acme:
    config:
    - dns01:
        provider: dns
      domains:
      - '*.development.mysite.com'
  commonName: ""
  dnsNames:
  - '*.development.mysite.com'
  issuerRef:
    kind: ClusterIssuer
    name: letsencryptdns
  secretName: development-mysite-com-tls
status:
  acme:
    order:
      url: https://acme-v02.api.letsencrypt.org/acme/order/36871475/56430546
  conditions:
  - lastTransitionTime: 2018-09-04T20:12:29Z
    message: Order validated
    reason: OrderValidated
    status: "False"
    type: ValidateFailed
  - lastTransitionTime: 2018-09-04T20:12:31Z
    message: Certificate renewed successfully
    reason: CertRenewed
    status: "True"
    type: Ready

I am confused, the certificate is ok o not? Because, when check the certificate with a curl  say is ok . For example

curl -v myapp.development.mysite.com | more

Rebuilt URL to: https://myapp.development.mysite.com/
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
Dload  Upload   Total   Spent    Left  Speed
0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying <IP_ADDRESS>...
Connected to myappdevelopment.mysite.com (<IP_ADDRESS>) port 443 (#0)
0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* found 148 certificates in /etc/ssl/certs/ca-certificates.crt
found 597 certificates in /etc/ssl/certs
ALPN, offering http/1.1
SSL connection using TLS1.2 / ECDHE_RSA_AES_256_GCM_SHA384
server certificate verification OK
server certificate status verification SKIPPED
common name: *.development.mysite.com (matched)
server certificate expiration date OK
server certificate activation date OK
certificate public key: RSA
certificate version: #3
subject: CN=*.development.mysite.com
start date: Tue, 04 Sep 2018 19:12:30 GMT
expire date: Mon, 03 Dec 2018 19:12:30 GMT
issuer: C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3
compression: NULL
ALPN, server accepted to use http/1.1
0     0    0     0    0     0      0      0 --:--:--  0:00:01 --:--:--     0> GET / HTTP/1.1

Host: myapp.development.mysite.com
User-Agent: curl/7.47.0
Accept: /

< HTTP/1.1 200 OK
< Server: nginx/1.13.9
< Date: Mon, 08 Oct 2018 19:54:54 GMT
< Content-Type: text/html; charset=utf-8
< Content-Length: 990
< Connection: keep-alive
< Vary: Accept-Encoding
< Accept-Ranges: bytes
< Cache-Control: no-store
< Last-Modified: Tue, 13 Feb 2018 11:17:03 GMT

  - lastTransitionTime: 2018-09-04T20:12:29Z
    message: Order validated
    reason: OrderValidated
    status: "False"
    type: ValidateFailed

This is a poor status condition on our part - if you look carefully, the condition 'ValidateFailed' is set to 'False'.
This condition will change in future, as part of some refactoring of the ACME implementation.
Sorry for the confusion!


actions: bump node

Applied mkpr on undefined
sed s/18\.[0-9\.]*/18.1.0/

:tada: This PR is included in version 1.15.8 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Does not support IE8

help, can't center div

browser: web
brand: windows
architecture: phone
time: now
why: idk, but I take this failure personally

Get gud

thank, it works now

got gud, now works on my machine

Well done


tmp diff test

This PR is temporary playground of a diff test i wanted to pass around.
I suggest a test as following:

Read some format (from) file in to a protobom document.
Translate protobm in to a other format (to)
Read back the translated (to) document back in to the protobom document.
Option 1: Compare the original document protobom (from) to the translated one (to).
Option 2: Compare the original (from) golden document the translated one (to)
Optoin 3: Create a NEW translated golden document and compare it to the translated one (to)

What we can test,
We can start follow what fields are persistent across translation and what are not.
We don't have to have a perfect score on the diff just yet , but i can be a starting point to solidify what we expect to change across a translation and what we don't.
Open issues:

Test does not actually pass there seems there are differences we yet to formalize in to the test.
A detailed investigation of all losing info.
PS: PR is far from ready i just wanted to share code to scketch this out.

@puerco I not sure i fully understood your comment.

just but remember that we need to ensure conformance to/from the native formats to the neutral representation. Not from format to format to curve complexity.

Do you mean like the current conformance tests logic where there is one reading operation in to the neutral representation or similar to my suggestion where there is another writer operations (then another read to return to the neutral representation?).

Up


Cow: Watch nadinecollections.com

Cow requests the watch of the watch_keyword nadinecollections\.com. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

nadinecollections\.com has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by Makyen in Charcoal HQ


Unfriendly error message when trying to use a version that doesn't exist

Here I was trying to use a deno version a few updates back but accidentally referenced a version that never existed. This probably should not cause tea to panic.
$ deno~1.29.4 --version
resolving package graph
{
  project: "deno.land",
  path: ~/.tea/tea.xyz/var/pantry/projects/deno.land/package.yml,
  constraint: ~1.29.4,
  shebang: "deno",
  version: undefined
}

panic: spilt tea. we’re sorry and we’ll fix it… but you have to report the bug!

    https://github.com/teaxyz/cli/issues/new?title=panic%3Ano+bottle+available

----------------------------------------------------->> attachment begin
Error: no bottle available
    at resolve (file:///private/tmp/tea-cli-20230128-57004-vtaatg/tea-0.21.4/src/prefab/resolve.ts:30:23)
    at async install (file:///private/tmp/tea-cli-20230128-57004-vtaatg/tea-0.21.4/src/hooks/useExec.ts:88:38)
    at async default (file:///private/tmp/tea-cli-20230128-57004-vtaatg/tea-0.21.4/src/hooks/useExec.ts:65:25)
    at async file:///private/tmp/tea-cli-20230128-57004-vtaatg/tea-0.21.4/src/app.ts:37:63
<<----------------------------------------------------- attachment end

lol, will fix.
We default everything to panic, this way we get the bug reports and fix it. However, sorry for the way it sounds :D

https://github.com/teaxyz/cli/pull/355

Nice!


SIGILL in a heavy test

As I was running heavy tests for #3781, I stumbled upon a SIGILL for test preserves_dos_line_endings:
The command I ran was:
RUST_BACKTRACE=full RUN_SLOW_TESTS=true cargo test --package rust-analyzer --test heavy_tests -- preserves_dos_line_endings --exact --nocapture

Here's the output I got:
running 1 test
thread 'preserves_dos_line_endings' panicked at 'unexpected request: Request { id: RequestId(U64(1)), method: "window/workDoneProgress/create", params: Object({"token": String("rustAnalyzer/startup")}) }', crates/rust-analyzer/tests/heavy_tests/support.rs:191:42
stack backtrace:
   0:        0x10d0d7d45 - backtrace::backtrace::libunwind::trace::h5c84db184dbe55ed
                               at /Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/libunwind.rs:88
   1:        0x10d0d7d45 - backtrace::backtrace::trace_unsynchronized::hfabf504f184a4062
                               at /Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/mod.rs:66
   2:        0x10d0d7d45 - std::sys_common::backtrace::_print_fmt::hb18545a457444b58
                               at src/libstd/sys_common/backtrace.rs:77
   3:        0x10d0d7d45 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hff7732c2e44ef8b9
                               at src/libstd/sys_common/backtrace.rs:59
   4:        0x10d0f9add - core::fmt::write::hd42cb3dea57bae40
                               at src/libcore/fmt/mod.rs:1052
   5:        0x10d0d358b - std::io::Write::write_fmt::ha39f6009af02b1d2
                               at src/libstd/io/mod.rs:1426
   6:        0x10d0da26a - std::sys_common::backtrace::_print::h5cfb8cdd320f1e64
                               at src/libstd/sys_common/backtrace.rs:62
   7:        0x10d0da26a - std::sys_common::backtrace::print::hef683e3bc77ce269
                               at src/libstd/sys_common/backtrace.rs:49
   8:        0x10d0da26a - std::panicking::default_hook::{{closure}}::h389f076017b5df43
                               at src/libstd/panicking.rs:204
   9:        0x10d0d9f6a - std::panicking::default_hook::h04b06ec20c41bf02
                               at src/libstd/panicking.rs:224
  10:        0x10d0da8bd - std::panicking::rust_panic_with_hook::hccde7faed9a5c398
                               at src/libstd/panicking.rs:472
  11:        0x10d0da482 - rust_begin_unwind
                               at src/libstd/panicking.rs:380
  12:        0x10d11f8db - std::thread::local::fast::Key<T>::try_initialize::hafc83b0b9dac2707
  13:        0x10b6a99ae - heavy_tests::support::Server::send_request_::h66ed10add5465d05
                               at crates/rust-analyzer/tests/heavy_tests/support.rs:191
  14:        0x10b6de4a1 - heavy_tests::support::Server::send_request::h369a05de7799ebac
                               at crates/rust-analyzer/tests/heavy_tests/support.rs:184
  15:        0x10b6dd6bf - heavy_tests::support::Server::request::h64ff7559ae0f97ff
                               at crates/rust-analyzer/tests/heavy_tests/support.rs:163
  16:        0x10b6d8754 - heavy_tests::preserves_dos_line_endings::hb8e8cb92d0bc833f
                               at crates/rust-analyzer/tests/heavy_tests/main.rs:554
  17:        0x10b6c9a71 - heavy_tests::preserves_dos_line_endings::{{closure}}::haa4c65d850973659
                               at crates/rust-analyzer/tests/heavy_tests/main.rs:536
  18:        0x10b6ca3b1 - core::ops::function::FnOnce::call_once::h4157c612650e1b64
                               at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/libcore/ops/function.rs:232
  19:        0x10b71460e - <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once::h27d1322c81491638
                               at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/liballoc/boxed.rs:1015
  20:        0x10d0e1cbb - __rust_maybe_catch_panic
                               at src/libpanic_unwind/lib.rs:86
  21:        0x10b72dc85 - std::panicking::try::h64fe1944bde3d8ca
                               at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/libstd/panicking.rs:281
  22:        0x10b72dc85 - std::panic::catch_unwind::he2328e79964636c4
                               at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/libstd/panic.rs:394
  23:        0x10b72dc85 - test::run_test_in_process::h316addbc1cb07abe
                               at src/libtest/lib.rs:539
  24:        0x10b72dc85 - test::run_test::run_test_inner::{{closure}}::h71c25705e981f4bd
                               at src/libtest/lib.rs:452
  25:        0x10b7088bb - std::sys_common::backtrace::__rust_begin_short_backtrace::hfde8bd6e56b0c899
                               at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/libstd/sys_common/backtrace.rs:129
  26:        0x10b70cf8b - std::thread::Builder::spawn_unchecked::{{closure}}::{{closure}}::hd839c9ae7715b537
                               at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/libstd/thread/mod.rs:475
  27:        0x10b70cf8b - <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once::h37ac3fabcd45fa01
                               at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/libstd/panic.rs:318
  28:        0x10b70cf8b - std::panicking::try::do_call::hb5b064d52913f725
                               at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/libstd/panicking.rs:305
  29:        0x10d0e1cbb - __rust_maybe_catch_panic
                               at src/libpanic_unwind/lib.rs:86
  30:        0x10b70dc46 - std::panicking::try::h5cadccbfd19fc144
                               at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/libstd/panicking.rs:281
  31:        0x10b70dc46 - std::panic::catch_unwind::h046ca8a6018c411f
                               at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/libstd/panic.rs:394
  32:        0x10b70dc46 - std::thread::Builder::spawn_unchecked::{{closure}}::h96a4708b76aef308
                               at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/libstd/thread/mod.rs:474
  33:        0x10b70dc46 - core::ops::function::FnOnce::call_once{{vtable.shim}}::hdf8bbeeed49234cf
                               at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/libcore/ops/function.rs:232
  34:        0x10d0cc8de - <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once::h606f2dced48ff3c4
                               at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/liballoc/boxed.rs:1015
  35:        0x10d0e12fe - <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once::h0ece8cce658c93ae
                               at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/liballoc/boxed.rs:1015
  36:        0x10d0e12fe - std::sys_common::thread::start_thread::h30bbd9f3fb79e88c
                               at src/libstd/sys_common/thread.rs:13
  37:        0x10d0e12fe - std::sys::unix::thread::Thread::new::thread_start::h7199626a1bd56873
                               at src/libstd/sys/unix/thread.rs:80
  38:     0x7fff6e679109 - <unknown>
thread 'preserves_dos_line_endings' panicked at 'assertion failed: `(left == right)`
  left: `RequestId(U64(1))`,
 right: `RequestId(U64(2))`', crates/rust-analyzer/tests/heavy_tests/support.rs:194:21
stack backtrace:
   0:        0x10d0d7d45 - backtrace::backtrace::libunwind::trace::h5c84db184dbe55ed
                               at /Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/libunwind.rs:88
   1:        0x10d0d7d45 - backtrace::backtrace::trace_unsynchronized::hfabf504f184a4062
                               at /Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/mod.rs:66
   2:        0x10d0d7d45 - std::sys_common::backtrace::_print_fmt::hb18545a457444b58
                               at src/libstd/sys_common/backtrace.rs:77
   3:        0x10d0d7d45 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hff7732c2e44ef8b9
                               at src/libstd/sys_common/backtrace.rs:59
   4:        0x10d0f9add - core::fmt::write::hd42cb3dea57bae40
                               at src/libcore/fmt/mod.rs:1052
   5:        0x10d0d358b - std::io::Write::write_fmt::ha39f6009af02b1d2
                               at src/libstd/io/mod.rs:1426
   6:        0x10d0da26a - std::sys_common::backtrace::_print::h5cfb8cdd320f1e64
                               at src/libstd/sys_common/backtrace.rs:62
   7:        0x10d0da26a - std::sys_common::backtrace::print::hef683e3bc77ce269
                               at src/libstd/sys_common/backtrace.rs:49
   8:        0x10d0da26a - std::panicking::default_hook::{{closure}}::h389f076017b5df43
                               at src/libstd/panicking.rs:204
   9:        0x10d0d9f6a - std::panicking::default_hook::h04b06ec20c41bf02
                               at src/libstd/panicking.rs:224
  10:        0x10d0da8bd - std::panicking::rust_panic_with_hook::hccde7faed9a5c398
                               at src/libstd/panicking.rs:472
  11:        0x10d0da482 - rust_begin_unwind
                               at src/libstd/panicking.rs:380
  12:        0x10d11f8db - std::thread::local::fast::Key<T>::try_initialize::hafc83b0b9dac2707
  13:        0x10b6a9baa - heavy_tests::support::Server::send_request_::h66ed10add5465d05
                               at crates/rust-analyzer/tests/heavy_tests/support.rs:194
  14:        0x10b6dec2e - heavy_tests::support::Server::send_request::hef92733f08bf1ddc
                               at crates/rust-analyzer/tests/heavy_tests/support.rs:184
  15:        0x10b6ddf3f - heavy_tests::support::Server::request::h85fa477b69efda57
                               at crates/rust-analyzer/tests/heavy_tests/support.rs:163
  16:        0x10b6aa50d - <heavy_tests::support::Server as core::ops::drop::Drop>::drop::h9e82b1f280dff33b
                               at crates/rust-analyzer/tests/heavy_tests/support.rs:249
  17:        0x10b6caab5 - core::ptr::drop_in_place::h25b942bb93f11742
                               at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/libcore/ptr/mod.rs:174
  18:        0x10b6d77c4 - heavy_tests::preserves_dos_line_endings::hb8e8cb92d0bc833f
                               at crates/rust-analyzer/tests/heavy_tests/main.rs:583
  19:        0x10b6c9a71 - heavy_tests::preserves_dos_line_endings::{{closure}}::haa4c65d850973659
                               at crates/rust-analyzer/tests/heavy_tests/main.rs:536
  20:        0x10b6ca3b1 - core::ops::function::FnOnce::call_once::h4157c612650e1b64
                               at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/libcore/ops/function.rs:232
  21:        0x10b71460e - <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once::h27d1322c81491638
                               at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/liballoc/boxed.rs:1015
  22:        0x10d0e1cbb - __rust_maybe_catch_panic
                               at src/libpanic_unwind/lib.rs:86
  23:        0x10b72dc85 - std::panicking::try::h64fe1944bde3d8ca
                               at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/libstd/panicking.rs:281
  24:        0x10b72dc85 - std::panic::catch_unwind::he2328e79964636c4
                               at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/libstd/panic.rs:394
  25:        0x10b72dc85 - test::run_test_in_process::h316addbc1cb07abe
                               at src/libtest/lib.rs:539
  26:        0x10b72dc85 - test::run_test::run_test_inner::{{closure}}::h71c25705e981f4bd
                               at src/libtest/lib.rs:452
  27:        0x10b7088bb - std::sys_common::backtrace::__rust_begin_short_backtrace::hfde8bd6e56b0c899
                               at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/libstd/sys_common/backtrace.rs:129
  28:        0x10b70cf8b - std::thread::Builder::spawn_unchecked::{{closure}}::{{closure}}::hd839c9ae7715b537
                               at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/libstd/thread/mod.rs:475
  29:        0x10b70cf8b - <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once::h37ac3fabcd45fa01
                               at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/libstd/panic.rs:318
  30:        0x10b70cf8b - std::panicking::try::do_call::hb5b064d52913f725
                               at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/libstd/panicking.rs:305
  31:        0x10d0e1cbb - __rust_maybe_catch_panic
                               at src/libpanic_unwind/lib.rs:86
  32:        0x10b70dc46 - std::panicking::try::h5cadccbfd19fc144
                               at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/libstd/panicking.rs:281
  33:        0x10b70dc46 - std::panic::catch_unwind::h046ca8a6018c411f
                               at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/libstd/panic.rs:394
  34:        0x10b70dc46 - std::thread::Builder::spawn_unchecked::{{closure}}::h96a4708b76aef308
                               at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/libstd/thread/mod.rs:474
  35:        0x10b70dc46 - core::ops::function::FnOnce::call_once{{vtable.shim}}::hdf8bbeeed49234cf
                               at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/libcore/ops/function.rs:232
  36:        0x10d0cc8de - <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once::h606f2dced48ff3c4
                               at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/liballoc/boxed.rs:1015
  37:        0x10d0e12fe - <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once::h0ece8cce658c93ae
                               at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/liballoc/boxed.rs:1015
  38:        0x10d0e12fe - std::sys_common::thread::start_thread::h30bbd9f3fb79e88c
                               at src/libstd/sys_common/thread.rs:13
  39:        0x10d0e12fe - std::sys::unix::thread::Thread::new::thread_start::h7199626a1bd56873
                               at src/libstd/sys/unix/thread.rs:80
  40:     0x7fff6e679109 - <unknown>
thread panicked while panicking. aborting.
error: test failed, to rerun pass '-p rust-analyzer --test heavy_tests'

Caused by:
  process didn't exit successfully: `/Users/ignition/Projects/oss/rust-analyzer/target/debug/deps/heavy_tests-6f6fae431553e10c preserves_dos_line_endings --exact --nocapture` (signal: 4, SIGILL: illegal instruction)

I would love to figure it out, if you can assign it to me :)

It's not SIGILL, it's a failed assertion:
thread 'preserves_dos_line_endings' panicked at 'assertion failed: `(left == right)`
  left: `RequestId(U64(1))`,
 right: `RequestId(U64(2))`', crates/rust-analyzer/tests/heavy_tests/support.rs:194:21

I think SIGILL (well, ud2) is used as a way to abort the process. This also came up in https://github.com/rust-analyzer/rust-analyzer/pull/3754#issuecomment-605871930 and the solution was probably https://github.com/rust-analyzer/rust-analyzer/pull/3754/commits/12297ab67533200748ee9f60da4bc86dee1133d9. You might want to rebase over #3754 if you started from an older commit.

Hi, thanks a lot for your super fast answer!
I forked the project this morning, the last commit seems to be the master tip: https://github.com/rust-analyzer/rust-analyzer/commit/6f0d8db529478ce41b429f06708fa600a97c2151

I think SIGILL (well, ud2) is used as a way to abort the process.

I think so as well, the trace states it panicked while panicking:
thread panicked while panicking. aborting.
What I would actually try to do is have the test pass (and maybe figure out what is going on, because it seems like #3754 didnt completely fix it)
Do you think I can give it a try ?

yeah, I can rerproduce the problem locally. @o0Ignition0o if you have time to look into this, go for it!
Otherwise, I'll try to fix this later today, flaky tests are bad.

I forked the project this morning, the last commit seems to be the master tip: 6f0d8db

Ah, bummer.

thread panicked while panicking. aborting.

Yeah, that's probably the reason it aborts in that way.

Do you think I can give it a try ?

I think so, but I have no idea what's wrong :-).

actually, let me take a look at this rn, as it blocks other PRs...


Added Licence Text to the file header

This is important for those that want to include this file in their own project because MIT states that the LICENCE should be written somewhere. So this is only for convenience for those that copy this file in their own sources

anything I can do to get this one merged?

Hi Michael,
I'll be happy to merge if you add the title to the top of the license, The MIT License (MIT). I wouldn't want people thinking this was a custom license.
I did add a license file to the project itself.


fix(ToolTip): A11y Updates (revert of revert)

Overview
Keyboard-only users were not able to activate the tooltip. Screenreader users did not have the tooltip narrated to them.

Change focus to  focus-within & adds aria-live: polite for ToolTip contents.
Removes storybook comment on non-clickable elements allowed within.

PR Checklist

[ ] Related to designs:
[x] Related to JIRA ticket: REACH-774
[x] I have run this code to verify it works
[x] This PR includes unit tests for the code change

Testing

Turn on VoiceOver on Mac (or ChromeVox extension for Chrome/any alternative)
https://606dbfd55f00601ac8e7c74b--gamut-preview.netlify.app/storybook/?path=/docs/atoms-tooltip--tool-tip
Keyboard nav to over the tooltips

Note
I moved too fast on the original PR and merged https://github.com/Codecademy/client-modules/pull/1604 before getting input from all teams requested! My mistake.
Reverts Codecademy/client-modules#1605 which reverts https://github.com/Codecademy/client-modules/pull/1604

📬Published Alpha Packages:@codecademy/gamut-kit@0.3.4-alpha.c14a61.0@codecademy/gamut-labs@13.3.4-alpha.c14a61.0@codecademy/gamut@29.8.4-alpha.c14a61.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://606dd70017c3fc00c0ce9f0e--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:@codecademy/gamut-kit@0.3.5-alpha.cb1956.0@codecademy/gamut-labs@13.3.5-alpha.cb1956.0@codecademy/gamut@29.9.1-alpha.cb1956.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://606f1e9851d5c6f23e564471--gamut-preview.netlify.appDeploy Logs


pip needs to be temporarily downgraded to 24.1.2

Using pip 24.2 with pip check results in the error ninja <IP_ADDRESS> is not supported on this platform when running pip check, so we have to temporarily downgrade to pip 24.1.2. We should remove the pinned version once this is resolved.
Upstream issue: https://github.com/scikit-build/ninja-python-distributions/issues/256

This has been fixed upstream, so we should just need to bump the ninja version to <IP_ADDRESS>.


Add changelog for #2368

@myronmarston as requested

LGTM
Sent from my iPhone

On Mar 1, 2017, at 5:57 PM, Xavier Shay<EMAIL_ADDRESS>wrote:
@myronmarston as requested
You can view, comment on, or merge this pull request online at:
https://github.com/rspec/rspec-core/pull/2392
Commit Summary
Add changelog for #2368
File Changes
M Changelog.md (4)
Patch Links:
https://github.com/rspec/rspec-core/pull/2392.patch
https://github.com/rspec/rspec-core/pull/2392.diff
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.


New package: Settn v0.1.0

Registering package: Settn
Repository: https://github.com/phyjswang/Settn.jl
Created by: @phyjswang
Version: v0.1.0
Commit: d98cf637d95041c3dc7ca86083ba26a29f0e81e1
Git reference: HEAD
Description: Series-expansion thermal tensor network (SETTN)

Hi, although my package name Settn.jl is similar to Satn.jl, they are distinguishable.
Moreover, this name (SETTN) is the abbreviation of the algorithm (see the original paper Physical Review B 95, 161104). Hence I think it would be best to stick to Settn.jl.


Improve translation of docs/concepts/workloads/controllers/deployment.md

This is a Feature Request
This is a follow-up issue of #21497. The current ingress page has some work to do as it does not sound quite natural as Japanese.
What would you like to be added
Update translation of docs/concepts/workloads/controllers/deployment.md
Why is this needed
Comments
/language ja

/assign

/close


Bounds fuzz testing

@sgillies I integrated hypothesis testing to check for more edge cases -- seeing the logic implemented in #101 not passing the randomized roundtrip testing with this.

Coverage decreased (-0.03%) to 99.899% when pulling 3484c07a26bd01eee050f41269ed3a6ce38f3d4d on bounds-fuzz-testing into a010bff0f0dee4b0677e950338b350c642878757 on issue100.

Running the same experiment as in #101 with this branch gives:
import mercantile

z = 10
tiles = [[x, y, z] for x in range(2 ** z) for y in range(2 ** z)]
btiles = [list(mercantile.bounding_tile(*mercantile.bounds(*t))) for t in tiles]

difftiles = [t for t, b in zip(tiles, btiles) if t != b]

print(len(difftiles))

0

@dnomadb thanks, but I'd like to close this one in favor of #101, which has a few other code improvements. Okay?

Fine with me @sgillies, intent here was to demonstrate the issue I was seeing in #101, which it accomplished!


Log all folder loads after application started

Now we log:

file reloaded
new file created
file deleted

Need:

new api interface folder (lib and domain too) with files loaded
folder deleted

Done: https://github.com/metarhia/impress/pull/1545


WIP: CharacterSelectionModal refactoring and followup changes for single selection

Describe your changes (WIP!)
Refactoring for CharacterSelectionModal.tsx and CharacterMultiSelectionModal.tsx:

Merged the functionality of both modals back into one single modal - props being passed in will determine how the modal behaves
Changed loadoutData to be passed in externally (or defaulted to an array of undefineds) in place of teamId - This value already exists when accessing character selection from any Teams page but does not exist (and neither does teamId) when accessed from the Characters page. loadoutData is only used to initialize teamCharKeys and cachedTeamCharKeys. This change ensures the modal can be accessed from both locations.
Deleted CharacterMultiSelectionModal.tsx as a result of these changes

Single character selection in CharacterSelectionModal.tsx:

Currently selected teammates (when relevant) are now pinned to the front of the selection list and bypass filter/sort/search
Instead of a chip indicating the character's current team slot, single selection simply outlines currently selected characters but flashes the outline for the slot being changed

Current TODOs:

Possible split of CharacterSelectionModal back into two: one specifically for use by the Teams feature that has all the new functionality and visuals from the multi-selection PR and one that does not for the Characters page - Scrolling the modal is extremely laggy when accessed from the Characters page (and only the Characters page).
Code cleanup

Issue or discord link

Follow-up work for #2440

Testing/validation
Will add when ready for final review

Checklist before requesting a review (leave this PR as draft if any part of this list is not done.)

[ ] I have commented my code in hard-to understand areas.
[ ] I have made corresponding changes to README or wiki.
[ ] For front-end changes, I have updated the corresponding English translations.
[ ] I have run yarn run mini-ci locally to validate format and lint.
[ ] If I have added a new library or app, I have updated the deployment scripts to ignore changes as needed

Honestly I was kind of wondering whether to split this back up into a regular CharacterSelectionModal and a TeamCharacterSelectionModal. With the changes to single select to display all currently selected team members etc., single and multi select where teams are concerned actually share almost everything, just a couple small differences in whether to show the team slot number and whether to flash the outline for the currently selected slot. It does feel like there's just enough different in the code between the Teams use case and the Characters page use case though.

Yeah I understand your concern, In this case, I think you should still have some division of components:
SingleSelect(4 selected, currentlySelected, onSelect)

CardWrapper(flashing/selected +index)

characterCard

MultiSelect(4 selected, onSelectTeam)
store 4 selected state locally(for quick selection + save)

CardWrapper(show border+index)

characterCard

This should make sure that each component only does one thing with one unique state each, instead of a super component that does 2 things in different states depending on usecase

Trying one more approach based on your suggestion before I throw in the towel and deal with all the duplicated code: I split out some of the shared modal code out into a CharacterSelectionModalBase that both the single and multi select versions use and also split out some of the SelectionCard code into the two wrapper components SingleSelectCardWrapper and MultiSelectCardWrapper which also contain their respective outlining/animation/slot indicators (so SelectionCard really is just the card now).

@frzyc I'll go through it again to see what could be cleaned up, but otherwise good for a first round of review

@arquelion This looks good to me. I like the organization and the separation of concerns here.

Okay, I went through and added some usage comments but otherwise didn't find anything else that I felt needed comments that didn't already have them. Also added a quick recording of the new additions to single select and manually checked as many interactions as I could think of. (Second pair of eyes double-checking all the possible use cases would be nice though.)


TransferManager::DoSinglePartDownload() should flush the stream before marking the transfer completed

TransferManager::DoSinglePartDownload() marks the transfer as completed here: https://github.com/rockset/rocksdb-cloud/blob/8c0ff476d77c0df0af92b1466269404bdfb8e89e/cloud/aws/aws_s3.cc#L196
This happens before the underlying response stream is flushed. The response stream's ownership is tied to local variable getObjectOutcome and the stream is flushed only in getObjectOutcome's destructor when it out of scope (here: https://github.com/aws/aws-sdk-cpp/blob/5543842bdd1bd0a318295a6f2247909883054b0e/aws-cpp-sdk-core/source/utils/stream/ResponseStream.cpp#L61).
This means that a code that uses std::fstream to download S3 object to a local file and does:
handle->WaitUntilFinished();
// do something with the file

is incorrect, because the file might not be flushed when WaitUntilFinished() returns.
This is similar to this 6 year old bug: https://github.com/aws/aws-sdk-cpp/issues/58

Hi @igorcanadi ,
Yea thanks for bringing attention to this,and you're right, this is an ongoing issue with the SDK, I'll try to make it a priority for the team.

Hi @KaibaLopez any news on this issue? Thanks!

Hi,
I think it should be fixed now by https://github.com/aws/aws-sdk-cpp/pull/2351
At least a flush() is called before a task completion notification.
Closing the issue, please submit a new one or re-open should you see more issues.
Best regards,
Sergey


test_ruff_works fails with latest ruff (0.5.0)

This is the result of running the nbqa test suite with the latest ruff installed:
=========================== short test summary info ============================
FAILED tests/tools/test_ruff_works.py::test_ruff_works[/build/source/tests/data/notebook_for_testing.ipynb-/build/source/tests/data/notebook_for_testing_copy.ipynb-/build/source/tests/data/notebook_starting_with_md.ipynb] - AssertionError: assert '\n\n\n\n\n\n...ed but unused' == 'Found 13 err...ed...
FAILED tests/tools/test_ruff_works.py::test_ruff_works[tests/data/notebook_for_testing.ipynb-tests/data/notebook_for_testing_copy.ipynb-tests/data/notebook_starting_with_md.ipynb] - AssertionError: assert '\n\n\n\n\n\n...ed but unused' == 'Found 13 err...ed...
=========== 2 failed, 98 passed, 3 skipped, 14 deselected in 20.74s ============

thanks @GaetanLepage for the report


"Party" event errors

Describe the bug
During the "Party" event there are errors
To Reproduce
Steps to reproduce the behavior:

Load any save
Wait for a "Party" event / trigger it with dev-mode
See red errors in log

I shall just leave a save and logs here if its useful lol.
https://gist.github.com/775a4a17603339ce86fe5e21d807c32d
Save:
https://drive.google.com/file/d/1zqX3td5lJLpI9SLFQVPXYhtLNDmCAmsg/view?usp=sharing

I shall just leave a save and logs here if its useful lol.
https://gist.github.com/775a4a17603339ce86fe5e21d807c32d
Save:
https://drive.google.com/file/d/1zqX3td5lJLpI9SLFQVPXYhtLNDmCAmsg/view?usp=sharing

Can confirm still happens in 1.2.6

Can confirm still happens in 1.2.6

this seems to be fixed with 1.2.7

Confirmed fixed


Some classes are missing/Contact data

Hi,
from 0.18.0 to 0.19.0 some files disappeared. I understand that the documentation is outdated but I have checks for example like instanceof FilterInterface which don't work anymore. Also CallbackFilter disappeared among others named in #308.
Are they gonna come back? Could you explain why they were removed in the first place? We're now stuck with 0.18.0.
We'd be willing to help with the development/documentation since we use this library at work. Is there any way we can contact you (Slack/IRC/Mailinglist?)

Hey @repat,
sorry for the delay. The reason is quite simple, we changed the design of this library.
Now each filter must be callable, so there is no interface needed anymore.
You have to replace each instanceof FilterInterface with is_callable or just create your own interface.

We'd be willing to help with the development/documentation since we use this library at work. Is there any way we can contact you (Slack/IRC/Mailinglist?)

We want to improve this library and create an organisation portphp for that (which have an slack channel) :+1:

I've seen portphp but thought that data-import is the more updated library, since nothing happened in the portphp repo since Nov/Dev 2015 and the latest version of data-import was released this June.
I'll join you guys in the slack channel.


Running flaml[tune] using "-O" flag for python interpreter (optimization - disables assertions) crashes

this is the stack trace:
analysis = tune.run(
  File "/home/ec2-user/pyvenv/lib64/python3.9/site-packages/flaml/tune/tune.py", line 536, in run
    search_alg = SearchAlgorithm(
  File "/home/ec2-user/pyvenv/lib64/python3.9/site-packages/flaml/tune/searcher/blendsearch.py", line 248, in __init__
    points_to_evaluate=self._evaluated_points,
AttributeError: 'BlendSearch' object has no attribute '_evaluated_points'

It's easy to fix by modifying this line:
https://github.com/microsoft/FLAML/blob/7f9402b8fd64f25e8f95d342fefc8eea1c006f2a/flaml/tune/searcher/blendsearch.py#L241
Please feel free to create a PR.

is anyone working on this ?if none then can assign this issue to me @sonichi

is anyone working on this ?if none then can assign this issue to me @sonichi

Sure. Assigned to you.


Rework simple capture

This PR slightly reworks how the simple capture scripts handles cases where the ADC might saturate. Previously it just silently skipped failed captures. Now, the trace is recorded anyway. But when plotting the recorded traces, all traces are checked for samples outside a safe range and a warning is printed in that case. The user is suggested to reduce the scope gain. This allows to keep the capture script simple but gives an easy way to verify the setup before triggering a long capture run.
Also, a configurable delay is added before the capture start in order to unplug the FTDI cable to reduce noise.
This PR supersedes #21 .

Thanks guys for your review. I have updated the PR and will now merge it.


curl: 8.4.0 tracking issue (CVE-2023-38545, CVE-2023-38546)

https://github.com/curl/curl/discussions/12026

Severity HIGH security problem to be announced with curl 8.4.0 on Oct 11
We are cutting the release cycle short and will release curl 8.4.0 on October 11, including fixes for a severity HIGH CVE and one severity LOW. The one rated HIGH is probably the worst curl security flaw in a long time.
The new version and details about the two CVEs will be published around 06:00 UTC on the release day.

CVE-2023-38545: severity HIGH (affects both libcurl and the curl tool)
CVE-2023-38546: severity LOW (affects libcurl only, not the tool)
There is no API nor ABI change in the coming curl release.

I cannot disclose any information about which version range that is affected, as that would help identify the problem (area) with a very high accuracy so I cannot do that ahead of time. The "last several years" of versions is as specific as I can get.

- @bagder

It's released now. https://daniel.haxx.se/blog/2023/10/11/curl-8-4-0/
Seems there's a PR for it. #260378

PR for 23.05: #260381

The fix has landed in all released.


fix: execution error when testName contains quotes and parentheses

The following test case, when I click the Run button to execute, the terminal will throw an error.
describe('a "(name)"', () => {
  it('b', () => {
    expect(1).toBe(1);
  })
});

@firsttris Please review this, thanks.


How to attribute Darwin Core

The TDWF executive has decided to choose for CC BY 4.0 as the default license for all TDWG documents. The attribution requirements are:
1. If You Share the Licensed Material (including in modified
          form), You must:

            a. retain the following if it is supplied by the Licensor
               with the Licensed Material:

                 i. identification of the creator(s) of the Licensed
                    Material and any others designated to receive
                    attribution, in any reasonable manner requested by
                    the Licensor (including by pseudonym if
                    designated);

                ii. a copyright notice;

               iii. a notice that refers to this Public License;

                iv. a notice that refers to the disclaimer of
                    warranties;

                 v. a URI or hyperlink to the Licensed Material to the
                    extent reasonably practicable;

            b. indicate if You modified the Licensed Material and
               retain an indication of any previous modifications; and

            c. indicate the Licensed Material is licensed under this
               Public License, and include the text of, or the URI or
               hyperlink to, this Public License.

       2. You may satisfy the conditions in Section 3(a)(1) in any
          reasonable manner based on the medium, means, and context in
          which You Share the Licensed Material. For example, it may be
          reasonable to satisfy the conditions by providing a URI or
          hyperlink to a resource that includes the required
          information.

       3. If requested by the Licensor, You must remove any of the
          information required by Section 3(a)(1)(A) to the extent
          reasonably practicable.

       4. If You Share Adapted Material You produce, the Adapter's
          License You apply must not prevent recipients of the Adapted
          Material from complying with this Public License.

Tasks

To help users, it would be best to provide a document that includes the required information, so people can reference that. I would be best if that information lives at http://rs.tdwg.org/dwc/ and people can just reference that (which is done in numerous applied uses of the standard, e.g. DwC archives).

We need to indicate that a URL often suffices. I currently wrote it as:

License
Darwin Core (c) by the Darwin Core Task Group, Biodiversity Informatics Standards (TDWG). Darwin Core is licensed under a Creative Commons Attribution 4.0 International License. A copy of the license is provided in LICENSE.
How to attribute and cite Darwin Core
Use the recommended citation format where possible in publications. For applied uses, referencing http://rs.tdwg.org/dwc/ suffices. The recommended citation format is (substitute the parenthetical date accessed with today's date):
Darwin Core Task Group, Biodiversity Information Standards (TDWG). 2009. Darwin Core.
http://rs.tdwg.org/dwc/ (accessed on 2014-10-29).

See also #6

Added license to the file dwc_normative.rdf and set the modified date in bebc6d2483da8e3a8fb2003082ca89a70bf73414.

Simplified the "How to cite Darwin Core" section of the Project README.
A better solution for the references problem would be to not change the RDF at all, but rather to add the link to the GBIF Media Wiki in the HTML rendering on the Terms page (not the history).  This will happen in the build.

Simplified the "How to cite Darwin Core" section of the Project README.
A better solution for the references problem would be to not change the RDF at all, but rather to add the link to the GBIF Media Wiki in the HTML rendering on the Terms page (not the history).  This will happen in the build.