Add s1920 sub_experiment_id

Hi @durack1 here is a copy of an email sent in January about dcppC sub-experiment IDs:
"In the final version of the article describing the DCCP protocol (https://pure.mpg.de/rest/items/item_2365756_6/component/file_2365767/content) we can read "Experiments should cover the period from 1950 to 2014, but starting from 1910 is desirable if possible."
This requirement has changed from an old version of the article where it was "starting from 1920 is desirable".
Unfortunately, we run IPSL-CM pacemaker experiments from 1920 to 2014 and PrePARE complains because the sub_experiment_id is not properly set.
Our understanding is that 1950-2014 is the shortest period to cover and starting before 1950 is more like a nice to have. If this is right, could it possible to update the WCRP JSON files accordingly (at least by adding "s1920" as allowed sub_experiment_id)"
This was approved by @taylor13, would it be possible to update the CMIP6_sub_experiment_id.json accordingly?
Many thanks !

@glevava thanks for raising this, it's not completely clear what change you are recommending.
The DCPP activity_id includes 26 separate experiments, and there are two identified "pacemaker" experiments, both dcppC-atl-pacemaker and dcppC-pac-pacemaker and both include sub_experiment_id of s1910, s1920, s1950.
Can you be more clear as to what change is required?

@durack1 Yes you're right but the "CMIP6_sub_experiment_id.json" should also have "s1920":"initialized near end of year 1920",. Thus the s1920 value will be propagated to the esg.cmip6.ini that is not currently the case.

@glevava I see what you mean, so CMIP6_sub_experiment_id.json needs to be amended to include:
{
    "sub_experiment_id":{
        "none":"none",
        "s1910":"initialized near end of year 1910",
+       "s1920":"initialized near end of year 1920",
        "s1950":"initialized near end of year 1950",
...

That's an easy fix, will do this now

Exactly. Thanks !

@glevava thanks for raising this, the change is now in place, take a peek at CMIP6_sub_experiment_id.json and let me know if you see anything else awry


fix: Move streams thread

move streams thread to application configuration

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.0 out of 2 committers have signed the CLA.:x: elisamozammel:x: LockeBirdseyYou have signed the CLA already but the status is still pending? Let us recheck it.


Guild View Hangs When No Runs Are Found - Crashes Chrome Browser

shows spinning progress thingie, then crashed my browser

@cfregly could you provide the output of guild check so I can work to reproduce this?

Nevermind the version info, I was able recreate. Look for a fix in the next dev release (0.3.1.dev4).

@gar1t  is this fixed?  i have a workaround, so i haven't seen this since i first created the issue.  i can try to test it later today.

This should be fixed but I'd love to get a +1 from you, at which point we can close!

Closing for now. If this shows up we can reopen.


Implement Clear Button in Search Field

A clear icon is needed to remove the searched content in the search box.

I will implement a clear icon in the search box to allow users to easily remove their search input with a single click. This will enhance usability by simplifying the process of clearing the search field.


Add tests

[x] Add tests for generate_homebrew_formula
[x] Add test workflow

Rebased with main and updated the tests.


The buttons in documentation page are not functional

The buttons to github, linkedin and x (formely twitter) are not functional. And i think its better to use icon of X instead of old twitter account. I am a beginner.
Please assign it to me.
Steps to reproduce the behavior:

Go to Documentation from navbar
Click on the github, linkedin, twitter icon
See error

Expected behavior
Upon clicking the icons the page should redirect to respective links.
Screenshots

Desktop (please complete the following information):

OS: Windows
Browser Chrome
Version 126

Smartphone (please complete the following information):

Device: Redmi Note 11
OS: MIUI 14
Browser: Google Chrome
Version 129

Hey @subin-shk , thanks for offering to take this on! Just a heads-up that the current documentation page is temporary, so I don't need any changes to it right now. However, if you're interested, you can create a new documentation page after thoroughly going through the website and understanding how everything works. Let me know if you're up for that challenge! 😊

@notsoocool what sort of things would you prefer to add on your new documentation page?

Actually the Main landing page is getting revamped, so what you can do is, you can bring out things from landing page here and also add some few more things.


Enhances mssql schema to detect sizes of string fields

Q
A

Is bugfix?
no

New feature?
enhancement

Breaks BC?
no

Tests pass?
those I could test yes

Fixed issues
#16378

Sure, I will do but it will take a bit more long because of my current sparse time. :+1:

@samdark, PDO sqlsrv driver has a problem in Win10 refering to PDO::ATTR_EMULATE_PREPARE. If it is used, an exception is throwed: PDOException: SQLSTATE[IMSSP]: The given attribute is only supported on the PDOStatement object. and all tests are skipped!
To make the tests work in my environment, I have to bypass those lines for sqlsrv driverName. Even althoug, the pre-existing tests are not passing:
$ php vendor\phpunit\phpunit\phpunit tests\framework\db\mssql\SchemaTest.php --verbose

# tests resulting error because of the exception refering to emulate_prepare
.EEEEEE..........E.FF.F..................................
# resulting in multiple "PDOException: SQLSTATE[IMSSP]: The given attribute is only supported on the PDOStatement object."

# After bypass emulate prepare:
...............E.FF.F............................................ 65 / 82 ( 79%)
.................

Time: 2.33 minutes, Memory: 10.00MB

There was 1 error:

1) yiiunit\framework\db\mssql\SchemaTest::testCompositeFk
Trying to get property of non-object

C:\Users\c126830\Dev\php\_arquivados\yii2\tests\framework\db\SchemaTest.php:234
C:\Users\c126830\Dev\php\_arquivados\yii2\vendor\phpunit\phpunit\phpunit:52

--

There were 3 failures:

1) yiiunit\framework\db\mssql\SchemaTest::testNegativeDefaultValues
Failed asserting that 0 matches expected -123.

C:\Users\c126830\Dev\php\_arquivados\yii2\tests\framework\db\SchemaTest.php:492
C:\Users\c126830\Dev\php\_arquivados\yii2\vendor\phpunit\phpunit\phpunit:52

2) yiiunit\framework\db\mssql\SchemaTest::testColumnSchema
Failed asserting that two arrays are equal.
--- Expected
+++ Actual
@@ @@
 Array (
-    0 => 'bit_col'
-    1 => 'blob_col'
-    2 => 'bool_col'
-    3 => 'bool_col2'
-    4 => 'char_col'
-    5 => 'char_col2'
-    6 => 'char_col3'
-    7 => 'enum_col'
-    8 => 'float_col'
-    9 => 'float_col2'
-    10 => 'int_col'
-    11 => 'int_col2'
-    12 => 'json_col'
-    13 => 'numeric_col'
-    14 => 'smallint_col'
-    15 => 'time'
-    16 => 'tinyint_col'
-    17 => 'ts_default'
+    0 => 'blob_col'
+    1 => 'bool_col'
+    2 => 'bool_col2'
+    3 => 'char_col'
+    4 => 'char_col2'
+    5 => 'char_col3'
+    6 => 'float_col'
+    7 => 'float_col2'
+    8 => 'int_col'
+    9 => 'int_col2'
+    10 => 'numeric_col'
+    11 => 'smallint_col'
+    12 => 'time'
+    13 => 'tinyint_col'
 )

C:\Users\c126830\Dev\php\_arquivados\yii2\tests\framework\db\SchemaTest.php:510
C:\Users\c126830\Dev\php\_arquivados\yii2\vendor\phpunit\phpunit\phpunit:52

3) yiiunit\framework\db\mssql\SchemaTest::testFindUniqueIndexes
Failed asserting that two arrays are equal.
--- Expected
+++ Actual
@@ @@
 Array (
-    'somecolUnique' => Array (...)
 )

C:\Users\c126830\Dev\php\_arquivados\yii2\tests\framework\db\SchemaTest.php:565
C:\Users\c126830\Dev\php\_arquivados\yii2\vendor\phpunit\phpunit\phpunit:52

FAILURES!
Tests: 82, Assertions: 364, Errors: 1, Failures: 3.

I think the current tests should be reviewed, maybe could be a bug.
To make a new test for this PR, in my current environment, I have to bypass all emulate prepare in tests for sqlsrv (I found it in 3 places). Should I go ahead and make the new test anyway since it seems work in other environments?

If your new tests isn't affected by other tests failures then yes, go ahead.

@samdark, tests added. If you preffer I can rebase to remove "Bypass" commit.

Merged. Thank you!


Affiliation with Checkgit?

I'm assuming there's no affiliation between this project and CheckGit, but thought it was worth raising. No doubt they're just scraping source for emails 🤢

I have never heard of CheckGit, sorry they're spamming you..


ingress: Propagate required annotations from Ingress to LB Service

This PR adds the required annotations from Ingress to Load Balancer Service.
Fixes: #20646

the changes LGTM @NikhilSharmaWe but it seems the unit tests are failing.

@aanm
Not sure but are the tests failing because we cannot compare maps through assert.Equal.
Should I try this approach instead for comparing the annotations: https://github.com/NikhilSharmaWe/cilium/commit/956694e34c0e82d1d964f44d9c295ab72e20adb9 ?

@aanm Not sure but are the tests failing because we cannot compare maps through assert.Equal. Should I try this approach instead for comparing the annotations: NikhilSharmaWe@956694e ?

The tests are failing because the code is not correctly formatted. Cilium uses Go 1.19 and perhaps the formatting has changed in this verison.

@aanm @sayboras
I have changed the flag name to ingress-lb-annotations.
Also, is this commit reasonable for the follow-up for supporting this flag ingress-lb-annotations in helm (e.g. ingress controller)?

@aanm @sayboras I have changed the flag name to ingress-lb-annotations.
Also, is this commit reasonable for the follow-up for supporting this flag ingress-lb-annotations in helm (e.g. ingress controller)?

@NikhilSharmaWe if you have it ready already I don't see the harm of adding with this PR.

@aanm Added the changes for adding support for flag ingress-lb-annotations in helm (ingressController), could you please take a look.
If want to take a look at only those new changes: https://github.com/cilium/cilium/commit/dc9c8114d228b16efd3353180a8f425d9ac8b379

@NikhilSharmaWe it looks that CI is failing because of the changes from this PR. Some files need to be generated with:
make -C install/kubernetes cilium/values.yaml

@aanm No new changes are generated from make -C install/kubernetes cilium/values.yaml.

@NikhilSharmaWe you need to apply this diff:
diff --git a/install/kubernetes/cilium/README.md b/install/kubernetes/cilium/README.md
index 0aba18de03..e0dad0f22c 100644
--- a/install/kubernetes/cilium/README.md
+++ b/install/kubernetes/cilium/README.md
@@ -328,6 +328,8 @@ contributors across the globe, there is almost always someone available to help.
 | imagePullSecrets | string | `nil` | Configure image pull secrets for pulling container images |
 | ingressController.enabled | bool | `false` | Enable cilium ingress controller This will automatically set enable-envoy-config as well. |
 | ingressController.enforceHttps | bool | `true` | Enforce https for host having matching TLS host in Ingress. Incoming traffic to http listener will return 308 http error code with respective location in header. |
