Possible critical bug involving Istio configs from isolated namespaces causing blackholes cluster-wide

Is this the right place to submit this?

[X] This is not a security vulnerability or a crashing bug
[X] This is not a question about how to use Istio

Bug Description
Hello, so we have been having a sporadic issue that has been a hell of a time tracking down, but we know something is wrong. 4 times now, over 3 different Istio versions (1.13>1.15>1.17) and 6 months, we've had BlackHoleClusters randomly start happening on different clusters and different applications, then fixing themselves. We also use Istio SmartDNS with VIP auto-allocation. This snippet is on all of our deployments enterprise-wide:
proxy.istio.io/config: |
    proxyMetadata:
        ISTIO_META_DNS_CAPTURE: "true"
        ISTIO_META_DNS_AUTO_ALLOCATE: "true"

Here is an example over the past 4 hours:

You can see they happen(green bars)...go away....happen....go away. Also note the multiple VIP's associated with the same ServiceEntry, which is below: (is that expected, that a VIP constantly changes for the same endpoint? Seems odd)
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: elasticache-beta-rocket-fdx-api
  namespace: beta-212697-rocket-fdx-api
spec:
  exportTo:
    - .
  hosts:
    - master.beta-212697-rocket-fdx-api.pvfqf7.use2.cache.amazonaws.com
  location: MESH_EXTERNAL
  ports:
    - name: elasticache
      number: 6379
      protocol: TCP
  resolution: DNS

This particular application has had no changes, pushes, nothing all day. We have dozens of applications on this cluster, all with exportTo: . on their ServiceEntry. Here's what we've discerned so far:

The BlackHoleClusters coincide with large Istiod pushes....if I overlay istiod logs on top of the BlackHoleClusters, the red arrows are when the blackholes start, and the blue arrows are when it resolves.

None of the ServiceEntries on our cluster are global...so this isn't a "conflict" situation. We enforce exportTo: . universally. However, VirtualServices and DestinationRules are exported mesh-wide, though none of them are related to this particular URL.

This isn't endpoint or TCP specific...this also happens to multiple apps hitting DynamoDB. In this example, you can see it going from working, to blackhole, to working, while switching VIPS (<IP_ADDRESS>, <IP_ADDRESS>):

test-rocket-client-info-store-api-59976bcf76-nsp7h istio-proxy [2023-11-27T16:09:42.270Z] "- - -" 0 - "-" 3500 5830 65201 - "-" "-" "-" "-" "<IP_ADDRESS>:443" outbound|443||dynamodb.us-east-2.amazonaws.com <IP_ADDRESS>:58816 <IP_ADDRESS>:443 <IP_ADDRESS>:39484 - - -
test-rocket-client-info-store-api-59976bcf76-nsp7h istio-proxy [2023-11-27T16:13:56.972Z] "- - -" 0 UH "-" 0 0 0 - "-" "-" "-" "-" "-" BlackHoleCluster - <IP_ADDRESS>:443 <IP_ADDRESS>:56838 dynamodb.us-east-2.amazonaws.com - -
test-rocket-client-info-store-api-59976bcf76-nsp7h istio-proxy [2023-11-27T17:04:51.606Z] "- - -" 0 - "-" 3469 5799 61007 - "-" "-" "-" "-" "<IP_ADDRESS>:443" outbound|443||dynamodb.us-east-2.amazonaws.com <IP_ADDRESS>:53284 <IP_ADDRESS>:443 <IP_ADDRESS>:51640 - - -
test-rocket-client-info-store-api-59976bcf76-nsp7h istio-proxy [2023-11-27T17:05:30.457Z] "- - -" 0 - "-" 3469 6355 52608 - "-" "-" "-" "-" "<IP_ADDRESS>:443" outbound|443||dynamodb.us-east-2.amazonaws.com <IP_ADDRESS>:41732 <IP_ADDRESS>:443 <IP_ADDRESS>:42652 - - -

If I use the Sidecar resource, and lock down the namespace to only care about its own Istio config, this problem goes away. So while I technically have a fix and probably should use Sidecars anyway, I shouldn't have to.

Based off the above, it seems like Istio configurations (VS, DR, SE, etc.) deployed in other namespaces, which then causes Istiod ids pushes, somehow affect egress traffic in other namespaces, even though aren't related, nor are ServiceEntries being exported to anything other than their own namespace. I noticed the VIP's are changing, one time during a BlackHoleCluster I noticed it was to a VIP that wasn't listed in my istioctl proxy-config listeners... output....once it started working, it was. Maybe Istiod is changing VIP's but then lagging on pushing them out? My only theory so far.
Myself and 2 co-workers are actively diving into this but are at a loss other than what we've described above. Happy to get any other information, logs, etc. We are worried if this starts happening more often in production.
Version
istioctl version
client version: 1.19.3
control plane version: 1.17.8
data plane version: 1.17.8 (168 proxies)

kubectl version
Client Version: version.Info{Major:"1", Minor:"25", GitVersion:"v1.25.12", GitCommit:"ba490f01df1945d0567348b271c79a2aece7f623", GitTreeState:"clean", BuildDate:"2023-07-19T12:23:43Z", GoVersion:"go1.20.6", Compiler:"gc", Platform:"darwin/amd64"}
Kustomize Version: v4.5.7
Server Version: version.Info{Major:"1", Minor:"24+", GitVersion:"v1.24.17-eks-4f4795d", GitCommit:"af19e454a15b5eb16d9f29d4d2361b3050ac78a6", GitTreeState:"clean", BuildDate:"2023-10-20T23:22:36Z", GoVersion:"go1.20.10", Compiler:"gc", Platform:"linux/amd64"}

Additional Information
Istio push metrics for the pod (2 days old)
pilot_xds_pushes{type="cds"} 24541
pilot_xds_pushes{type="eds"} 60245
pilot_xds_pushes{type="lds"} 24589
pilot_xds_pushes{type="nds"} 10903
pilot_xds_pushes{type="rds"} 24546

@howardjohn @stevenctl any ideas? Is the DNS response flip flopping?

Further testing....we turned off SmartDNS and so far....the BlackHoles have disappeared. So this problem may be a combination of using SmartDNS + large/frequent istiod pushes.

There have been many updates to guarantee allocating the same IP to the SE from @ramaraochavali

The recent versions should help. Please try and if it does not help - please share how many SEs do you have and across how many namespaces?

When you say "recent versions", which one specifically you talking about? We have 130 namespaces on this cluster with 548 ServiceEntries. This problem seems to happen specifically when someone deploys or changes something, which causes an Istio XDS push which seemingly changes the VIP.
It sounds like in a newer Istio version, this VIP no longer changes or changes way less often for better reasons?

@jbilliau-rcd You can blame on the code history, which should be very direct, sorry too late for me now

Ok stay tuned, we going to try latest version of 1.20 to see if it makes a difference.

@ramaraochavali  @hzxuzhonghu Unfortunately, even on the latest, it still happens...note it working on VIP <IP_ADDRESS>, then starting to blackhole, then coming back online on <IP_ADDRESS>.

What would cause Istio to push new auto-allocated IP's when using ISTIO_META_DNS_AUTO_ALLOCATE: "true"? Unfortunately, even though turning this off "fixes" the issue, we can't; it introduced the issue it was meant to fix, which is proxying TCP traffic for 2 different ServiceEntries on the same port, to different URL's. In this case, it's an AWS Postgres instance with a reader and writer replica.

Is it possible to share the SE names and in which namespace they are created if it is not confidential?

Sure, it just happened again this morning. Here is the ServiceEntry in our Istio configuration namespace, Istio-config, which is served out to all namespaces in the cluster, since it's an egress rule we want available globally:
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: egress-aws-sts
  namespace: istio-config
spec:
  hosts:
    - sts.amazonaws.com
    - sts.us-east-2.amazonaws.com
    - sts.us-east-1.amazonaws.com
    - sts.us-west-2.amazonaws.com
    - sts.us-west-1.amazonaws.com
    - sts.ca-central-1.amazonaws.com
  location: MESH_EXTERNAL
  ports:
    - name: aws-sts
      number: 443
      protocol: HTTPS
  resolution: DNS

You can see it working on <IP_ADDRESS>....then blackholes until the VIP switches over to .175, which is where it's at now.

istioctl proxy-config listener beta-rocket-client-info-store-api-blue-8694bfc96b-x268c -n rocket-client-info-store-api-beta | grep sts.us-east-2.amazonaws.com
<IP_ADDRESS> 443   ALL                                                                                Cluster: outbound|443||sts.us-east-2.amazonaws.com
This is ONE example. For the dynamodb one that the issue was created for, the SE looks like this:
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: dynamodb-beta-rocket-client-info-store-api
  namespace: rocket-client-info-store-api-beta
spec:
  exportTo:
    - .
  hosts:
    - dynamodb.us-east-2.amazonaws.com
  location: MESH_EXTERNAL
  ports:
    - name: dynamodb
      number: 443
      protocol: HTTPS
  resolution: DNS

There are 2 other SE's in this namespace, TCP-based, for access to an RDS instance. We've confirmed there are no other SE's on this cluster that are also pointing at dynamodb.us-east-2.amazonaws.com but not having an exportTo: .; all of our SE's have that, we enforce it through our helm chart.

I will add since deploying 1.20 and migrating everything over to it, the amount ofBlackHoleCluster does seem to have gone down quite a bit. The issue still persists, but seems to happen less often. So perhaps these changes you did made it better, but didn't 100% fix it? Not sure, we still doing our own research and testing to try to find the culprit and reproduce.

I suspect the ip allocation is less stable, we can have more tests on it.

/cc @kdorosh I think this is another use-case for your ServiceEntry doc from awhile ag

These look related maybe?
https://github.com/istio/istio/issues/43853
https://github.com/istio/istio/pull/43852

@hzxuzhonghu Should we use namespace + hostname + name of SE instead of (namespace, hostname) to reduce the collision even more ?

I do not think it helps much. First, there is no evidence the longer string have less hash conflict.  We do not support declaring same service within two SE. The behavior is undefined.
I believe the ideal solution will be using a similar ipam as kubernetes.

First, there is no evidence the longer string have less hash conflict.

It is not about longer string. Currently namespace + hostname (if saved in different service entry) is guaranteed to cause collision. If we add service entry name also it becomes a unique combination and i am sure collision will reduce. But whether to support this model or not is a different problem as same host with two SEs the behaviour is undefined.

It is not about longer string. Currently namespace + hostname (if saved in different service entry) is guaranteed to cause collision.

You are right. It can mitigate

SE is currently a namespaced resource that directly adds services to the global service registry. These kinds of conflicts are honestly expected (not intended) due to the design. I'm ok with mitigation to help users, but I remember there was a lot of discussion around the fundamental design of this resource and what it was meant to do. If we want to charge SE scope to be more like a namespaced resource (instead of the in-between version we have now) we may want to document it somewhere and potentially make other changes?

