TextInput component with placeholderTextColor attribute appears to overlap cursor

Noticed in our application that the placeholder text appeared above  the cursor:

Occurs on both iOS and Android platforms.
Simply removing the placeholderTextColor attribute appears to fix the overlap:

React Native version:

System:
    OS: macOS 10.15.2
    CPU: (4) x64 Intel(R) Core(TM) i5-7360U CPU @ 2.30GHz
    Memory: 1.21 GB / 16.00 GB
    Shell: 5.7.1 - /bin/zsh
  Binaries:
    Node: 10.16.0 - ~/.nvm/versions/node/v10.16.0/bin/node
    Yarn: 1.21.1 - /usr/local/bin/yarn
    npm: 6.9.0 - ~/.nvm/versions/node/v10.16.0/bin/npm
    Watchman: 4.9.0 - /usr/local/bin/watchman
  SDKs:
    iOS SDK:
      Platforms: iOS 13.2, DriverKit 19.0, macOS 10.15, tvOS 13.2, watchOS 6.1
    Android SDK:
      API Levels: 28, 29
      Build Tools: 29.0.2
      System Images: android-28 | Intel x86 Atom_64, android-28 | Google APIs Intel x86 Atom, android-29 | Intel x86 Atom_64, android-29 | Google APIs Intel x86 Atom
  IDEs:
    Android Studio: 3.5 AI-191.8<IP_ADDRESS>10548
    Xcode: 11.3/11C29 - /usr/bin/xcodebuild
  npmPackages:
    react: link:../libraries/node_modules/react => 16.11.0
    react-native: ^0.61.5 => 0.61.5

Steps To Reproduce