+| ingressController.ingressLBAnnotations | list | `[]` |  |
+| ingressController.ingressLBAnnotationsDefault | list | `["service.beta.kubernetes.io","service.kubernetes.io","cloud.google.com"]` | IngressLBAnnotations are the annotations which are needed to propagate from Ingress to the Load Balancer |
 | ingressController.secretsNamespace | object | `{"create":true,"name":"cilium-secrets","sync":true}` | SecretsNamespace is the namespace in which envoy SDS will retrieve TLS secrets from. |
 | ingressController.secretsNamespace.create | bool | `true` | Create secrets namespace for Ingress. |
 | ingressController.secretsNamespace.name | string | `"cilium-secrets"` | Name of Ingress secret namespace. |
diff --git a/install/kubernetes/cilium/values.yaml b/install/kubernetes/cilium/values.yaml
index ca4ad18fb8..147164f642 100644
--- a/install/kubernetes/cilium/values.yaml
+++ b/install/kubernetes/cilium/values.yaml
@@ -483,11 +483,11 @@ ingressController:
   # -- Enforce https for host having matching TLS host in Ingress.
   # Incoming traffic to http listener will return 308 http error code with respective location in header.
   enforceHttps: true
-
+
   # -- IngressLBAnnotations are the annotations which are needed to propagate
   # from Ingress to the Load Balancer
-  ingressLBAnnotationsDefault: ["service.beta.kubernetes.io", "service.kubernetes.io", "cloud.google.com"]
-
+  ingressLBAnnotationsDefault: ['service.beta.kubernetes.io', 'service.kubernetes.io', 'cloud.google.com']
+
   ingressLBAnnotations: []

   # -- SecretsNamespace is the namespace in which envoy SDS will retrieve TLS secrets from.

@NikhilSharmaWe CI is now complaining that it needs make -C Documentation update-cmdref

I have marked this PR as draft, feel free to change it to ready to review once you are done with changes. Thanks.

@sayboras When I run make -C install/kubernetes cilium/values.yaml, it says that 'cilium/values.yaml' is up to date.

When I run make -C install/kubernetes cilium/values.yaml, it says that 'cilium/values.yaml' is up to date.

Seems like this Make target is not declared as PHONY, please find below the diff to make some of CI jobs happy.
Kindly also check the GHA failures, which will have steps on how to fix or give you enough details about error.
diff --git a/Documentation/spelling_wordlist.txt b/Documentation/spelling_wordlist.txt
index 87d5e99959..f3f3658953 100644
--- a/Documentation/spelling_wordlist.txt
+++ b/Documentation/spelling_wordlist.txt
@@ -496,6 +496,7 @@ imagePullSecrets
 incrementing
 indices
 ingressController
+ingressLBAnnotations
 ingressing
 init
 initContainer
diff --git a/install/kubernetes/cilium/values.yaml b/install/kubernetes/cilium/values.yaml
index f82050b3f2..147164f642 100644
--- a/install/kubernetes/cilium/values.yaml
+++ b/install/kubernetes/cilium/values.yaml
@@ -483,11 +483,11 @@ ingressController:
   # -- Enforce https for host having matching TLS host in Ingress.
   # Incoming traffic to http listener will return 308 http error code with respective location in header.
   enforceHttps: true
-
+
   # -- IngressLBAnnotations are the annotations which are needed to propagate
   # from Ingress to the Load Balancer
   ingressLBAnnotationsDefault: ['service.beta.kubernetes.io', 'service.kubernetes.io', 'cloud.google.com']
-
+
   ingressLBAnnotations: []

   # -- SecretsNamespace is the namespace in which envoy SDS will retrieve TLS secrets from.

/test

@sayboras Commit message consists of Sign-off but the error is saying the opposite.

Should it be as per below instead? You can also use git commit --amend --signoff as well.

Signed-off-by: Nikhil Sharma<EMAIL_ADDRESS>

CI was passed before, the force pushes are just to adjust commit message (e.g. typo and sign off).
Mark this ready to merge.


Operator in crash loop: index out of range [5] with length 5

Describe the bug:
Operator container constantly crashing on startup with the following error
{"level":"info","ts":1631912333.9664009,"logger":"controller_vault","msg":"Reconciling Vault","Request.Namespace":"vault","Request.Name":"vault"} panic: runtime error: index out of range [5] with length 5
Expected behaviour:
Operator pod should either not have this issue or gracefully handle error
Steps to reproduce the bug:
Deploy operator to vault-infra namespace per documented install instructions
Deploy Vault object to vault namespace
Environment details:

Kubernetes version: 1.19
Cloud-provider/provisioner: AWS
bank-vaults version: 1.14.1, also tried 0.14.0
Install method: Helm

/kind bug
Additional context:
Operator config
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "5"
    meta.helm.sh/release-name: vault-operator
    meta.helm.sh/release-namespace: vault-infra
  labels:
    app.kubernetes.io/instance: vault-operator
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: vault-operator
    helm.sh/chart: vault-operator-1.14.1
  name: vault-operator
  namespace: vault-infra
spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app.kubernetes.io/name: vault-operator
  strategy:
    type: Recreate
  template:
    metadata:
      creationTimestamp: null
      labels:
        app.kubernetes.io/instance: vault-operator
        app.kubernetes.io/name: vault-operator
    spec:
      affinity: {}
      containers:
      - command:
        - vault-operator
        - -sync_period
        - 1m
        env:
        - name: WATCH_NAMESPACE
        - name: POD_NAME
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: metadata.name
        - name: OPERATOR_NAME
          value: vault-operator
        - name: OPERATOR_LOG_LEVEL
          value: debug
        - name: BANK_VAULTS_IMAGE
          value: ghcr.io/banzaicloud/bank-vaults:1.14.1
        image: ghcr.io/banzaicloud/vault-operator:1.14.1
        imagePullPolicy: IfNotPresent
        livenessProbe:
          failureThreshold: 3
          httpGet:
            path: /
            port: 8080
            scheme: HTTP
          initialDelaySeconds: 60
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 1
        name: vault-operator
        ports:
        - containerPort: 8080
          protocol: TCP
        - containerPort: 8383
          protocol: TCP
        readinessProbe:
          failureThreshold: 3
          httpGet:
            path: /ready
            port: 8080
            scheme: HTTP
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 1
        resources:
          limits:
            cpu: "2"
            memory: 4Gi
          requests:
            cpu: "1"
            memory: 2Gi
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      serviceAccount: vault-operator
      serviceAccountName: vault-operator
      terminationGracePeriodSeconds: 10

Vault object config
apiVersion: vault.banzaicloud.com/v1alpha1
kind: Vault
metadata:
  labels:
    app.kubernetes.io/name: vault
    vault_cr: vault
  name: vault
  namespace: vault
spec:
  annotations:
    common/annotation: "true"
  caNamespaces:
  - '*'
  config:
    api_addr: https://vault.vault:8200
    cluster_addr: https://${.Env.POD_NAME}:8201
    listener:
    - tcp:
        address: <IP_ADDRESS>:8300
        tls_cert_file: /etc/letsencrypt/tls.crt
        tls_key_file: /etc/letsencrypt/tls.key
    - tcp:
        address: <IP_ADDRESS>:8200
        tls_cert_file: /vault/tls/server.crt
        tls_key_file: /vault/tls/server.key
    storage:
      raft:
        path: /vault/file
    ui: true
  credentialsConfig:
    env: ""
    path: ""
    secretName: ""
  externalConfig:
    auth:
    - roles:
      - bound_service_account_names:
        - default
        - vault
        - vault-secrets-webhook
        bound_service_account_namespaces:
        - default
        - vault
        - vswh
        name: default
        policies: allow_secrets
        ttl: 1h
      type: kubernetes
    policies:
    - name: allow_secrets
      rules: path "secret/*" { capabilities = ["create", "read", "update", "delete",
        "list"] }
    secrets:
    - description: General secrets.
      options:
        version: 2
      path: secret
      type: kv
  image: vault:1.6.2
  ingress:
    annotations:
      external-dns.alpha.kubernetes.io/target:
      ingress.kubernetes.io/protocol: https
      ingress.kubernetes.io/ssl-proxy-headers: 'X-Forwarded-Proto: https'
      ingress.kubernetes.io/ssl-redirect: "true"
      kubernetes.io/ingress.class: traefik
      traefik.ingress.kubernetes.io/frontend-entry-points: http,https
      vault.security.banzaicloud.io/vault-addr: http://vault.vault:8200
      vault.security.banzaicloud.io/vault-skip-verify: "true"
    spec:
      rules:
      - host:
  nodeAffinity: {}
  podAntiAffinity: failure-domain.beta.kubernetes.io/zone
  resources:
    vault:
      limits:
        cpu: "2"
        memory: 4Gi
      requests:
        cpu: "1"
        memory: 2Gi
  securityContext: {}
  serviceAccount: vault
  servicePorts:
    api-port: 8200
    cluster-port: 8201
    external-port: 8300
    https-port: 443
  serviceRegistrationEnabled: true
  serviceType: LoadBalancer
  size: 3
  statsdDisabled: true
  unsealConfig:
    kubernetes:
      secretNamespace: vault
    options:
      preFlightChecks: true
  vaultAnnotations:
    service.beta.kubernetes.io/aws-load-balancer-backend-protocol: tcp
    service.beta.kubernetes.io/aws-load-balancer-internal: <IP_ADDRESS>/16
    service.beta.kubernetes.io/aws-load-balancer-type: internal
    type/instance: vault
  vaultConfigurerAnnotations:
    type/instance: vaultconfigurer
  vaultConfigurerLabels:
    example.com/log-format: string
  vaultContainerSpec:
    name: ""
    resources: {}
  vaultEnvsConfig:
  - name: VAULT_LOG_LEVEL
    value: debug
  vaultLabels:
    example.com/log-format: json
  veleroEnabled: true
  volumeClaimTemplates:
  - metadata:
      name: vault-raft
    spec:
      accessModes:
      - ReadWriteOnce
      resources:
        requests:
          storage: 20Gi
      volumeMode: Filesystem
  volumeMounts:
  - mountPath: /vault/file
    name: vault-raft
  - mountPath: /etc/letsencrypt
    name: vault-ingress-tls
  volumes:
  - name: vault-ingress-tls
    secret:
      defaultMode: 420
      secretName: vault-ingress-tls

This seems to be an issue when I added an additional serviceport for https access, I removed the original externalport 8300 and now operator is no longer crashing.

When I re-deployed with latest operator code locally, I couldn't reproduce issue as it added the additional port to the service.  It seems that if the service is deployed initially and a new port is added to existing Vault object, it doesn't update the service and thus it hits this range error since Vault expects 6, but only finds 5 when querying service.

I took the Vault CR example you have added to the issue but I neither could reproduce the issue with the most recent version of the operator.

Thanks @bonifaido , I will see if it shows up again, it might have been some disconnect while I was working on getting the operator configured between it and the service.  At this point I will close this, and re-open if I see it again.