/cc @kdorosh I think this is another use-case for your ServiceEntry doc from awhile ago

https://github.com/istio/api/pull/2935 linking the PR with my proposed fix and design doc which stalled in interest

So every day I get a bit more information....Something must've changed from Istio 1.15 > 1.17, because these devs have been deploying these ephemeral ends since June 30th. These blackholes started 11/7, which is when we started canarying out Istio 1.17.

Also, remember.....the BlackHoleClusters aren't tied necessarily to the duplicate ServiceEntries. They just seem to cause blackholes randomly across ANY namespace and ANY ServiceEntry, that's what's so confusing about this. The developers have since removed all of the duplicates and the problem has gone away. So while they shouldn't be creating duplicates and we have since fixed it, the idea that this could cause random widespread outages is very scary for production. I can't control whether or not devs deploy duplicates, can only offer best practices and hope for the best.
So to reiterate, so far, it *seems this started after 1.15 and the creation of duplicates causes issues on unrelated namespaces and other ServiceEntries.

@ramaraochavali and I will take a look,  we did change the allocation algorithm some releases before, but it was intended to behave better.

I added a test, which shows the hash conflict is a little severe.

So what happens when there is a "hash conflict"? Is that what causes Istio to issue a new VIP to a ServiceEntry when using auto-allocation?

So what happens when there is a "hash conflict"? Is that what causes Istio to issue a new VIP to a ServiceEntry when using auto-allocation?

Yes

I am thinking an optimization which could make it not change even after some service deletion, would test it later.

Hey guys, so I'm reading a bit through the linked PR, some it's over my head so just a general question; regardless of ServiceEntry duplicates, collisions, etc. that might occur, why would they spill over and effect other namespaces? Isn't that the point of exportTo: ., to keep any issues isolated to the NS in question?
If this problem doesn't respect namespace isolation for some reason, then why does applying a Sidecar resource seem to fix it? Isn't that kinda the same thing as applying exportTo: ., just on the flip side? Instead of saying "don't push this anywhere except this namespace", a Sidecar is saying "don't listen for anything else in any other namespaces`. Effectively, those are the same thing, no?

short answer: backwards compatibility
longer answer: ServiceEntry handles a bunch of different use cases where the different behaviors make sense

exposing an external service --> purely namespaced ServiceEntry makes sense
expose a VM service to the mesh with a UX similar to k8s services --> DNS is global (just like k8s service)

My doc explores all these tradeoffs at length, and I still think we should implement it (i.e. DNS search paths) in ambient to avoid carrying that tech debt forward.

Previously i thought this issue was caused by ip allocation inconsistency. Now the sidecarScope services seem skeptical.
Can you check the /debug/sidecarz output to see the services in sidecar scope?  Compare them
What does the Sidecar looks like, i am wondering why the exportTo: . does not help

Our default Sidecar, which we deploy in our custom-made Helm chart, looks like this:
apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
  name: {{ include "app-template.name" . }}-sidecar
spec:
  egress:
  - hosts:
    - "./*"                               # current namespace
    - "istio-system/*"           # istio-system services
    - "istio-config/*"             # global cluster service entries
    - "cluster-userinfo-svc/*"   # cluster userinfo svc
    - "default/*"                     # kubernetes service api

I'll try recreating this again and checking the /debug/sidecarz output.

Im trying to recreate it again, reapplying and deleting a YAML manifest over and over. I've done it probably 30 times, only gotten it to happen twice, so definitely sporadic (always fun to troubleshoot). I am noticing something else weird though, maybe related.....the VIP's my app is connecting to aren't the same ones listed as listener IP's using istioctl.

Note how it's connecting over .252 and .208, yet the listener IP's are .206 and .241.
@hzxuzhonghu when you ask "Can you check the /debug/sidecarz output to see the services in sidecar scope? Compare them", what do you mean by that exactly? how do I do that?

istioctl x internal-debug sidecarz will do the trick
On Mon, Dec 18, 2023 at 12:08 PM Jason Billiau @.***>
wrote:

Im trying to recreate it again, reapplying and deleting a YAML manifest
over and over. I've done it probably 30 times, only gotten it to happen
twice, so definitely sporadic (always fun to troubleshoot). I am noticing
something else weird though, maybe related.....the VIP's my app is
connecting to aren't the same ones listed as listener IP's using istioctl.
image.png (view on web)
https://github.com/istio/istio/assets/69006307/4b070e30-e1d0-4c84-a05c-bc6db75aacaf
Note how it's connecting over .252 and .208, yet the listener IP's are
.206 and .241.
@hzxuzhonghu https://github.com/hzxuzhonghu when you ask "Can you check
the /debug/sidecarz output to see the services in sidecar scope? Compare
them", what do you mean by that exactly? how do I do that?
—
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/issues/48055#issuecomment-1861512474, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEYGXITBEH4VIFACLJOURDYKCPEXAVCNFSM6AAAAAA74QFWFCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRRGUYTENBXGQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

@hzxuzhonghu Apologies for the delay, holidays and just being busy, finally swinging back around to this. I ran the command  John pasted above, not sure if this is correct or not:
istioctl x internal-debug sidecarz/test-rocket-fastpass-78cd97b4c5-sf92d.rocket-fastpass-test
error: according to below command list, please check all supported internal debug commands
["adsz","adsz?push=true","authorizationz","cachez","cachez?clear=true","cachez?sizes=true","clusterz","config_distribution","config_dump","configz","connections","ecdsz","edsz","endpointShardz","endpointz","inject","instancesz","mcsz","mesh","ndsz","networkz","push_status","pushcontext","registryz","resourcesz","sidecarz","syncz","telemetryz"]
["adsz","adsz?push=true","authorizationz","cachez","cachez?clear=true","cachez?sizes=true","clusterz","config_distribution","config_dump","configz","connections","ecdsz","edsz","endpointShardz","endpointz","inject","instancesz","mcsz","mesh","ndsz","networkz","push_status","pushcontext","registryz","resourcesz","sidecarz","syncz","telemetryz"]
["adsz","adsz?push=true","authorizationz","cachez","cachez?clear=true","cachez?sizes=true","clusterz","config_distribution","config_dump","configz","connections","ecdsz","edsz","endpointShardz","endpointz","inject","instancesz","mcsz","mesh","ndsz","networkz","push_status","pushcontext","registryz","resourcesz","sidecarz","syncz","telemetryz"]

Is there anything else I can provide to help troubleshoot this or narrow it down? It sounded like you had an idea of what might be causing this, is that still the case?

istioctl x internal-debug sidecarz?proxyID=test-rocket-fastpass-78cd97b4c5-sf92d.rocket-fastpass-test should do it

Sorry for the hassle here, it doesn't seem to like that:
➜  ~ kubectl get pods -n rocket-fastpass-test
NAME                                            READY   STATUS    RESTARTS   AGE
test-rocket-fastpass-78cd97b4c5-sf92d           2/2     Running   0          21h
➜  ~ istioctl x internal-debug sidecarz?proxyID=test-rocket-fastpass-78cd97b4c5-sf92d.rocket-fastpass-test -n rocket-fastpass-test
zsh: no matches found: sidecarz?proxyID=test-rocket-fastpass-78cd97b4c5-sf92d.rocket-fastpass-test
Running just istioctl x internal-debug sidecarz does seem to imply  that's the correct format.
➜  ~ istioctl x internal-debug sidecarz
Error:  You must provide a proxyID in the query string, e.g. [edsz?proxyID=istio-ingressgateway]
Im using the latest version, 1.20.1 of istioctl.

That is your shell not liking ?. Do istioctl x internal-debug 'sidecarz?proxyID=test-rocket-fastpass-78cd97b4c5-sf92d.rocket-fastpass-test'

doh....🤦
So I do get output now, quite a lot actually. is this of any use to provide right now? The issue isn't currently happening. Would I need to create duplicate SE's and try to recreate the issue, running this command during the 5-10 second window as it's actively Blackholing to be of any use?

@hzxuzhonghu Is there anything else you need from me or that I can provide? Are we agreeing this is an issue? Just want to make sure this doesn't get lost in the fold.

Please try this patch https://github.com/istio/istio/pull/48896
I think this issue is caused by different SE produces same host name services. We allocate different ips for x.y.z.hostname.  And then we generate DNS name table with all IPs for a single hostname.
Now with the pr above, we can make sure only one service will be allocated ip addr.

Ah, good to see we may already have a fix! I'll look into building a copy of Istio from that PR, never done that before. In case it takes me a while, can I expect to see this change in the next Istio patch release?

it is easy, just run make docker.pilot in the istio root dir

Hey guys, apologies for the delay. This issue just happened again and lasted for 5 min, then self-corrected. It's not an easy thing to reproduce however, as just "creating duplicate service entries" doesn't seem to be enough, so there must be something else that happens that does it.
Still trying!

Also, our nonprod environment, which this is occurring on, is running 1-19-7. This issue was created originally on 1-17-8, so it's still present on the latest 1-19 release.
If I am unable to reproduce this in a timely manner, how confident are you @hzxuzhonghu  that this fixes it? And will that PR make it's way into a future Istio release regardless of my ability to confirm it fixes my issue or not?

The patch does fix something, i am not quite sure it can solve this issue, as we have not get the root cause of this issue

@hzxuzhonghu  @howardjohn @ramaraochavali  I haven't been able to reproduce this reliably so far and we have since upgraded to Istio 1.19.7. I'll close for now and reopen if it happens again, specifically if I can reproduce it. Thanks for all the responses and help!

@hzxuzhonghu  this has been happening again lately....seemingly tied to when new pods come up which causes an Istio XDS push. We had new pods come up in an unrelated namespace that caused blackholeclusters for 20 min to this namespace. Same issue....Istio SmartDNS VIP's are being changed and until the sidecar "picks up" the new VIP, traffic blackholes. Is your patch in Istio 1.22? Have there been any changes between 1.19 and 1.22 that might fix this? It's starting to get concerning and affecting production.

Oh, one final thing; this namespace is actually using the Sidecar object as well, so my previous thinking that it would fix this issue is no longer valid. It isn't even watching the namespace that got deployed to that seemed to line up time-wise with the blackholes starting.

It looks like the issue has been around since Istio 1.10? Is this not the same thing? Says it was fixed in 1.17....that doesn't seem to be the case from what Im seeing
https://github.com/istio/istio/issues/44849

Reopening since this is still an issue. Looks to possibly be fixed by a DNS Autoallocation V2, currently slated to possibly be in 1.23. Once this is released, I'll be happy to put it through its paces and close this with the confidence that this is finally resolved.

@jbilliau-rcd seems like it was fixed now in #49965