Create a TextInput
Add a placeholderTextColor (in our case, the value was #CFCECE)

Describe what you expected to happen:
We expected the cursor to continue to appear over the placeholder text.
Snack, code example, screenshot, or link to a repository:

I tried to reproduce in this snack: https://snack.expo.io/B12ftrpkL
Unfortunately, not reproducible on iOS, however it seems to be an issue with or without the placeholderTextColor attribute on Android, so I'm not sure this simulator can be trusted for this specific issue. 😕

Does this occur the same for both multiline and single line inputs?


CI: K8sDatapathConfig Encapsulation Check iptables masquerading with random-fully fails on k8s-all

every build on https://jenkins.cilium.io/job/cilium-master-K8s-all/ fails
/home/jenkins/workspace/cilium-master-K8s-all/1.14-gopath/src/github.com/cilium/cilium/test/ginkgo-ext/scopes.go:514
Pod "testclient-gzk8w" can not connect to "http://google.com"
Expected command: kubectl exec -n<PHONE_NUMBER>14k8sdatapathconfigencapsulationcheckiptablesmasquera testclient-gzk8w -- curl --path-as-is -s -D /dev/stderr --fail --connect-timeout 5 --max-time 20 http://google.com -w "time-> DNS: '%{time_namelookup}(%{remote_ip})', Connect: '%{time_connect}',Transfer '%{time_starttransfer}', total '%{time_total}'" --retry 10
To succeed, but it failed:
Exitcode: 1
Err: context deadline exceeded
Stdout:

Stderr:

focused test run also fails in the same way on 1.14, so it's unlikely this is infra/ci related: https://jenkins.cilium.io/job/Cilium-PR-Ginkgo-Tests-Kernel-Focus/100/

This test validates a new Cilium flags (iptablesRandomFully) that is propagated to our masquerading iptables rules (as --random-fully). That flags should only affect the selection of the new source port when doing SNAT.
The test doesn't fail on our PRs but fails in k8s-all, which indicates the failure is somehow related to the Kubernetes version. So, it doesn't fail for 1.12, 1.19, and 1.18, but does fail for 1.14, 1.15, 1.16 at least. That could be due to some weird interaction with kube-proxy for those versions.
We weren't able to reproduce locally with the same K8s versions and kernel (4.9), even after multiple runs. There might be some timing factor that makes this harder.
Two things we can check next:

Compare the iptables rules for K8s versions that work and don't work. We have enough versions of each that it may be possible to spot a difference that matters.
I don't think we have an equivalent test in CI without the new iptablesRandomFully option (i.e., Check iptables masquerading with random-fully without that option). It might be worth adding such a test to check if it also fails. If it also fails, then the flake has nothing to do with the new option.

I don't think we have an equivalent test in CI without the new iptablesRandomFully option (i.e., Check iptables masquerading with random-fully without that option). It might be worth adding such a test to check if it also fails. If it also fails, then the flake has nothing to do with the new option.

In #14476 I added a test for masquerading without the random-fully iptables option, and the test is running fine for the different 1.14, 1.15 and 1.16 k8s versions:

https://jenkins.cilium.io/job/cilium-master-K8s-all/555/testReport/Suite-k8s-1/14/K8sDatapathConfig_Encapsulation_Check_iptables_masquerading_without_random_fully/
https://jenkins.cilium.io/job/cilium-master-K8s-all/555/testReport/Suite-k8s-1/15/K8sDatapathConfig_Encapsulation_Check_iptables_masquerading_without_random_fully/
https://jenkins.cilium.io/job/cilium-master-K8s-all/552/testReport/Suite-k8s-1/16/K8sDatapathConfig_Encapsulation_Check_iptables_masquerading_without_random_fully/

I don't think we have an equivalent test in CI without the new iptablesRandomFully option (i.e., Check iptables masquerading with random-fully without that option). It might be worth adding such a test to check if it also fails. If it also fails, then the flake has nothing to do with the new option.

In #14476 I added a test for masquerading without the random-fully iptables option, and the test is running fine for the different 1.14, 1.15 and 1.16 k8s versions:

https://jenkins.cilium.io/job/cilium-master-K8s-all/555/testReport/Suite-k8s-1/14/K8sDatapathConfig_Encapsulation_Check_iptables_masquerading_without_random_fully/
https://jenkins.cilium.io/job/cilium-master-K8s-all/555/testReport/Suite-k8s-1/15/K8sDatapathConfig_Encapsulation_Check_iptables_masquerading_without_random_fully/
https://jenkins.cilium.io/job/cilium-master-K8s-all/552/testReport/Suite-k8s-1/16/K8sDatapathConfig_Encapsulation_Check_iptables_masquerading_without_random_fully/

Some updates here: I took a look at the iptables configuration to see if I can spot any difference between a k8s version that is known to work and one that does not.
I started from 1.18, which is known to work.
I reproduced the test locally with:
$ NFS=1 K8S_VERSION=1.18 KUBEPROXY=1 ginkgo --focus "K8sDatapathConfig.*Check iptables masquerading with random-fully" -- -cilium.provision=true -cilium.holdEnvironment=true-cilium.runQuarantined

before that I added a helpers.HoldEnvironment("") at the end of relevant test:
--- a/test/k8sT/DatapathConfiguration.go
+++ b/test/k8sT/DatapathConfiguration.go
@@ -279,6 +279,7 @@ var _ = Describe("K8sDatapathConfig", func() {
                        By("Test iptables masquerading")
                        Expect(testPodHTTPToOutside(kubectl, "http://google.com", false, false)).
                                Should(BeTrue(), "Connectivity test to http://google.com failed")
+                       helpers.HoldEnvironment("")
                })

After the test run I dumped the iptables configuration (1.18.txt) and it looks like there are no rules with the --random-fully option set:
$ rg random-fully 1.18.txt
$

although if I grep for --random-fully in the Cilium logs I get:
level=debug msg="Considering removing iptables rule" obj="-A CILIUM_POST_nat -s <IP_ADDRESS>/24 ! -d <IP_ADDRESS>/8 ! -o cilium_+ -m comment --comment \"cilium masquerade non-cluster\" -j MASQUERADE --random-fully" subsys=iptables
level=debug msg="Removing iptables rule" obj="[-w 5 -t nat -D CILIUM_POST_nat -s <IP_ADDRESS>/24 ! -d <IP_ADDRESS>/8 ! -o cilium_+ -m comment --comment cilium masquerade non-cluster -j MASQUERADE --random-fully]" subsys=iptables
level=debug msg="Considering removing iptables rule" obj="-A KUBE-POSTROUTING -m comment --comment \"kubernetes service traffic requiring SNAT\" -j MASQUERADE --random-fully" subsys=iptables
level=debug msg="Considering removing ip6tables rule" obj="-A CILIUM_POST_nat -s fd02::100/120 ! -d fd02::100/120 ! -o cilium_+ -m comment --comment \"cilium masquerade non-cluster\" -j MASQUERADE --random-fully" subsys=iptables
level=debug msg="Removing ip6tables rule" obj="[-w 5 -t nat -D CILIUM_POST_nat -s fd02::100/120 ! -d fd02::100/120 ! -o cilium_+ -m comment --comment cilium masquerade non-cluster -j MASQUERADE --random-fully]" subsys=iptables
level=debug msg="Considering removing ip6tables rule" obj="-A KUBE-POSTROUTING -m comment --comment \"kubernetes service traffic requiring SNAT\" -j MASQUERADE --random-fully" subsys=iptables

(I don't have context on why Cilium is suggesting that).
Repeating the same test on 1.14 (which is known for not working) I got the following iptables configuration: 1.14.txt. There is still no trace of rules with --random-fully:
$ rg random-fully 1.14.txt
$

But this time Cilium was not suggesting to remove the rules:
vagrant@k8s1:~$ ks logs $(cilium_pod k8s1) | grep random-fully
level=info msg="  --iptables-random-fully='true'" subsys=daemon

Some updates here: I took a look at the iptables configuration to see if I can spot any difference between a k8s version that is known to work and one that does not.
I started from 1.18, which is known to work.
I reproduced the test locally with:
$ NFS=1 K8S_VERSION=1.18 KUBEPROXY=1 ginkgo --focus "K8sDatapathConfig.*Check iptables masquerading with random-fully" -- -cilium.provision=true -cilium.holdEnvironment=true-cilium.runQuarantined

before that I added a helpers.HoldEnvironment("") at the end of relevant test:
--- a/test/k8sT/DatapathConfiguration.go
+++ b/test/k8sT/DatapathConfiguration.go
@@ -279,6 +279,7 @@ var _ = Describe("K8sDatapathConfig", func() {
                        By("Test iptables masquerading")
                        Expect(testPodHTTPToOutside(kubectl, "http://google.com", false, false)).
                                Should(BeTrue(), "Connectivity test to http://google.com failed")
+                       helpers.HoldEnvironment("")
                })

After the test run I dumped the iptables configuration (1.18.txt) and it looks like there are no rules with the --random-fully option set:
$ rg random-fully 1.18.txt
$

although if I grep for --random-fully in the Cilium logs I get:
level=debug msg="Considering removing iptables rule" obj="-A CILIUM_POST_nat -s <IP_ADDRESS>/24 ! -d <IP_ADDRESS>/8 ! -o cilium_+ -m comment --comment \"cilium masquerade non-cluster\" -j MASQUERADE --random-fully" subsys=iptables
level=debug msg="Removing iptables rule" obj="[-w 5 -t nat -D CILIUM_POST_nat -s <IP_ADDRESS>/24 ! -d <IP_ADDRESS>/8 ! -o cilium_+ -m comment --comment cilium masquerade non-cluster -j MASQUERADE --random-fully]" subsys=iptables
level=debug msg="Considering removing iptables rule" obj="-A KUBE-POSTROUTING -m comment --comment \"kubernetes service traffic requiring SNAT\" -j MASQUERADE --random-fully" subsys=iptables
level=debug msg="Considering removing ip6tables rule" obj="-A CILIUM_POST_nat -s fd02::100/120 ! -d fd02::100/120 ! -o cilium_+ -m comment --comment \"cilium masquerade non-cluster\" -j MASQUERADE --random-fully" subsys=iptables
level=debug msg="Removing ip6tables rule" obj="[-w 5 -t nat -D CILIUM_POST_nat -s fd02::100/120 ! -d fd02::100/120 ! -o cilium_+ -m comment --comment cilium masquerade non-cluster -j MASQUERADE --random-fully]" subsys=iptables
level=debug msg="Considering removing ip6tables rule" obj="-A KUBE-POSTROUTING -m comment --comment \"kubernetes service traffic requiring SNAT\" -j MASQUERADE --random-fully" subsys=iptables

(I don't have context on why Cilium is suggesting that).
Repeating the same test on 1.14 (which is known for not working) I got the following iptables configuration: 1.14.txt. There is still no trace of rules with --random-fully:
$ rg random-fully 1.14.txt
$

But this time Cilium was not suggesting to remove the rules:
vagrant@k8s1:~$ ks logs $(cilium_pod k8s1) | grep random-fully
level=info msg="  --iptables-random-fully='true'" subsys=daemon

That netfilter option has had a somewhat lacking support in iptables in the past, so it may be worth checking that it is even supposed to appear in iptables rule dumps. It could be that in the 1.14 case, there are iptables rules with --random-fully but they are dumped without the --random-fully, maybe? (Which I'd consider a bug upstream.)
The Considering removing ... messages come from removeCiliumRules. It might be worth checking if that is expected. If --random-fully rules are for some reason removed on 1.18, it could explain why 1.18 succeeds and 1.14 fails.

That netfilter option has had a somewhat lacking support in iptables in the past, so it may be worth checking that it is even supposed to appear in iptables rule dumps. It could be that in the 1.14 case, there are iptables rules with --random-fully but they are dumped without the --random-fully, maybe? (Which I'd consider a bug upstream.)
The Considering removing ... messages come from removeCiliumRules. It might be worth checking if that is expected. If --random-fully rules are for some reason removed on 1.18, it could explain why 1.18 succeeds and 1.14 fails.

Good shout @pchaigno :raised_hands:
It looks like iptables 1.6.1 shipped with the test VM (based on  ubuntu 18.04) does not support --random-fully:
vagrant@k8s1:~$ sudo iptables -t nat -A CILIUM_POST_nat -s <IP_ADDRESS>/24 ! -d <IP_ADDRESS>/8 ! -o cilium_+ -m comment --comment 'cilium masquerade non-cluster' -j MASQUERADE --random-fully
iptables v1.6.1: unknown option "--random-fully"
Try `iptables -h' or 'iptables --help' for more information.

There's even a bug tracked for that but it doesn't look like the fix landed in 18.04.
That said, I'm still unsure about why this test runs fine on some k8s version while not on others :/ are all CI images for 4.9 based on ubuntu 18.04?

Good shout @pchaigno :raised_hands:
It looks like iptables 1.6.1 shipped with the test VM (based on  ubuntu 18.04) does not support --random-fully:
vagrant@k8s1:~$ sudo iptables -t nat -A CILIUM_POST_nat -s <IP_ADDRESS>/24 ! -d <IP_ADDRESS>/8 ! -o cilium_+ -m comment --comment 'cilium masquerade non-cluster' -j MASQUERADE --random-fully
iptables v1.6.1: unknown option "--random-fully"
Try `iptables -h' or 'iptables --help' for more information.

There's even a bug tracked for that but it doesn't look like the fix landed in 18.04.
That said, I'm still unsure about why this test runs fine on some k8s version while not on others :/ are all CI images for 4.9 based on ubuntu 18.04?

@jibi In this case, aren't we using the iptables binary shipped in our cilium-agent Docker image?
$ iptables -V
iptables v1.6.1
vagrant@k8s1:~$ ks exec cilium-9czg5 -- iptables -V
iptables v1.8.4 (legacy)

@jibi In this case, aren't we using the iptables binary shipped in our cilium-agent Docker image?
$ iptables -V
iptables v1.6.1
vagrant@k8s1:~$ ks exec cilium-9czg5 -- iptables -V
iptables v1.8.4 (legacy)

Ah that's right, I was looking at the wrong iptables output. Running it again from inside the container shows that the rule is there:
vagrant@k8s1:~$ ks exec -it $(cilium_pod k8s1) -- iptables-save | grep random-fully
-A CILIUM_POST_nat -s <IP_ADDRESS>/24 ! -d <IP_ADDRESS>/8 ! -o cilium_+ -m comment --comment "cilium masquerade non-cluster" -j MASQUERADE --random-fully

Ah that's right, I was looking at the wrong iptables output. Running it again from inside the container shows that the rule is there:
vagrant@k8s1:~$ ks exec -it $(cilium_pod k8s1) -- iptables-save | grep random-fully
-A CILIUM_POST_nat -s <IP_ADDRESS>/24 ! -d <IP_ADDRESS>/8 ! -o cilium_+ -m comment --comment "cilium masquerade non-cluster" -j MASQUERADE --random-fully

Some updates here: I opened https://github.com/cilium/cilium/pull/14562 to try catch this test failing in the CI (as I am unable to do so on the local test environment) without success. I think next step would be to unquarantine the test so that maybe we can try catch it failing in the k8s-all pipeline?

Some updates here: I opened https://github.com/cilium/cilium/pull/14562 to try catch this test failing in the CI (as I am unable to do so on the local test environment) without success. I think next step would be to unquarantine the test so that maybe we can try catch it failing in the k8s-all pipeline?

It might make sense to wait for the split of k8s-all in multiple pipelines to unquarantine. That split might be enough to fix the flakes we have/had.

It might make sense to wait for the split of k8s-all in multiple pipelines to unquarantine. That split might be enough to fix the flakes we have/had.

Not sure whether this is exactly the same flake, but I've just seen K8sDatapathConfig Encapsulation Check iptables masquerading with random-fully and K8sDatapathConfig Encapsulation Check iptables masquerading without random-fully fail on #15241: https://jenkins.cilium.io/job/Cilium-PR-K8s-1.19-kernel-4.19/4894/

Looks similar, let's reopen. I might have a fix anyway :-)


Registering an EKS cluster defaults to manually entered name

What kind of request is this (question/bug/enhancement/feature request):
bug
Steps to reproduce (least amount of steps as possible):

Select to register an existing EKS cluster
Enter any name (like donnie-test)
Select an EKS cluster with a different name (like test)

Result:
The request that is made to the backend has no reference to the cluster that already exists in EKS. For example, the scenario above would have no reference to the cluster test, only to the name donnie-test.
Other details that may be helpful:
Request example: {"dockerRootDir":"/var/lib/docker","enableClusterAlerting":false,"enableClusterMonitoring":false,"enableNetworkPolicy":false,"windowsPreferedCluster":false,"type":"cluster","name":"donnie-test","eksConfig":{"imported":true,"displayName":"donnie-test","region":"us-east-2","type":"eksclusterconfigspec","amazonCredentialSecret":"cattle-global-data:cc-bf4ng"},"labels":{}}
Related Issue:
https://github.com/rancher/rancher/issues/29103
Specifically, this comment: https://github.com/rancher/rancher/issues/29103#issuecomment-733993630

The bug fix is verified with Rancher server rancher\rancher:master-head version 5ebc964 and rancher\rancher:v2.5-head version db350a6
Steps:
Import an EKS cluster.
Enter a cluster name.
Import an EKS cluster with a different name:

Result:
Display name is correct in request:
eksConfig: {imported: true, displayName: "aaron-eks", region: "us-east-2", type: "eksclusterconfigspec",…}
amazonCredentialSecret: "..."
displayName: "aaron-eks"
imported: true
region: "us-east-2"
type: "eksclusterconfigspec"

Cluster is registered with non-display name:


Please update vendored copy of k8s.io/client-go

Our current copy of k8s.io/client-go uses juju/ratelimit which is LGPL3. Upstream moved away from this in kubernetes/client-go@acc5249 - it'd be good if we followed this change as well.

@dholbach We will consider updating client-to newer version for next release.


Faster Expr::eval

Faster Expr::eval

Add recycling of intermediate result vectors.

Add EvaMode to indicate if lazies have been loaded and if we only have non-null flat vectors left.

Add a fast path for non-null flat vector Expr::eval.

Do not check for lazy vectors inside an eval that already checked the operands with ensureFieldLoaded.

Add fast exit from ensureFieldLoaded for flat vectors.

Make context.nullsPruned() circumvent nulls checks after it is set.

Make ensureWritable take an optional VectorPool for reuse.

make copying a constant scalar to a FlatVector use applyToSelected
to get a tight loop for contiguous places.

Thank you for the review. I’ll address this tonight. In the meantime, can you accept the piece with just the changes to encoding() in vector/? I sent this as PR 1590.
The problem is that this will not pass CI without a ton of changes of * to & and nullability declarations.
Reply to this email directly, view it on GitHub https://github.com/facebookincubator/velox/pull/1570#pullrequestreview-971558993 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AKPPPTZID4SFCA626UUSCDLVJWH4NANCNFSM5VQLQTMA .
You are receiving this because you were mentioned.Message ID: @.***>

Good point. All we can do here is to check. The meaning of flat non null mode is that on the descending edge there is no call to check for encoding or nullness but this can still happen on the returning edge.
You had a question about constness. Is the RowVector in EvalCtx const? It is declared as such and we can say it is RowVector* const. It is now declared const RowVector *. The latter is not quite true because a lazy can be replaced by a loaded  vector. This is children_[x] so the RowVector is still const but  children_ not.
The rule is that a lazy can be replaced by loaded whether at top level or inside wrappers. This is effected by ensureFieldLoaded. Does it need const_cast? We must adjust the constness in a couple of places and we’ll see what can be const.
I think the other comments are addressed.

@oerling This PR is very large and contains a long list of unrelated changes. Also CI is failing. Let's create separate PRs for each of the changes. It would be helpful to see how much improvement we get from each of these.

@oerling thanks for these improvements.
From reading the description it seems like many of them could be separated to different PRs.
This will give benefit of easier code review and improved "damage control" - when in cases of failures in replayer clusters we would have smaller changes to consider and not the whole set.

@oerling Orri, linux-build  CircleCI job is failing. Is this expected?


Run generate-index as gid 1000

Fixes #387
This should work across all known OpenShift architectures, storage plugins, and filesystems (without extended attributes).
Signed-off-by: Josh Manning<EMAIL_ADDRESS>

@mayurwaghmode Please test this on your environment.

@mayurwaghmode Please test this on your environment.

@jsm84 I have tested this on ppc64le's OCP 4.10 and 4.11, and it is working as expected. Thank you so much

Thanks @jsm84 . I was facing the permissions issue on OCP 4.12-nightly cluster and this fix resolved it.

@mporrato Can you please check if this change is compatible with the permission issues you fixed this week? If so we can merge it.

@mporrato Can you please check if this change is compatible with the permission issues you fixed this week? If so we can merge it.

Just ran an integration test with this patch applied on top of the current main branch and it seems to work just fine, but I can't test on CRC right now.


Madagascar Malaria Report

Please find attached the template for malaria report in Madagascar. Do let me know if any clarifications are needed.
Rapport de Surveillance Epidemiologique Hebdomadaire du Paludisme v1.docx

Can I get an English version of this as well please?

Sure - please find attached. Thanks Jonathan. Please note an additional column is included in Table 1 to reflect RDT positive or negative (the rapid test for malaria).
So to record RDT positive or negative for simple, severe and malaria deaths... (in table 1)
Just let me know if you need any clarifications.
Rapport de Surveillance Epidemiologique Hebdomadaire du Paludisme v1 EN.docx

Hi John, Are the surveillance./consultations and surveillance./fever columns in the mad case form?  Can they be equal to a number higher than 0 or 1? Can you confirm that the age for these cases is given in the child_age and pt./age columns?

Hi Jonathan - the consultations and fever columns are in the register form, and sorry there are listed as intro./consultation and intro/.fever in the register form. My mistake.
Yes than can be higher than 0 or 1.
Yes age is child_age or pt./age from the case report

Hi John, Little confused about this. I don't believe the top two rows of the table are possible then? It's surely not possible to break data from the daily register down by age taken from the case report form...

Er yes indeed! Again my oversight! In which case could I propose to include a Total columns for age-groups and to include the total consultations / fever cases here from the register because you are quite right we can't break this down right now.
I will speak with MOH as we may need to edit the register to include age break down in future

Not entirely clear on how you're envisaging this total column to work. I understand the concept of a total column across the age groups. Not sure about how the daily register consultations and fever count fits into this?

Something like the attached?
Rapport de Surveillance Epidemiologique Hebdomadaire du Paludisme v2 EN.docx

Ah great.  Though presumably there's the same problem with breaking down consultations and pregnant women?

er yes! so please blank out in the same way. i'm glad there is another pair of eyes on all this.

Almost finished this.  How are we counting "all" malaria cases? Do we count all occurrences of cd./malaria_rdt and cd./malaria_slide?

Great - thanks so much Jonathan.
Yes but all malaria cases means all cases that are either RDT or slide positive

There's presumably a reason why the malaria report is only interested in children over 2 months or older? It's just making the totals look a little odd, because the totals I think are including  some cases for younger than one month (though I've not confirmed this yet, it could be an error in my code).
This is almost there now. I just have to write a proper test for it, so that I can make sure numbers are being calculated properly, etc...

Hi Jonathan - wonderful thanks so much.
I didn't even see that and yes we need to correct. could you please include 0 - 2 months as a separate column? it is good to ensure all totals add up.

This is deployed. Let me know of anything that's urgently wrong.  I am aware of the following that still needs to be done:
-We will need to translate the new strings.
-The consultations figure for some spurious reason doesn't match that on the front page.  Not really clear on why at the moment, but will look into it.

Wonderful the Malaria Report is there! – thank you! Some comments if that is ok:

Translation doesn’t seem to be applied fully? Only in some places?
Please could we name the report:

Malaria Epidemiological Surveillance Report (for English)
Rapport de Surveillance Épidémiologique du Paludisme (for French)

Apologies for the change but Number of RDT tests performed is now being calculated from the Daily Register variable intro./rdt and from the Case Report. Could we please change *
Could we please use a lighter shade of grey for the boxes that are blanked out. Even just leaving the same row colour but with no content is ok.

@Gulfa regarding the intro./rdt variable. This was included later so some register will not have a value recorded. Could we please ensure that any register with no intro./rdt recorded be changed so that it equals the number recorded in intro./fever?

Thanks Jonathan:

No I don't mean to calculate from both. I mean to just calculate the number of RDT tests performed based on the daily register variable intro./rdt (as we do to calculate the number of fever cases).
Ok - no problem. I take your advice and we keep it as it is!

Thank you.

Thanks for the quick response.
As I understand it, the total number of RDT tests could therefore be different to the sum of the broken down data (by sex/age etc...) because they are coming from two different data sources. Does this mean you want me to remove these breakdown cells like we have done for the consultations row and the fever row?

Ah sorry. Yes please - as we cannot disaggregate this number either now.

With you.  Will do.

I am assuming that the intro./rdt data is just an integer number of RDT tests that need to be summed like the consultations and fever cases... let me know if this is wrong.

Yes that's right

I think I agree with @johnhaskew  - I prefer a lighter shade of grey for the empty cells.  I've change the shade to match the header and key columns. It should be included in the next deployment.  Other than that I believe this issue is now closed.


Socks proxy

Hi,
Can't connect via socks proxy, saw message Invalid protocol . How can i resolve it?
I'm try
browser.proxy = 'socks5://host:port'

Zombie doesn't support socks


RFC: Ideas for New Lean Attributes

Introduction
Hello. Here are some ideas for new Lean attributes. While Lean 4 supports user attributes, attributes like the ones indicated below, for the following use cases, might be best delivered as built-ins, provided in either core Lean or mathlib.
Use Cases
Search
Creating or using an existing ontology for mathematical metadata would enable enhancing Loogle search capabilities.
Topics for a mathematical metadata ontology include expressing original discovers, transcribers/formalizers, pertinent organizations, dates of discovery and transcription, objects' natural-language titles and descriptions, categories (MSC2020), keywords, and much more.
@[discoverer (value := "Gottfried Wilhelm Leibniz", date := "...")]
@[transcriber (value := "Alice Smith", date := "...")]
@[transcriber (value := "Robert Jones", date := "...")]
@[title (lang := "en", value: = "the natural language name of theorem")]
@[title (lang := "fr", value := "le nom en langage naturel du théorème")]
@[description (lang := "en", value := "...")]
@[description (lang := "fr", value := "...")]
theorem ...

Intellisense
With a mathematical metadata ontology, a special key, chord, or sequence could enable Intellisense-integrated natural-language search.
That is, users could type a key, chord, or sequence to commence a text-entry mode where they could type a natural-language title (e.g., @[title] attributes), possibly then making use of an on-screen menu (e.g., showing items' @[title] and @[description] attributes' values), and/or press the Tab key to select a recommendation, to retrieve a Lean object identifier which would be entered into the Lean content.
Tooltips
With a mathematical metadata ontology, a @[description] attribute and perhaps @[example] attributes could be used to provide that content to display when a user hovers over a thing in VS Code. There could also be multiple types of descriptions, one being intended for search, the other for tooltips.
Alternatively, special-purpose attributes, such as @[tooltip] or @[usage], could be provided.
In addition to using attributes' text values, attributes could refer to functions which return text strings. For the use case of tooltips, perhaps such functions could receive data about the hovered-over thing and the hover event context.
Illustrations and Animations
See also: Lean widgets
Illustrations can enhance the comprehension of proofs by both human mathematicians and multimodal AI systems.
@[illustration ...]
theorem ...

Approaches considered here include (1) referring to visual content by relative or absolute URLs via a href, (2) using encapsulated visual templates which could receive arguments with which to produce visual content, and (3) fully procedurally-generated visual content where Lean functions would be able to receive arguments with which to vary resultant visual content (drawing with Lean).
With respect to producing illustrations for LaTeX documents, software options include [1]: PGF/TikZ, PSTricks, and the default graphics packages. Other graphics packages included in LaTeX include: pgfplots, Xy-pic, ePiX, MetaPost, MetaFun, and Mfpic. Independent GUI wrappers and software tools which create images suitable for inclusion in LaTeX documents include: LaTeXPiX, TPX, Xfig, Asymptote, Inkscape, Ipe, Knitr/Sweave, KtikZ,QtikZ, and GeoCobra.
Document Processing
Software for processing Lean content into other formats (e.g., markdown, wikitext, LaTeX, HTML, PDF, or Jupyter notebooks) could use attributes to provide features specific to the resultant output formats. For instance, some @[illustration] attributes could be used to obtain visual content to add to resultant output content.
Conclusion
Thank you for any comments, questions, or feedback on these ideas.

Thanks for sharing these ideas! I agree that there are so many possibilities for extending code with auxillary information, visual representation etc.
What I'm missing from this RFC though is a very strong motivation to create these as built-in attributes. Lean is very extensible in particular to allow such features to be developed outside the core component. For something with a vast design space as these, I would feel more comfortable of such features are prototyped in their own library, maybe used to good effect within some larger development (maybe mathlib), and only when and if that proves to be useful we can consider making them official and out-of-the-box. Does that make sense?

Thank you. Yes, that makes sense.
With respect to the first subtopic of creating or selecting a mathematical metadata ontology to benefit search, Intellisense, and tooltips, in my opinion, a direct process towards including a resultant set of attributes in either core Lean or mathlib would be useful because, to showcase and deliver any benefits, any resultant set of attributes would need to be recognized by a number of other Lean projects: the Loogle search engine and the VS Code extension.
With respect to the second subtopic, illustration- and animation-related attributes, I included those ideas in this RFC while thinking about the automatic generation of educational multimedia documents from formal proofs. Yes, these ideas and uses of attributes could more readily be independently researched, developed, and prototyped with user libraries to showcase their uses and benefits before seeking to make any involved attributes official or out-of-the-box.
What do you think about that motivation for the first subtopic?

Good points. Remember that core lean is not math specific, and most math results are in mathlib only. A mathematical ontology would, I expect, achieve all it can even if it lives in mathlib only - so maybe bring it up there? (The two projects are maintained and governed rather differently, and an RFC here will likely not lead to action on the mathlib side.)
Once the ontology exists there and is used by mathlib specific tools, I expect more general tools (Loogle, documentation) may begin to support it, or provide extension hooks necessary for it.

Excellent. Ok, I will revise and expand on this RFC, being sure to include a section for motivation, into a new issue for the mathlib4 community repository upcoming.
Thank you for mentioning documentation. I will include that in that issue's list of use cases.

Dear @AdamSobieski, what is the mathematical metadata ontology in this context? Does it have anything to do with the semantic web ontologies (OWL, LISP) and logical reasoning on top of them?

@blokhin, hello. I've continued on these ideas in another issue: https://github.com/leanprover-community/mathlib4/issues/15509 .
The issue, there, lists the use cases of automatically generating educational resources and documentation, enhancing the Loogle search engine, and enhancing developer experiences (Intellisense, tooltips). It may be the case that even more metadata attributes would make sense to broach for consideration with respect to the Lean ecosystem – for inclusion in the mathlib library – for those or more use cases.
In addition to attributes' properties being capable of having numbers or text strings for their values, other Lean elements could be referenced. For instance, if example elements could be optionally labeled or identified, theorem elements could be annotated with @[usage] attributes referencing those example elements which illustrate their usage.
Yes, developers could use Semantic Web technologies to perform reasoning over and to query metadata on Lean elements.


PEP8 compliances

I created a branch called iss_15. Starting from this, each one of us will create a branch, and fix a file according to PEP8 rules.

@scalabrindario: file database.py --> Branch called PEP8_database
@andreaparisi96: file main.py --> Branch called PEP8_main
@LucaBallistri: file covid19.py and test_csv_maker.py  --> Branch called PEP8_covid19_test
@pietroquerci1999: file csv_maker.py  --> Branch called PEP8_csv_maker

Please when you finish comment below, next I will merge all

I fixed my files here: https://github.com/scalabrindario/Covid-19/commit/cbb6ebaf7411d11b4a6658e3fb4f6045ed3b4c25 and here: https://github.com/scalabrindario/Covid-19/commit/2907909a709c405d3dea08c9af881c337f72804f

I fixed my file here: https://github.com/scalabrindario/Covid-19/commit/64a3c48c14215db0e3ea8aea37a070ed17474e7b

I fixed my file here: https://github.com/scalabrindario/Covid-19/commit/fbe88850b5afa3e2d207e4b4b0aa62ead71d5382

I merged all the branches here https://github.com/scalabrindario/Covid-19/commit/dcd37060458eb0995b892dedda2d0b812f49be2a


JIT ideas

[x] removing needless PC increments from the JIT (PC gets restored to a constant on jump, on error, or on end of block/trace)
[ ] removing empty else clauses in JIT emitted code.
[ ] Detecting "simple" Java functions, that is, functions that don't have branches, don't throw exceptions,  don't call other functions, etc.

These simple functions can be JIT optimised immediately after first run.
Simple functions also don't need frame.locals. Their local array can be just symbols in emitted code.
Simple functions will also be ideal candidates for inlining.

[ ] The JIT emiters can use symbolic frame.locals just as they use a symbolic operand stack. This will be useful to optimise "simple" functions, and help in inlining functions.
[ ] Implement function inlining.
[ ] Peep hole optimisations. For example, javac has a tendency to emit code like this: istore_0; iload_0. This can be optimised to dup; istore_0;. This optimisation can be done at JIT time. Or perhaps as a separate pass, triggered before JIT threshold is reached. Alternatively, this can be done by a separate tool AOT.

Things which I have already experimented with, and got mixed results:

Convert to fast opcodes during JIT whenever possible.
Re-JIT after fast opcodes are written in interpreter mode.
Attaching values to emitted JIT function. For example, constant lookups need not be done when the emitted function is run. They can be pre-computed and attached to the emitted function. Gives good performance on every benchmark, except Scimark.
Various ways of optimising the interpreter loop.

using switch-case statement to lookup JIT functions
swapping in a different interpreter function when JIT threshold is reached

Some more ideas:

Shorten the names of some APIs used in emitted JIT functions. Eg: fieldOwnerConstructor
Add API for registering method overrides. Follow up from #435. This is not exactly related a JIT TODO. I was just waiting for JIT to land and mature, so that I can hand-tune methods selectively.
Support for wide instructions. Though I haven't encountered the WIDE opcode prefix in any of my benchmarks.

The JIT should eventually change to perform a pre-JIT pass to determine basic blocks and construct a control flow graph. As it currently stands, the JIT may inline a basic block into multiple blocks due to the way it handles branches. The CFG will let us figure out when a block is jumped to once, letting us inline branches (including if/else branches), among other improvements.

Detecting "simple" Java functions, that is, functions that don't have branches, don't throw exceptions, don't call other functions, etc.

Yes; we should have a mechanism to deposit JIT metadata on methods, such as whether or not a function can complete synchronously. We could probably support exceptions in there if we are sufficiently clever, e.g. lazily constructing stack frames when needed.
There are other tricks here we can use from other JVMs. For example, private methods cannot be overridden, so virtual calls to private methods are not actually virtual -- so we know the destination method statically.
Finally, we should probably augment the native method API at some point so the JIT can tell which functions are synchronous.

Shorten the names of some APIs used in emitted JIT functions. Eg: fieldOwnerConstructor

I don't view this as a useful optimization? Unless you mean to optimize for some of Chrome's inlining heuristics (e.g. source code size).

Shorten the names of some APIs used in emitted JIT functions. Eg: fieldOwnerConstructor

I don't view this as a useful optimization? Unless you mean to optimize for some of Chrome's inlining heuristics (e.g. source code size).

Reducing the source code size to reduce parsing time, and also to a certain extent -- memory consumption. But the latter is not specific to JIT; the parsing time is.

@hrj I experimented with changing the JIT over to emitting a single Function, with case statements for each basic block. I changed your opcode size functionality to cover 100% of the opcodes, so the JIT can compile an entire method at once. (And fixed some bugs -- for example, invokeinterface is actually 5 bytes long because it has an empty 5th byte.)
This JIT is currently slower than yours, likely because it does not unconditionally inline basic blocks when a branch is not taken. But I think it is a good basis from which we can build a control flow graph of basic blocks, which we can use to inline blocks into their dominators.
It's in a branch here. I restructured some of the code to make the JIT a little more self-encapsulated. I don't want to merge it in until it is roughly at parity with the speed of your JIT. Feel free to build on it.

@jvilk Interesting. I just had a glance and will look deeper into it later.
It will be good to merge the bug fix and JIT restructuring into master, so that even if we are unable to optimise or enhance that branch, development on master branch can continue without merge conflicts or regressions.


Define parent_job_for_tape_type

As noted in https://github.com/JuliaGPU/CUDA.jl/pull/2260#discussion_r1508550355
it is a bit akward to add a specific interface to KernelAbstraction
so instead we add it to EnzymeCore.

But what should the argument type be here? That’s similarly weird to have a
function that takes a KA type in EnzymeCore
On Tue, Mar 5, 2024 at 12:38 PM Valentin Churavy @.***>
wrote:

@.**** commented on this pull request.
In lib/EnzymeCore/src/EnzymeCore.jl
https://github.com/EnzymeAD/Enzyme.jl/pull/1328#discussion_r1513324869:

@@ -239,6 +239,8 @@ end

function tape_type end
+function parent_job_for_tape_type end
Its pretty much
https://github.com/JuliaGPU/CUDA.jl/blob/8e25fc1ada7f63e2e9b93785b451a751e58a20e1/ext/EnzymeCoreExt.jl#L9
for the extended version of tape_type introduced in #1104
https://github.com/EnzymeAD/Enzyme.jl/pull/1104 we need to be able to
construct a parent_job explicitly. There is a question who should own that
API. Originally I had it in KA, but it makes more sense in EnzymeCore,
since otherwise we can never call the new tape_type function.
—
Reply to this email directly, view it on GitHub
https://github.com/EnzymeAD/Enzyme.jl/pull/1328#discussion_r1513324869,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJTUXEZ7Z4MUZEICG6TH5TYWYGJTAVCNFSM6AAAAABEHULMSSVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTSMJXHA2DKOJRGM
.
You are receiving this because you commented.Message ID: <EnzymeAD/Enzyme.
@.***>

It doesn't need to be a KA type, we could imagine a backend (IPU?) that doesn't use KA.
We are simply declaring a name for this function here. For packages that use KA and want to use the generic rule in KA they can use the KA backend types, for others it is just a name and they could use their own type to dispatch on.

Copying here for persistence:
I guess my issue is that I don't understand what this function is supposed to do.
Eg a kernel or function could have a type tape of float64 (eg squared something), but it's ambiguous what parent job that corresponds to.
Also the KA backend arg that you pass in isn't a tape type that enzyme would generate so thst confuses me too.

I guess my issue is that I don't understand what this function is supposed to do.

It returns the parent_job to pass to tape_type. tape_type(parent_jov_for_tape_type(...), ...)

Ah so this is really parent job for use in tape type, not generate a parent job from a tape type.
The name feels too specific, maybe parent_job_for_context ?  But similarly then I'd want to undertand what args are legal for the context and what they mean

Apologies: realized this is a somewhat rambly chain of thought as I think this through:
I guess a clarifying question that may help answer this, in what context would we need to call to get this information?
E.g. inside of CUDA.jl, for making the tape, we would presumably know that we need a CUDA parent job so hypothetically it could side-step this (or call it with any constant input, like :CUDA).
For KA, writing the generic form of the rule requires converting whatever KA context there is into a context here.
Are there other contexts we would want or need this?
At the moment the only conditional dispatch I can foresee is the KA one, which is great since then we could use the KA type. But in that case, why have this here and not KA.
So I wonder if there's another type we would want (and could apply conversions to). Since we'd only want this for GPUCompiler jobs I suppose that's relatively small (and perhaps we could consider some enum type there? but also that then begs the question of why not have that in GPUCompiler then).

But in that case, why have this here and not KA.

The question is indeed who owns the extension. For me the extension is owned by Enzyme since AD
is not part of the core functionality of KA. We host the extension in KA since it needs to be kept more in sync with the internals of KA, but Enzyme should provide all
the necessary interfaces to make it feasible to write a rule. Right now using the new form of tape_type that requires a CompilerJob is only use-able directly by GPUCompiler users like CUDA.jl or AMDGPU.jl. KA doesn't need to know what a CompilerJob is.
So the question is if we want KA to have a generic rule it needs some way to query the correct tape type. From the extension perspective the natural object to query with is the backend, which is owned by CUDA.jl or AMDGPU.jl, we could of course add KA as a dependency to EnzymeCore, so that we can access the abstract backend type, but we can use monkey patching to avoid the load time impact.

but also that then begs the question of why not have that in GPUCompiler then

GPUCompiler does intentionally not specify what the possible set of users is, there is a limited set of targets, but these are not quite meant as interface types.

What about making a subpackage in KA like KernelGradiwnts in the past.
I’m somewhat skeptical of having an interface function whose arguments
aren’t owned by the package or depended on (KA shouldn’t be a dependency of
EnzymeCore since we already got complaints about and since removed the
Adapt dependency).
It’s also a bit weird since while now needed for tape type it’s not really
related to AD, but the compiler job. Eg I see this more like a similar
GPUCompiler job for this package function.
Maybe we make a new compilerjobs package?
On Tue, Mar 5, 2024 at 3:47 PM Valentin Churavy @.***>
wrote:

But in that case, why have this here and not KA.
The question is indeed who owns the extension. For me the extension is
owned by Enzyme since AD
is not part of the core functionality of KA. We host the extension in KA
since it needs to be kept more in sync with the internals of KA, but Enzyme
should provide all
the necessary interfaces to make it feasible to write a rule. Right now
using the new form of tape_type that requires a CompilerJob is only
use-able directly by GPUCompiler users like CUDA.jl or AMDGPU.jl. KA
doesn't need to know what a CompilerJob is.
So the question is if we want KA to have a generic rule it needs some way
to query the correct tape type. From the extension perspective the natural
object to query with is the backend, which is owned by CUDA.jl or
AMDGPU.jl, we could of course add KA as a dependency to EnzymeCore, so that
we can access the abstract backend type, but we can use monkey patching to
avoid the load time impact.
but also that then begs the question of why not have that in GPUCompiler
then
GPUCompiler does intentionally not specify what the possible set of users
is, there is a limited set of targets, but these are not quite meant as
interface types.
—
Reply to this email directly, view it on GitHub
https://github.com/EnzymeAD/Enzyme.jl/pull/1328#issuecomment-1979691839,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJTUXDUED5FYLDIGTFRQ7TYWY4PTAVCNFSM6AAAAABEHULMSSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZZGY4TCOBTHE
.
You are receiving this because you commented.Message ID: <EnzymeAD/Enzyme.
@.***>

I agree with you that this name does belong into KernelAbstractionsEnzymeExt and there is some weirdness putting it into either.
The benefit of extensions is that they are automatically loaded, creating a third package like KernelGradients would require the user to load it manually. Extensions in Julia currently can't have their own dependencies.

Ready from my side. The EnzymeCore extension in KernelAbstractions doesn't have access to GPUCompiler. So I kept the API of returning the job object.


portfolio done

The portfolio page layout is done. The Index page is done and ready for the mail chimp banner to be placed at the bottom. The shop page still needs to get added before tomorrow night.

Nice work! 👍 :shipit:


Module not found: Error: Can't resolve 'transit-js' in 'transit-immutable-js'

Installing transit-immutable-js not installing transit-js
ERROR in ./~/transit-immutable-js/index.js
Module not found: Error: Can't resolve 'transit-js' in '[project-root]\node_modules\transit-immutable-js'
 @ ./~/transit-immutable-js/index.js 1:14-35
 @ ./app/store/localStorage.js
 @ ./app/app.js

https://github.com/glenjamin/transit-immutable-js/blob/master/package.json#L21-L24
I imagine there's a peerDependency warning from npm you're ignoring somewhere?

Yes:
warning<EMAIL_ADDRESS>has unmet peer dependency "transit-js@>= 0.8".
warning<EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>
Do I need install them manually?

Yep, since npm 3 peer dependencies have to be manually selected and installed.

I think we should change npm install transit-immutable-js to npm install transit-js transit-immutable-js to readme.


For work edit page tooltips, add missing line to keywords tooltip

First, the tooltip for the keywords should read:
Tooltip text: Keywords should reflect significant concepts related to the deposit. At least one entry is required. If you would like to enter your department affiliation, please do so under the Contributors section and choose "Department" for the role term.
The first line of the above is missing.
Secondly, the Tooltip for the License information -- the last one in the document -- is missing entirely.
See Tooltips doc for text: https://docs.google.com/document/d/1gjvqYXmwMpMGWTdZynoHtxDgQVTt9fGn7QGVE4uhXXQ/edit#heading=h.v2a0c7kuvnie
See wireframes for locations: https://projects.invisionapp.com/share/EQXC9CLKCR2#/screens/431445056

Hi @amyehodge, could you point to the work you're not seeing the license tooltip? I just captured the following screen-shot on H2 stage and the license tooltip is present (https://sul-h2-stage.stanford.edu/works/3/edit) :

Thanks!

@jermnelson I'm at a loss. I'm seeing it now. So, there's just the one missing bit for the keywords. I'll update the ticket title.

@jermnelson I'm at a loss. I'm seeing it now. So, there's just the one missing bit for the keywords. I'll update the ticket title.

@amyehodge no worries; maybe a browser cache issue? PR #1116 was just merged so closing this issue.


Update Sciml [and Pyciemss?] to use per-user message queues

Description of issue
Operations on the Sciml (and pyciemms) services need to be modified to use a per-user-queue instead of a single queue named in the environment variables. At the moment Sciml is the more pressing issue as its the one we're wanting to have give updates now. If its outside the scope of this issue to modify pyciemms then please duplicate this issue for pyciemms to be done at a future time.

[ ] Modify the endpoints on the services to accept a String parameter queue-name for the queue name to publish messages to (for example .../calibrate?queue-name=FOOBAR). If endpoints other than calibrate need queue names for the future consider doing that now.
[ ] Remove references to environment variable queues to avoid confusion in the future.
[ ] Have intermediate results published to the queue given at the operation kickoff.

Note that this issue will need to be done in sync with #2237


Fixes Bug 1191415 - Refactor editor.js to use 4 spaces for indentation

@Nolski looks good?

Yeah, I was working with another on a similar PR but this one seems to do the job just fine. :shipit:


WFS docs initial (WFS 1.1 and WFS 2.0)

Including a variety of examples.

GetFeature using a BoundingBox
GetFeature using a Filter
GetFeature using StoredQueries

@JuergenWeichand thanks very much for the docs/contributions!!!


have custom file types treated as markdown notes

🚀 The feature, motivation and pitch
I like to keep my leet code exercises as obsidian notes. We can markdown style comment blocks in a cpp file, the only issue is that Obsidian does not recognize a cpp extension as a note file, can we have the option to enable some custom file extensions (or patterns that match the file name) to be treated as a plain markdown note?
Alternatives
No response
Additional context
No response

I would also be really interested in this. It would be amazing to be able to have an obsidian link in comments so i can directly link back to my vault. I could basically have documentation links where needed.

I found this in the source code, but don't really know the architecure
https://github.com/epwalsh/obsidian.nvim/blob/ee298fd2136612a4ca6a745a4aec3f49ce6f94b0/lua/obsidian/client.lua#L580
Client.find_files_async = function(self, term, callback, opts)
  opts = opts or {}

  local matches = {}
  local tx, rx = channel.oneshot()
  local on_find_match = function(path_match)
    matches[#matches + 1] = Path.new(path_match)
  end

  local on_exit = function(_)
    tx()
  end

  local find_opts = self:_prepare_search_opts(opts.search)
  find_opts:add_exclude "*.md"
  find_opts.include_non_markdown = true

  search.find_async(self.dir, term, find_opts, on_find_match, on_exit)

  async.run(function()
    rx()
    return matches
  end, callback)
end

@sadtab
i think this is only realated to the ObsidianSearch feature.


soc: arm: stm32: DTSI update for eeprom size stm32l151Xc

Add EEPROM size to STM32L151xC.dtsi.
Signed-off-by: Noelle Clement<EMAIL_ADDRESS>

If requested, I can see if I can implement the changes suggested by @pabigot above, but I'd first like a confirmation whether this is indeed desired or not (@erwango ?)

If requested, I can see if I can implement the changes suggested by @pabigot above, but I'd first like a confirmation whether this is indeed desired or not (@erwango ?)

If requested, I can see if I can implement the changes suggested by @pabigot above, but I'd first like a confirmation whether this is indeed desired or not (@erwango ?)

I'm fine with this proposal. Go ahead (in a dedicated commit).

If requested, I can see if I can implement the changes suggested by @pabigot above, but I'd first like a confirmation whether this is indeed desired or not (@erwango ?)

I'm fine with this proposal. Go ahead (in a dedicated commit).


In 0.5.3, only displays first 11 lines in code cell until clicked

The rest of the cell is blank, until I click in the cell, whereupon it displays.
This is under MacOS 12.12.6 in Safari 12.0.1 and Chrome 70.0.3538.110. Persists after system restart.

I can't reproduce this anymore, so I'm going to assume 0.6.0 or the changes I'm working on now fixed this!


Should the manip. list be cut off if new manip. is pushed?

likely to fix the unexpected result of undo/redo delete

24d61d7eb2db6104185343df6b87a7e6e91a0877


Can't run unit and iteg tests separately

🐛 Bug description

It's common to want to run unit and integ tests separately because integ tests are slower and can be prone to failure
cargo test currently supports this as documented here: https://github.com/rust-lang/cargo/issues/10491#issuecomment-1074078912

unit: cargo test --lib --bins
integ: cargo test --test "*"

When i pass these flags to wasm-pack test I get a panic in wasm-bidgen-test

unit: wasm-pack test -- --lib --bins throws panicked at 'flag --lib not supported'
integ:  wasm-pack test -- --test * throws panicked at 'flag --test not supported'

I thought this was in issue in wasm-bindgen but they sent me over here: https://github.com/rustwasm/wasm-bindgen/issues/3432
Specifically they pointed out this code: https://github.com/rustwasm/wasm-pack/blob/081861b10e2e81a230701510172f80aaa4f92e3d/src/test/mod.rs
🤔 Expected Behavior
wasm-pack test -- --lib --bins does not panic
👟 Steps to reproduce

Create a new project and install wasm-pack
run wasm-pack test -- --lib --bins

🌍 Your environment
Include the relevant details of your environment.
wasm-pack version: 0.10.3
rustc version: 1.69.0

I'm not observing a panic in 0.11.1, is this fixed?

yeah youre right! thanks :)


[New Feature]: Use GraalVM native-image to generate native executables for the jballerina compiler

Description
As of now the jballerina compiler is executed using the JVM. It is possible to generate platform specific native-images of the jballerina compiler using GraalVM native image for better performance.
Describe your problem(s)
Compared to other compilers, jballerina compiler takes more time to compile the source code.
Describe your solution(s)
It is possible to speed up this process by generating a native executable for the jballerina compiler and using the native executable for compiling ballerina code.
This will not change the existing compilation process. The native executable will also compile a given ballerina source to JVM bytecode. But we will have to provide platform specific executables for each ballerina distribution.

Related area
-> Compilation
Related issue(s) (optional)
No response
Suggested label(s) (optional)
No response
Suggested assignee(s) (optional)
No response

Adding @hasithaa and @MaryamZi


[Suggestion (Plugin)]: Set fish/rarity chances per bait or bait's fish/rarities

Suggestion
Currently (2.0.0 #166), the probability of a specific fish/rarity in a bait is defined through the boost value in general in baits.yml. If possible, I would like this feature to be set for each bait in the plugin, or, in more detail, for each fish/rare set in the bait.
For example, "Stringy Worms" in the default baits.yml increases the chance of catching fish of "Common" and "Legendary" rarities. I wish there was a function to ignore the boost setting, add a weight of 2000 to the “Common” rarity (summation), and add a weight of 30 to the “Legendary” rarity.
(I'm not good at English, so I used Google Translator. I'm truly sorry if my writing style was unnatural or offensive.)

Hi, this is already possible.
Set the weight: 100 on a rarity to adjust the probability.
I assume you actually mean for the bait to have various effects though?
i.e. the bait adjusts multiple rarities with varying weights?
Stringy Worms -> Common: 2000, Legendary: 30 ?

I wish it were possible to adjust the probability of catching a fish with one bait for each grade. Yes, like the Stringy Worms example you sent.


Creating data tags doesn't refresh current view

Version and Platform (required):

Binary Ninja Version: 3.1.3478-dev, 3.0 (not a new issue)
OS: Windows
OS Version: 11
CPU Architecture: x64

Bug Description:
I'm adding tags at addresses with bv.create_auto_data_tag, and if a tag is added to the function currently displayed in the UI it does not redraw to show the tags until the user clicks away and comes back to the function.
Steps To Reproduce:
Please provide all steps required to reproduce the behavior:

Execute python bv.create_auto_data_tag(0x1234, bv.tag_types['Bugs'], "foo"), using an address within the current function UI view. (I had a MLIL view open.)
Observe the view didn't change to show the bug icon.
Switch the view to a different function, then switch back.
Observe the bug icon present on the address now.

Expected Behavior:
Behavior should go directly from step 1 to 4 in the above sequence, or there should be an API to force a redraw.
Additional Information:
Affects user_data_tags as well.

Tested in 4.2 and it seems to work fine now


Missing packages?

Lines 81 and 84 in the Step3 script don't work for me. Do these functions (draw and auc) come from packages that aren't loaded? Or maybe from the ggsn package which I couldn't install?

The code has been updated to include the installation and loading of the package


cannot add CA to request

looking at:
https://github.com/visionmedia/superagent/blob/master/test/node/https.js
is see that superagent supports providing the CA during the request
  request
      .get('https://localhost:8443/')
      .ca(cert)

but this is not possible in supertest
var requestHttps = require('supertest')('https://localhost:8002');
  requestHttps
                .get('/')
                .ca(fs.readFileSync('test/data/SSL/dev-client.crt'))

returns
TypeError: Object # has no method 'ca'
Maybe i'm missing something, but to me this could be bug.

Is there a way to pass in an HTTP server and the CA cert?
  var agent = request.agent(server);
  agent.get('/').ca(caRootCertificate);

gets me a TypeError: Object #<Test> has no method 'ca'

I am getting below error
"fs.readFileSync is not a function error"
what could be an issue?


web issue reporter create issue not working when logged in

Testing #213597
while logged in, cannot create issue, but can only preview issue.

fixed in edge:

try using github.dev or codespaces
help -> report issue


Merging Back to Main Branch with new CasualStickFigure and FancyStickFigure classes

CasualStickFigure and FancyStickFigure classes have been added and the myPictureViewer class is modified to test the drawings of these classes.

Looks good!


Change iOS Audio Provider to StreamingKit

In my opinion the library is more complete, lightweight, performant. Documentation for the library is also very nicely done and the code is easy to follow.
The library is StreamingKit

Thanks for creating the the PR. We are using DOUAudioStreamer so that we would be able to do local media caching in the future (It got a cachedPath property and we could make use of it). Are StreamingKit capable to do media caching?


Add a check to the settings validator for nCycles and startCycle

It can be confusing to the user to know how to properly set nCycles in restart runs.

Is it the number of cycles you want to run after the restart?
Or is it the number of total cycles you want the completed *.h5 file to have (i.e. old cycles plus new cycles after the restart)?

Turns out it is option (2), but I wouldn't say this is clear right now.
It would be good to add a check in the settings validator to make sure that the user has set this correctly, otherwise the resulting error when nCycles < startCycle can be confusing.
I can do this eventually, just wanted to put it here to remind myself.

Well, I would have guessed it was option (1), so you're probably right on the need for clarification.
Thanks!


[ownership] Add verification that parent borrow scopes completely enc…

…lose implicit child borrow scopes introduced via BorrowScopeOperand.
As an example consider a begin_borrow/end_borrow scope and a coroutine:
  %0 = begin_borrow %...
  ...
  %token = apply %coroutine(%0)
  ...
  end_apply %token
  ...
  end_borrow %0

With this change, we will validate that the end_borrow never enters the region
of code until the coroutine is actually finished executing (as shown by the
end_apply).

@swift-ci test

@swift-ci test source compatibility

Once this is in, I am going to introduce mark_dependence as an instruction like this.

Build failed
Swift Test OS X Platform
Git Sha - c195f73d59046deeb2c3024a0bc9db169c84ab50

Nice! The OS X check caught something

Build failed
Swift Test Linux Platform
Git Sha - c195f73d59046deeb2c3024a0bc9db169c84ab50

@atrick Found the problem. Mandatory inlining was not handling coroutines correctly. It was inserting the end_borrows/destroys for certain values after the apply site of the coroutine, not after the end_apply, abort_apply.
Interestingly, I was just improving this code here in #27405 where I refactored out this apply site functionality (since I needed it somewhere else where begin_apply was actually not supported). I am going to add in a commit based upon that one for FullApplySites only that acts like insertAfter [see #27405] for apply and try_apply and that returns the token users of the begin_apply as insertion points for begin_apply instead.
The nice thing about this is when we add a coroutine apply function that is a terminator (which I imagine we will), all this code will be correct automagically. The beauty of having abstractions! = ).

I landed the coroutine fix. I am curious if this passes now.

@swift-ci test

@swift-ci test source compatibility

Debug source compat suite failure was a jenkins error.

@swift-ci Please Test Source Compatibility Debug

Release Source Compat only failure is a known failure:
17:35:51   FAIL: Sourcery, 5.1, 20bdf6, Swift Package
I expected Debug to fail in a similar way.

Debug did fail the same way. Merging!


[docs] Add contribution guidance section in document

fix #345

@GOODBOY008 @ruanhang1993 PTAL

@ruanhang1993 Thank you for the very detailed review. I have revised it according to the review comments.

Hi, looks like check_branch has some mistake.

Hi, looks like check_branch has some mistakes. https://ververica.github.io/flink-cdc-connectors/master/content/about.html#building-from-source

I will fix it.


Include guard is dysfunctional.

DEBUG_BREAK_H macro is used as an include guard but it is not defined anywhere in the header causing multiple inclusions of debugbreak.h into a single translation unit to produce redefinition errors.

Thanks for noticing and fixing this.


rhdf5 broken on 21.11-pre

Describe the bug
The rhdf5 library does not work on latest release.
To Reproduce
nix-shell -I 'nixpkgs=https://github.com/NixOS/nixpkgs/archive/refs/tags/21.11-pre.tar.gz' -p 'rWrapper.override { packages = [ rPackages.rhdf5 ]; }'

Expected behavior
A shell with R and rhdf5.
Additional context
Instead I get:
these derivations will be built:
  /nix/store/62rbp1iwk3qyzrwa7xffc0hhvlf0xry2-rhdf5_2.32.4.tar.gz.drv
  /nix/store/vsagg33zz18jmhsshqqrl5k499g2iqph-r-Rhdf5lib-1.10.1.drv
  /nix/store/1r21pqhdrnnxm7iic43hnn5lmaqjsi7w-r-rhdf5-2.32.4.drv
  /nix/store/nnh13xysfxpll6cd9c21d2drahways9x-R-4.0.4-wrapper.drv
these paths will be fetched (1.46 MiB download, 5.87 MiB unpacked):
  /nix/store/3xyij4rjz3z4yzj4incazjwiirkaz4f4-nghttp2-1.43.0-bin
  /nix/store/4x861aprr5ljaa2prcvhyxcrara8rmyb-openssl-1.1.1k-dev
  /nix/store/cdib8alblidlnj6vh27l1mi9slksm7vr-openssl-1.1.1k-bin
  /nix/store/fg560vvb30i52v4gm93ah513c6swqna7-curl-7.76.1-bin
  /nix/store/gvb3z5nqzw8m9s4kmifxq8jh5dqnnxjw-nghttp2-1.43.0-dev
  /nix/store/jm6zis2b51h8immqv7s32xwzln8xx2iv-curl-7.76.1-dev
  /nix/store/k09ayvnk26x86v3m1q4spi458sbsvyzz-libssh2-1.9.0
  /nix/store/szawrh0qpa2mg1w9krlrh2mkzw271ncx-curl-7.76.1
  /nix/store/w140ykfr9imm7nflzqwz4by7yr1dh3mw-libssh2-1.9.0-dev
building '/nix/store/vsagg33zz18jmhsshqqrl5k499g2iqph-r-Rhdf5lib-1.10.1.drv'...
unpacking sources
unpacking source archive /nix/store/4jvc6sjfg9fv5xmxmnp6fh830lgalhyi-Rhdf5lib_1.10.1.tar.gz
source root is Rhdf5lib
setting SOURCE_DATE_EPOCH to timestamp<PHONE_NUMBER> of file Rhdf5lib/configure
patching sources
applying patch /nix/store/fqsil1vhdy3m7w983pfcb54sd4cs5kb0-Rhdf5lib.patch
patching file configure
Hunk #1 FAILED at 2880.
1 out of 1 hunk FAILED -- saving rejects to file configure.rej
builder for '/nix/store/vsagg33zz18jmhsshqqrl5k499g2iqph-r-Rhdf5lib-1.10.1.drv' failed with exit code 1
cannot build derivation '/nix/store/1r21pqhdrnnxm7iic43hnn5lmaqjsi7w-r-rhdf5-2.32.4.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/nnh13xysfxpll6cd9c21d2drahways9x-R-4.0.4-wrapper.drv': 1 dependencies couldn't be built
error: build of '/nix/store/nnh13xysfxpll6cd9c21d2drahways9x-R-4.0.4-wrapper.drv' failed

Notify maintainers
@iimog
Metadata
 - system: `"x86_64-linux"`
 - host os: `Linux 4.15.0-135-generic, Ubuntu, 18.04.3 LTS (Bionic Beaver)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.3.7`
 - channels(ivan): `""`
 - channels(root): `"nixpkgs-21.03pre245659.30e98a4fd67"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixpkgs`

Maintainer information:
# a list of nixpkgs attributes affected by the problem
attribute:
# a list of nixos modules affected by the problem
module:

"6.topic: rust" should be removed, this is an R package, not Rust.

This was fixed in #125556


Rename ImportClusterResourceService to OneshotClusterResourceImporter

What type of PR is this?
/area simulator
/kind cleanup

What this PR does / why we need it:
If we add the syncing service (#327), it has two features to import resources of a real cluster, one-shot importing and continuous syncing.
So the current naming of ImportClusterResouceService would be confusing.
This PR renames ImportClusterResourceService to OneshotClusterResourceImporter. This will avoid the confusion.
Which issue(s) this PR fixes:

Part of #327
Special notes for your reviewer:
We should also rename mock_clusterresourceimporter, but this is generated by gomock so we need to replace golang/mock with uber-go/mock (#363). This PR once leaves it.
/label tide/merge-method-squash

/ok-to-test


Update broken link.

Update link from https://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml to https://google.github.io/styleguide/javascriptguide.xml

I signed it!

I do apologize for the delay in getting to this; previously, no one was currently watching this repository. However, I just merged an equivalent patch. Thank you.


Create house_robber.cpp

Added House Robber problem, solved using dynamic programming
Checklist

[x] Added description of change
[x] Added file name matches File name guidelines
[x] Added tests and example, test must pass
[x] Added documentation so that the program is self-explanatory and educational - Doxygen guidelines
[x] Relevant documentation/comments is changed or added
[x] PR title follows semantic commit guidelines
[x] Search previous suggestions before making a new one, as yours may be a duplicate.
[x] I acknowledge that all my contributions will be made under the project's license.

Notes:

Does your code conform to the standards and the checklist?

Does your code conform to the standards and the checklist?

Yes I have added enough comments and also take care of naming conventions.

It does not follow the repo standards. All the details are provided in the links in the checklist. Please review and update the code accordingly. No reviews will be provided until the code is updated to the repo standards.
Thank you for your contribution.

It does not follow the repo standards. All the details are provided in the links in the checklist. Please review and update the code accordingly. No reviews will be provided until the code is updated to the repo standards.
Thank you for your contribution.

Please review now, i have added test cases and solution as well.

@kvedala  please review it now. I have done all the required changes.

@SumukhBhardwaj hey! where did you find the problem statement?
Can you please tell me how can I share my solution?
(P.S. I am new to open source and need some initial help.)


Add role binding example

Add role binding example for service account spark-operator-api-user

nice catch and addition! thanks Bo!


Added LayoutContainer in FastAdapter.ViewHolder

Added LayoutContainer in order to utilise Android Extensions to access and cache views.
Ref: https://proandroiddev.com/kotlin-android-extensions-using-view-binding-the-right-way-707cd0c9e648

I don't think this should be added. Not everyone wants to use kotlin android extensions, and plus it isn't recommended. It is very easy to add it per project, as shown in your PR

I understand now, you're right. I wasn't aware of the synthetics debate. At first the reason I wanted to include this was because there are many developers that do.
itemView.textView.text = "String Here"
Which has performance issues.
Compared to adding LayoutContainer which turns above code into
textView.text = ""
Since Kotlin Android Extensions showed up there are many developers that have joined the band wagon myself included and are unaware of such details.
@AllanWang If this was created as an another module that adds support for Android Extensions that contains another ViewHolder that inherits FastAdapter.ViewHolder and LayoutContainer, would this be more acceptable? That way it is not directly included in the FastAdapter.ViewHolder but is optional for the user to include it?

As AllanWang correctly already said kotlin extensions aren't recommended by Google and I also don't think they should be added to the core.

You certainly could, but at that point it may be worth considering whether a new submodule is worth it for the 3 line change. It may also be interesting to see why ViewHolders aren't yet supported out of experimental yet, or whether there are any plans to update the extension at all. Speaking of helpers, I do have my own ViewHolder that is based on LayoutBinding that I plan on sharing eventually, but that's for another PR. While I use it mainly to get ids, I find it a lot nicer to use, and it comes with some benefits beyond a few lines

I also doubt that
itemView.textView.text = "String Here"

has performance issues if it is bound once at the beginning. If anything it's faster if you know you'll use the ID. In the end, everything uses findViewById

Understood then I'll just close this and wait for your future PR. Thank you for the feedback :)


Add comparison table for (cupyx.)scipy.sparse.*_matrix classes class methods

Generate a comparison table that lists all APIs in (cupyx.)scipy.sparse.*_matrix classes as in #7762.
Please check whether the naming for the comparison table is appropriate. Thank you.

LGTM!
/test skip


Added option for redirecting.

We have a case where we want to redirect our user to our login page. We can't do the redirect on the client since we check the token before even returning any client side code (server side rendered index).
I simply added a wrapper to the reply to check if a redirectUrl is set. If the Url is set reply.redirect to that instead of returning a 400, 401. Additionally if the validate is rejects the token it will follow same logic of redirecting if a url is available.
Updated the pull request to include the hapi 8 upgrade.  My previous pull request can be removed.

I was able to use
server.ext('onPreResponse', function(res){
})

to get the status code to do the redirect.  This pull request is no longer needed.
Thanks


Add ucx-proc=*=cpu to CI environments to block cudatoolkit install

Looks like newer versions of pyarrow pull in ucx and subsequently cudatoolkit unless we specify the CPU version of ucx-proc; given that the cudatoolkit package is quite large (~667MB), I'm interested in if we can get away with adding this constraint to prevent installing it in CPU testing.

[ ] Closes #xxxx
[ ] Tests added / passed
[ ] Passes pre-commit run --all-files

Looks like tests are passing on Ubuntu, but failing early on for Windows/macOS because ucx-proc is only available for Linux platforms; how do we feel about conditionally patching in ucx-proc for the Ubuntu jobs?

Yeah that makes sense, I had assumed that improvements to environment initialization would be larger and that this would be as simple as just adding the pinning to the environment files; given that isn't the case, okay with closing this out


Blog Pages Generated By Content Path Have Flicker

Please provide the environment you discovered this bug in.

Clone the Analog Project
Run pnpm i
Run nx serve blog-app

Navigate here: http://localhost:3000/archived/post1-2024
Here is the official hosted version:
https://deploy-preview-1042--analog-blog.netlify.app/archived/post1-2024
You will see the page load empty first, and then it loads.
First Flicker Problem
There are actually 2 different flicker problems.
The first flicker is due to the Observable Not Resolving in time for the server to load the data. It does not await the markdown comopnent to render. At first I thought this was a problem with the of('') on this line, but even when I set the variable directly to equal the router observable, it does not complete before the server page is generated.
Generally, I would use the waitFor function to force the component to resolve the observable (as a promise) on the server in a different zone before rendering, but that does not work either.  This is a dire problem as it could effect loading meta tags or schema for SEO purposes. We need to generate on the server.
We need a Zone.js expert for this.
Second Flicker Problem
If you set the content$ directly and comment out the markdown rendering on this line, you will see it loads (without markdown parsing) on the server in time. However, there is a second flicker.
This problem is not as serious, but I believe the second flicker is from the observable running 2x. Generally speaking the server should fetch the data and hydrate the data to the browser so it doesn't have to reparse the markdown component. It should not re-run the observable on the client unless there is a route change.
Should we just remove the observables all together here? I think signals could help simplify some of this code.
Which area/package is the issue in?
content
Description
Here is a direct blog example you can see the problem:

https://www.prestonlamb.com/blog/strongly-typed-reactive-forms-in-angular
https://perko.dev/blog/post/2023-08-31-quickly-setup-drupal-on-windows-with-laragon

I can't tell if this is a second flicker problem or transition, so may be unrelated:

https://mrrobot.dev/blog/the-importance-of-softskills

I just looked a few blogs from Brandon's post:

https://dev.to/analogjs/how-to-build-a-blog-with-analog-and-angular-4pk2

Please provide the exception or error you saw
One way to fix the problem completely would be to remove the ability to pass the markdown code directly to the markdown component and handle it server side only then load it in a resolver. This would keep the client code bundle smaller. It adds a better UX but worse DX (arguably).
We may not need to worry about the ZoneJS issue as @atscott points out Pending Tasks will take over ZoneJS's ability to run async tasks outside a component.
https://github.com/analogjs/analog/issues/1033
Either way, Flicker Problem #1 needs immediate attention.
Other information
If someone figures out the fix and doesn't want to do the PR, I am willing to do it.
I would be willing to submit a PR to fix this issue

[X] Yes
[ ] No

@brandonroberts - I think we have two options here after doing some research.

Put everything in a resolver. The problem with this is that it gets rid of the ability to pass the markdown context to:

<analog-markdown content="" />

Wait (maybe even a year) for PendingTasks to be public as mentioned here.

On a different note, I think the markdown conversion should be handled completely on the server in an endpoint. There is no reason to load up the client with that package.
This is a huge bug SSR, but I don't know that it can be fixed without a re-write of the analog-markdown component with resolvers... for now.
J

@jdgamble555 Yea, I don't want to have to require a resolver because the analog-markdown component should be usable without it.
I'd even use the private ΘPendingTasks symbol until it becomes public API if that provides a reasonable solution. We can always switch internally to the public API when it becomes available.
We could render the markdown on the server and only ship that to the client, but needs some investigation there also.

Is it possible to use the private 'ΘPendingTasks' ?
The markdown on the server would just be an internal endpoint accepted the markdown data and returning the html. Of course we need to await that too, but would be cleaner.


Prepare the module for django 1.9

The changes are quite straightforward, and some similar to the #758.

Moreover, we would very much like to use the native JSON field, but still we don't have the perfect idea on how to do it. I thought of a setting, but you might have @omab some suggestions.
Cheers

This has been here for quite a long time now and there is a lot of other PR waiting. I am getting tons of warnings with the python-social-auth module on Django 1.9 project. Do you need mainteiners for this project @omab maybe?

A similar change was already introduced a while ago, it also forms part of the new app social-app-django.
Thanks!


Fingerprint permission

 Issue by andris95
Thursday Mar 16, 2017 at 08:16 GMT
Originally opened as https://github.com/googlesamples/android-FingerprintDialog/issues/45

Hello! In this sample project there is comment like this:

Now the protection level of USE_FINGERPRINT permission is normal instead of dangerous.

But it is not true, in my project I am using compilseSdkVersion and targetSdkVersion 25.0.2.
And for example, to check if the device has a fingerprint sensor, i call this method:
if (!mFingerprintManager.isHardwareDetected())
and it says

if (!mFingerprintManager.isHardwareDetected())

 Comment by yashasvigirdhar
Tuesday Jun 06, 2017 at 07:08 GMT

By Normal permission, it means that you can declare the permission in manifest and will be granted the same on app install. You don't need to request this permission at runtime. (All this applies for api >= 23 of course)

 Comment by LoPoBo
Friday Jun 16, 2017 at 12:35 GMT

I also saw this comment and found it confusing; has USE_FINGERPRINT ever been dangerous? I could not find any documentation supporting this.


🐛 [cloud_firestore] Permission Denied error started to happen today without me changing the Firestore rules or anything in the app

Bug report
All of a sudden today, my Flutter application is getting this exception:
Unhandled Exception: [cloud_firestore/permission-denied] The caller does not have permission to execute the specified operation.
E/flutter (16121): #0      StandardMethodCodec.decodeEnvelope
message_codecs.dart:652
E/flutter (16121): #1      MethodChannel._invokeMethod
platform_channel.dart:310
E/flutter (16121): <asynchronous suspension>
E/flutter (16121): #2      MethodChannel.invokeMapMethod
platform_channel.dart:510
E/flutter (16121): <asynchronous suspension>
E/flutter (16121): #3      MethodChannelQuery.get
method_channel_query.dart:99
E/flutter (16121): <asynchronous suspension>

The thing is, the app has been running for almost a year with no problems and I have not touched the Firestore security rules since then, which are
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if request.auth.uid != null;
    }
  }
}

So yesterday, everything worked, but today I am getting the permission denied error. Nothing changed from the apps perspective! I am 100% positive that I am successfully logged in the app.
My production users can't use the app now!

I'm experiencing the same problem in several apps that use Firestore and apparently the error is in Google Cloud, you can follow their solution here: https://status.cloud.google.com/incidents/iRvJVnsbz8T47ySiy5Hg

Thank you for the link @netoreboucas ! I could not find any solution on that page though.

Aaaand drumroll, they fixed it! 👍

All we can do is wait. But apparently they have already corrected it, based on their latest report.


[req/ack] Potentially harden req/ack interfaces for OTP scrambling keys

Description
Factored out from #11172:
The data lines transmitting OTP scrambling keys and nonces from OTP Ctrl to users don't return to 0 and keep their values. Which is good. However, some users of OTP keys seem to have no spurious ack detection, in particular:

KeyMgr has no spurious ack/valid detection. But there is probably little use in latching in a wrong root key.
Flash Ctrl seems not to have spurious ack detection. Don't know if there would be any use in loading a wrong key here.
SRAM Ctrl seems not to have spurious ack detection. Here I can see a potential interest in loading a wrong / weak / deterministic key.
OTBN has no spurious ack detection. Here I can see a potential interest in loading a wrong / weak / deterministic key.
Ibex latches the key upon spurious acks but won't use the key in the scrambled SRAMs of the icache. To use the keys, the ack needs to come while the req is high. Also here I can see interest in loading a wrong / weak / deterministic key. But it's probably sufficiently hard with the current design.

For M2.5 I suggest that we:

Confirm if KeyMgr and Flash Ctrl are fine as is.
Check  if we can add at least some lightweight spurious ack detection to SRAM Ctrl and OTBN similar to what Ibex has.

I mark this issue for discussion in the security WG.
First estimate, since this potentially affects multiple IP blocks and discussions have not concluded yet:

estimate 32

I think your reasoning is valid @ballifatih. Latching in 'once' makes sense. I understand this means the original purpose of this issue here must be addressed, right?

keymgr
The internal state of the keymgr is advanced in the ROM_EXT. The ROM_EXT can opt to run a comparison test by comparing an output of the key manager against a known value set at manufacturing time. See discussion: https://github.com/lowRISC/opentitan/issues/10323.
The attacker still has to extract the gate level constant, and seed secret stored in flash_ctrl in order to recreate the device root key. I consider this high effort given that the attacker has to target at least three different types of data. The attacker also has to target code execution in the ROM_EXT.
flash_ctrl
On the flash_ctrl, I suspect this is going to result in boot failure due to failure to unscramble ROM_EXT. This will result in ROM sigver failure. The ROM then trigger shutdown and lockdown the device.

@GregAC this issue is on the agenda for Sec WG 03/30.
@moidx I agree: I also do not see any concerning attack path from FI onto the req/ack interface.
@ballifatih wanted to latch-in the OTP root key in one single cycle instead of continuously to simplify masking it w/ fresh entropy which we use to protect all further processing against SCA (see #7614). This seemed reasoable to me and this is already merged as I understand (see PR #17509).

Thanks for your input @moidx, @ballifatih and everyone else.
We've discussed this in the Security WG meeting on Mar 30 2023 and concluded the following:

keymgr and flash_ctrl can be left as is. As @moidx outlined corresponding attacks on keymgr and flash_ctrl would either be very high effort or pointless, respectively. As @ballifatih mentioned, the behavior of keymgr might change slightly to make such an attack even more difficult.
SRAM Ctrl can be left as is. The timing window is very short and these memories are used frequently, there is a high chance to corrupt the memory by changing the key at the wrong time. Because is Ibex is constantly using these RAMs.
OTBN should be extended with some lightweight spurious ack detection / to not latch the new scrambling key unless both req and ack are high at the same time. This is recommended as OTBN may be idle for quite some time between running different applications. Before running a new application, IMEM and DMEM are rewritten by Ibex. This means a change of the scrambling key when being idle could remain unnoticed.

I am thus opening a new OTBN-specific issue and will close this one.

Here is the OTBN issue: #17772


Generic Script Error on sqf::call

Due to the fact that assignments don't return nil, but NOTHING:
The sqf::call wrapper assigns the result of a call to a variable which can be NOTHING because of said fact.
This can cause a generic script error.

This can be solved by not always grabbing a return value.
This can either be done by implementing two additional sqf::call wrappers that just return nothing. Or using a dynamic approach that detects whether the user even want's a return value.
SQF function to call script without return value
intercept_fnc_callWrapper_NoReturn = {
	scopeName "main";
	(missionNamespace getVariable "INTERCEPT_CALL_ARGS") params ["_args", "_code"];
	_args call _code;
	INTERCEPT_DUMMY;
};

A wrapper that detects whether the return value is needed could look like this:
/**
         * @brief Wrapper for return value of sqf::call
         * @desc This will call the script function and only fetch the return value if you use/store it.
         */
        class call_ret_val {
        public:
            explicit call_ret_val(game_value args_) : args(args_) {}
            call_ret_val(const call_ret_val&) = delete;
            call_ret_val(call_ret_val&&) = delete;
            call_ret_val& operator=(const call_ret_val&) = delete;
            call_ret_val& operator=(call_ret_val&&) = delete;
            operator game_value&& () const { return get_return_value(); }
            game_value&& operator*() const { return get_return_value(); };
            game_value&& operator->() const { return get_return_value(); };
            ~call_ret_val() {
                if (executed) return;
                set_variable(mission_namespace(), "INTERCEPT_CALL_ARGS", args);
                host::functions.invoke_raw_unary(
                    __sqf::unary__isnil__code_string__ret__bool,
                    get_variable(mission_namespace(), "intercept_fnc_callWrapper_NoReturn")
                );
            }
        private:
            game_value&& get_return_value() const {
                //Cannot be done more than once
                assert(!executed);
                set_variable(mission_namespace(), "INTERCEPT_CALL_ARGS", args);
                host::functions.invoke_raw_unary(
                    __sqf::unary__isnil__code_string__ret__bool,
                    get_variable(mission_namespace(), "intercept_fnc_callWrapper")
                );
                executed = true;
                return std::move(get_variable(mission_namespace(), "INTERCEPT_CALL_RETURN"));
            }
            const game_value args;
            bool executed{ false };
        };

Which works fine in almost all cases.
game_value ret = sqf::call(code); //Calls conversion operator which returns result of get_return_value()
sqf::call(code); //Return value is never used. Which means it destructs right after this call meaning we call the function without grabbing a return value
(*sqf::call(code)).size(); //uses operator* which returns result of get_return_value();
std::string ret = sqf::call(code); //implicitly calls operator game_value&& and game_value's conversion operator to std::string
object ret = sqf::call(code); //implicitly calls operator game_value&& and conversion to object.

I don't really like that you would have to use (*). to get the return value.
We cannot use operator-> because that returns a pointer. And we only have a temporary here. We could however return the result of the call inside call_ret_val and return the pointer to that. But that could go bad if you use the to_array function of game_value to get a auto_array reference. call_ret_val and thus the game_value might get destroyed before you are done working with the auto_array ref.
The bigger problem is following
auto ret = sqf::call(code); //Doesn't compile. Because auto deduces to call_ret_val which can't be assigned using operator=
auto ret = *sqf::call(code); //Fine. Calls operator* which returns rvalue game_value and move assigns it into ret which deduced to game_value

This would break a lot of code.
The absolute best solution would be using operator. which returns the stored return value.
(http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0252r0.pdf)
But it doesn't look like it will make it into c++17

@NouberNou What do you think? This would all be fine if we disallow the use of auto for variables that store the returned data from sqf::call. Many people will stumble over that probably. We can probably add that as a remark in the Documentation of sqf::call which should make it quite clear to the user. If the user doesn't want to read the documentation then it's his fault when he does stuff wrong.
If the user uses "anything" other than auto. It will compile and behave as expected.
Anything here being anything that game_value can convert to.

Why not this?
intercept_fnc_callWrapper = {
	scopeName "main";
	(missionNamespace getVariable "INTERCEPT_CALL_ARGS") params ["_args", "_code"];
	[_x] apply {_args call _code} select 0
};

Btw, _args and _code will be changed in the called code.

Good catch if that really works

Should maybe prefix the locals with _intercept_ to avoid collisions.
This method already takes care of _x, but in scheduled that might be undefined and result in an error.
[if (!isNil "_x") then {_x}]

as work-around if that's a concern.

We can't be scheduled. So that's not a concern.


Giving issue while adding web part to app catalog

I have adding SPFx web part to my site by adding .sppkg file to app catalog. Upto 4 days back it was worked fine. But all of sudden from yesterday web part is not visible on page. When I try to find the SPFx app in modern view, I am not able to find the web part. But if i see the site contents page in classic view web part is appearing. I have tried to remove the web part, it almost took 20 hrs to get deleted.
I thought something was wrong here. So I decided to add same web part with newer version. But while adding it is giving me following error.

If I do gulp serve then in workbench it is working fine. Not in production.
I am using gulp bundle --ship and gulp package-solution --ship commands to generate the files.

As per the information there is currently an outage that prevents you from uploading/adding/removing apps https://sharepoint.stackexchange.com/questions/235444/issue-while-adding-web-part-to-app-catalog

Hi @ymihir we are also facing same issue with our multiple Tenants, Thanks for the Update

That should be fixed by now. You can close that issue.

Closing as this was related on the outage.


The assignment reviews page should display the tag count

Either per round or the total

This issue shows Tags in Score Page where student can see answered tags per review


PASS_TO_PASS tests failing on original program

Thank you for creating the dataset!
I was running scripts on the benchmark, and realized that sometimes the PASS_TO_PASS tests fail on the original version of the subject when no patch was applied.
For example, in matplotlib__matplotlib-24334, upon checking out the base_commit, entering the conda env, and performing install commands, executing the test_cmd pytest --no-header -rA --tb=no -p no:cacheprovider lib/matplotlib/tests/test_axes.py results in some test failures on my system (ubuntu 20.04 LTS). The following tests failed and are in the PASS_TO_PASS list of this instance:
FAILED lib/matplotlib/tests/test_axes.py::test_hist2d[png] - matplotlib.testing.exceptions.ImageComparisonFailure: images not close (RMS 5.559):
FAILED lib/matplotlib/tests/test_axes.py::test_hist2d[pdf] - matplotlib.testing.exceptions.ImageComparisonFailure: images not close (RMS 142.950):
FAILED lib/matplotlib/tests/test_axes.py::test_hist2d[svg] - matplotlib.testing.exceptions.ImageComparisonFailure: images not close (RMS 4.493):
FAILED lib/matplotlib/tests/test_axes.py::test_hist2d_transpose[pdf] - matplotlib.testing.exceptions.ImageComparisonFailure: images not close (RMS 155.125):

These tests seem to test for histogram generation. I am not sure why they fail, but maybe some system-level dependencies were missing / having wrong version on my system.
May I know whether these tests could pass on your system? Since some of the projects in the benchmark require quite a number of system-level dependencies, it might be good to have a Docker environment. Also, for the tests that are not very related to the target issue but have unstable behavior due to the host environment, would you consider removing them from the benchmark?
Thank you for looking into this!

Hi @yuntongzhang thanks for your detailed issue description. We just released a report detailing the improvements we've made to SWE-bench evaluation over the past month that aims to resolve a lot of issues around evaluation that have been reported.
I have a feeling that the issues you detailed may be resolved by the latest swebench==1.1.0, specifically because we have made installation more explicit and reproducible. You're correct in that to our knowledge, it seems that some of our installation specifications were underspecified.
We will also release execution logs + predictions for all models run on SWE-bench so far by tomorrow.
Regarding some ofyour other points...

Docker environment - you're absolutely right. We're currently working on putting together a Dockerfile that is a good reflection of the system we run on. This is taking some time + requires trial and error, but we hope to deliver one by June.
We have some ongoing work focused on better curation of task instances + identifying relevant tests. As of the report, we have greater confidence that the latest SWE-bench task instances are evaluated with relevant tests, but if there is a clear demonstration of tests being problematic, we'll certainly consider removing them as a course of action.

Hope this helps! Leaving this open in case there are any follow up questions.

Closing this due to inactivity. We are planning on releasing a new SWE-bench evaluation harness soon, it should address any additional issues that still remain with the current version of SWE-bench.