Nprogress with Backbone

I'm trying to display nprogress when the views are being rendered using backbone. The nprogress progesses smothely, but gets stuck at the end and never stops.
How could i fix this. Below is the code snippet that im trying to do
	app.NProgress.start();

	this.collection.each( function( item ){
		this.renderPhotoSet( item );
		app.NProgress.inc();
	}, this );

	app.NProgress.done();

Put "app.NProgress.inc();" before the loop, it's going to increment anyways. Use Undescore's _.each(), which is synchronous, to loop through the collection and then "app.NProgress.done();"  will fire after the loop.


add closeOnSelection prop on DatePicker

request add closeOnSelection prop on DatePicker

I don't think it really makes sense to have anything like that for the date picker itself. There is an undocumented on:select event which you could use to manually hide the DatePicker


Publishing Greip to Raycast store.

Description
Greip helps you get the full information about your IP Address, your country or even detecting bad-words in a specific text.
Screencast

Checklist

[x] I read the extension guidelines
[x] I read the documentation about publishing
[x] I ran npm run build and tested this distribution build in Raycast
[x] I checked that files in the assets folder are used by the extension itself
[x] I checked that assets used by the README are placed outside of the metadata folder

Hi @gre-dev 👋
I made some improvements, do you mind checking them out that I didn't break something 😊

Thanks for the check @gre-dev; I forgot to add the dependency - should be better now 🧑🚒

Works well now, thanks.
You can merge it ✨


Add dartk, dartkp Windows buildbots

Considering https://github.com/dart-lang/sdk/issues/31706, it seems pretty important now we add Windows dartk, dartkp buildbots.
@alexmarkov

I've re-enabled the window precomp bot, but it immediately fails:
Test configurations: dartkp_dart_precompiled_release_x64_strong dartkp_dart_precompiled_release_x64_strong
Running "vm_compile_to_kernel" command: set DART_CONFIGURATION=ReleaseX64 & set DART_VM_FLAGS=--limit-ints-to-64-bits & C:\b\s\w\ir\cache\builder\sdk\pkg\vm\tool\gen_kernel --aot --strong-mode --sync-async --platform=out/ReleaseX64/vm_platform_strong.dill -o C:/b/s/w/ir/cache/builder/sdk/out/ReleaseX64/generated_compilations/dartkp-strong/runtime_tests_vm_dart_byte_array_test/out.dill C:\b\s\w\ir\cache\builder\sdk\runtime\tests\vm\dart\byte_array_test.dart
CreateProcessW failed 193
Process error:
Command: C:\b\s\w\ir\cache\builder\sdk\pkg\vm\tool\gen_kernel --batch ([--aot, --strong-mode, --sync-async, --platform=out/ReleaseX64/vm_platform_strong.dill, -o, C:/b/s/w/ir/cache/builder/sdk/out/ReleaseX64/generated_compilations/dartkp-strong/runtime_tests_vm_dart_byte_array_test/out.dill, C:\b\s\w\ir\cache\builder\sdk\runtime\tests\vm\dart\byte_array_test.dart])
Error: ProcessException: %1 is not a valid Win32 application.
Command: C:\b\s\w\ir\cache\builder\sdk\pkg\vm\tool\gen_kernel --batch
step returned non-zero exit code: 1
https://logs.chromium.org/v/?s=dart%2Fbuildbucket%2Fcr-buildbucket.appspot.com%2F8954405349461037856%2F%2B%2Fsteps%2Fstrong_vm_tests_shard_10%2F0%2Fstdout

These builders are now fully working with the exception of blamelist emails which is tracked elsewhere:
https://bugs.chromium.org/p/chromium/issues/detail?id=808193


Many polymer behavior annotations wrong?

I've tried to build a project with polymer-build.
It does fail b/c of some annotations issues like:
/*
    @polymerBehavior PxVisBehavior.baseSize
*/
PxVisBehavior.baseSize = {

...

}

/*
    @polymerBehavior PxVisBehavior.baseSize
*/
PxVisBehavior.margins = {

}

Is there a reason for that? Would you accept a PR that fixes these duplicates?

Hmm... the reason is a copy and paste error  ;)
Yeah, we would love a PR if you find such errors. If not, please list which other behaviors you see that have such duplicate docs and we'll fix them.
Thanks


Fix missing military landuse areas.

Added missing comma. Not sure how that ever worked...
Note: a migration is necessary.
Connects to #367.
@rmarianski could you review, please?

Nice catch! Is it possible that it was concatenating the two strings together? I see that the migration is updating both military and rural just in case.
:+1:

Yeah, it looks like it was concatenating. But this syntax only appears to work at the end of a line... It seems very strange to me:
mapzen=# select 'foo''bar';
 ?column?
----------
 foo'bar
(1 row)

mapzen=# select 'foo' 'bar';
ERROR:  syntax error at or near "'bar'"
LINE 1: select 'foo' 'bar';
                     ^
mapzen=# select 'foo'
mapzen-#  'bar';
 ?column?
----------
 foobar
(1 row)


rename: Replace huddle with direct_message_group in locale.

Across 46 portable object files, replace huddle_display_name with direct_message_group_display name. To pass tests, huddle_display_name in missed_message.subject.txt and email_notifications.py were renamed as well.
Fixes part of #28640.

I don't think the locale changes are useful given how the i18n system works; see
https://zulip.readthedocs.io/en/latest/translating/internationalization.html for details; you should just rename the variable an translations will need to do some (trivial) work to update their strings.

I'll read the article and act accordingly. Thank you for the information, Tim


When will smiles be randered as Kekule structrue and when will not?

And can we config it to always (not) use kekulize?

Seems like only when all carbons in the ring in lower case will the ring be aromatized.

smiles should be kekulize mode

Here are some more test cases.  My summary of the current behaviour:

Rings only draw as aromatic when all the atoms (not bonds!) that make up the ring are aromatic (lower case).
Double bonds draw as half-dashed aromatic bonds when they're both a) between aromatic atoms and b) in rings.
Explicit aromatic bonds (:) draw as single bonds; I can't figure out how to draw one that's not part of a ring.


License clarity

The README and LICENSE for the repository are MIT.  However, the files themselves say "all rights reserved" ("ARR").  Those are incompatible; the ARR should be removed if the intention is to license the code under the MIT terms.
Cheers.

The file headers have been updated to include the text "Use of this source code is governed by the MIT license that can be found in the LICENSE file." which should clarify any licensing doubts.

Awesome, cheers @tstranex


Clean up package.json scripts

SDK-356
WIP

Coverage remained the same at 70.855% when pulling 8b1a080e7d2b0b81ced82f04015a0c38335150fa on remove-parallel-shell into 25312dc0846a49ac4daae80b149a924c004dfdce on master.

Coverage increased (+0.06%) to 70.915% when pulling 7b826400843bab85f3d8af1416241bef028bf937 on remove-parallel-shell into 25312dc0846a49ac4daae80b149a924c004dfdce on master.

Coverage decreased (-0.02%) to 70.84% when pulling 7b826400843bab85f3d8af1416241bef028bf937 on remove-parallel-shell into 25312dc0846a49ac4daae80b149a924c004dfdce on master.


How to control filename on download

Sorry to post this as an issue but I'm stuck for time time to figure this out. I have everything working ok but my files show up as
http://localhost:3000/cfs/files/seams-files/fj2X9w5eY8tAcXPw5 which is fine except that I want them to download as the file name which is correctly stored in the original object which looks like this
{ createdByTransform: true,
_id: 'fj2X9w5eY8tAcXPw5',
original:
 { name: 'This is a word.docx',
   updatedAt: Fri Jul 03 2015 14:40:57 GMT+0100 (BST),
   size: 22557,
   type: 'application/vnd.openxmlformats-officedocument.wordprocessingml.document' },
uploadedAt: Fri Jul 03 2015 14:44:40 GMT+0100 (BST),
copies: { 'seams-files': [Object] },
collectionName: 'seams-files' },

Unfortunately the file downloads as fj2X9w5eY8tAcXPw5.docx. How can I make it download as 'This is a word.docx'.
Thanks for any suggestions which point me in the right direction
Rob

If you have a link for people to click and start the download, you could have a link tag as:
This is a word.docx
In this way, the browser will download this file as "This is a word.docx".
If you are initiating the start automatically (like many websites), you could create this link by jQuery and start the download like this:
$('').attr({href="http://localhost:3000/cfs/files/seams-files/fj2X9w5eY8tAcXPw5", download="This is a word.docx"}).text("This is a word.docx").click();
The only problem is when people enter the download link directly in the browser, neither of these techniques would work. You would need server code send the correct header to change the download file name. Which unfortunately I don't know how to. I'm currently using Iron Router to provide a customized downloading access point.
Hope this helps!

Thanks @Zodiase

Hi @Zodiase, could you share your code to provide a custom download link?


3.18 compatibility

Hey,
I know there's a ticket for gnome 3.16 compatibility, but 3.18 is out and it doesn't work either D;

As far as I know, it does, and without any actual bug report, there is nothing I or someone else can fix.


Update sources-dist.json

This is the initial integration of the Nuki adapter

The both links here are wrong. The adapter is in your user or ?! :-)

Oh, ja...sorry. Fixed it. Do I have to create a new pull request?

Nope, pushing the fixes here was exactly right


Behat failure: Facebook WebDriver TimeOutException

There's currently a behat failure in the following branches:

4.5
4

The scenario that is failing is archiving a block, but I'm unable to replicate the bug in: elemental 4.x & recipe-cms 4.x
Looks like something to do with the web driver, so I've titled the issue as such.

Covered in https://github.com/silverstripe/silverstripe-elemental/issues/887


Newsletter draft for December 2021

Here's the draft. Please add any events that I missed.

[x] Update PR data on Nov 30
[x] Update contributors data on Nov 30
[x] Flang update from @AlexisPerry
[ ] LFortran update from @certik

Thank you!

PR created for Flang updates: https://github.com/milancurcic/fortran-lang.github.io/pull/2

I don't have the time to write it up for LFortran. If anybody has time to help, I would appreciate it. If not, then let's skip this month.

No problem, I should be able to write it up this afternoon.

@certik see 64e5950310deb3076f36cbff21e7d6e2b7ce9988. I only summarized user-facing changes for brevity. I think this newsletter is ready to go.

I'll go ahead and merge. Thank you all!

@milancurcic thanks Milan! I really appreciate it. It looks great.


Website is not working: Giving 404 error

Is there an existing issue for this?

[X] Yes, I have searched the existing issues and none of them match my problem.