Indeed, looks like it! Thanks for that, I'll keep my eyes peeled for it's implementation into a future Istio release.


Allow to propagate date changes only if "Apply" button has been pressed

Hi Mikael,
first of all thanks for sharing your datepicker, I found it very neat and easy to use.
I'd like to suggest a new feature: be able to "Cancel" a date selection, or in other words, require to explicitly press the "Apply" button before the dates are changed.
In my PR you can see that I still propagate the date changes while the user is selecting the date range, but if the user presses Cancel, or clicks outside the date selector, the changes are reverted.
Otherwise, if the user presses "Apply" the new dates are kept as selected.
Also, I've added an explicit event to let the parent app know when dates have been applied following a click on "Apply" button.
To avoid introducing behaviour changes I've wrapped this new feature within a new property "require-apply" set to False by default.
Thanks again for sharing this,
Luca

Thanks @pdvluca for the contribution!
I'll pull the branch later tonight and test your changes. But I agree, this should be behaviour of the cancel button. :)

I pulled the branch and this is my thoughts:
I want this datepicker to be as close as the original AirBnb datepicker as possible. So to emulate that, all we need to do is to set the initialDates when pressing cancel. Otherwise the same logic should apply as currently.
I kinda feel that the extra event ('dates-applied') is making the api more complex. Then it's better to just always select the dates, and to keep the dates selected if clicking outside the datepicker.
However, when pressing "Cancel", we do something like this:
cancel() {
  this.closeDatepicker()
  this.selectDate(this.initialDate1)
  this.selectDate(this.initialDate2)
},

Or is there some reason why you think that dates should not be applied when clicking outside the datepicker?

You're right, on airbnb if you click outside the datepicker it has the same behaviour as "Apply", not as "Cancel". It feels more natural to me that if you click outside the datepicker the changes should be ignored, but I guess is personal preference, and I value consistency more, hence I'll remove that.
Regarding the 'dates-applied' event, basically I'd like to be able to be notified when the selection is "firm", not just when the user is playing around with dates.
If we're using the datepicker to filter some date, typically I'll trigger a refresh of the data when the user presses apply, not every time that the user adjusts dates.
Does it make sense?
Maybe it could be replaced by a datepicker-closed event?

Done, closed event added and now clicking outside the datepicker is treated as clicking on Apply button.


Intermittent test failure in Conway 'single proposal' tests

Two tests failed in #4234 but succeeded on retrying the job. The failure messages were:
   expected: Coin 10000
    but got: Coin 9999

To rerun use: --match "/Conway/Imp/ConwayImpSpec/ENACT/Treasury withdrawals/Withdrawals exceeding treasury submitted in a single proposal/" --seed 155819741

   expected: Coin 10000
    but got: Coin 9999

To rerun use: --match "/Conway/Imp/ConwayImpSpec/ENACT/Treasury withdrawals/Withdrawals exceeding maxBound Word64 submitted in a single proposal/" --seed 155819741

I was able to reproduce both failures on e47a836b using
cabal test cardano-ledger-conway:test:tests --test-options '--match "single proposal" --seed 155819741'

I'm attaching a complete log file in case the CI logs have been discarded by the time someone gets to this.

Fixed in #4248


Fixes #625

$column has been renamed to column but still $column is used in select filter which causes empty select to show up as filter. This check-in fixes that so that select filter shows up with data.

As per my comments: https://github.com/esvit/ng-table/issues/625
I don't think this is an issue


Add support for LocalExecutor

Prerequisite for adding support for LocalExecutor in smol-axum for single-threaded async.

@notgull I closed this PR as I realised I did an oopsie and duplicated impl for hyper::rt::Executor<>. Because Executor<> and LocalExecutor<> don't share a common trait, it's not trivial to implement this generically. Furthermore, the Send bound cannot be relaxed easily.
Now, this could be fixed with conditional compilation and feature flags. Is this something you'd be ok with?

Now, this could be fixed with conditional compilation and feature flags. Is this something you'd be ok with?

Sorry for the delayed response. Yes I would.


this library relies on outdated puppeteer-core?

puppetter-web was removed in 2020 (puppeteer-core), the puppeteer-core version mentioned in package.json is 13.0.0, and current version is 19+. Do I need to use 13.0.0 in order to use the library?

+1 for upgrading puppeteer-core dependency.
Modern versions of Chrome now includes a recorder tool that can export user's actions as Puppeteer scripts for future playback. However, these generated scripts use features from modern versions of Puppeteer (such as Locator.race). Therefore, updating puppeteer-core dependency to recent versions will be super helpful.


Grouping by weekday/week/day

I am currently trying to use kysely for a dashboard I am building. But I am missing the "WEEK", etc. functions. Is there any way to achieve a query like:
SELECT
	WEEK(createdDate) as createdWeek,
	COUNT(finishedDate) as finishedCount,
	COUNT(id) as count
FROM
	Table
WHERE
	providerId = "clgz9g6gn0007a4l98chlsae9"
GROUP BY
	createdWeek
ORDER BY
	createdWeek;

I couldn't find any issue about this.

This should do it:
db.selectFrom('Table')
  .select(({ fn }) => [
    fn<number>('WEEK', ['createdDate']).as('createdWeek'),
    fn.count('finishedDate').as('finishedCount'),
    fn.count('id').as('count')
  ])
  .where('providerId', '=', 'clgz9g6gn0007a4l98chlsae9')
  .groupBy('createdWeek')
  .orderBy('createdWeek')

That's good to know. Didn't know about the fn argument or even a function as argument.
Is there any place in the docs about this? Otherwise it would need to be added.

@iduuck Kysely is fully documented in your IDE and in generated jsdocs site. We are working on a user-friendly docs site.
There's also a queries forum on our discord server with real-world examples.


[Integration-Test] Init sofa integration test

Hi community
This task is needed to test support for the sofa-rpc protocol.
you can add project in apache shenyu, The structure is as follows：
-----shenyu-integration-test
-----------shenyu-integration-test-sofa
Don't worry, they are not very difficult, you can refer to：

shenyu-integrated-test-http
also you requires some knowledge of docker

Please read the Contribution Guideline before submitting the PR
If you would like to participate, Please leave a message under this issue.

@ChDoBigThings
Hi， How's your mission going?

@ChDoBigThings Hi, do you still doing this issue? If not, I can help to add soft integration test.

@ChDoBigThings Hi, do you still doing this issue? If not, I can help to add soft integration test.

Hi, Please help add soft integration test.

@ChDoBigThings Hi, do you still doing this issue? If not, I can help to add soft integration test.

Hi, Please help add soft integration test.

ok, I will try to finish it.

done


Add ability to chain returns with doReturn()

I was looking for the ability to do this on StackOverflow (http://stackoverflow.com/questions/34190095/can-i-chain-returns-with-powermockito-using-doreturn) and I can't take credit for this idea, another user submitted it.  But I think it would be very helpful if it is possible:
What's happening is that org.powermock.api.mockito.PowerMockito.doReturn (et al) will return a PowerMockitoStubber implementation, which extends Mockito's Stubber; under the hood, PowerMockitoStubberImpl extends StubberImpl. Because PowerMock doesn't need to change the functionality, it does not override these calls; the second doReturn in PowerMockito.doReturn(foo).doReturn(bar) will invoke Mockito's StubberImpl and return a Mockito Stubber.
This is a problem, because in the transition to Stubber, you lose the PowerMockito when signatures, such as the one you need. In short, PowerMockito doVerb calls do support chaining, and do support referring to Methods reflectively or by name, but currently not both at the same time.
Internally, StubberImpl follows the builder pattern, returning itself after every call:
public Stubber doCallRealMethod() {
answers.add(new CallsRealMethods());
return this;
}
Because this refers to the PowerMockitoStubberImpl subclass, it would be easy to cast the Stubber to PowerMockitoStubber to get access to the additional methods. For the above workaround, you're making the cast yourself:
((PowerMockitoStubber) PowerMockito.doReturn(valueA).doReturn(valueB))
.when(mockedObject, "methodName");
As a long term solution, because anything that returns PowerMockitoStubber necessarily returns Stubber, this may be possible to fix for all PowerMockito users purely through an interface override (noting the caveats listed on Joseph D. Darcy's Oracle Weblog). I haven't tested this, but it may be this easy:
/* in PowerMockitoStubber.java, for each doVerb method: */
@Override public PowerMockitoStubber doNothing();

Interesting idea! It would be great if you could contribute by trying it out and submit a pull request. If it works the way you'll describe we'll bring it in to the next release.

Pull request is merged, so I think the issue could be closed.

Hi! I'm glad this feature request got some traction, but this is not actually the type of chaining I was talking about originally.
The pull request (#599) handles multiple doReturn values specified at once, as in:
doReturn(1, 2, 3).when(Counter.class, "count");

The original StackOverflow answer I gave deals with chained return values:
doReturn(1).doAnswer(someAnswer).when(Counter.class, "count");

This is currently not possible because PowerMockitoStubber doesn't redefine the methods on the Stubber interface to return PowerMockitoStubber instead.
You should probably reopen this issue.


#4931: add apis to get ethernet by socket ids

clean ci https://github.com/tenstorrent-metal/tt-metal/actions/runs/7656924027

@tt-aho I'm now returning all sockets connected to another chip.


Support nested block comment

See #133. This commit also changed the wrapper of Lexer.x from posn to monad which brings the capability of using start codes in lexer. This may benefit the implementation of string interpolation in the future.

Please test this patch before merging, since the basic structure of the lexer has been changed. Though I tried my best to keep the original interface of lexer and parser. The test by make test2 can pass.

It looks good, well done!


snippets: rtt-console: fix issues

Fix some snippet issues.

@gmarull @tejlmand  is this needed in 4.0 in your view?  If not can we set the milestone to 4.1?


Webpack removing preact import used by jsx

Bug report

What is the current behavior?
Webpack strips the preact import from the source code which will throw an error when running the JS in the browser: MyComponent.tsx:8 Uncaught ReferenceError: preact is not defined.
If the current behavior is a bug, please provide the steps to reproduce.
See the minimal repository here: https://github.com/Badestrand/webpack-error-stripping-preact-import/tree/main
Run webpack run build and open src/index.html in browser. In the console you will see the error MyComponent.tsx:4 Uncaught ReferenceError: preact is not defined. I included the compiled main.js in the src folder of the repository as well.

What is the expected behavior?
The source code in MyComponent.tsx is
import * as preact from 'preact'

export default function MyComponent() {
	return (

	)
}

The compiled source code is
/***/ "./src/MyComponent.tsx":
/*!*****************************!*\
  !*** ./src/MyComponent.tsx ***!
  \*****************************/
/***/ ((__unused_webpack_module, __webpack_exports__, __webpack_require__) => {

__webpack_require__.r(__webpack_exports__);
/* harmony export */ __webpack_require__.d(__webpack_exports__, {
/* harmony export */   "default": () => (/* binding */ MyComponent)
/* harmony export */ });
function MyComponent() {
  return preact.h("div", null);
}

/***/ }),

Notice that the import of preact was stripped, which causes the code to fail.
The import does NOT get stripped and everything works fine if I either a) make it javascript instead of typescript by changing the file extension or b) reference preact directly in the file, e.g. by adding the line !!preact.h.

Other relevant information:
webpack version:  5.72.0
Node.js version: v14.15.0
Operating System: Mac OS Monterey
Additional tools:

in your repro output looks like
/***/ "./src/MyComponent.tsx":
/*!*****************************!*\
  !*** ./src/MyComponent.tsx ***!
  \*****************************/
/***/ ((__unused_webpack_module, __webpack_exports__, __webpack_require__) => {

__webpack_require__.r(__webpack_exports__);
/* harmony export */ __webpack_require__.d(__webpack_exports__, {
/* harmony export */   "default": () => (/* binding */ MyComponent)
/* harmony export */ });
function MyComponent() {
  return /*#__PURE__*/React.createElement("div", null);
}

/***/ }),

so it looks like you have wrong babel config see
/*#__PURE__*/React.createElement

so preact doesn't have any usage => this import was tree-shaken.

Thank you for looking into it - the .babelrc was missing in the repository but I uploaded it now.
The .babelrc:
{
	"presets": [
		"@babel/preset-env",
		"@babel/preset-typescript"
	],
	"plugins": [
		[
			"@babel/plugin-transform-runtime", {
				"regenerator": true
			}
		],
		["@babel/plugin-transform-react-jsx", {
			"pragma": "preact.h",
			"pragmaFrag": "preact.Fragment",
		}]
	]
}

This means the jsx will not result in React.createElement but in preact.h instead. And then obviously the preact import should not be tree-shaken.

hm.. looks like @babel/preset-typescript removes unused import ( if change exstension to .jsx all works fine ). See https://github.com/babel/babel/issues/9723#issuecomment-475018627

The order of my presets is env->react->typescript, shouldn't that first resolve the jsx and then pass the resolved code to typescript which now should see all the "preact.h" statements?
I played around with changing the preset order but that didn't seem to change anything.

hm.. I think you should ask in babel issue tracker how to configure this.. ( or maybe preact ) looks like typescript preset removes import..


Complie flag

The flag of arch ``sm35'' is depreciated, should be using sm52 or higher instead.

fixed


Slider Tooltips Overlap

I'll probably open a PR for this myself when I have some time, but in case anyone wants to get to it before me:
Currently if you have a range slider with two tooltips, they'll begin to overlap when the values get close together. This can make it difficult to see what values you actually have selected. See https://nightcatsama.github.io/vue-slider-component/example/#demo3 for an example of this.
A good solution would be to have them join together when they would otherwise overlap each other. See http://ionden.com/a/plugins/ion.rangeslider/demo.html for an example of what I mean.

I am sorry that I haven’t responded for so long.
This is a good feature, but I haven’t had time recently. I’ll consider adding it later.

No worries on the delay! I may open a PR for it myself in the coming weeks if I can find the time. I'm doing it in a hacky way now and I'd like to clean it up and make it more "official".

Is this feature available in version 3 ?
I tried and they still seem to overlap : https://jsfiddle.net/5zs2abwg/

@digEmAll Unfortunately, this feature was removed in version 3.x.
However, similar functions can be implemented through the slot.
https://jsfiddle.net/NightCatSama/3hg0246q/5/

Thanks, that's really useful !

BTW, this is a very useful feature that would be nice to have "by default" in this great library.
Just my two cents :)

@digEmAll Thank you for your suggestion, I have considered it before.
However, in the 3.x version the tooltip is attached to the dot component. So adding a merge tooltip will make the component complex and difficult to understand.
So, i didn't add this feature.

+1
Missing this feature greatly

@digEmAll Unfortunately, this feature was removed in version 3.x.
However, similar functions can be implemented through the slot.
https://jsfiddle.net/NightCatSama/3hg0246q/5/

This solution is quite complex to implement if you have lots of sliders.
You have make one showMergeTooltip per slider


TG: add district scraper

Page 6 contains the "Total kumuliert" and "Letzte 7 Tage" values that should be sufficient to create a scraper with weekly data.
https://www.tg.ch/public/upload/assets/103465/FP_LageTG_Wochenbericht.pdf

I'll ask TG to provide this data in a machine-readable form, so that we don't have to scrape another PDF.

Great, thanks!

TG added their district data on opendata.swiss as CSV: https://opendata.swiss/de/dataset/covid_19-fallzahlen-kanton-thurgau
Thanks @dkoltg!


Inclusão de escola.

@jaquionias Please provide us with:

the school official website URL
the school street address, including city and country
an URL of a page on the official website where the school offers an IT-related long-term (>1 year) course
a proof, which shows that the school recognizes the domain you are submitting as an official email domain for the students.

@jaquionias You might miss my previous comment. Please react.

@jaquionias I am sorry, this request remains unanswered for a while. I have to close it without merging. Please reopen and comment if you have an update regarding the aforementioned issue. Thank you for your understanding!


Encryption and Sending/Receiving of pictures failures

This is really two separate issues:

Enabling encryption on versions later than 14.0.2 is not working. Will not enable.

Regardless of version,  I and other users are unable to send or receive pictures.  Attempts to send a file merely force close ChatSecure. Phones in use are Galaxy S4 and LG G2

And this 's my problem, when it comes to sending and recieving data:
I am on playstore version , december 2014; my chats start using OTR encryption right away (mostly :P ).
But sending pictures takes for ever ... . I'm connected via wifi, but sending a picture (cam, 1.2mb) takes about 45 minutes.
Saying, it works, yes; But sharing stuff isn't that much fun though ;)

Same issue on Chatsecure version 14.2.3 on Galaxy S1 and Oneplus 2 and a custom XMPP server on Openfire.
OTR works only if both phones are downgraded to version 13.1.2 but never if at least a single one of them is upgraded to a any higher version.
Also, Orbot is running on both phones version 15.1.2
All versions are from the F-Droid repo.

Same issue on Chatsecure version 14.2.3 on Galaxy S1 and Oneplus 2 and a custom XMPP server on Openfire.
OTR works only if both phones are downgraded to version 13.1.2 but never if at least a single one of them is upgraded to a any higher version.
Also, Orbot is running on both phones version 15.1.2
All versions are from the F-Droid repo.


Container error code 139 then restarts

What happened?
Installed many times, many different ways, it seems that the container does not even start properly as there is nothing in the logs.
I am running on Pi-os  , latest boobworm version with all the updates on raspberry pi 5
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian
Tried deploying by command line with docker,  and by using portainer..  same thing.   just exits with error 139 , no output.
I also made a new container with portainer using the hello-world example, that worked, had something in the log files, so I know the system works enough to deploy a container..
also adguardhome is running fine on this system in another container
AdguardHome-Sync Version
v 0.6.11
(fresh off site as of 23/07/24)
AdguardHome Version
Version:   v0.107.51
but its not even getting that far to even try and connect.
Configuration
tried lots of different configs, but even just this basic one should get it to run and output an error, but not even that happens. (trying to keep it as basic as possible to get it to at least start...
---------
version: "2.1"
services:
  adguardhome-sync:
    image: ghcr.io/bakito/adguardhome-sync
    container_name: adguard_syncTest3
    command: run
    ports:
      - 8084:8080
    restart: unless-stopped

Current Applied Configuration
tried that, no output what so ever

Relevant log output
Doesn't show anything in logs

Anything else?
I wish I had a log file to paste here..  then i'd have something to work with..
Thinking the code just does not run on this version of raspberry pi OS
cat /etc/os-release
gives:
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)" NAME="Debian GNU/Linux" VERSION_ID="12" VERSION="12 (bookworm)" VERSION_CODENAME=bookworm ID=debian HOME_URL="https://www.debian.org/" SUPPORT_URL="https://www.debian.org/support" BUG_REPORT_URL="https://bugs.debian.org/"

Hi @Martin-Dolan
Are you running the binary or docker version?
Can you please provide the cpu arch of your pi?
uname -m

The raspberry pi 5 is a 64-bit 2.4 GHz quad-core ARM Cortex-A76
I know people have successfully run it on raspberry pi 3 (different chip though)
I'm running the docker version.
I've tried installing it using both methods using Docker CLI and docker compose  - (ghcr.io/bakito/adguardhome-sync)

what us the output of  uname -m

aarch64

Ahh ok..  That makes sense.
It's the first time I've tried to set this up, and also the first time I've used docker, portainer and a pi 5 so I want sure if it was because it didn't work /wasn't supported or because I was doing something wrong /stupid/uneducated 🤣
That's why gave it a good go before bothering you!
Also learnt a hell of a lot over the last week and a bit..
Let me know when you want me to test it!

@Martin-Dolan can you please try the most recent main tag image?
https://github.com/bakito/adguardhome-sync/pkgs/container/adguardhome-sync