Product Variant
Cloud (http://rxresu.me)
Current Behavior

Expected Behavior
Website should be open clearly
Steps To Reproduce
Open the website https://rxresu.me/
What browsers are you seeing the problem on?
No response
What template are you using?
None
Anything else?
No response

Yes, I'm facing the same issue as well.

Same issue, testing from UK

same issue

Facing same issue from NL

same issue here

Hey folks, sorry for the 404.
It's quite late here, but looking into the issue right now.

Hey folks, sorry for the 404. It's quite late here, but looking into the issue right now.

Could it have anything to do with your recent commit? Or is the server itself at fault?

@cvyl The server is at fault, it keeps maxing out it's specs. Running htop shows the servers have a 100% memory usage almost all day every day. I have a two server Docker Swarm setup for this, and both of them get overwhelmed with requests some times.

It's back online now 🟢
Thank you everyone for the helpful messages and emails, for bringing this to my attention.

@AmruthPillai ah, thank you for clarifying!


Write Documentation for the Contributing to PASS section.

What?
Write Documentation for the Contributing to PASS section.
Why?
This is needed for the PASS Welcome Guide. It is part of a series of sections that explains the why and how of PASS at a non-technical level.
How?
Write the documentation using markdown in a user friendly voice, and follow the PASS Documentation Style Guide in #912.
Acceptance Criteria
Written documentation in markdown and pushed to the new documentation repository.
Related Issues

This needs to be done after #912 and #913.

Add the style guide in this section.


Use Amberdata API

Use Amberdata API as primary data source. This allows us to add tickers for ERC20 tokens that have a presence in the Amberdata market price database.

I sent you a PM about where to get the private API key.

Still it demonstrates the fallback pricing which is obtained from the DAI oracle works fine, in case both the APIs are down.

@JamesSmartCell closes https://github.com/AlphaWallet/alpha-wallet-android/issues/903?

good catch.
Fixes #903 .


chore: setup package

Relevance
We want to move as much amazon handlers out of shop API as possible to avoid dirtying the shop api namespace, to allow possible re-use, and to allow the potential of making this package open source.
Success Measures

add php container (we need for xsd2php and various tests
integrate on ci
add .env and .env (primarily to allow xdebug setup)
add linting
add dopr
add dopr commands to:

fetch the xsd list
build data objects into a temp folder
copy required data objects into a production folder
rename data object validation yml files to serializer specs

add wrapper to get client incidents for:

POST_PRODUCT_DATA
POST_INVENTORY_AVAILABILITY_DATA
POST_PRODUCT_PRICING_DATA
POST_PRODUCT_IMAGE_DATA
POST_PRODUCT_RELATIONSHIP_DATA

closing, wrong source ^^


collect tkn pac repo creation use cases

I’m adding the repo for the first time and want GitHub
I’m adding the repo for the first time and want webhook
I have already added the repo but need to add the webhook again. Why?

cc @siamaksade let us know if there is any other use case to develop


Worker Nodes cannot communicate with API Server

Expected Behavior
After setting up Cloud Infrastructure with Terraform and configuring MicroK8s with Ansible, it should work with calico fine and without errors.
Current Behavior
After setting up Cloud Infrastructure with Terraform and configuring MicroK8s it with Ansible, Calico starts on each node calico-pods but only on the master node the pod gets to the state running . On both worker nodes the pods are looping in killing and creating. If I use kubectl describe pod calico-node-v8x6l -n kube-system I get following output:
  Type     Reason     Age                From               Message
  ----     ------     ----               ----               -------
  Normal   Scheduled  52s                default-scheduler  Successfully assigned kube-system/calico-node-v8x6l to worker-node-1
  Normal   Pulled     52s                kubelet            Container image "docker.io/calico/cni:v3.25.1" already present on machine
  Normal   Created    52s                kubelet            Created container upgrade-ipam
  Normal   Started    52s                kubelet            Started container upgrade-ipam
  Normal   Pulled     21s (x2 over 52s)  kubelet            Container image "docker.io/calico/cni:v3.25.1" already present on machine
  Normal   Created    21s (x2 over 52s)  kubelet            Created container install-cni
  Normal   Started    21s (x2 over 52s)  kubelet            Started container install-cni
  Normal   Pulled     20s                kubelet            Container image "docker.io/calico/node:v3.25.1" already present on machine
  Normal   Created    20s                kubelet            Created container calico-node
  Normal   Started    20s                kubelet            Started container calico-node
  Warning  Unhealthy  2s (x4 over 19s)   kubelet            Readiness probe failed: calico/node is not ready: felix is not ready: Get "http://localhost:9099/readiness": dial tcp [::1]:9099: connect: connection refused
  Warning  Unhealthy  2s                 kubelet            Liveness probe failed: calico/node is not ready: Felix is not live: Get "http://localhost:9099/liveness": dial tcp [::1]:9099: connect: connection refused

If I do kubectl logs calico-node-v8x6l -n kube-system for example then I get:
Defaulted container "calico-node" out of: calico-node, upgrade-ipam (init), install-cni (init)
Error from server: Get "https://<IP_ADDRESS>:10250/containerLogs/kube-system/calico-node-v8x6l/calico-node": dial tcp <IP_ADDRESS>:10250: i/o timeout

Those Problems are only on Worker Nodes, if I do the same commands on the calico node which is located on the master node I get logs and no errors at all.
Possible Solution
I don't know what's going on so I can't tell what a solution could be.
Steps to Reproduce (for bugs)

Create 3 Servers in Hetzner Cloud (2 worker and 1 master all with arm64, 4VCPUs and 8GB RAM)
Configure MicroK8s on nodes with Ansible
Watch Calico Nodes failing

Context
After using Raspberry Pi I wanted to switch to cloud based clusters, and after spinning up those Hetzner Servers and installing microk8s the goal was to configure load balancer and firewall.
Your Environment

Calico version: 3.25.1 (Standard with microK8s)
Orchestrator version (e.g. kubernetes, mesos, rkt): kubernetes client v1.29.2, kubernetes server v1.30.1
Operating System and version: Servers run with Debian 12

@mazdakn I didn't tried the newer versions, because this Calico Version is included in my microk8s installation. With v1.29 od microk8s it get s automatically installed and if I understand it correct there is no possibility to upgrade to a later version, because the installation is with Ansible Commands.
I install the cluster with some Ansible Commands, that configure the standard environment with calico, coredns, docker and more.
If BGP is the standard, then yes I use BGP in my cluster, is there a way to check that?

Error from server: Get "https://<IP_ADDRESS>:10250/containerLogs/kube-system/calico-node-v8x6l/calico-node": dial tcp <IP_ADDRESS>:10250: i/o timeout

This error seems to suggest an issue with Kubernetes itself being able to communicate with the node in order to get logs, not necessarily an issue with Calico (which isn't involved in node->node communication like this).
I'd probably start by verifying that your network enables all nodes to communicate with each other - is there a firewall / security group in your cluster? Does it allow the necessary traffic?

@caseydavenport Yes I got one firewall rule in Hetzner Cloud, but its configured for incoming traffic, not inside the cluster.
I think with Security Group you mean SecurityContext and the installation of microk8s isn't with any security rules at all only some modifications with mode, but here the code for your understanding.
`- name: Install alternative packagemanagement system snapd
ansible.builtin.apt:
name: "{{ item }}"
state: "present"
force_apt_get: "yes"
with_items:
- snapd

name: Cgroup enable in kernal
ansible.builtin.replace:
path: /boot/firmware/cmdline.txt
regexp: '^([\w](?!.\b{{ item }}\b).)$'
replace: '\1 {{ item }}'
with_items:

"cgroup_memory=1"
"cgroup_enable=memory"
when: ansible_default_ipv4.address | ipaddr('ip-adress-range')

name: Disable swap
ansible.builtin.service:
name: dphys-swapfile
state: stopped
enabled: false
when: ansible_default_ipv4.address | ipaddr('<IP_ADDRESS>/24')

name: Install microk8s
community.general.snap:
classic: yes
name:
- microk8s

name: Add all users into the microk8s group
ansible.builtin.user:
name: "{{ ansible_ssh_user }}"
groups: microk8s
append: true

name: Add kubectl alias
ansible.builtin.lineinfile:
create: true
mode: "644"
path: /etc/profile.d/00-aliases.sh
line: "alias kubectl='microk8s kubectl'"
state: present
insertafter: EOF

name: Unconditionally reboot the machine with all defaults
become: true
ansible.builtin.reboot:`

but its configured for incoming traffic, not inside the cluster.

You may need to add rules to your firewall to allow the necessary in-cluster communications between nodes, if it doesn't already allow them. Here's a reference: https://docs.tigera.io/calico/latest/getting-started/kubernetes/requirements#network-requirements

I fixed it with some Firewall Rules. I got one for traffic from outside but forgot the traffic inside the cluster between single nodes. Some internal firewall rules fixed the problem. Thank you for your help an the link.


Homebrew 3.2.10 does not respect HOMEBREW_NO_AUTO_UPDATE=1

brew config output
HOMEBREW_VERSION: 3.2.10
ORIGIN: https://github.com/Homebrew/brew
HEAD: ab2118a402a44451b1d7559167b6956dc47cc19a
Last commit: 2 weeks ago
Core tap ORIGIN: https://github.com/Homebrew/homebrew-core
Core tap HEAD: 073c1b2f9d79dda3c5145782a12105bc086d221f
Core tap last commit: 13 days ago
Core tap branch: master
HOMEBREW_PREFIX: /usr/local
HOMEBREW_CASK_OPTS: []
HOMEBREW_EDITOR: code
HOMEBREW_MAKE_JOBS: 16
HOMEBREW_NO_AUTO_UPDATE: set
Homebrew Ruby: 2.6.3 => /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/bin/ruby
CPU: 16-core 64-bit kabylake
Clang: 12.0.5 build 1205
Git: 2.30.1 => /Applications/Xcode.app/Contents/Developer/usr/bin/git
Curl: 7.64.1 => /usr/bin/curl
macOS: 11.6-x86_64
CLT: <IP_ADDRESS>.9
Xcode: 12.5.1

brew doctor output
Warning: Some installed formulae are deprecated or disabled.
You should find replacements for the following formulae:
  ilmbase

Warning: You have unlinked kegs in your Cellar.
Leaving kegs unlinked can lead to build-trouble and cause formulae that depend on
those kegs to fail to run properly once built. Run `brew link` on these:
  imath
  openexr

Warning: Homebrew's "sbin" was not found in your PATH but you have installed
formulae that put executables in /usr/local/sbin.
Consider setting your PATH for example like so:
  echo 'export PATH="/usr/local/sbin:$PATH"' >> ~/.zshrc

[X] I ran brew update and am still able to reproduce my issue.
[X] I have resolved all warnings from brew doctor and that did not fix my problem.

What were you trying to do (and why)?
I was trying to brew install httpie a library, and it updated every keg I have installed, despite the fact that I have the HOMEBREW_NO_AUTO_UPDATE=1 env variable set.
What happened (include all command output)?
It updated every keg
What did you expect to happen?
The keg I was installing to be installed
Step-by-step reproduction instructions (by running brew commands)
`brew install httpie`

HOMEBREW_NO_AUTO_UPDATE is to do with updating Homebrew itself, not formulae/kegs.
There is no system to autoupdate for every formula/keg in brew itself. There is however https://github.com/Homebrew/homebrew-autoupdate.
However, when installing new formulae or upgrading a specific one, this may sometimes trigger an upgrade for other formulae in the dependency tree. This is due to the nature of ABI compatibility and how the latest version of a formulae is only built and tested with the latest version of its dependencies - not with an arbitrary mixture. This can be large if you haven't upgraded much in quite some time. https://docs.brew.sh/FAQ#why-does-brew-upgrade-formula-also-upgrade-a-bunch-of-other-stuff

The problem is I don't want homebrew to randomly update all my packages when I run brew install. I was under the impression that's what the environment variable does. Is some other way to disable this behavior?

take a look at the documentation for HOMEBREW_NO_INSTALL_UPGRADE, but we don't provide support for using outdated bottles
https://github.com/Homebrew/brew/blob/master/Library/Homebrew/env_config.rb#L267-L270

The problem is I don't want homebrew to update unrelated packages when I run brew install.

This. 100% this. I run Homebrew on my GitHub Actions CI server to install two formulae (CMake and Ninja), but then Homebrew goes and updates seven more formulae, stuff like aws-cli (which I don’t use), adding a solid 3 minutes or more to my build. For me this is just an annoyance since my repo is public, but were this a private  repo, this problem would be costing me money by eating up my expensive Mac build minutes.
I have added export HOMEBREW_NO_INSTALL_UPGRADE=1 in my CI script, to no effect. I am using Homebrew 3.2.12, as installed on GitHub Actions’ macOS hosted runner (documented here). Could you please provide some pointers as to what I am missing here? Thanks!

Sounds like you're actually looking for HOMEBREW_NO_INSTALLED_DEPENDENTS_CHECK.

This should be a global default. Typing brew install [package] and then having homebrew update every other package installed on your system is so far outside of expected behavior and causes all kinds of downstream problems. Please please please disable this behavior by default.

Having broken packages on your system is not a desirable default. It's not true it upgrades everything - only those in the same dependent tree.
Homebrew is an evergreen (rolling release) package manager. That means we only ship the latest version of anything, but this comes at the cost that we also ship ABI breaking updates (which means anything depending on it needs a rebuild or they will simply no longer run at all) which can happen somewhat regularly depending on the formula. If you want this to not happen, you're looking for a package manager that enforces full "freezes" and only does major updates once a year or so. Evergreen package managers target people who upgrade their installed packages often and want the latest (and thus the number upgraded during the dependents check ends up being close to zero).
HOMEBREW_NO_INSTALLED_DEPENDENTS_CHECK exists because we recognise the CI scenario where the broken packages are often ones the developer didn't actually install themselves in the first place.

Yes, what @Bo98 said. If (and when) it was the global default: Homebrew will regularly break unrelated packages instead of upgrading them.
Relatedly, just because you personally don't like this behaviour that's not a good reason for changing the default. We set the defaults based on what works for the majority of our millions of users based on issues reported and error-based analytics. We're not going to move to a default that's known to break installations in many circumstances.

HOMEBREW_NO_AUTO_UPDATE is to do with updating Homebrew itself, not formulae/kegs.

I'm afraid this statement may need at little more detail because HOMEBREW_NO_AUTO_UPDATE may indeed prevent surprise upgrades of formulas.
By default, the brew install [package] command automatically runs brew update --preinstall which will update the formula files located in  Library/Taps/homebrew/homebrew-core before Homebrew proceeds to install [package].
Chances are, however, that some dependencies of [package] were already installed on the system before the user ran the brew install [package] command. Let's refer to those as shared dependencies.
If there are updates available to a shared dependency (e.g. the corresponding .rb file in Library/Taps/homebrew/homebrew-core was updated since the dependency was installed) Homebrew will carry on and upgrade it.
Homebrew will also carry on and upgrade all packages that depend on a shared dependency.
This may lead to a cascade effect and users who are surprised to see existing packages/services ending up in an unusable state after running a seemingly innocent `brew install [package] command. See https://github.com/Homebrew/discussions/discussions/57 for examples of this.
The HOMEBREW_NO_AUTO_UPDATE environment variable changes this behaviour entirely (see [1]) because it stops brew install [package] commands from running brew update --preinstall. As a consequence, shared dependencies are not upgraded, and brew install [package] does not trigger a cascade effect of dependency upgrades.
With HOMEBREW_NO_AUTO_UPDATE the user must run brew update manually (to update Library/Taps/homebrew/homebrew-core) because it is no longer done automatically as part of install/upgrade/etc commands.
Personally, I find this leads to a more stable user experience and this is how I prefer to use Homebrew.

[1] The HOMEBREW_NO_AUTO_UPDATE environment variable prevents brew install [package] from upgrading shared dependencies:
https://github.com/Homebrew/brew/blob/e8ee5b05f9dfd0ec42870810f245d4ea3305845b/Library/Homebrew/brew.sh#L230-L270


More noticabe region color during evil-multiedit

Hi.
Dracula and Catppuccin have similar colors for highlighted words. It is grey.
But unlike Catppuccin, Dracula changes its regions to a more noticeable color during evil-multiedit.

Catppuccin. It is very hard to find the matching words.

Dracula. It is very easy to spot the selected regions.

Hey, yeah this should probably be changed to the same style as the match face with red background and mantle foreground.
Seems evil-multiedit uses the iedit faces, I'll update the title of the issue to reflect that its about adding iedit faces and by extension adding support for evil-multiedit.
The faces iedit-occurrence and iedit-read-only-occurrence, if you want to make a PR, it would be appreciated!


We should be able to run e2e tests against an existing deployment

In order to debug tests and extend the coverage we want to be able to run the e2e test suite against an existing CAA deployment.

nb: wrong repo :)


Custom headers doesn't seem to be working.

Trying to use CloudFlare api to get the users information. Need to send headers with the call and it doesn't seem to work with Alamofire.
override func viewDidLoad() {
    super.viewDidLoad()
    // Do view setup here.
    let manager = Alamofire.Manager.sharedInstance
    // Add API key header to all requests make with this manager (i.e., the whole session)
    manager.session.configuration.HTTPAdditionalHeaders = [
        "X-Auth-Email": "\(passedEmail)",
        "X-Auth-Key": "\(passedApiKey)",
        "Content-Type": "application/json"
    ]
    manager.request(.GET, "https://api.cloudflare.com/client/v4/user")
        .responseJSON { _, _, JSON, _ in
            println(JSON)
    }
}

Is this a bug or am I doing something wrong?

Hi @SwiftFire,
The behavior works correctly. We have tests confirming this. The issue you are running into has been asked and answered many times before. Instead of creating a support issue in Github, please open a question on Stack Overflow and tag Alamofire. The Alamofire community is very helpful and supportive. Stack Overflow is the best place to get your question answered quickly and correctly.
Best of luck.

From our Contribution Guidelines
Asking Questions
We don't use GitHub as a support forum. For any usage questions that are not specific to the project itself, please ask on Stack Overflow instead. By doing so, you'll be more likely to quickly solve your problem, and you'll allow anyone else with the same question to find the answer. This also allows maintainers to focus on improving the project for others.


Call for Play link is dead maybe?

Hi @taylorcate @RJP43
Not sure if this is the right place for this, feel free to delete or what have you :) But Just noticed that on the MUDDLE Wiki page, this link seems to leads to 404 error:
On this page: https://github.com/taylorcate/MUDDLE/wiki
"November 2nd, 2018 - [MUDDLE  #5  FOR PLAY]"(https://github.com/taylorcate/MUDDLE/blob/master/PromotionalMaterials/CFP_MM_11-2.png)
link appears dead. Just FYI :)
xoxo

p.s. I'm sorry I can't remember how to add labels! #mommybrain #oldbroad  And can't find your post telling me about how. #facepalm Arg. #process :)

You are so right, that link is dead. I'll patch it up today! Happens when we're constantly trying to organize our toys 😂 thank you for letting us know!

@nadinejl #eagle{2}ye #bugcatcher -- Thanks, neighbor! :ant::bird:
As for the label inquiry, #mommybrain or not if you were looking to label this issue you won't see the option to. O{I]n this main MUDDLE issues board][backyard only direct "contributors" (@taylorcate and I) can add labels. I will add the appropriate labels now. In the future and as we are formulating a workflow, an editor will add label(s) and assign a reviewer for "creator-created issues". Seriously tho, THANKS again for catching the bug and letting us know - this was the just right place to do so!! :heart_eyes:
Now in regards to labels [...again], since creators contribute in "forkfuls" we leave labels up to you in your backyard. In fact, while we [model|muddle] in our wiki, projects and issues boards, README.md files, repo. tags, and repo. description (:arrow_down:reference image:arrow_down:),

we encourage creators to c{ustomize][reate all of the above on you][thei}r "muddled fork". As we continue to create the MUDDLE model we hope our methods get muddled by watching your muddle grow. :sunflower:
:revolving_hearts:model turns to muddle while muddle turns to model:revolving_hearts:
@nadinejl I am heading over to your backyard soon with an invite to play; meanwhile, I am renaming this issue and inviting other #eagle{2}ye #bugcatcher(s) to point out bugs here! Thanks again (a million times over) for contributing to the #neighBBoard and helping catch bugs!

@RJP43 I love this! Thank you! 🥇☺👏👍💖


Install secret

Fixes  #1121

Why do we have both openapi.yaml and pipeline.yaml. These look the be the same.

The first one is generated by the code generator.


Hack.chat stopped working

Hack.chat website is not working

Yes, even app is also not working...
Please check this ASAP.

it's ok you'll survive without it for a while

Will it come back up?
So sad that it wad down the day I desperately needed it.

Hi,
I don't have time to keep asking my hosting provider to bring it back up. They're getting annoyed as well. If I shut down the server permanently, is there an alternative that I should recommend?

@AndrewBelt nah TC has been down for a while now

Hi , join hack.chat alternative on WhatsApp https://chat.whatsapp.com/290egRfYnu11LwyGqgtsHz

https://vps.unrealsecurity.net
hack.chat  alternative

That whatsapp group is shitty group full of indonesian kids and i joined just to redirect everyone to my HC alt.


ENH: Generalised ufuncs in special

This PR follows the one merged yesterday about overhauling the ufunc machinery. The purpose here is to extend that slightly (and only slightly) so that SciPy special can support generalised ufuncs for some of its existing functions. In particular, I am thinking of all the functions in _specfun.pyx. These include the Legendre polynomials, Airy and Bessel function zeros, and so on. No doubt others will follow.
These functions differ from their counterparts in that their kernels may take arrays as their inputs or outputs. A canonical example is matrix multiplication over stacks of matrices. Here it is a bit simpler, essentially we have special functions that return outputs with one or more additional dimensions. Usually these additional dimensions corrrespond simply to a value n in the input, so we have a function producing an array of shape (n, ...). Currently, these functions in SciPy only work for scalar input, so given a value x the output is an array of size n. But there is no reason to have such a restriction, we could easily be given an array x of shape (d0, ..., dm) and get output of shape (n, d0, ..., dm). Here we introduce such functionality.
This is actually quite a small change. We need to use NumPy's generalised ufunc machinery, namely PyUFunc_FromFuncAndDataAndSignature and pass an appropriate signature. Let's focus on lpn. With the new machinery, this is just:
PyObject *_lpn = SpecFun_NewGUFunc({special::lpn}, 2, "_lpn", "docstring here", "()->(n),(n)");
PyModule_AddObjectRef(_special_ufuncs, "_lpn", _lpn);

Then, at the Cython / Python level, The Legendre polynomials lpn went from:
def lpn(int n, double z):
    """
    Compute Legendre polynomials Pn(x) and their derivatives
    Pn'(x). This is a wrapper for the function 'specfun_lpn'.
    """
    cdef double *ppn
    cdef double *ppd
    cdef cnp.npy_intp dims[1]
    dims[0] = n + 1

    pn = cnp.PyArray_ZEROS(1, dims, cnp.NPY_FLOAT64, 0)
    pd = cnp.PyArray_ZEROS(1, dims, cnp.NPY_FLOAT64, 0)
    ppn = <cnp.float64_t *>cnp.PyArray_DATA(pn)
    ppd = <cnp.float64_t *>cnp.PyArray_DATA(pd)
    specfun_lpn(n, z, ppn, ppd)
    return pn, pd

to:
def lpn(n, z):
    """
    Compute Legendre polynomials Pn(x) and their derivatives
    Pn'(x). This is a wrapper for the function 'specfun_lpn'.
    """

    pn = np.zeros((n + 1,) + np.shape(z), dtype = np.float64)
    pd = np.zeros((n + 1,) + np.shape(z), dtype = np.float64)
    return _lpn(z, out = (pn, pd))

This also has the additional benefit of eliminating the need for Cython in these functions.
The last change is at the C++ level. This one is perhaps mostly for @steppi to check out. We need a very simple struct or class that can act as the C++-equivalent of a view (pointer, shape, and strides). Although there is nothing yet in C++17, that is actually already accepted into later versions of the standard, namely std::span in C++20 and std::mdspan in C++23. Since we only support C++17, we can either create our own versions of these or create another data structure that is equivalent. It is just pointer, shape, and strides. CuPy does exactly the latter.
In this PR I made my own std::span. The Legendre polynomials then become, in C++.
inline void lpn(double x, std::span<double> pn, std::span<double> pd) {
    specfun::lpn(pn.size() - 1, x, pn.data(), pd.data());
}

And the generalised ufunc is published as above.
Putting this here now for thoughts.

Thanks everyone for the comments so far, that's helpful. Just wanted to add some additional context on the std::span.
Because we are dealing with gufuncs, we need something to hold the shape and stride information. Imagine a special function that takes a set of matrices as input, you have to have the shapes and strides to handle the memory appropriately. CuPy realised this, already for several years now, and they have a very simple struct called CArray that does this. You can see it here.
What's also interesting is that C++ has now voted classes like this into the standard, namely std::span and std::mdspan. So they are being standardised. These are its versions of the NumPy views. I am definitely aware and agree it will be several years before we move to C++20 and certainly C++23. But, if we want to use one of these, we can just mock it until then like I've done here.
The question for us is just what simple struct should hold this information. If something is in an upcoming standard, I'm inclined to use that as it represents where things are heading. Otherwise I'd just make a very simple of CuPy's CArray. Here I just tried with std::span because it was quick and indicative of one option.

The question for us is just what simple struct should hold this information. If something is in an upcoming standard, I'm inclined to use that as it represents where things are heading.

If we want to aim towards std::span, we could consider absl::span which is mostly a backport of the C++20 facility to earlier standard modes. Though abseil is not without a substantial share of headaches (i.e. by default its ABI depends on the standard version used to compile; this can be controlled but needs pretty deep involvement of packagers/distributors), so this would have to be weighed very carefully. It would likely be easier to copy CuPy's CArray, but I thought I'd mention it.

I've just pushed another version. I'm exploring the idea of using a very minimal std::mdspan, essentially just CuPy's CArray but written to look like the upcoming std::mdspan. Things we don't need won't be implemented.
In terms of new features, we will now be able to use these function broadcast over their array arguments. Here is lpn working for an array argument x for the first time. To make this happen, really only gufuncs were needed.
import numpy as np

import scipy as sp

x = np.random.uniform(0, 1.0, (5, 10, 3))
l, lp = sp.special.lpn(41, x)

I am having a couple of questions before we end up in the gufunc discussion and not sure if we answered them already;

Did we figure out all ufuncs machinary issues already, if there were any?
Do we need gufuncs on top of the existing ufuncs? Do we have a real performance benefit? We can always do the loop at the C level using NumPy arrays. No C++ complexity needed on top and NumPy also has similar implementations. Many special functions are not exposed to handle higher degrees anyways.
Do we really need to write code that uses C++ standard library? It seems to me that the new C++ code is not bringing any useful abstraction over the boring C code. What does it bring that C cannot? This is a very real concern. There is a large community which is avoiding the std lib code of C++ like the plague because it has not been stable since the last 4 versions of the standard. I tend to agree with that group and situation of std::span and std::mdspan is the easiest examples since mentioned above. Note that we are 7 years from C++17 and there is already two major releases folks cannot switch without major issues.

Just to be clear, this is not a preemptive criticism against C++ however, as a code archive language, we have to be really careful as I have been going over these code for a while now. Code archive value is very important and C++ is changing fast with every compiler bringing new problems. I would caution on not using anything C++ std specific and benefit from its version-to-version established features only. Especially anything we will home-bake will be 100% an issue in just a few years later.
We don't need to rush these decisions. I would instead make sure that we have a stable code base first. Because while we are very enthusiastic now, 5 years later there is no guarantee that we will be here modernizing the code to C++23 which is not a trivial task.

Did we figure out all ufuncs machinary issues already, if there were any?

For ufunc machinery itself, I would say essentially yes. There are no substantial issues remaining. There is an issue of simplifying cython_special so that it doesn't depend on the existing _ufuncs extension (generated with _generate_pyx.py), to avoid code duplication with the new _special_ufuncs extension from #20260 but it's not really related to adding gufuncs. There's also an issue of special.seterr and friends not working when ufuncs are split across multiple extension modules. This was a pre-existing issue and error handling was already not working for ellip_harm2 which is provided by a separate extension module. There is a proposed fix here: https://github.com/scipy/scipy/pull/20321. I don't think these issues have bearing on this proposal to add gufuncs though.

Do we need gufuncs on top of the existing ufuncs? Do we have a real performance benefit? We can always do the loop at the C level using NumPy arrays. No C++ complexity needed on top and NumPy also has similar implementations. Many special functions are not exposed to handle higher degrees anyways.

Doing the loop at the C level using NumPy arrays would work for SciPy, but the goal is to have a library which will work in a wider range of array libraries. We're targeting CuPy now, and hope to eventual provide functions to PyTorch, Jax and more. Also, @izaid has been maintaining gufunc versions of some of the relevant special functions in SciPy for several years now, and I know they are useful for him and others working on similar topics in computational physics.

Do we really need to write code that uses C++ standard library? It seems to me that the new C++ code is not bringing any useful abstraction over the boring C code. What does it bring that C cannot? This is a very real concern. There is a large community which is avoiding the std lib code of C++ like the plague because it has not been stable since the last 4 versions of the standard. I tend to agree with that group and situation of std::span and std::mdspan is the easiest examples since mentioned above. Note that we are 7 years from C++17 and there is already two major releases folks cannot switch without major issues.

The primary reason for relying on the C++ standard library is that it vastly simplifies the process of writing code which will work both in SciPy on CPU and on CUDA.  NVIDIA offers libcudacxx which replicates the C++ standard library. If we write code using the C++ standard library for SciPy, then it typically will just work by swapping in the corresponding things from libcudacxx based on conditional compilation when running on CUDA. I think pasting in a reference implementation of std::mdspan is convenient because mdspan is already implemented in libcudacxx, https://github.com/NVIDIA/libcudacxx/issues/236, so we know we can get this working on both SciPy and CUDA right away.
To address the stability of the C++ standard library, I suspect the subset of the C++ standard library which is also available in libcudacxx will tend to be more stable than other parts of the standard library due to the need for coordination. Perhaps @jrhemstad would have something to say about this.
I appreciate the feedback though @ilayn . The goal is to produce a library of special functions which could be used on a wide range of array libraries on both CPU and GPU. I understand that this has lead us to make decisions which may be seen as suboptimal if we were writing this only for SciPy. I think the benefits of having a common code base for special functions between array libraries outweighs the pain of added complexity in SciPy.  I think having a wider range of dependent packages will help keep bit rot in check, since there will be more stakeholders with an interest in the health of the library. Our eventual goal is that this special function library will be split off into a separate thing that is vendored as a submodule in different places. It's already being vendored (not as a submodule) by CuPy, https://github.com/cupy/cupy/tree/main/cupy/_core/include/cupy/special.

I understand that this has lead us to make decisions which may be seen as suboptimal if we were writing this only for SciPy.

Not at all, I think this is all fantastic work and really gives a big satisfaction of all that horror we went through while translating from F77

I think the benefits of having a common code base for special functions between array libraries outweighs the pain of added complexity in SciPy. I think having a wider range of dependent packages will help keep bit rot in check, since there will be more stakeholders with an interest in the health of the library.

Fully agree. However, CUDA is not also safe from all this instability either. We are talking about a language that does not have a proper complex number implementation. Hence really it is all over the place for numeric work. There are certainly a lot of production grade code written in C++ and I definitely acknowledge their value. But we are not a large domain expert C++ authors like optimization libraries or Nvidia team. Thus at some point this complexity we are introducing will boomerang back to us as a maintainer burden (I'm definitely being pessimistic here, and I realize that).

Our eventual goal is that this special function library will be split off into a separate thing that is vendored as a submodule in different places.

I think this would be great to have indeed. Is there any timeline you have in mind however crude it might be?

@ilayn and @steppi, many thanks for the valuable discussion, I think it is really productive and I appreciate it. I just want to chip in a little.
@ilayn, I agree with you that data structures from the C++ standard should not be part of the numerical algorithms. We're not setting out to do that. The intention really is to keep things as C-like as possible. And here std::mdspan actually helps us achieve this goal. Let me give an example.
This is the Legendre polynomial algorithm originally from specfun. It is C code.
inline void lpn(int n, double x, double *pn, double *pd) {
    int k;
    double p0, p1, pf;
    pn[0] = 1.0;
    pn[1] = x;
    pd[0] = 0.0;
    pd[1] = 1.0;
    p0 = 1.0;
    p1 = x;
    for (k = 2; k <= n; k++) {
        pf = (2.0*k - 1.0)/k*x*p1 - (k - 1.0)/k*p0;
        pn[k] = pf;
        if (fabs(x) == 1.0) {
            pd[k] = 0.5*pow(x, k+1)*k*(k+1);
        } else {
            pd[k] = k*(p1 - x*pf)/(1.0 - x*x);
        }
        p0 = p1;
        p1 = pf;
    }
    return;
}

This is the same algorithm, but using std::mdspan. I currently have this working locally.
void lpn(double x, std::mdspan<double, std::dextents<int, 1>, std::layout_stride> pn,
         std::mdspan<double, std::dextents<int, 1>, std::layout_stride> pd) {
    int n = pn.size() - 1;

    int k;
    double p0, p1, pf;
    pn[0] = 1.0;
    pn[1] = x;
    pd[0] = 0.0;
    pd[1] = 1.0;
    p0 = 1.0;
    p1 = x;
    for (k = 2; k <= n; k++) {
        pf = (2.0 * k - 1.0) / k * x * p1 - (k - 1.0) / k * p0;
        pn[k] = pf;
        if (fabs(x) == 1.0) {
            pd[k] = 0.5 * pow(x, k + 1) * k * (k + 1);
        } else {
            pd[k] = k * (p1 - x * pf) / (1.0 - x * x);
        }
        p0 = p1;
        p1 = pf;
    }
}

The only difference between the functions is in the function signatures, otherwise they are both essentially C code. But, by changing the function signature to use std::mdspan, we have enabled it for arbitrary strided layouts and everything is totally safe. This is very useful for us and other array libraries. And this matters even more for functions involving 2D, 3D, and higher arguments, for instance like the associated Legendre polynomials who have two indices (n and m).
I'm keen on std::mdspan because there is finally a standard version of NumPy's view in C++. And NVIDIA already vendoring it is great.
As for when we will split off special, for us to do that we need to cleanly cut out all the existing Cython. Then I'd be very happy to! And what we are discussing here is a missing part of being able achieve that. Our objective with the recent PRs has been to work out ways to replace the different kinds of functions that are currently in SciPy's special. Things that can be replaced by gufuncs is one of the last, perhaps the last, families that I see.

The only issue I am having unease is this part
void lpn(double x, std::mdspan<double, std::dextents<int, 1>, std::layout_stride> pn,
             std::mdspan<double, std::dextents<int, 1>, std::layout_stride> pd)

not because it is using std::mdspan but its portability with newer compilers or whatever the new canon is with C++. The code by itself is just fine so I don't have any problem with us using it.
Are they (standard committee) going to fiddle with it, will the syntax stay the same, do we need additional flags to keep this working, is it going to play nice with someone using C++23 and linking to this in year 2028 etc.
But anyways let me stop here because it is a bit of a meta issue and diverting your attention to irrelevant stuff. So let's get this in and when all done we can look at the resulting situation a bit better.

The only issue I am having unease is this part
void lpn(double x, std::mdspan<double, std::dextents<int, 1>, std::layout_stride> pn,
             std::mdspan<double, std::dextents<int, 1>, std::layout_stride> pd)

not because it is using std::mdspan but its portability with newer compilers or whatever the new canon is with C++. The code by itself is just fine so I don't have any problem with us using it.
Are they (standard committee) going to fiddle with it, will the syntax stay the same, do we need additional flags to keep this working, is it going to play nice with someone using C++23 and linking to this in year 2028 etc.
But anyways let me stop here because it is a bit of a meta issue and diverting your attention to irrelevant stuff. So let's get this in and when all done we can look at the resulting situation a bit better.

Thanks @ilayn! Sounds good. If we come across a better solution, I'm all ears.
I've just checked in a reference implementation of std::mdspan, exact same as what NVIDIA is using. This will live in our special C++ library and it will exit with it too. In this PR, I shall aim to convert the Legendre polynomials and the associated Legendre polynomials.

Yeah, kokkos could be a solution too. Could you please document how scipy/special/special/mdspan.h was created? It might be easier to just go with a submodule?

Yeah, kokkos could be a solution too. Could you please document how scipy/special/special/mdspan.h was created? It might be easier to just go with a submodule?

Course, done.

I deleted clpn from _specfun.pyx, but it looks like I now get something related to deprecation errors.
scipy/_lib/tests/test_public_api.py:456: in test_private_but_present_deprecation
    getattr(module, attr_name)
        attr       = None
        attr_name  = 'clpn'
        correct_import = <module 'scipy.special' from '/Users/runner/work/scipy/scipy/build-install/lib/python3.11/site-packages/scipy/special/__init__.py'>
        correct_module = None
        import_name = 'scipy.special'
        message    = '`scipy.special.specfun.clpn` is deprecated...'
        module     = <module 'scipy.special.specfun' from '/Users/runner/work/scipy/scipy/build-install/lib/python3.11/site-packages/scipy/special/specfun.py'>
        module_name = 'scipy.special.specfun'
scipy/special/specfun.py:41: in __getattr__
    return _sub_module_deprecation(sub_package="special", module="specfun",
        name       = 'clpn'

I wasn't aware that anything in _specfun.pyx is part of a public API. They are not listed in cython_special, nor elsewhere in the special documentation so far as I can see. Anyone know what's up? Am I deleted to take things out of _specfun.pyx or not?

Yes that is what we mentioned as item 1 in the other PR. The _specfun.pyx exposes a private Python module that is used in the Python API of special, here is the part that it is being used
https://github.com/scipy/scipy/blob/b349725606606bd9adcf26a4c9a0d01e26880298/scipy/special/_basic.py#L2021-L2047
The module is imported at the top
https://github.com/scipy/scipy/blob/b349725606606bd9adcf26a4c9a0d01e26880298/scipy/special/_basic.py#L17
So if you delete a function you also need to modify the module usage across the Python parts

Earlier, specfun was a public module and has some deprecation mechanism over https://github.com/scipy/scipy/blob/main/scipy/special/specfun.py
We currently have SciPy 2.0 as the final date but not sure if we can touch it @lucascolley any thoughts about this one?

Yes that is what we mentioned as item 1 in the other PR. The _specfun.pyx exposes a private Python module that is used in the Python API of special, here is the part that it is being used
https://github.com/scipy/scipy/blob/b349725606606bd9adcf26a4c9a0d01e26880298/scipy/special/_basic.py#L2021-L2047
The module is imported at the top
https://github.com/scipy/scipy/blob/b349725606606bd9adcf26a4c9a0d01e26880298/scipy/special/_basic.py#L17
So if you delete a function you also need to modify the module usage across the Python parts

Thanks @ilayn. Yes, this part I understand and I've already made such modifications in this PR for lpn and clpn.

Earlier, specfun was a public module and has some deprecation mechanism over https://github.com/scipy/scipy/blob/main/scipy/special/specfun.py
We currently have SciPy 2.0 as the final date but not sure if we can touch it @lucascolley any thoughts about this one?

Ok, this is relevant. My intention here is to replace things from _specfun.pyx so they are no longer being used at all in SciPy. I didn't realise it used to be public, so I just need to know where I can delete things out of _specfun.pyx or should just leave the functions there but unused.

We currently have SciPy 2.0 as the final date but not sure if we can touch it @lucascolley any thoughts about this one?

Probably best to ask @h-vetinari .

You are in luck scipy.special.specfun.clpn is set to go away this release anyway so you can just remove it from the __all__ in specfun.py and the test will be happy.
In [1]: from scipy.special.specfun import clpn
<ipython-input-1-e8cd8a8bd59c>:1: DeprecationWarning: `scipy.special.specfun.clpn` is deprecated along with the `scipy.special.specfun` namespace. `scipy.special.specfun.clpn` will be removed in SciPy 1.14.0, and the `scipy.special.specfun` namespace will be removed in SciPy 2.0.0.
  from scipy.special.specfun import clpn

More generally anything that is in scipy.special.specfun that isn't in spipy.special can be removed as they will be deprecated with a similar warning.

Am a little late to the party :-), still am going to ask about a generlization.
Question: is it correct that mdspan is mean to serve for the following use case: given a python ndarray object, wrap its data pointer into a convenient GIL-free (and in general python-free) data structure, which allows at least indexing and in-place modifications?
Such a data structure is required all over scipy, not only in scipy.special gufuncs, and it'd be best to have a sort of best-practices recommendation for all of scipy.
The main thing IMO is the ability to toggle bounds checking at compile time. Does mdspan allow this?
I'd then be happy to use it right away instead of my banausic https://github.com/scipy/scipy/pull/19970/files#diff-1d06e2703e983014d899d2c42544507f537a5c6eebc84ec484cf125eed03e102R50

Am a little late to the party :-), still am going to ask about a generlization. Question: is it correct that mdspan is mean to serve for the following use case: given a python ndarray object, wrap its data pointer into a convenient GIL-free (and in general python-free) data structure, which allows at least indexing and in-place modifications?
Such a data structure is required all over scipy, not only in scipy.special gufuncs, and it'd be best to have a sort of best-practices recommendation for all of scipy. The main thing IMO is the ability to toggle bounds checking at compile time. Does mdspan allow this? I'd then be happy to use it right away instead of my banausic https://github.com/scipy/scipy/pull/19970/files#diff-1d06e2703e983014d899d2c42544507f537a5c6eebc84ec484cf125eed03e102R50

Yes, the answer is yes. In short, std::mdspan is a new class that has been accepted into the C++23 standard. It's purpose is to provide multidimensional array access given a data pointer, shape, and stride information. Yes, it supports indexing and in-place modifications. By default, there is no bounds-checking, but if that's something you want there are ways to customise it.
It is non-owning, so the memory allocation and life cycle is controlled by the user. It is just a pointer, shape, and strides. C++23 won't be widespread for a while yet, but there is a reference implementation of it that we've checked in here. It doesn't use any new language features or anything, it's just a class that has been standardised. The reason why it is important to me is precisely to stop writing custom poor man implementations of what is just an ndarray view in C++.
I've no doubt there are many places where it would be useful! Here @steppi and I are trying to get all the special functions into a compact C++ library, so regardless of what SciPy does we'll need it anyway. Probably you and all the other maintainers could have a much wider discussion about using std::mdspan in SciPy.

By default, there is no bounds-checking, but if that's something you want there are ways to customise it.

Mind showing how?

I think you'd need to customise the AccessorPolicy type in std::mdspan. See here. The default accessor is no bounds checking. If SciPy really needs the bound checking, I can whip up an example.

Probably you and all the other maintainers could have a much wider discussion about using std::mdspan in SciPy.

Would be great to put the implementation up the DAG, so that other submodules can #include it. Ditto for the complex values support BTW :-).

I think that needs to be something that the maintainers do. Obviously I see the need! For the special work here, we need a copy ourselves anyway.

Since I was pinged here, I thought folks might like to know that libcudacxx's cuda::std::mdspan and cuda::std::span implementations are conforming and backported to work in C++14. We did this specifically for situations like these where users what to take advantage of these types before they can migrate to newer C++ Standard versions.
There is nothing CUDA specific about them and they work with normal C++ compliers like clang/gcc/msvc.

Right, this is ready for the review. Here's the deal.
I've translated three functions, namely the Legendre polynomials lpn for real or complex arguments, the associated Legendre polynomials lpmn, and the associated Legendre polynomials for complex arguments clpmn. They all now have a corresponding gufunc. As discussed and shown above, there are still Python (not Cython) functions that allocate the output arrays based on the arguments n and m. Then the gufunc gets called. This enables 1) broadcasting over arbitrary inputs and 2) removal of all Cython for these functions. Both big wins, I think.
I don't intend to translate any other functions in this PR. This was really to establish the gufunc pattern and get it ready to use for the remaining functions. I'm optimistic we're now in a very solid position to easily translate all functions in special, groups at a time.
cc @steppi

Very cool @izaid. I'll start taking a look at this once I'm through with the Windows debugging for https://github.com/scipy/scipy/pull/20321. Thanks @jrhemstad, it's really cool you backported that. It'll be very helpful when we try to get these running on CuPy.

(it might be worth adding the pre-commit hook to automatically lint on commits with cp tools/pre-commit-hook.py .git/hooks/pre-commit (http://scipy.github.io/devdocs/dev/contributor/pep8.html#pep8-and-scipy))

I've added lqn and lqmn too, in order to complete all things Legendre.

I've added lqn and lqmn too, in order to complete all things Legendre.

Awesome!

FYI: https://github.com/scipy/scipy/issues/20334 is an issue to discuss the adoption of std::mdspan like behaviours. Could we please move any discussion about them to there?

@steppi Have addressed all comments so far.

I kept the scalar checks on all the gufunced functions and left their docstrings alone.

I'm perfectly fine adding the gufunced versions now honestly. It's not going to break the scalar case and it's not like a release is imminent. I can add the tests in a follow up if you like.

I kept the scalar checks on all the gufunced functions and left their docstrings alone.

I'm perfectly fine adding the gufunced versions now honestly. It's not going to break the scalar case and it's not like a release is imminent. I can add the tests in a follow up if you like.

Done and committed, with the docstrings change to reflect they can take arrays. If you want to add the tests in a follow-up PR, happy with that.

While writing tests just to check that the output shapes are correct. I've discovered that
lqmn(3, 8, [[2.0, 2.0], [2.0, -1.0]])

results in a segfault
malloc(): invalid size (unsorted)
Aborted (core dumped)

I'm going to debug it @izaid. I think it's important that I can debug and maintain this code on my own if needed.

While writing tests just to check that the output shapes are correct. I've discovered that
lqmn(3, 8, [[2.0, 2.0], [2.0, -1.0]])

results in a segfault
malloc(): invalid size (unsorted)
Aborted (core dumped)

I'm going to debug it @izaid. I think it's important that I can debug and maintain this code on my own if needed.
Update: it seems if z is any array with more than one element, at least one of which is -1.0, then lqmn segfaults.

Good find! I see the error. In the non-complex lqmn, you see some lines at the top like
        for (i = 0; i < (m + 1); i++) {
            for (j = 0; j < (n + 1); j++) {
                qm(j, i) = 1e300;
                qd(j, i) = 1e300;
            }
        }

Switch i and j in the indices, so that it is qm(i, j) and qd(i, j). My bad in the translation from pointer indexing.

I've pushed the tests that just check output shape. I saw some failures when running the full test suite, including slow tests that don't run in CI,
python dev.py test -t scipy.special.tests -m full

scipy/special/tests/test_mpmath.py:1740: in clpnm
    return sc.clpmn(m.real, n.real, z, type=3)[0][-1,-1]
        m          = 0j
        n          = 0j
        z          = (-2-1000j)
scipy/special/_basic.py:1860: in clpmn
    p = np.empty((mp + 1, n + 1) + z.shape, dtype=np.complex128)
E   TypeError: 'numpy.float64' object cannot be interpreted as an integer
        m          = 0.0
        m_sign     = 1
        mp         = 0.0
        n          = 0
        type       = 3
        z          = array(-2.-1000.j)
=================================== short test summary info ===================================
FAILED scipy/special/tests/test_mpmath.py::TestSystematic::test_legenp - TypeError: 'numpy.float64' object cannot be interpreted as an integer
FAILED scipy/special/tests/test_mpmath.py::TestSystematic::test_legenp_complex_2 - TypeError: 'numpy.float64' object cannot be interpreted as an integer
FAILED scipy/special/tests/test_mpmath.py::TestSystematic::test_legenp_complex_3 - TypeError: 'numpy.float64' object cannot be interpreted as an integer

It's because previously, lpmn, clpmn, and lqmn allowed for non integer m and n and casted the values to int. I'm not sure this behavior is desirable, but it would require a deprecation cycle to change, so we'd better keep it here.

I've pushed the tests that just check output shape. I saw some failures when running the full test suite, including slow tests that don't run in CI,
python dev.py test -t scipy.special.tests -m full

scipy/special/tests/test_mpmath.py:1740: in clpnm
    return sc.clpmn(m.real, n.real, z, type=3)[0][-1,-1]
        m          = 0j
        n          = 0j
        z          = (-2-1000j)
scipy/special/_basic.py:1860: in clpmn
    p = np.empty((mp + 1, n + 1) + z.shape, dtype=np.complex128)
E   TypeError: 'numpy.float64' object cannot be interpreted as an integer
        m          = 0.0
        m_sign     = 1
        mp         = 0.0
        n          = 0
        type       = 3
        z          = array(-2.-1000.j)
=================================== short test summary info ===================================
FAILED scipy/special/tests/test_mpmath.py::TestSystematic::test_legenp - TypeError: 'numpy.float64' object cannot be interpreted as an integer
FAILED scipy/special/tests/test_mpmath.py::TestSystematic::test_legenp_complex_2 - TypeError: 'numpy.float64' object cannot be interpreted as an integer
FAILED scipy/special/tests/test_mpmath.py::TestSystematic::test_legenp_complex_3 - TypeError: 'numpy.float64' object cannot be interpreted as an integer

It's because previously, lpmn, clpmn, and lqmn allowed for non integer m and n and casted the values to int. I'm not sure this behavior is desirable, but it would require a deprecation cycle to change, so we'd better keep it here.

Yes,  not really ideal to allow floats as input for m and n. I saw some of this too at some point. I agree our strategy should be leave it as is, while we sort out the special function implementations underneath.

Great work! Do the docs need to be updated here in the API reference?

Great work! Do the docs need to be updated here in the API reference?

Indeed they do. Good catch @dschmitz89!

Aside from the licensing issue, I quite like where this is going. Thanks for all the hard work on this!

您的邮件我已收到，我会加班加点的看完您珍贵的来信，尽快给您回复的！谢谢啦！陈鑫

@izaid, do you plan to shelve this until we hear back from Kokkos about licensing? If you want to keep adding new functions in this branch, make sure to add simple tests like we did for the Legendre functions. Also, you still need to address @dschmitz89 comment about the docs. Let me know if you want me to do any of this stuff for you.

Indeed, noted! Though I've added the Ricatti-Bessel functions, I haven't changed their external behaviour in this PR. They still only take scalars. I just removed them from needing Cython bindings. We'll open them to arrays in a future PR, at which point new tests can be added.
@steppi How should I update the docs? What file will I find that?

@steppi How should I update the docs? What file will I find that?

https://github.com/scipy/scipy/blob/bb92c8014e21052e7dde67a76b28214dd1dcb94a/scipy/special/__init__.py#L475-L476

@dschmitz89 Docs updated, thanks for catching it! This is done otherwise, I don't intend to make any more changes to it.
I think @steppi will add a comment regarding the license.

After some discussion @izaid and I have determined that the old BSD licensed mdspan isn't really satisfactory, and it would require some work on our part to make it useful in the way we want. @izaid submitted an issue here, https://github.com/kokkos/mdspan/issues/321, asking for re-licensing of kokkos/mdspan. In the meantime, I found this answer on stackoverflow, https://opensource.stackexchange.com/questions/11556/can-i-use-apache-2-0-licensed-project-inside-my-bsd-3-clause-licensed-project, with this piece of information:
When you are not modifying Apache-2.0 covered code but are merely distributing unmodified copies, then things are simpler. Different scenarios:
A Git submodule is not a copy but merely a link. I don't think that adding an Apache-2.0 covered submodule would trigger any license obligations.
I've seen that the MIT licensed CuPy vendors the Apache2 licensed cccl library suite from NVIDIA as a submodule: https://github.com/cupy/cupy/tree/main/third_party. cccl contains a copy of kokkos/mdspan.h. Is this something that would work for SciPy? Or would it place restrictions on SciPy can be packaged?

A Git submodule is not a copy but merely a link.

This is irrelevant. We distribute source and binary tarballs with the code actually included. That we manage our development environments with git submodules doesn't matter to the analysis.

This is irrelevant. We distribute source and binary tarballs with the code actually included. That we manage our development environments with git submodules doesn't matter to the analysis.

Thanks @rkern. That's what I would have expected. I saw that CuPy distributes wheels, https://docs.cupy.dev/en/stable/install.html#installing-cupy-from-pypi, so thought perhaps they knew something I didn't.

Huh, it also looks like CuPy includes Apache 2 code, directly in its repository: https://github.com/cupy/cupy/blob/a834f040024519f9cf345a1161a3132ae3e30553/cupy/_core/include/cupy/complex/math_private.h.

Right, I've gone ahead and replaced the kokkos mdspan with my own mdspan. This solves the licensing problem. It's clearly different, the kokkos one being thousands of lines and mine being ~150 lines.
Long term, would be great to use the kokkos reference implementation, but at the licensing question can progress independently.
Will now just do some clean up and fixes regarding rebasing, then done.
cc @steppi @rgommers

This be done.

For the mypy failure, I think we just need an entry in https://github.com/scipy/scipy/blob/main/mypy.ini for scipy.special._gufuncs

@rgommers, do you think is OK now merge now that @izaid has (hopefully temporarily) replaced kokkos mdspan with his own minimal implementation? I don’t want to merge this with a blocking review.

The CI failure is unrelated, although I don't know why it's suddenly appearing everywhere.

CI is green, this is done. Would be great to merge, the blocking review was due to licensing, addressed by me writing our own mdspan to sort us out in the interim.

I've seen that the MIT licensed CuPy vendors the Apache2 licensed cccl library suite from NVIDIA as a submodule: https://github.com/cupy/cupy/tree/main/third_party. cccl contains a copy of kokkos/mdspan.h. Is this something that would work for SciPy? Or would it place restrictions on how SciPy can be packaged?

Thanks @rkern. That's what I would have expected. I saw that CuPy distributes wheels, https://docs.cupy.dev/en/stable/install.html#installing-cupy-from-pypi, so thought perhaps they knew something I didn't.

CCCL is on Apache 2.0 with LLVM exception and CuPy is on MIT, there's no issue in CuPy vendoring CCCL (confirmed with NVIDIA legal) as both are compatible, and CuPy does not have the GPLv2 concern as SciPy does.
If the license discussion (#20396) works out, I would encourage SciPy to consider using cuda::std::span from CCCL::libcudacxx, which works on both host and device universally.
(cc: CCCL lead @jrhemstad for vis)