Still nothing :(
I used ghcr.io/bakito/adguardhome-sync:main
version: "2.1" services:   adguardhome-sync:     image: ghcr.io/bakito/adguardhome-sync:main     container_name: adguardhome-sync     command: run --config /config/adguardhome-sync.yaml     volumes:       - /DATA/AppData/adguardhome-sync/config/adguardhome-sync.yaml:/config/adguardhome-sync.yaml
Also tried the same with ghcr.io/bakito/adguardhome-sync:alpine-main
so is it downloading the right version for my system?
Let me know if I'm doing something stupid...

Actially I`m a bit puzzled on which arch is really needed, as I can not test it myself.
Can you give this image a try?
quay.io/bakito/adguardhome-sync
Do you have other docker images/applications that run?
If so, can you run docker inspect <image-name>
And do the same with adguardhome sync?
docker inspect ghcr.io/bakito/adguardhome-sync:main
And attach the output?
I'm specially intrested in the Architecture an OS sections.

No problem, I'll do it as soon as I get home.
You know more about this than I do, but as far as I can work out from what I've read, the pi 5 uses arm64  aarch64
This might help?
https://www.raspberrypi.com/documentation/computers/linux_kernel.html
Also if I open a shell from casa os I get :
Linux raspberrypi 6.6.31+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.6.31-1+rpt1 (2024-05-2 9) aarch64

Holly sh!t  I think you fixed it.
I just ran the docker hello world example again and that said arm64v8
I then noticed you put some more arch versions up and one was arm64v8, so I downloaded adguardhome-sync again and it actually ran this time - well it has something in the log files at least which is a start!  ill go and test it actually works now, but at least its running!!
thank you sooooooo much!!!!

Good to hear, I'll close the isseu then.

Yes, just been testing- It's just various config/settings stuff I have to work out now, but it did the symc of 5 pages of static leases which is good!
Thanks again <3

a new release is currently being built


Kotlin-Gradle-Plugin outdated version

Hi, thanks very much for this great library.
I'm trying to compile my app to Android and I get the following error :
FAILURE: Build failed with an exception.

* What went wrong:
The Android Gradle plugin supports only Kotlin Gradle plugin version 1.5.20 and higher.
The following dependencies do not satisfy the required version:
project ':matomo_forever' -> org.jetbrains.kotlin:kotlin-gradle-plugin:1.3.50

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 3s
Exception: Gradle task assembleDebug failed with exit code 1
Exited

My flutter doctor :
[✓] Flutter (Channel stable, 3.7.0, on Fedora Linux 37 (Workstation Edition) 6.1.7-200.fc37.x86_64, locale fr_FR.UTF-8)
[✓] Android toolchain - develop for Android devices (Android SDK version 33.0.1)
[✓] Chrome - develop for the web
[✓] Linux toolchain - develop for Linux desktop
[✓] Android Studio (version 2021.3)
[✓] VS Code (version 1.74.3)
[✓] Connected device (3 available)
[✓] HTTP Host Availability

Hello @netapy ,
Thanks a lot for your message and for raising this!
I will try to reproduce and solve this issue as soon as possible.

Salut @netapy ,
Version 1.0.4+1 of this plugin just published on pub.dev now got those lines updated:
android/build.gradle:
...
    ext.kotlin_version = '1.6.20'
...
        classpath 'com.android.tools.build:gradle:7.0.0'
...

android/gradle/wrapper/gradle-wrapper.properties:
...
distributionUrl=https\://services.gradle.org/distributions/gradle-7.0.2-all.zip

I hope this solves your issue.
If it doesn't, I'm very sorry for the inconvenience and you may want to try updating those lines in your own project, as can be seen also in the example project here:
https://github.com/lcuis/matomo_forever/blob/dc8b3bd8f0baa534ebaf90f7205e59c20f392f66/example/android/build.gradle#L2
https://github.com/lcuis/matomo_forever/blob/dc8b3bd8f0baa534ebaf90f7205e59c20f392f66/example/android/build.gradle#L9
https://github.com/lcuis/matomo_forever/blob/dc8b3bd8f0baa534ebaf90f7205e59c20f392f66/example/android/gradle/wrapper/gradle-wrapper.properties#L6

It works perfectly with your fix !
Thank you for being so responsive and efficient.
Best,

Great! Thanks a lot for your confirmation and again for bringing this issue to my attention!


Added LAAT Pilots, Chassis Ability and Points

If I'm reading that test script output correctly, has it fail on the pilot image URL check?

and two missing commas... It's become my MO...
Will chase those image URLs for completeness and submit another Pull Request.


fix: npm publish verification

adding support for IEEE P1363 formatted signatures
fix the npm publish attestation bug. The verification always return success, because it was not using PAE signature

@trishankatdatadog PTAL

I like that you used the dsselib.EnvelopeVerifier interface.
Could you maybe add a bit more in the PR description as to what this PR is doing? esp. that this is adding support for IEEE P1363 formatted signatures.

 Thanks for fixing this!

LGTM, could use another pair of eyes to see whether I missed anything, thx!

@ianlewis provided a good review already. Waiting for his LGTM too. Thanks again!

Just to double-check: we do verify that the observed artefact digest does match the expected subject digest in both the provenance and publish attestations, correct?

yes

yes

Sorry to press you, but is there a test to this effect? I may have missed it...

yes

Sorry to press you, but is there a test to this effect? I may have missed it...

the tests are not part of this PR. They are present in the rest of the code.


[BUG] MongoDB Error

Describe the bug
The plugin starts and it connects to MongoDB but nothing works after that.
To Reproduce
Steps to reproduce the behavior:
Start the Server and watch
Expected behavior
A clear and concise description of what you expected to happen.
Screenshots and Logs
Connecting to MongoDB

Error:

Software Details:

Server Software: PurPur
Server Software Version: Current: git-Purpur-1933 (MC: 1.19.3)*
Plugin Version [LATEST]
Java Version: 17

This issue is fixed in the latest DEV build which can now be downloaded in the GitHub Actions. For further help make sure to send a message on my Discord or feel free to respond again to the issue.


V4 Add access ingress internal (istio)

Note: This PR will be merged into v4-branch. This PR is to make the review-process easier (as changes for v4 can get quite big)
This PR add support for access.ingress.internal:
ex usage:
access:
  ingress:
    internal:
      - application: app2
        namespace: n1
      # Allow traffic and do JWT validering from app3 from namespace n3
      - application: app3
        namespace: n3
        rules:
          - method: ["GET"]
            path: ["api/"]
            jwt:
              issuer: https://keycloak.ssb.no/auth/realms/ssb
              audience: app3
      - application: app3
        namespace: n3
        rules:
          - methods: ["GET"]
            paths: ["api/"]
          - methods: ["POST"]
            paths: ["internal/api/"]

One todo:
Consider to add support for 'when' (see https://istio.io/latest/docs/reference/config/security/authorization-policy/#Rule )
     - application: app3
        namespace: n3
        rules:
          - methods: ["GET"]
            paths: ["api/"]
            when: #TODO: Consider to support when
              - key: request.headers["x-ssb-ekstern-id"]
                values: ["123456789"]
              - key: request.headers[Authorization]
                values: ["Bearer *"]

Ref: https://statistics-norway.atlassian.net/browse/SKYINFRA-321

Implemented support for specifying serviceaccount as a field on ingress ( a65440b ), ref earlier discussion.

Rebased onto main

Merging this. Will have to do a more thorough review before v4 anyways, and I feel this has been review enough (also, Vidar doesn't have permission to approve explicit any more (out of github group))


kernel-bond Java processes do not exit while python3 kernel restart

OS: Ubuntu 16.04.3 LTS (GNU/Linux 2.6.32-042stab126.2 x86_64)
With python3.6.4 and anaconda 4.4.7, BeakerX version 0.11.0.
I have used version 0.10.0 on my server. This morning, I came across an issue that the Python kernel always dead and could not restart. After check, when the Python kernel stopped, the Java threads remained in system and consumed all the memory.
I update to 0.11.0, the issue remains.

might have been this: https://github.com/twosigma/beakerx/issues/6832


On Clicking Link a New Browser Window Is not Recognized by Robot.

Originally submitted to Google Code by sharifuddinnadeem on 28 Sep 2011

I am clicking on a link new browser on Current Window "Harness" and  that opens up another fire fox browser window with title "New Browser"
This "New Browser" window may be a Popup Window or Normal Window. I have no clue.
But When I am using Select Window Keyword , robot report gives error that Window "New Browser" is not found.
Can some body suggest me how to recognize new window in selenium library.
Here is my test case:
Open Browser	http://qsiwebgeneric/logIn.jsp	firefox
Select Window   Harness
Click Link	New Browser  (it will open up new browser)
Select Window   New Browser  (it's failing here.

Originally submitted to Google Code by @yanne on 16 Oct 2011

If the opened browser window is actually a separate process (= new, independent browser instance), there's no way for Selenium to get control of it. If the window is opened by JavaScript, Select Window should work.
Can you attach selenium-server.log that is written to your output directory?

Originally submitted to Google Code by @yanne on 14 Dec 2011

Closing due to lack of information


Datatables date sorting based on alphabetic ordering instead of date ordering

Effectively resolved in f7aebf1d986424d911f8ed90027b2d279e7ee774 by sorting by ticket ID descending, as larger ticket ID numbers indicate a more recently created ticket.


MRG: start cleaning up geometry

This is setting the stage for #165 . Might take more than one PR.
Very much work in progress right now

Codecov Report

Merging #174 into master will decrease coverage by 1.21%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #174      +/-   ##
==========================================
- Coverage   68.13%   66.92%   -1.22%
==========================================
  Files          19       19
  Lines        1955     1959       +4
==========================================
- Hits         1332     1311      -21
- Misses        623      648      +25

Impacted Files
Coverage Δ

hnn_core/cell.py
68.86% <ø> (-0.37%)
:arrow_down:

hnn_core/basket.py
100.00% <100.00%> (ø)

hnn_core/pyramidal.py
100.00% <100.00%> (+1.67%)
:arrow_up:

hnn_core/network.py
53.71% <0.00%> (-12.36%)
:arrow_down:

hnn_core/tests/test_compare_hnn.py
95.83% <0.00%> (-4.17%)
:arrow_down:

hnn_core/dipole.py
57.83% <0.00%> (-1.43%)
:arrow_down:

hnn_core/parallel_backends.py
15.06% <0.00%> (-1.36%)
:arrow_down:

hnn_core/feed.py
45.18% <0.00%> (ø)

hnn_core/mpi_child.py
0.00% <0.00%> (ø)

hnn_core/params_default.py
17.64% <0.00%> (ø)

... and 5 more

Continue to review full report at Codecov.

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

okay this is good to go for me. There is more work, but I stop here to keep the scope of the PR limited
@cjayb or @ntolley would you like to review?

Codecov Report

Merging #174 into master will decrease coverage by 1.48%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #174      +/-   ##
==========================================
- Coverage   68.13%   66.64%   -1.49%
==========================================
  Files          19       19
  Lines        1955     1943      -12
==========================================
- Hits         1332     1295      -37
- Misses        623      648      +25

Impacted Files
Coverage Δ

hnn_core/cell.py
68.86% <ø> (-0.37%)
:arrow_down:

hnn_core/basket.py
100.00% <100.00%> (ø)

hnn_core/pyramidal.py
100.00% <100.00%> (+1.67%)
:arrow_up:

hnn_core/network.py
53.71% <0.00%> (-12.36%)
:arrow_down:

hnn_core/tests/test_compare_hnn.py
95.83% <0.00%> (-4.17%)
:arrow_down:

hnn_core/dipole.py
57.83% <0.00%> (-1.43%)
:arrow_down:

hnn_core/parallel_backends.py
15.06% <0.00%> (-1.36%)
:arrow_down:

hnn_core/feed.py
45.18% <0.00%> (ø)

hnn_core/mpi_child.py
0.00% <0.00%> (ø)

hnn_core/params_default.py
17.64% <0.00%> (ø)

... and 5 more

Continue to review full report at Codecov.

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

Codecov Report

Merging #174 into master will decrease coverage by 1.48%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #174      +/-   ##
==========================================
- Coverage   68.13%   66.64%   -1.49%
==========================================
  Files          19       19
  Lines        1955     1943      -12
==========================================
- Hits         1332     1295      -37
- Misses        623      648      +25

Impacted Files
Coverage Δ

hnn_core/cell.py
68.86% <ø> (-0.37%)
:arrow_down:

hnn_core/basket.py
100.00% <100.00%> (ø)

hnn_core/pyramidal.py
100.00% <100.00%> (+1.67%)
:arrow_up:

hnn_core/network.py
53.71% <0.00%> (-12.36%)
:arrow_down:

hnn_core/tests/test_compare_hnn.py
95.83% <0.00%> (-4.17%)
:arrow_down:

hnn_core/dipole.py
57.83% <0.00%> (-1.43%)
:arrow_down:

hnn_core/parallel_backends.py
15.06% <0.00%> (-1.36%)
:arrow_down:

hnn_core/feed.py
45.18% <0.00%> (ø)

hnn_core/mpi_child.py
0.00% <0.00%> (ø)

hnn_core/params_default.py
17.64% <0.00%> (ø)

... and 5 more

Continue to review full report at Codecov.

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

okay addressed comments. And I did a few more clean up things while I was at it

Are we waiting on any other higher-priority PRs that this might interfere with or are we good to rebase and merge?

I think there might be some minor conflicts with @ntolley 's PR? But I can help rebase that one if needed. Let's keep the ball rolling.

I think there might be some minor conflicts with @ntolley 's PR?

No need to worry about that, I can deal with merge conflicts as they come up. Most of the finicky code in my PR lives in network_builder.py.


Refresh crate versions.

Bump the edition to 2021.

hey @shaleh , thanks for the PR. Current changes to main are stalled. The next version of toml-bombadil lives on this branch https://github.com/oknozor/toml-bombadil/pull/213 and should be added there. I did not had a lot of time to fix the CI an release that recently but I'll try to do it soon.

All good. Thanks for the heads up. Refreshed PR and rebased.

The watch support is a bigger kettle of fish so I left it out of this PR. They have completely rewritten the API. I wonder if extracting the watch logic and instead recommending people run the watchexec cli would be a better option. Should the watchexec logic stay it basically needs a clean start.


ScrollableViewport pauses animation when it changes size.

If a widget within a ScrollableViewport animates some layout change that results in the ScrollableViewport changing it size, any fling that happens to be running is paused and continued only after this animation is done.
@apwilson reported this bug earlier and @HansMuller added that the cause may likely be that the fling get continuously restarted while the animation is running.

@dragostis can you confirm if this is still reproducible and if yes, could you provide a minimal complete reproducible code sample along with your flutter doctor -v and your
flutter run --verbose
Thanks

Hi @dragostis
Even though the widget in question seems to not exist anymore, can you confirm if this is still reproducible and if yes, could you provide a minimal complete reproducible code sample along with your flutter doctor -v.
Thank you

Without additional information, we are unfortunately not sure how to resolve this issue.
We are therefore reluctantly going to close this bug for now.
Please don't hesitate to comment on the bug if you have any more information for us; we will reopen it right away!
Thanks for your contribution.
Could everyone who still has this problem please file a new issue with the exact description of what happens, logs, and the output of flutter doctor -v.
All system setups can be slightly different, so it's always better to open new issues and reference related issues.


duration: Infinity silently breaks toasts

Describe the feature / bug 📝:
When duration is set to Infinity as recommended in https://github.com/emilkowalski/sonner/issues/190, the toast never shows (it appears to never get added to the DOM).
Steps to reproduce the bug 🔁:

Set duration via

<Toast duration={Infinity} />
<Toast toastOptions={{ duration: Infinity }} />
toast('hej', { duration: Infinity })

Trigger the toast
Observe no toast

<EMAIL_ADDRESS><EMAIL_ADDRESS>¹ latest at time of this post
Otherwise, sonner is pretty sweet! (love that it doesn't use a hook, so it can be triggered outside a component)

Second this, Number.MAX_SAFE_INTEGER also does not display the toast.

toast('hej', { duration: Infinity })
This renders the toast for me that stays on the screen without any issues, am I missing something?

am I missing something?

Apparently, the part where it doesn't work at all. No idea why it's working for you. For me, duration: Infinity functions exactly like an off switch.

Can you create a codesandbox with reproduction?


Funcktion has wrong answer

When i use func run.bold or run.italic, run.underline etc. i have "True" or "None" in result. Why isn't it "True" or "False"???
Please be aware that the maintainer does create and evolve that package in his spare time. Please hold a second, breath deeply and think about your words.

Sorry for my anger, i was tired at that moment. I delited my code with examples and can't give you more Informathion


Devcontainer for Linux Development

This PR adds a .devcontainer directory with a configuration based on the template managed by Swift Server. Read more about that here. This enables Linux development on a macOS machine, using Docker.
I added this to fix the CI issue @kyouko-taiga has been hitting. The changes for that are in this PR as well - let me know if you'd like them separated. It appears we just had a few unnecessary flags that instructed the linker to find libraries that do not exist. Removing those appears to solve the issue locally (I can run swift test successfully) but I have yet to test it on CI.

On Mar 10, 2023, at 11:01 AM, Nick DeMarco @.***> wrote:
This PR adds a .devcontainer directory with a configuration based on the template managed by Swift Server https://github.com/swift-server/swift-devcontainer-template. Read more about that here https://forums.swift.org/t/swift-devcontainer-template/63161. This enables Linux development on a macOS machine, using Docker.

Love this, Nick!


Staging

@@               Coverage Report               @@
##              master          staging    +/- ##
=================================================
- Coverage      84.15%           78.65%    -5.49%
- Complexity        40               41        +1
=================================================
  Files              2                2         0
  Lines             82               89        +7
=================================================
+ Hits             774              775        +1
- Misses            13               19        +6


Building from source on Ubuntu for gpu environment

Description
I tried building from source for a while now. Followed the official link for building on Ubuntu. I wanted to experiment with GPU setup. My instance has two Tesla P100 in it.
used cp config/linux_gpu.cmake config.cmake instruction
Error Message
-- The C compiler identification is GNU 5.4.0
-- The CXX compiler identification is GNU 5.4.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc - works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ - works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- CMAKE_CROSSCOMPILING FALSE
-- CMAKE_HOST_SYSTEM_PROCESSOR x86_64
-- CMAKE_SYSTEM_PROCESSOR x86_64
-- CMAKE_SYSTEM_NAME Linux
-- CMake version '3.17.2' using generator 'Ninja'
-- Looking for a CUDA compiler
-- Looking for a CUDA compiler - /usr/local/cuda-10.1/bin/nvcc
-- The CUDA compiler identification is NVIDIA 10.1.168
-- Check for working CUDA compiler: /usr/local/cuda-10.1/bin/nvcc
-- Check for working CUDA compiler: /usr/local/cuda-10.1/bin/nvcc - works
-- Detecting CUDA compiler ABI info
-- Detecting CUDA compiler ABI info - done
-- Detecting CUDA compile features
-- Detecting CUDA compile features - done
-- CMAKE_BUILD_TYPE is unset, defaulting to Release
-- Intel MKL-DNN compat: set DNNL_BUILD_EXAMPLES to MKLDNN_BUILD_EXAMPLES with value `OFF`
-- Intel MKL-DNN compat: set DNNL_BUILD_TESTS to MKLDNN_BUILD_TESTS with value `OFF`
-- Intel MKL-DNN compat: set DNNL_ENABLE_JIT_PROFILING to MKLDNN_ENABLE_JIT_PROFILING with value `OFF`
-- Intel MKL-DNN compat: set DNNL_LIBRARY_TYPE to MKLDNN_LIBRARY_TYPE with value `STATIC`
-- Intel MKL-DNN compat: set DNNL_ARCH_OPT_FLAGS to MKLDNN_ARCH_OPT_FLAGS with value ``
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Found OpenMP_C: -fopenmp (found version "4.0")
-- Found OpenMP_CXX: -fopenmp (found version "4.0")
-- Found OpenMP: TRUE (found version "4.0")
-- GPU support is disabled
-- Found Doxygen: /usr/bin/doxygen (found version "1.8.11") found components: doxygen missing components: dot
-- Found Git: /usr/bin/git (found version "2.7.4")
-- Intel(R) VTune(TM) Amplifier JIT profiling disabled
-- Found OpenBLAS libraries: /usr/lib/libopenblas.so
-- Found OpenBLAS include: /usr/include
CMake Warning at /usr/share/OpenCV/OpenCVConfig.cmake:185 (message):
  opencv_imgcodecs is required but was not found
Call Stack (most recent call first):
  CMakeLists.txt:355 (find_package)

-- OpenCV <IP_ADDRESS> found (/usr/share/OpenCV)
--  OpenCV_LIBS=opencv_core;opencv_highgui;opencv_imgproc
-- Performing Test OPENMP_HAVE_WERROR_FLAG
-- Performing Test OPENMP_HAVE_WERROR_FLAG - Success
-- Performing Test OPENMP_HAVE_STD_GNUPP11_FLAG
-- Performing Test OPENMP_HAVE_STD_GNUPP11_FLAG - Success
-- Performing Test OPENMP_HAVE_STD_CPP11_FLAG
-- Performing Test OPENMP_HAVE_STD_CPP11_FLAG - Success
-- Found PythonInterp: /usr/bin/python (found version "3.5.2")
-- Cannot find llvm-lit.
-- Please put llvm-lit in your PATH, set OPENMP_LLVM_LIT_EXECUTABLE to its full path, or point OPENMP_LLVM_TOOLS_DIR to its directory.
CMake Warning at 3rdparty/openmp/cmake/OpenMPTesting.cmake:22 (message):
  The check targets will not be available!
Call Stack (most recent call first):
  3rdparty/openmp/cmake/OpenMPTesting.cmake:40 (find_standalone_test_dependencies)
  3rdparty/openmp/CMakeLists.txt:49 (include)

-- Performing Test LIBOMP_HAVE_FNO_EXCEPTIONS_FLAG
-- Performing Test LIBOMP_HAVE_FNO_EXCEPTIONS_FLAG - Success
-- Performing Test LIBOMP_HAVE_FNO_RTTI_FLAG
-- Performing Test LIBOMP_HAVE_FNO_RTTI_FLAG - Success
-- Performing Test LIBOMP_HAVE_X_CPP_FLAG
-- Performing Test LIBOMP_HAVE_X_CPP_FLAG - Success
-- Performing Test LIBOMP_HAVE_WCAST_QUAL_FLAG
-- Performing Test LIBOMP_HAVE_WCAST_QUAL_FLAG - Success
-- Performing Test LIBOMP_HAVE_WNO_UNUSED_FUNCTION_FLAG
-- Performing Test LIBOMP_HAVE_WNO_UNUSED_FUNCTION_FLAG - Success
-- Performing Test LIBOMP_HAVE_WNO_UNUSED_LOCAL_TYPEDEF_FLAG
-- Performing Test LIBOMP_HAVE_WNO_UNUSED_LOCAL_TYPEDEF_FLAG - Failed
-- Performing Test LIBOMP_HAVE_WNO_UNUSED_VALUE_FLAG
-- Performing Test LIBOMP_HAVE_WNO_UNUSED_VALUE_FLAG - Success
-- Performing Test LIBOMP_HAVE_WNO_UNUSED_VARIABLE_FLAG
-- Performing Test LIBOMP_HAVE_WNO_UNUSED_VARIABLE_FLAG - Success
-- Performing Test LIBOMP_HAVE_WNO_SWITCH_FLAG
-- Performing Test LIBOMP_HAVE_WNO_SWITCH_FLAG - Success
-- Performing Test LIBOMP_HAVE_WNO_COVERED_SWITCH_DEFAULT_FLAG
-- Performing Test LIBOMP_HAVE_WNO_COVERED_SWITCH_DEFAULT_FLAG - Failed
-- Performing Test LIBOMP_HAVE_WNO_DEPRECATED_REGISTER_FLAG
-- Performing Test LIBOMP_HAVE_WNO_DEPRECATED_REGISTER_FLAG - Failed
-- Performing Test LIBOMP_HAVE_WNO_SIGN_COMPARE_FLAG
-- Performing Test LIBOMP_HAVE_WNO_SIGN_COMPARE_FLAG - Success
-- Performing Test LIBOMP_HAVE_WNO_GNU_ANONYMOUS_STRUCT_FLAG
-- Performing Test LIBOMP_HAVE_WNO_GNU_ANONYMOUS_STRUCT_FLAG - Failed
-- Performing Test LIBOMP_HAVE_WNO_UNKNOWN_PRAGMAS_FLAG
-- Performing Test LIBOMP_HAVE_WNO_UNKNOWN_PRAGMAS_FLAG - Success
-- Performing Test LIBOMP_HAVE_WNO_MISSING_FIELD_INITIALIZERS_FLAG
-- Performing Test LIBOMP_HAVE_WNO_MISSING_FIELD_INITIALIZERS_FLAG - Success
-- Performing Test LIBOMP_HAVE_WNO_MISSING_BRACES_FLAG
-- Performing Test LIBOMP_HAVE_WNO_MISSING_BRACES_FLAG - Success
-- Performing Test LIBOMP_HAVE_WNO_COMMENT_FLAG
-- Performing Test LIBOMP_HAVE_WNO_COMMENT_FLAG - Success
-- Performing Test LIBOMP_HAVE_WNO_SELF_ASSIGN_FLAG
-- Performing Test LIBOMP_HAVE_WNO_SELF_ASSIGN_FLAG - Failed
-- Performing Test LIBOMP_HAVE_WNO_VLA_EXTENSION_FLAG
-- Performing Test LIBOMP_HAVE_WNO_VLA_EXTENSION_FLAG - Failed
-- Performing Test LIBOMP_HAVE_WNO_FORMAT_PEDANTIC_FLAG
-- Performing Test LIBOMP_HAVE_WNO_FORMAT_PEDANTIC_FLAG - Failed
-- Performing Test LIBOMP_HAVE_WSTRINGOP_OVERFLOW_FLAG
-- Performing Test LIBOMP_HAVE_WSTRINGOP_OVERFLOW_FLAG - Failed
-- Performing Test LIBOMP_HAVE_MSSE2_FLAG
-- Performing Test LIBOMP_HAVE_MSSE2_FLAG - Success
-- Performing Test LIBOMP_HAVE_FTLS_MODEL_FLAG
-- Performing Test LIBOMP_HAVE_FTLS_MODEL_FLAG - Success
-- Performing Test LIBOMP_HAVE_MMIC_FLAG
-- Performing Test LIBOMP_HAVE_MMIC_FLAG - Failed
-- Performing Test LIBOMP_HAVE_M32_FLAG
-- Performing Test LIBOMP_HAVE_M32_FLAG - Failed
-- Performing Test LIBOMP_HAVE_X_FLAG
-- Performing Test LIBOMP_HAVE_X_FLAG - Success
-- Performing Test LIBOMP_HAVE_WARN_SHARED_TEXTREL_FLAG
-- Performing Test LIBOMP_HAVE_WARN_SHARED_TEXTREL_FLAG - Success
-- Performing Test LIBOMP_HAVE_AS_NEEDED_FLAG
-- Performing Test LIBOMP_HAVE_AS_NEEDED_FLAG - Success
-- Performing Test LIBOMP_HAVE_VERSION_SCRIPT_FLAG
-- Performing Test LIBOMP_HAVE_VERSION_SCRIPT_FLAG - Success
-- Performing Test LIBOMP_HAVE_STATIC_LIBGCC_FLAG
-- Performing Test LIBOMP_HAVE_STATIC_LIBGCC_FLAG - Success
-- Performing Test LIBOMP_HAVE_Z_NOEXECSTACK_FLAG
-- Performing Test LIBOMP_HAVE_Z_NOEXECSTACK_FLAG - Success
-- Performing Test LIBOMP_HAVE_FINI_FLAG
-- Performing Test LIBOMP_HAVE_FINI_FLAG - Success
-- Found Perl: /usr/bin/perl (found version "5.22.1")
-- Performing Test LIBOMP_HAVE_VERSION_SYMBOLS
-- Performing Test LIBOMP_HAVE_VERSION_SYMBOLS - Success
-- Performing Test LIBOMP_HAVE___BUILTIN_FRAME_ADDRESS
-- Performing Test LIBOMP_HAVE___BUILTIN_FRAME_ADDRESS - Success
-- Performing Test LIBOMP_HAVE_WEAK_ATTRIBUTE
-- Performing Test LIBOMP_HAVE_WEAK_ATTRIBUTE - Success
-- Looking for include files windows.h, psapi.h
-- Looking for include files windows.h, psapi.h - not found
-- Looking for EnumProcessModules in psapi
-- Looking for EnumProcessModules in psapi - not found
-- LIBOMP: Operating System     -- Linux
-- LIBOMP: Target Architecture  -- x86_64
-- LIBOMP: Build Type           -- Release
-- LIBOMP: Library Kind         -- SHARED
-- LIBOMP: Library Type         -- normal
-- LIBOMP: Fortran Modules      -- FALSE
-- LIBOMP: Build                -- 20140926
-- LIBOMP: Use Stats-gathering  -- FALSE
-- LIBOMP: Use Debugger-support -- FALSE
-- LIBOMP: Use ITT notify       -- TRUE
-- LIBOMP: Use OMPT-support     -- TRUE
-- LIBOMP: Use OMPT-optional  -- TRUE
-- LIBOMP: Use Adaptive locks   -- TRUE
-- LIBOMP: Use quad precision   -- TRUE
-- LIBOMP: Use TSAN-support     -- FALSE
-- LIBOMP: Use Hwloc library    -- FALSE
-- Looking for sqrt in m
-- Looking for sqrt in m - found
-- Looking for __atomic_load_1
-- Looking for __atomic_load_1 - not found
-- Looking for __atomic_load_1 in atomic
-- Looking for __atomic_load_1 in atomic - found
-- check-libomp does nothing.
-- check-ompt does nothing.
-- check-openmp does nothing.
USE_LAPACK is ON
CMake Warning at 3rdparty/googletest/googletest/CMakeLists.txt:47 (project):
  VERSION keyword not followed by a value or was followed by a value that
  expanded to nothing.

-- Found GTest: gtest
-- Found CUDNN: /usr/local/cuda/lib64/libcudnn.so
-- Found OpenMP_C: -fopenmp
-- Found OpenMP_CXX: -fopenmp
-- Found OpenMP: TRUE
-- Looking for clock_gettime in rt
-- Looking for clock_gettime in rt - found
-- Looking for fopen64
-- Looking for fopen64 - not found
-- Looking for C++ include cxxabi.h
-- Looking for C++ include cxxabi.h - found
-- Looking for nanosleep
-- Looking for nanosleep - found
-- Looking for backtrace
-- Looking for backtrace - found
-- backtrace facility detected in default set of libraries
-- Found Backtrace: /usr/include
-- Check if the system is big endian
-- Searching 16 bit integer
-- Looking for sys/types.h
-- Looking for sys/types.h - found
-- Looking for stdint.h
-- Looking for stdint.h - found
-- Looking for stddef.h
-- Looking for stddef.h - found
-- Check size of unsigned short
-- Check size of unsigned short - done
-- Searching 16 bit integer - Using unsigned short
-- Check if the system is big endian - little endian
-- /home/cc/mxnet/3rdparty/dmlc-core/cmake/build_config.h.in -> include/dmlc/build_config.h
-- Performing Test SUPPORT_MSSE2
-- Performing Test SUPPORT_MSSE2 - Success
-- Autodetected CUDA architecture(s):  6.0 6.0
-- CUDA: Using the following NVCC architecture flags -gencode;arch=compute_60,code=sm_60
-- Found CUDAToolkit: /usr/local/cuda-10.1/include (found version "10.1.168")
-- Found NVML: /usr/local/cuda/include
-- Found NVML (include: /usr/local/cuda/include, library: /usr/lib/x86_64-linux-gnu/libnvidia-ml.so)
-- Found NCCL: /usr/include
-- Found NCCL (include: /usr/include, library: /usr/lib/x86_64-linux-gnu/libnccl.so)
-- Performing Test SUPPORT_MSSE3
-- Performing Test SUPPORT_MSSE3 - Success
-- Determining F16C support
-- Performing Test COMPILER_SUPPORT_MF16C
-- Performing Test COMPILER_SUPPORT_MF16C - Success
-- Found Python3: /usr/bin/python3.5 (found version "3.5.2") found components: Interpreter
CMake Warning at CMakeLists.txt:832 (message):
  OpenCV_VERSION_MAJOR: 2, version 3 with imgcodecs is required for im2rec,
  im2rec will not be available

-- Configuring done
-- Generating done
-- Build files have been written to: /home/cc/mxnet/build

To Reproduce
Just followed the instruction from the building page.
cmake -GNinja ..
is failing
What have you tried to solve it?

Installed nccl, cuDNN
Also Followed old build instruction using make

Environment
curl --retry 10 -s https://raw.githubusercontent.com/dmlc/gluon-nlp/master/tools/diagnose.py | python

----------Python Info----------
Version      : 3.5.2
Compiler     : GCC 5.4.0 20160609
Build        : ('default', 'Oct  8 2019 13:06:37')
Arch         : ('64bit', 'ELF')
------------Pip Info-----------
Version      : 8.1.1
Directory    : /usr/lib/python3/dist-packages/pip
----------MXNet Info-----------
No MXNet installed.
----------System Info----------
Platform     : Linux-4.4.0-177-generic-x86_64-with-Ubuntu-16.04-xenial
system       : Linux
node         : bytescheduler
release      : 4.4.0-177-generic
version      : #207-Ubuntu SMP Mon Mar 16 01:16:10 UTC 2020
----------Hardware Info----------
machine      : x86_64
processor    : x86_64
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                48
On-line CPU(s) list:   0-47
Thread(s) per core:    2
Core(s) per socket:    12
Socket(s):             2
NUMA node(s):          2
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 63
Model name:            Intel(R) Xeon(R) CPU E5-2670 v3 @ 2.30GHz
Stepping:              2
CPU MHz:               1463.015
CPU max MHz:           3100.0000
CPU min MHz:           1200.0000
BogoMIPS:              4601.07
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              30720K
NUMA node0 CPU(s):     0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38,40,42,44,46
NUMA node1 CPU(s):     1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39,41,43,45,47
Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm epb invpcid_single ssbd ibrs ibpb stibp kaiser tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm xsaveopt cqm_llc cqm_occup_llc dtherm ida arat pln pts md_clear flush_l1d
----------Network Test----------
Setting timeout: 10
Error open Conda: https://repo.continuum.io/pkgs/free/, HTTP Error 403: Forbidden, DNS finished in 0.026647567749023438 sec.
Timing for MXNet: https://github.com/apache/incubator-mxnet, DNS: 0.0013 sec, LOAD: 0.5594 sec.
Timing for GluonNLP: http://gluon-nlp.mxnet.io, DNS: 0.1320 sec, LOAD: 0.4132 sec.
Timing for D2L (zh-cn): http://zh.d2l.ai, DNS: 0.0350 sec, LOAD: 0.1409 sec.
Timing for GluonNLP GitHub: https://github.com/dmlc/gluon-nlp, DNS: 0.0000 sec, LOAD: 0.5460 sec.
Timing for FashionMNIST: https://repo.mxnet.io/gluon/dataset/fashion-mnist/train-labels-idx1-ubyte.gz, DNS: 0.0922 sec, LOAD: 0.3971 sec.
Timing for D2L: http://d2l.ai, DNS: 0.0331 sec, LOAD: 0.4027 sec.
Timing for PYPI: https://pypi.python.org/pypi/pip, DNS: 0.0118 sec, LOAD: 0.2965 sec.

You need c++17 compiler for compiling latest master version. Doc will be updated by https://github.com/apache/incubator-mxnet/pull/18161/


Animation.isComplete is true after calling play() on clean armature.animation

Hi,
I get armature.animation.isComplete value of TRUE when I call play for a newly created Armature instance. I checked the source. Looks like _totalTime is set to 0 play() because it only is calculated from this code:
if(tweenTime >= 0)
{
    _totalTime = tweenTime;
}
else if(tweenEnabled && exMovementID)
{
    _totalTime = _movementData.durationTo;
}
else
{
    _totalTime = 0;
}

So it ends up on else because exMovementID is null. But it would also fail when durationTo is 0. Later in code it reads durationTween
_duration = duration >= 0  duration : _movementData.durationTween;
Not sure  about it but I think _totalTime should be updated by _duration value i.e.
_totalTime += _duration
or isComplete should be updated by _isPlaying value i.e.
public function get isComplete():Boolean
{
    return _loop < 0 && _currentTime >= _totalTime && !_isPlaying;
}

But I'm not aware of all the logic behind this nor how exactly it works so it's just speculations. Anyway, please fix it :)
The bug relates to the latest 'dev' branch v2.0

Hi, the bug has been fixed


Add -f flag to allow FGA model files to be provided to the fga model validate command

I'd like to be able to validate a model using the OpenFGA CLI, and my model is stored in a model.fga file.
# model.fga
model
  schema 1.1

type user

type document
  relations
    define viewer: [user]

and I'd like to be able to fga model validate -f model.fga.

We don't support shorthand flags for the moment until the rest of the cli has stabilized.
You can do:
fga model validate --file model.fga

I was using an old version of the CLI. Nvm 😄


When the tab receives focus, immediately move focus to the active control

I'm mostly just putting the PR out there for comments. I'm worried that this might have horrifying unintentional side-effects for accessibility, which I'm not loving.
This PR makes the Tab immediately toss focus to the active control, whenever the Tab receives focus, for any reason.

Left-click on the tab to focus the window? Focus the control. #3609
Close the color picker? Focus the control.
Hit esc to dismiss the menuflyout from the New Tab menu, the tab context menu? Focus the control. #5750
Hit esc to dismiss the tab rename? Focus the control.

@carlos-zamora will this horribly break accessibility?
My other theory here is to pre-emptively prevent the tab from receiving focus. That would probably involve

Focusing the control when a tab is left clicked
Manually passing focus to the control when any flyout is closed
Manually passing focus to the control when the color picker is closed
Manually passing focus to the control when the tab renamer is dismissed
Manually passing focus to the control when the command palette is closed
Manually passing focus to the control when <any future UI> is closed

So that might not scale as well, but that might be the more correct solution.

[x] I work here
[ ] This is UI so it doesn't have tests
[x] Closes #3609
[x] Closes #5750

I don't know about this. I recall there being some UI paradigm where you can use the tab key to move around between UI elements. And if that element is a tab row, you can then use the arrow keys to move a highlight between the tabs and press spacebar to then switch to the highlighted one. And if you're shirking the focus off the tab row anytime it hits... that's probably broken. I don't know if that's a part of the TabView control that we get from MUX, but I'm doing that right now in Microsoft Edge and it works that way...

Yea, that was basically exactly my feeling with this PR. It seemed like "it worked", but not the right way.
Unless anyone else has any enlightened ideas about how to do this in a more clever way, I think I'm going to change this to the more manual "this control knows it's been closed, so it'll ask for focus to go back to the Terminal". It'll be more manual work to do for each and every UI element, but seems like the only good solution.

Downloaded and did some testing:

Narrator:

user can use the Narrator+Left and Narrator+Right commands to navigate to other UI elements. So the user is still able to access the tabs (aside from using our custom keybindings to invoke them). (reference)

NVDA:

The good news is that NVDA already separates UI navigation from where the focus actually is (there's an NVDA keybinding to specifically navigate to the focused object). So, this basically doesn't affect it.
(unrelated to this PR) The bad news is, NVDA's UI navigation model exposes so many ugly details in our UI (i.e.: the cutout is something you can navigate to as an "unknown" object). This makes finding the tabs a pain (Tab Row Control --> list --> ), and I wasn't able to find the dropdown. The workaround here though is to use the dropdown keybinding.
All of these problems already existed before though. So I'll file an issue to track that specifically since it's unrelated to this PR.

TL;DR: this did not horribly break accessibility

Is this just waiting on the reviewer to approve?  Besides the merge conflicts, or is there some other blocker here?

I've kinda just left this stagnate while we were building some other UI elements, because this probably needs to be solved in a way that's more cohesive across various different UI elements. Most of that work is being tracked in #6680. I want to make sure that however we actually do end up fixing this is the right solution, not just a hack, and this fix seems like a hack ATM.

Closing in favor of the much more targeted strike in #10048


feat(fscomponents): Custom styling for swatch show more/less

Allows setting maxSwatches to 0 or negative to continue showing all swatches even when show less is selected. This also allows specific styling for the container when less or more is selected. This does slightly alter the behavior because the style is applied to a view wrapping just the swatches and not the more/less selection.

Added classes that allow adding vender-specific styling to affect the scrollable area's behavior.


[DOC] Confusing text for HugeCTR data types in 02-ETL-with-NVTabular Movielens example notebook

Report incorrect documentation
Location of incorrect documentation
Provide links and line numbers if applicable.
Describe the problems or issues found in the documentation
02-ETL-with-NVTabular notebook says we pass in hugectr datatypes when creating the dataset but we don’t actually do that which is confusing to a new user.

In reality, we pass in hugectr dictionary of datatypes later when we transform the workflow.
Suggested fix for documentation
Make text around passing in hugeCTR datatypes dictionary less confusing.

@kshitizgupta21 Thanks for the feedback.
As you are pointing, that description should be updated. I will include it in PR #1329


fastfetch: 2.17.0 -> 2.17.2

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for fastfetch is: Like neofetch, but much faster because written in C
meta.homepage for fastfetch is: https://github.com/fastfetch-cli/fastfetch
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 2.17.2 with grep in /nix/store/7qq7nzqlkdvcv62vi3g1y3z6xzc810mw-fastfetch-2.17.2
found 2.17.2 in filename of file in /nix/store/7qq7nzqlkdvcv62vi3g1y3z6xzc810mw-fastfetch-2.17.2

Rebuild report (if merged into master) (click to expand)

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath

fastfetch

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/7qq7nzqlkdvcv62vi3g1y3z6xzc810mw-fastfetch-2.17.2 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A fastfetch https://github.com/r-ryantm/nixpkgs/archive/e2fb886b51df7502b83145d6f417f37a0a9f0f69.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/e2fb886b51df7502b83145d6f417f37a0a9f0f69#fastfetch

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/7qq7nzqlkdvcv62vi3g1y3z6xzc810mw-fastfetch-2.17.2
ls -la /nix/store/7qq7nzqlkdvcv62vi3g1y3z6xzc810mw-fastfetch-2.17.2/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

2 packages built:

fastfetch
fastfetch.man

Maintainer pings
cc @khaneliman for testing.

Result of nixpkgs-review pr 324806 run on x86_64-linux 1

2 packages built:

fastfetch
fastfetch.man

Result of nixpkgs-review pr 324806 run on aarch64-darwin 1

2 packages built:

fastfetch
fastfetch.man

the comment should start with @NixOS/nixpkgs-merge-bot merge, otherwise the regex won't trigger :)


Automated cherry pick of #4683: hostman: distro name OpenWrt instead of OpenWRT

Cherry pick of #4683 on release/2.12.
#4683: hostman: distro name OpenWrt instead of OpenWRT

Codecov Report

:exclamation: No coverage uploaded for pull request base (release/2.12@cb2f1aa). Click here to learn what that means.
The diff coverage is 0%.

@@              Coverage Diff               @@
##             release/2.12   #4688   +/-   ##
==============================================
  Coverage                ?   6.86%
==============================================
  Files                   ?     502
  Lines                   ?   85619
  Branches                ?       0
==============================================
  Hits                    ?    5877
  Misses                  ?   79248
  Partials                ?     494

Flag
Coverage Δ

#aFlag
6.86% <0%> (?)

Impacted Files
Coverage Δ

pkg/hostman/guestfs/fsdriver/linux.go
0% <0%> (ø)

pkg/hostman/guestfs/fsdriver/base.go
13.08% <0%> (ø)

Continue to review full report at Codecov.

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

/lgtm

/approve


Join error

Everytime any user joins my server I end up getting this error.
http://pastebin.com/n3YjNLpe
Sponge V 1693
Forge V 1890

You're using incompatible versions of PEX and Sponge -- actually read the forum post with download links.