Init app support + standard .gitingore

Fixes #24
Adds support for init_app flask extension style - More details in #24

@alexchamberlain (or anyone at @bloomberg-oss): is there any chance of this getting merged sometime soon? I'm interested in using this library on a project that uses the flask factory pattern and this would be super helpful. Thanks!

Apologies for the slow response here - I have updated my notification settings, so that I get notifications from the bloomberg org to my bloomberg address, so hopefully, I'll be more responsive.
On the code itself, I think it looks great - thanks for taking the time to make the change. I've posted 1 additional commit that uses a property instead of a setter. @sergioisidoro Is that OK with you?
On .gitignores, I'll be honest - I'm not a massive fan. I encourage people to use a global .gitignore, especially for editor-specific files. What do you think?

See also https://github.com/bloomberg/python-github-webhook/pull/20 for .gitignore, limited to only those files generated by the repo.

Hi @alexchamberlain.
Yes, of course. Actually that was a TIL, because I've never used that @xx.setter pattern and it looks interesting.
On the .gitignore matter, I have multiple python projects in my local machine, and so the gitignore may vary from project to project (eg. some projects might have the coverage of the latest branch stored in the git). So I'm not a big fan of global gitignores.
This .gitignore is the standard provided by github (https://github.com/github/gitignore/blob/master/Python.gitignore), and I've had no issues with it. But if you feel like #20 makes more sense, go ahead :)

Released as 1.0.4


Essex:New York

ArcIMS
http://rpts-web.co.essex.ny.us/rpts/website/essexcountygispublic/

We have a statewide layer - I support source duplication but going to close for now unless someone wants to go after this.


118

following https://github.com/conda-forge/cudatoolkit-feedstock/pull/83

Checklist

[ ] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

Will ask. Thanks for the feedback! 🙏


flutter build takes forever to build ios app giving me an error TARGET_BUILD_DIR

Is there an existing issue for this?

[X] I have searched the existing issues
[X] I have read the guide to filing a bug

Steps to reproduce
Just updated flutter to 3.7.7 and basically nothing much, it run well on xcode but in vscode , it will take forever to compile and in the end i get the error Xcode build is missing expected TARGET_BUILD_DIR build setting. Could not build the precompiled application for the device.
Actual results
I mean it just doesn't compile
Logs

Logs

Launching lib/main.dart on Pannam 10.5 in debug mode...
main.dart:1
Signing iOS app for device deployment using developer identity: "Apple Development<EMAIL_ADDRESS>(ZW5F8V79HK)"
Xcode build done.                                           102.0s
Xcode build is missing expected TARGET_BUILD_DIR build setting.
Could not build the precompiled application for the device.

Error launching application on Pannam 10.5.
Exited

Flutter Doctor output
Doctor summary (to see all details, run flutter doctor -v):
[!] Flutter (Channel stable, 3.7.7, on macOS 12.6.3 21G419 darwin-x64, locale en-US)
! Warning: dart on your path resolves to /usr/local/Cellar/dart/2.17.6/libexec/bin/dart, which is not inside your current Flutter SDK checkout at
/Users/pannam/flutter. Consider adding /Users/pannam/flutter/bin to the front of your path.
[✓] Android toolchain - develop for Android devices (Android SDK version 33.0.0)
[✓] Xcode - develop for iOS and macOS (Xcode 14.2)
[✓] Chrome - develop for the web
[✓] Android Studio (version 2022.1)
[✓] VS Code (version 1.76.2)
[✓] Connected device (3 available)
[✓] HTTP Host Availability
! Doctor found issues in 1 category.
pannam@pannams-MacBook-Pro fly_nepal %

how u solve this problem?

I may have upgrade flutter. Unsure how I fixed it..try reinstall ur ide (vscode) then upgrade to a stalled version.


Error submitting metrics with async api client

Describe the bug
When using the Datadog API async client, an error occurs when submitting metrics data:
HTTP response body: Payload is not in the expected format: invalid character 's' looking for beginning of value
Exact same metrics data can be successfully submitted using the non-async client.
To Reproduce
The following code (adapted from the async example in the README) will reproduce the error:
from datadog_api_client.v1 import AsyncApiClient, Configuration
from datadog_api_client.v1.api.metrics_api import MetricsApi
from datadog_api_client.v1.model.metrics_payload import MetricsPayload
from datadog_api_client.v1.model.point import Point
from datadog_api_client.v1.model.series import Series

try:
    body = MetricsPayload(
        series=[
            Series(
                metric="system.load.1",
                type="gauge",
                points=[Point([datetime.now().timestamp(), 2.1])],
                tags=["test:ExampleSubmitmetricsreturnsPayloadacceptedresponse"],
            )
        ]
    )

    configuration = Configuration()
    async with AsyncApiClient(configuration) as api_client:
        api_instance = MetricsApi(api_client)
        response = await api_instance.submit_metrics(body=body)
        print(response)

except BaseException as ex:
    logger.exception('Error submitting metrics to datadog: {}', ex)

Error response:
datadog_api_client.v1.exceptions.ApiException: (400)
Reason: Bad
HTTP response headers: HttpHeaders({'Date': 'Fri, 08 Apr 2022 20:26:30 GMT', 'Content-Type': 'text/plain; charset=utf-8', 'Content-Length': '91', 'Connection': 'keep-alive', 'x-content-type-options': 'nosniff', 'strict-transport-security': 'max-age=15724800;', 'content-security-policy': "frame-ancestors 'self'; report-uri https://logs.browser-intake-datadoghq.com/api/v2/logs?dd-api-key=pube4f163c23bbf91c16b8f57f56af9fc58&dd-evp-origin=content-security-policy&ddsource=csp-report&ddtags=site%3Adatadoghq.com", 'x-frame-options': 'SAMEORIGIN'})
HTTP response body: Payload is not in the expected format: invalid character 's' looking for beginning of value

Expected behavior
Request should succeed and metrics data should be available in the DataDog metrics explorer. (Like it is when making the request with the non-async client.)
Screenshots
If applicable, add screenshots to help explain your problem.
Environment and Versions (please complete the following information):
Linux with Python v3.8.10 and  datadog-api-client = {extras = ["async"], version = "^1.10.0"}
Additional context
After looking at the differences between the non-async and async API clients, I noticed that it appears the async client never actually serializes the provided body data.
For reference, the non-async client does it here, but I did not see similar code for the async client.

Thanks for the report, reproduced. We're indeed missing the serialization step in the async case. I'll fix it, sorry for the troubles.

My original bug report had a small mistake, for the body I used a plan dictionary, but if I follow the examples for the non-async client I should be sending a MetricsPayload object:
    body = MetricsPayload(
        series=[
            Series(
                metric="system.load.1",
                type="gauge",
                points=[Point([datetime.now().timestamp(), 2.1])],
                tags=["test:ExampleSubmitmetricsreturnsPayloadacceptedresponse"],
            )
        ]
    )

But for some reason the MetricsPayload object is not serializable to json, but I don't understand why since I thought that's what the non-async client is actually doing?

Ok, I found the problem looks like I needed to call body.to_dict() first before serializing to json. That must be done by one of the intermediate layers in the client.


pull v1.0 into main

omg the new app is out.


Add download for PA Chester and Montgomery counties

[ ] Send confirmation email to Nichole and Emma
[ ] Setup Okta accounts for Nicole Rafalko<EMAIL_ADDRESS>and Crowley, Emma<EMAIL_ADDRESS>[ ] Setup Okta groups for Montgomery and Chester
[ ] Setup a feed for each with the STRAC schema
[ ] Run past STRAC through to generate downloads

Done


Move version number for maven-dependency-plugin out into a variable s…

…o we can also use it in the reporting section
Currently, when running for instance mvn versions:display-dependency-updates, I get several error messages saying that the plugin lacks a version number. Unfortunately it looks like plugins in the reporting section doesn't pick up version numbers from dependencyManagement, so I've added a property to keep it in one place. The warning went away, and we are able to keep the version number consistent, but I'm not too happy with this workaround, so if anyone has a better idea feel free to let me know.

My suggestion is to add a declaration of any reporting plugin to the pluginManagement section, then you can remove the repeated version from the reporting section.  Maven 3 will resolve Reporting plugins the same way as build plugins.

Ok, I went back and double-checked this now.
It appears that the warnings I got were wrong and fixed in a later maven release (I was running 3.0.5). See the https://issues.apache.org/jira/browse/MSITE-443?focusedCommentId=14451732&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14451732 and the next comment.
I experimented with reverting my changes and it indeed looks like it picks up the version number when running the maven commands, even though it seems to have problems adding the version number to the effective POM. In summary, I believe this pull request would only offer added complexity, so I no longer think it should be merged.
Note though, the comment above the one I linked to, where someone had problems with getting the version number from pluginManagement to apply in the reporting section. I'm fairly sure I ran into similar issues when I first experimented, and that's why (initially most) some plugin version numbers are placed in properties. Things seems to have been cleaned up a bit since I last touched this part, so it might be easier ways to do this now.


Allow specifying the Helm Chart's imagePullPolicy in values.yaml

Hello,
We deploy Kubernetes clusters programmatically, and part of the use case that we support is air-gapped (that is, without Internet access). The Helm Chart deploys several pods and daemonsets, among which are calico-node and csi-node-driver. Would it be possible to specify the pull policy of the aforementioned pods/daemonsets? Otherwise, as soon as we add a second node to the cluster, the daemonsets are brought up, and since we still haven't had time to push the images, they are downloaded from the Internet.
Current Behavior
You can't change the image pull policy unless you modify the yamls, and even then you can only override tigera-operator.
Possible Solution
Provide the following option:
- name: tigera-operator
   imagePullPolicy: IfNotPresent

and similar for other pods/daemonsets, or potentially one option for all of them.
Your Environment

Calico version: 3.24.5
Orchestrator version (e.g. kubernetes, mesos, rkt): K3s
Operating System and version: Red Hat 8.6
Link to your project (optional):

+1 from me, I've wanted support for this in the operator for some time.


Fix #180

This fixes problems building on OSX without the single.hpp.
Additionally, I made single.py always use / instead of \.

Rebased with develop branch.


libextobjc's onExit macro conflicts with Cocos2D library

Would it be possible to rename the onExit macro to something a little less common? Say onExitScope  or something similar? At present it conflicts with at least the Cocos2D library which has an onExit method that is heavily used in Cocos2D applications.

Took me forever to figure out what was going on! Changed it to ext_onExit in my personal cocos2d project


Blank login popup

Master branch has a bug causing appear blank dropdown menu when clicking on Login button.

@elnurvl  Just wanted to ask about that too. :+1:

Yep it's due to a problem with react-bootstrap, see #1463.
Anyway, I'm about to merge devel in master, that won't a problem anymore 🗡
Thanks for reporting!


Issue when we set more than 1 replicas of operator

Using HA setup described in doc https://github.com/aerospike/aerospike-kubernetes-operator/wiki/Deploy-operator, when we apply the configuration proposed, there is sometimes error reported:
"deploy/samples/dim_nostorage_cluster_cr.yaml": Internal error occurred: failed calling webhook "aerospikeclusters.aerospike.com": Post https://aerospike-cluster-webhook.aerospike.svc:443/admission/reviews/aerospikeclusters/mutating?timeout=30s: dial tcp ip:443: connect: connection refused

Assumption that this is related to the kubernetes service when it's route traffic to the subscriber pod.
If you retry few times configuration will be eventually applied.

Hi @vasilievip,
We have tried to reproduce the problem, but have not been able to in our testing with >1 replicas of the operator on GKE and EKS.  If you can provide more details, we will test with your specific configuration.

hello @sherylsage, I will add our configurations, and how to reproduce this situation
The version of our K8S cluster
kubectl get no
NAME                       STATUS   ROLES    AGE   VERSION
sandbox-k8s-dp-master-01   Ready    master   13h   v1.19.7

Operator specs
apiVersion: apps/v1
kind: Deployment
metadata:
  name: aerospike-kubernetes-operator
  namespace: aerospike
spec:
  replicas: 3
  selector:
    matchLabels:
      name: aerospike-kubernetes-operator
  template:
    metadata:
      labels:
        name: aerospike-kubernetes-operator
    spec:
      serviceAccountName: aerospike-kubernetes-operator
      containers:
        - name: aerospike-kubernetes-operator
          image:  docker-hub.artifactory.playticorp.com/aerospike/aerospike-kubernetes-operator:v0.0.12-beta
          command:
          - aerospike-kubernetes-operator
          imagePullPolicy: Always
          ports:
          - containerPort: 8443
          env:
          - name: WATCH_NAMESPACE
            value: aerospike
            # Use below value for watching multiple namespaces by operator
            # value: aerospike,aerospike1,aerospike2
          - name: POD_NAME
            valueFrom:
              fieldRef:
                fieldPath: metadata.name
          - name: OPERATOR_NAME
            value: "aerospike-kubernetes-operator"
          - name: LOG_LEVEL
            value: debug

When we applied configurations, we often see this situation. Sometimes configuration is successfully applied, but sometimes we have an error.
root@sandbox-k8s-dp-master-01:/home/eartemenko/aerospike-kubernetes-operator# kubectl apply -f deploy/samples/dim_nostorage_cluster_cr.yaml
Error from server (InternalError): error when creating "deploy/samples/dim_nostorage_cluster_cr.yaml": Internal error occurred: failed calling webhook "aerospikeclusters.aerospike.com": Post "https://aerospike-cluster-webhook.aerospike.svc:443/admission/reviews/aerospikeclusters/mutating?timeout=30s": dial tcp <IP_ADDRESS>:443: connect: connection refused
root@sandbox-k8s-dp-master-01:/home/eartemenko/aerospike-kubernetes-operator# kubectl get po -n aerospike -o wide
NAME                                             READY   STATUS    RESTARTS   AGE   IP              NODE                       NOMINATED NODE   READINESS GATES
aerospike-kubernetes-operator-7c8595d8cb-8cdkk   1/1     Running   0          13m   <IP_ADDRESS>    sandbox-k8s-dp-worker-03   <none>           <none>
aerospike-kubernetes-operator-7c8595d8cb-lzg8q   1/1     Running   0          14m   <IP_ADDRESS>   sandbox-k8s-dp-worker-01   <none>           <none>
aerospike-kubernetes-operator-7c8595d8cb-mntjr   1/1     Running   0          14m   <IP_ADDRESS>   sandbox-k8s-dp-worker-02   <none>           <none>
root@sandbox-k8s-dp-master-01:/home/eartemenko/aerospike-kubernetes-operator# kubectl get svc -n aerospike -o wide
NAME                                    TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)             AGE   SELECTOR
aerospike-cluster-webhook               ClusterIP   <IP_ADDRESS>   <none>        443/TCP             19m   name=aerospike-kubernetes-operator
aerospike-kubernetes-operator-metrics   ClusterIP   <IP_ADDRESS>    <none>        8383/TCP,8686/TCP   17m   name=aerospike-kubernetes-operator
root@sandbox-k8s-dp-master-01:/home/eartemenko/aerospike-kubernetes-operator# kubectl apply -f deploy/samples/dim_nostorage_cluster_cr.yaml
aerospikecluster.aerospike.com/aerocluster created
root@sandbox-k8s-dp-master-01:/home/eartemenko/aerospike-kubernetes-operator# kubectl apply -f deploy/samples/dim_nostorage_cluster_cr.yaml
aerospikecluster.aerospike.com/aerocluster configured
root@sandbox-k8s-dp-master-01:/home/eartemenko/aerospike-kubernetes-operator# kubectl apply -f deploy/samples/dim_nostorage_cluster_cr.yaml
aerospikecluster.aerospike.com/aerocluster configured
root@sandbox-k8s-dp-master-01:/home/eartemenko/aerospike-kubernetes-operator# kubectl apply -f deploy/samples/dim_nostorage_cluster_cr.yaml
Error from server (InternalError): error when applying patch:
{"spec":{"aerospikeConfig":{"logging":[{"any":"info","clustering":"debug","name":"/var/log/aerospike/aerospike.log"}]},"storage":{"volumes":[{"path":"/opt/aerospike","sizeInGB":3,"storageClass":"thin-disk","volumeMode":"filesystem"}]}}}
to:
Resource: "aerospike.com/v1alpha1, Resource=aerospikeclusters", GroupVersionKind: "aerospike.com/v1alpha1, Kind=AerospikeCluster"
Name: "aerocluster", Namespace: "aerospike"
for: "deploy/samples/dim_nostorage_cluster_cr.yaml": Internal error occurred: failed calling webhook "aerospikeclusters.aerospike.com": Post "https://aerospike-cluster-webhook.aerospike.svc:443/admission/reviews/aerospikeclusters/validating?timeout=30s": dial tcp <IP_ADDRESS>:443: connect: connection refused
root@sandbox-k8s-dp-master-01:/home/eartemenko/aerospike-kubernetes-operator# kubectl apply -f deploy/samples/dim_nostorage_cluster_cr.yaml
aerospikecluster.aerospike.com/aerocluster configured
root@sandbox-k8s-dp-master-01:/home/eartemenko/aerospike-kubernetes-operator# kubectl apply -f deploy/samples/dim_nostorage_cluster_cr.yaml
aerospikecluster.aerospike.com/aerocluster configured
root@sandbox-k8s-dp-master-01:/home/eartemenko/aerospike-kubernetes-operator# kubectl apply -f deploy/samples/dim_nostorage_cluster_cr.yaml
aerospikecluster.aerospike.com/aerocluster configured
root@sandbox-k8s-dp-master-01:/home/eartemenko/aerospike-kubernetes-operator# kubectl apply -f deploy/samples/dim_nostorage_cluster_cr.yaml
aerospikecluster.aerospike.com/aerocluster configured
root@sandbox-k8s-dp-master-01:/home/eartemenko/aerospike-kubernetes-operator# sleep 60
root@sandbox-k8s-dp-master-01:/home/eartemenko/aerospike-kubernetes-operator# kubectl apply -f deploy/samples/dim_nostorage_cluster_cr.yaml
aerospikecluster.aerospike.com/aerocluster configured
root@sandbox-k8s-dp-master-01:/home/eartemenko/aerospike-kubernetes-operator# kubectl apply -f deploy/samples/dim_nostorage_cluster_cr.yaml
aerospikecluster.aerospike.com/aerocluster configured
root@sandbox-k8s-dp-master-01:/home/eartemenko/aerospike-kubernetes-operator# kubectl apply -f deploy/samples/dim_nostorage_cluster_cr.yaml
aerospikecluster.aerospike.com/aerocluster configured
root@sandbox-k8s-dp-master-01:/home/eartemenko/aerospike-kubernetes-operator# kubectl apply -f deploy/samples/dim_nostorage_cluster_cr.yaml
aerospikecluster.aerospike.com/aerocluster configured
root@sandbox-k8s-dp-master-01:/home/eartemenko/aerospike-kubernetes-operator# kubectl apply -f deploy/samples/dim_nostorage_cluster_cr.yaml
Error from server (InternalError): error when applying patch:
{"spec":{"aerospikeConfig":{"logging":[{"any":"info","clustering":"debug","name":"/var/log/aerospike/aerospike.log"}]},"storage":{"volumes":[{"path":"/opt/aerospike","sizeInGB":3,"storageClass":"thin-disk","volumeMode":"filesystem"}]}}}
to:
Resource: "aerospike.com/v1alpha1, Resource=aerospikeclusters", GroupVersionKind: "aerospike.com/v1alpha1, Kind=AerospikeCluster"
Name: "aerocluster", Namespace: "aerospike"
for: "deploy/samples/dim_nostorage_cluster_cr.yaml": Internal error occurred: failed calling webhook "aerospikeclusters.aerospike.com": Post "https://aerospike-cluster-webhook.aerospike.svc:443/admission/reviews/aerospikeclusters/mutating?timeout=30s": dial tcp <IP_ADDRESS>:443: connect: connection refused

How we reproduce this issue by 100%
1  Delete selector spec in aerospike-cluster-webhook service
# Service for webhook
apiVersion: v1
kind: Service
metadata:
  name: aerospike-cluster-webhook
  namespace: aerospike
spec:
  ports:
    - port: 443
      # Can be the name of port 8443 of the container
      targetPort: 8443

Manually create EP without pod which is master in our case it's pod with IP <IP_ADDRESS>

kubectl get po -n aerospike  -o wide
NAME                                             READY   STATUS    RESTARTS   AGE    IP              NODE                       NOMINATED NODE   READINESS GATES
aerospike-kubernetes-operator-7c8595d8cb-8cdkk   1/1     Running   0          98m    <IP_ADDRESS>    sandbox-k8s-dp-worker-03   <none>           <none>
aerospike-kubernetes-operator-7c8595d8cb-lzg8q   1/1     Running   0          100m   <IP_ADDRESS>   sandbox-k8s-dp-worker-01   <none>           <none>
aerospike-kubernetes-operator-7c8595d8cb-mntjr   1/1     Running   0          100m   <IP_ADDRESS>   sandbox-k8s-dp-worker-02   <none>           <none>

Example of EP spec
apiVersion: v1
kind: Endpoints
metadata:
  name: aerospike-cluster-webhook
  namespace: aerospike
subsets:
- addresses:
  - ip: <IP_ADDRESS>
    nodeName: sandbox-k8s-dp-worker-02
    targetRef:
      kind: Pod
      name: aerospike-kubernetes-operator-7c8595d8cb-mntjr
      namespace: aerospike
  - ip: <IP_ADDRESS>
    nodeName: sandbox-k8s-dp-worker-01
    targetRef:
      kind: Pod
      name: aerospike-kubernetes-operator-7c8595d8cb-lzg8q
      namespace: aerospike
  ports:
  - port: 8443
    protocol: TCP

3 When you will query EP you will endpoint without primary pod
kubectl get ep -n aerospike  -o wide aerospike-cluster-webhook
NAME                        ENDPOINTS                               AGE
aerospike-cluster-webhook   <IP_ADDRESS>:8443,<IP_ADDRESS>:8443   20m

And now we always have the error
root@sandbox-k8s-dp-master-01:/home/eartemenko/aerospike-kubernetes-operator# kubectl apply -f deploy/samples/dim_nostorage_cluster_cr.yaml
Error from server (InternalError): error when applying patch:
{"spec":{"aerospikeConfig":{"logging":[{"any":"info","clustering":"debug","name":"/var/log/aerospike/aerospike.log"}]},"initContainer":"docker-hub.artifactory.playticorp.com/aerospike/aerospike-kubernetes-init:0.0.12","storage":{"volumes":[{"path":"/opt/aerospike","sizeInGB":3,"storageClass":"thin-disk","volumeMode":"filesystem"}]}}}
to:
Resource: "aerospike.com/v1alpha1, Resource=aerospikeclusters", GroupVersionKind: "aerospike.com/v1alpha1, Kind=AerospikeCluster"
Name: "aerocluster", Namespace: "aerospike"
for: "deploy/samples/dim_nostorage_cluster_cr.yaml": Internal error occurred: failed calling webhook "aerospikeclusters.aerospike.com": Post "https://aerospike-cluster-webhook.aerospike.svc:443/admission/reviews/aerospikeclusters/mutating?timeout=30s": dial tcp <IP_ADDRESS>:443: connect: connection refused
root@sandbox-k8s-dp-master-01:/home/eartemenko/aerospike-kubernetes-operator# kubectl apply -f deploy/samples/dim_nostorage_cluster_cr.yaml
Error from server (InternalError): error when applying patch:
{"spec":{"aerospikeConfig":{"logging":[{"any":"info","clustering":"debug","name":"/var/log/aerospike/aerospike.log"}]},"initContainer":"docker-hub.artifactory.playticorp.com/aerospike/aerospike-kubernetes-init:0.0.12","storage":{"volumes":[{"path":"/opt/aerospike","sizeInGB":3,"storageClass":"thin-disk","volumeMode":"filesystem"}]}}}
to:
Resource: "aerospike.com/v1alpha1, Resource=aerospikeclusters", GroupVersionKind: "aerospike.com/v1alpha1, Kind=AerospikeCluster"
Name: "aerocluster", Namespace: "aerospike"
for: "deploy/samples/dim_nostorage_cluster_cr.yaml": Internal error occurred: failed calling webhook "aerospikeclusters.aerospike.com": Post "https://aerospike-cluster-webhook.aerospike.svc:443/admission/reviews/aerospikeclusters/mutating?timeout=30s": dial tcp <IP_ADDRESS>:443: connect: connection refused
root@sandbox-k8s-dp-master-01:/home/eartemenko/aerospike-kubernetes-operator# kubectl apply -f deploy/samples/dim_nostorage_cluster_cr.yaml
Error from server (InternalError): error when applying patch:
{"spec":{"aerospikeConfig":{"logging":[{"any":"info","clustering":"debug","name":"/var/log/aerospike/aerospike.log"}]},"initContainer":"docker-hub.artifactory.playticorp.com/aerospike/aerospike-kubernetes-init:0.0.12","storage":{"volumes":[{"path":"/opt/aerospike","sizeInGB":3,"storageClass":"thin-disk","volumeMode":"filesystem"}]}}}
to:
Resource: "aerospike.com/v1alpha1, Resource=aerospikeclusters", GroupVersionKind: "aerospike.com/v1alpha1, Kind=AerospikeCluster"
Name: "aerocluster", Namespace: "aerospike"
for: "deploy/samples/dim_nostorage_cluster_cr.yaml": Internal error occurred: failed calling webhook "aerospikeclusters.aerospike.com": Post "https://aerospike-cluster-webhook.aerospike.svc:443/admission/reviews/aerospikeclusters/mutating?timeout=30s": dial tcp <IP_ADDRESS>:443: connect: connection refused
root@sandbox-k8s-dp-master-01:/home/eartemenko/aerospike-kubernetes-operator# kubectl apply -f deploy/samples/dim_nostorage_cluster_cr.yaml
Error from server (InternalError): error when applying patch:
{"spec":{"aerospikeConfig":{"logging":[{"any":"info","clustering":"debug","name":"/var/log/aerospike/aerospike.log"}]},"initContainer":"docker-hub.artifactory.playticorp.com/aerospike/aerospike-kubernetes-init:0.0.12","storage":{"volumes":[{"path":"/opt/aerospike","sizeInGB":3,"storageClass":"thin-disk","volumeMode":"filesystem"}]}}}
to:
Resource: "aerospike.com/v1alpha1, Resource=aerospikeclusters", GroupVersionKind: "aerospike.com/v1alpha1, Kind=AerospikeCluster"
Name: "aerocluster", Namespace: "aerospike"
for: "deploy/samples/dim_nostorage_cluster_cr.yaml": Internal error occurred: failed calling webhook "aerospikeclusters.aerospike.com": Post "https://aerospike-cluster-webhook.aerospike.svc:443/admission/reviews/aerospikeclusters/mutating?timeout=30s": dial tcp <IP_ADDRESS>:443: connect: connection refused

Hi @JRaver, thanks for providing the data. It seems that we have got the problem.
Let me just explain what has been happening here.
If we run multiple operator pods then there will be only a single leader pod, which will have a running webhook server.
Now with the current setup, aerospike-cluster-webhook service points to all the operator pods. Thus, it will send the occasional requests to the non-leader pods, which will obviously fail because there is no webhook server running in the non-leader pod.
This can be fixed if the aerospike-cluster-webhook service points to the leader pod only.
For this, we can add a readiness probe in the operator.yaml file.
Please try the given operator config and let us know if it is working for you.
# Operator
apiVersion: apps/v1
kind: Deployment
metadata:
  name: aerospike-kubernetes-operator
  namespace: aerospike
spec:
  replicas: 1
  selector:
    matchLabels:
      name: aerospike-kubernetes-operator
  template:
    metadata:
      labels:
        name: aerospike-kubernetes-operator
    spec:
      serviceAccountName: aerospike-kubernetes-operator
      containers:
        - name: aerospike-kubernetes-operator
          image: aerospike/aerospike-kubernetes-operator:1.0.0
          command:
          - aerospike-kubernetes-operator
          imagePullPolicy: Always
          ports:
          - containerPort: 8443
          env:
          - name: WATCH_NAMESPACE
            value: aerospike
            # Use below value for watching multiple namespaces by operator
            # value: aerospike,aerospike1,aerospike2
          - name: POD_NAME
            valueFrom:
              fieldRef:
                fieldPath: metadata.name
          - name: OPERATOR_NAME
            value: "aerospike-kubernetes-operator"
          - name: LOG_LEVEL
            value: debug
          readinessProbe:
            exec:
              command:
              - stat
              - "/tmp/cert"
            initialDelaySeconds: 5
            periodSeconds: 5
            timeoutSeconds: 5
            failureThreshold: 1

@sud82  Hello thank you for the response.  I have tested your proposal for HA, it's work I even tested disaster when the leader goes down and can't spin up, and it chooses a new leader. But I think it's not a production-ready solution because, we can't update this operator with the Rolling Update strategy. Now I will explain why
For example, we created deployment from spec with 3 pods
NAME                                             READY   STATUS    RESTARTS   AGE   IP              NODE                            NOMINATED NODE   READINESS GATES
aerospike-kubernetes-operator-754dc8c66f-27vbk   0/1     Running   0          11s   <IP_ADDRESS>   sandbox-b-k8s-stage-worker-01   <none>           <none>
aerospike-kubernetes-operator-754dc8c66f-8w22x   1/1     Running   0          11s   <IP_ADDRESS>     sandbox-b-k8s-stage-worker-03   <none>           <none>
aerospike-kubernetes-operator-754dc8c66f-lhzw4   0/1     Running   0          11s   <IP_ADDRESS>    sandbox-b-k8s-stage-worker-02   <none>           <none>

After that we decide to update it, I just add a new Env variable TEST to the spec.
apiVersion: apps/v1
kind: Deployment
metadata:
  name: aerospike-kubernetes-operator
  namespace: aerospike
spec:
  replicas: 3
  selector:
    matchLabels:
      name: aerospike-kubernetes-operator
  template:
    metadata:
      labels:
        name: aerospike-kubernetes-operator
    spec:
      serviceAccountName: aerospike-kubernetes-operator
      containers:
        - name: aerospike-kubernetes-operator
          image: docker-hub.artifactory.playticorp.com/aerospike/aerospike-kubernetes-operator:1.0.0
          command:
          - aerospike-kubernetes-operator
          imagePullPolicy: Always
          ports:
          - containerPort: 8443
          env:
          - name: TEST
            value: some_value
          - name: WATCH_NAMESPACE
            value: aerospike
            # Use below value for watching multiple namespaces by operator
            # value: aerospike,aerospike1,aerospike2
          - name: POD_NAME
            valueFrom:
              fieldRef:
                fieldPath: metadata.name
          - name: OPERATOR_NAME
            value: "aerospike-kubernetes-operator"
          - name: LOG_LEVEL
            value: debug
          readinessProbe:
            exec:
              command:
              - stat
              - "/tmp/cert"
            initialDelaySeconds: 5
            periodSeconds: 5
            timeoutSeconds: 5
            failureThreshold: 1

We applied new spec and now k8s spin up the new pod and stuck
kubectl get po -n aerospike   -o wide   -w
NAME                                             READY   STATUS    RESTARTS   AGE     IP              NODE                            NOMINATED NODE   READINESS GATES
aerospike-kubernetes-operator-754dc8c66f-27vbk   0/1     Running   0          5m44s   <IP_ADDRESS>   sandbox-b-k8s-stage-worker-01   <none>           <none>
aerospike-kubernetes-operator-754dc8c66f-8w22x   1/1     Running   0          5m44s   <IP_ADDRESS>     sandbox-b-k8s-stage-worker-03   <none>           <none>
aerospike-kubernetes-operator-754dc8c66f-lhzw4   0/1     Running   0          5m44s   <IP_ADDRESS>    sandbox-b-k8s-stage-worker-02   <none>           <none>
aerospike-kubernetes-operator-7f86bfbc74-mncmw   0/1     Running   0          52s     <IP_ADDRESS>   sandbox-b-k8s-stage-worker-01   <none>           <none>
kubectl rollout history -n aerospike deploy/aerospike-kubernetes-operator
deployment.apps/aerospike-kubernetes-operator
REVISION  CHANGE-CAUSE
1         <none>
2         <none>

kubectl rollout status -n aerospike deploy/aerospike-kubernetes-operator
Waiting for deployment "aerospike-kubernetes-operator" rollout to finish: 1 out of 3 new replicas have been updated...

^C sleep 100
kubectl rollout status -n aerospike deploy/aerospike-kubernetes-operator
Waiting for deployment "aerospike-kubernetes-operator" rollout to finish: 1 out of 3 new replicas have been updated...

Deployment stuck because k8s in the upgrade procedure is waiting  when the pod will be UP and Ready.
If we change the upgrade procedure to Recreate it will redeploy everything,  k8s delete all pods and spin up new, we lost our operator on some small-time, everything will come back, but in rollout status, we will see, not finished deployment
kubectl rollout history -n aerospike deploy/aerospike-kubernetes-operator
deployment.apps/aerospike-kubernetes-operator
REVISION  CHANGE-CAUSE
1         <none>
2         <none>
3         <none>

kubectl rollout status -n aerospike deploy/aerospike-kubernetes-operator
Waiting for deployment "aerospike-kubernetes-operator" rollout to finish: 1 of 3 updated replicas are available...
^C kubectl get po -n aerospike   -o wide   -w
NAME                                            READY   STATUS    RESTARTS   AGE     IP              NODE                            NOMINATED NODE   READINESS GATES
aerospike-kubernetes-operator-ccb486c7c-fkft6   0/1     Running   0          3m12s   <IP_ADDRESS>   sandbox-b-k8s-stage-worker-01   <none>           <none>
aerospike-kubernetes-operator-ccb486c7c-hglfx   1/1     Running   0          3m12s   <IP_ADDRESS>    sandbox-b-k8s-stage-worker-02   <none>           <none>
aerospike-kubernetes-operator-ccb486c7c-wn7xv   0/1     Running   0          3m12s   <IP_ADDRESS>    sandbox-b-k8s-stage-worker-03   <none>           <none>

From my perspective of view, I think you should separate webhooks from the operator and move it to another deployment and after that, you can scale the webhook seperatly
Thank you.

Hi @JRaver, Thanks for trying it out.
Yes, we are aware of this issue related to upgrading the Operator. This is the solution for this 1.0.* only. Currently, for the upgrade, you have to delete and redeploy the operator.
We have plans to separate webhook and operator when we will upgrade Operator-SDK for operator.

This has been fixed in master.


FW-490. [ADD] MoteISTv5 Project Folder

This will replace #FW-490. Add support for MSP430X processors
Because, this pull request will join all my project
For now, i'm just testing if i didnt break your compilation environment as i'll be adding the new mspgcc as a 'different' tool chain (newmspgcc) to maintain some backward compatibility without extensive changes, later we can then work and unify them....

THIS IS NOT YET IMPLEMENTED. I'M TESTING STUFF
I'LL ADVISE FOR REVISION

@changtengfei by any chance you don't know how i use sudo on -travis.yml ?

@MrD2 I didn't know what you are saying? :-)

Never mind @changtengfei,
Already solved the issue "kinda - i cheated"
I'm still going to test my stuff, so... not ready yet, but the compiler is already available ;)

I'm deleting this until i have everything ok


python310Packages.types-setuptools: 63.2.1 -> 63.2.2

Description of changes
Update to latest upstream release 63.2.2

Things done

Built on platform(s)

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

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

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

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

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

[x] Fits CONTRIBUTING.md.

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

9 packages built:

checkov
cyclonedx-python
pip-audit
python310Packages.cyclonedx-python-lib
python310Packages.requirements-parser
python310Packages.types-setuptools
python39Packages.cyclonedx-python-lib
python39Packages.requirements-parser
python39Packages.types-setuptools


Feature request: Persistent history

Preface: I love this tool!
History doesn't persist across rdsline sessions. I've found myself quite often accidentally Ctrl-C-ing out and losing all my complicated SQL queries.

Thanks for the suggestion! We can add this definitely :)
It seems readline already has all we need to achieve it.

The other aspect is the Ctrl-C portion of your feedback. It seems like terminating on Ctrl-C is usually not always what the user intents (.quit or Ctrl-D are usually how I end up my sessions)

https://github.com/hpolloni/rdsline/pull/14


make flag show the type of input expected for heartbeat_interval

This is a golangtime.Duration value (string representation) not int64 value so make this more obvious to avoid the user having to check the correct value in the code.

This is unnecessary. The help text makes it clear that it's a duration and also formats the default value properly:
$ vttablet --help 2>&1 | grep -A1 heartbeat_interval
  -heartbeat_interval duration
    	How frequently to read and write replication heartbeat. (default 1s)

I'll close this if there are no objections.


boolean row-wise reductions?

Currently these can be done, but they're a bit clunky
e.g. of how one might do dropna using the current api:
columns = df.get_column_names()
mask = ~df.get_column_by_name(columns[0]).isnan()
for col in columns[1:]:
    mask &= ~df.get_column_by_name(col).isnan()
result = df.get_rows_by_mask(mask)

It might be good to have something that takes a boolean DataFrame, like
df.isnan()

and returns a 1-D Column which reduced the DataFrame by row, either with any or all
OK with not having DataFrame.mean(axis=1) as part of the standard, but for boolean values this seems like a fairly important task for filtering?
e.g. of where I came across this:
https://github.com/mwaskom/seaborn/blob/5d9f37159bbd3ac44c8c8a06825583ba25648525/seaborn/relational.py#L513

The line of Seaborn code you pointed at is y = data.get("y", empty). Did you mean self.plot_data.dropna() higher up, or something else?
For .dropna() I assume that that's only an example, and that is a method that should be added to the API rather than reimplemented in user land?
I'm not 100% clear about the ask here. There are .any and .all methods: https://github.com/data-apis/dataframe-api/blob/d10a096ccc1612ec4acf8503aff58b3acb4e3738/spec/API_specification/dataframe_api/dataframe_object.py#LL467-L477C12.
You are thinking that those need to be able to be used row-wise in addition to column-wise? If so, that sounds reasonable to me.

for me it shows the dropna line:

anyway, yes,  it's that one :)

There are .any and .all methods

Yes, but they do something different - I'll show an example
If we start with
       a      b      c
0   True  False  False
1  False   True  False
2  False  False  False

then df.any() would give
      a     b      c
0  True  True  False

What I think we need, for filtering purposes, is something which would give a Column containing
True
True
False

so we can pass it to get_rows_by_mask

Looks like we'll want separate methods .any_rowwise/all_rowwise which work only for a dataframe consisting of columns that all have bool dtype, returning a Column, and supporting a skip_na keyword to deal with nulls.

I vaguely remember an earlier conversation where the decision was made to punt on supporting row-wise operations for the time being given the difficulty in implementing them nicely for many dataframe implementations.
Did we rule out a DataFrame level dropna function?

I vaguely remember an earlier conversation where the decision was made to punt on supporting row-wise operations for the time being given the difficulty in implementing them nicely for many dataframe implementations.

Yes indeed, and that's still the intent, and that's why this proposal is only a very specific any/all method for boolean mask construction only. The case for that seems compelling, and it's being done here in as restricted a form as possible (only any/all, only bool dtype) to avoid encouraging other row-wise reduction APIs.

Did we rule out a DataFrame level dropna function?

No. And that seems useful.
This case isn't just for dropping NAs though, think about things like outlier filtering - say you want a column to use as a mask after identifying outliers in multiple columns with a thresholding operation a la values > 999.


Lootr mod Fails to Load in v1.12.2

I am unable to launch my pack after adding lootr 1.12.2 beta build latest.
Below is the crash report from forge/technic launcher (which we use for the modpack)
https://pastebin.com/Xs9uC4Xp
sorry i can't paste the entire log file here ti was too big.

Unfortunately that crash report isn't vaild. Can you try posting it to gist.github.com?

The paste seems to have expired but please ensure you have installed MixinBooter.

I'm going to close this as there hasn't been any response.


Week 3

Thanks @borisbradic i updated the pr. i just copied all files from the server and pushed them. i  checked one more time, I hope all scripts and screenshots are there

Check directory chapter16 > test11.sh is it a script or output file?
Please, try to put screenshots in directories named by the chapter: "chapter13", "chapter14", etc.. like this I can't navigate.. thank you.

Yeah, you are right, it is not a script it is the output that I created by mistake. I have one question before I push the changes. The examples start after test10.sh script in chapter 16 page 435, in the book we run the test11.sh/test12.sh scripts but there are no examples of script content, I suppose it is the same as test10.sh (that part confused me)?

Yes, you can go without those, it will be okey.

Thank you @borisbradic


FreeBSD support

This doesn't yet pass tests because the tarball fails to extract and I don't understand why. The URL it's using is correct and I'm able to download and unpack manually.

Backtrace from tests (click to expand)
$ RUST_BACKTRACE=full cargo build
warning: file `/usr/home/alex/Projects/juliaup/src/bin/julialauncher.rs` found to be present in multiple build targets:
  * `bin` target `julia`
  * `bin` target `julialauncher`
   Compiling juliaup v1.14.7 (/usr/home/alex/Projects/juliaup)
    Finished dev [unoptimized + debuginfo] target(s) in 1m 15s
$ RUST_BACKTRACE=full cargo test
warning: file `/usr/home/alex/Projects/juliaup/src/bin/julialauncher.rs` found to be present in multiple build targets:
  * `bin` target `julia`
  * `bin` target `julialauncher`
   Compiling juliaup v1.14.7 (/usr/home/alex/Projects/juliaup)
    Finished test [unoptimized + debuginfo] target(s) in 47.42s
     Running unittests src/lib.rs (target/debug/deps/juliaup-27e8dbb220796096)

running 7 tests
test operations::tests::match_markers_none_without_markers ... ok
test operations::tests::match_markers_returns_correct_indices ... ok
test operations::tests::match_markers_returns_err_with_multiple_end ... ok
test operations::tests::match_markers_returns_err_with_multiple_start ... ok
test operations::tests::match_markers_returns_err_without_end ... ok
test operations::tests::match_markers_returns_err_without_start ... ok
test utils::tests::test_parse_versionstring ... ok

test result: ok. 7 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.04s

     Running unittests src/bin/julialauncher.rs (target/debug/deps/julia-f28678fd7035ba9e)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running unittests src/bin/juliaup.rs (target/debug/deps/juliaup-60a8308d342a3057)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests/channel_selection.rs (target/debug/deps/channel_selection-c6413bcb97490fba)

running 1 test
test channel_selection has been running for over 60 seconds
test channel_selection ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 71.02s

     Running tests/command_add.rs (target/debug/deps/command_add-1879bb0894255f75)

running 1 test
test command_add ... FAILED

failures:

---- command_add stdout ----
thread 'command_add' panicked at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/ops/function.rs:250:5:
Unexpected failure.
code=1
stderr=``````
Installing Julia latest-freebsd-x86_64
Error: Failed to download and extract nightly: Failed to extract downloaded file from url `https://julialangnightlies-s3.julialang.org/bin/freebsd/x86_64/julia-latest-freebsd-x86_64.tar.gz`.

Stack backtrace:
   0: anyhow::error::<impl anyhow::Error>::msg
             at /home/alex/.cargo/registry/src/index.crates.io-6f17d22bba15001f/anyhow-1.0.79/src/error.rs:83:36
   1: juliaup::operations::install_from_url
             at ./src/operations.rs:463:13
   2: juliaup::operations::install_nightly
             at ./src/operations.rs:534:15
   3: juliaup::command_add::add_nightly
             at ./src/command_add.rs:84:26
   4: juliaup::command_add::run_command_add
             at ./src/command_add.rs:11:16
   5: juliaup::main
             at ./src/bin/juliaup.rs:59:37
   6: core::ops::function::FnOnce::call_once
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/ops/function.rs:250:5
   7: std::sys_common::backtrace::__rust_begin_short_backtrace
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/sys_common/backtrace.rs:155:18
   8: std::rt::lang_start::{{closure}}
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/rt.rs:166:18
   9: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/ops/function.rs:284:13
  10: std::panicking::try::do_call
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:552:40
  11: std::panicking::try
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:516:19
  12: std::panic::catch_unwind
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panic.rs:142:14
  13: std::rt::lang_start_internal::{{closure}}
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/rt.rs:148:48
  14: std::panicking::try::do_call
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:552:40
  15: std::panicking::try
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:516:19
  16: std::panic::catch_unwind
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panic.rs:142:14
  17: std::rt::lang_start_internal
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/rt.rs:148:20
  18: std::rt::lang_start
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/rt.rs:165:17
  19: main
  20: __libc_start1
             at /usr/src/lib/libc/csu/libc_start1.c:157:7
  21: _start
             at /usr/src/lib/csu/amd64/crt1_s.S:83
```
```
command=`JULIAUP_DEPOT_PATH="/tmp/.tmpt52UIs" JULIA_DEPOT_PATH="/tmp/.tmpt52UIs" "/usr/home/alex/Projects/juliaup/target/debug/juliaup" "add" "nightly"`
code=1
stdout=""
stderr=```
Installing Julia latest-freebsd-x86_64
Error: Failed to download and extract nightly: Failed to extract downloaded file from url `https://julialangnightlies-s3.julialang.org/bin/freebsd/x86_64/julia-latest-freebsd-x86_64.tar.gz`.

Stack backtrace:
   0: anyhow::error::<impl anyhow::Error>::msg
             at /home/alex/.cargo/registry/src/index.crates.io-6f17d22bba15001f/anyhow-1.0.79/src/error.rs:83:36
   1: juliaup::operations::install_from_url
             at ./src/operations.rs:463:13
   2: juliaup::operations::install_nightly
             at ./src/operations.rs:534:15
   3: juliaup::command_add::add_nightly
             at ./src/command_add.rs:84:26
   4: juliaup::command_add::run_command_add
             at ./src/command_add.rs:11:16
   5: juliaup::main
             at ./src/bin/juliaup.rs:59:37
   6: core::ops::function::FnOnce::call_once
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/ops/function.rs:250:5
   7: std::sys_common::backtrace::__rust_begin_short_backtrace
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/sys_common/backtrace.rs:155:18
   8: std::rt::lang_start::{{closure}}
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/rt.rs:166:18
   9: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/ops/function.rs:284:13
  10: std::panicking::try::do_call
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:552:40
  11: std::panicking::try
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:516:19
  12: std::panic::catch_unwind
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panic.rs:142:14
  13: std::rt::lang_start_internal::{{closure}}
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/rt.rs:148:48
  14: std::panicking::try::do_call
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:552:40
  15: std::panicking::try
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:516:19
  16: std::panic::catch_unwind
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panic.rs:142:14
  17: std::rt::lang_start_internal
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/rt.rs:148:20
  18: std::rt::lang_start
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/rt.rs:165:17
  19: main
  20: __libc_start1
             at /usr/src/lib/libc/csu/libc_start1.c:157:7
  21: _start
             at /usr/src/lib/csu/amd64/crt1_s.S:83
```

stack backtrace:
   0:     0x32c2adb78076 - std::backtrace_rs::backtrace::libunwind::trace::h7240633c0010cc0c
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/../../backtrace/src/backtrace/libunwind.rs:104:5
   1:     0x32c2adb78076 - std::backtrace_rs::backtrace::trace_unsynchronized::ha2c7a5c96fbc8505
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:     0x32c2adb78076 - std::sys_common::backtrace::_print_fmt::hd469fe19c1c8394f
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/sys_common/backtrace.rs:68:5
   3:     0x32c2adb78076 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h579f177009daf63c
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/sys_common/backtrace.rs:44:22
   4:     0x32c2adba2d30 - core::fmt::rt::Argument::fmt::hd069ebef5ef6ecf2
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/fmt/rt.rs:142:9
   5:     0x32c2adba2d30 - core::fmt::write::hdac3a427c10c4f97
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/fmt/mod.rs:1120:17
   6:     0x32c2adb74baf - std::io::Write::write_fmt::hede81785d7f048d1
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/io/mod.rs:1810:15
   7:     0x32c2adb77e54 - std::sys_common::backtrace::_print::hfa6dbd0c85e91f76
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/sys_common/backtrace.rs:47:5
   8:     0x32c2adb77e54 - std::sys_common::backtrace::print::h108ec5c827b50278
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/sys_common/backtrace.rs:34:9
   9:     0x32c2adb79917 - std::panicking::default_hook::{{closure}}::h963a7edfbc073915
  10:     0x32c2adb7961d - std::panicking::default_hook::h8e8085b99e7345eb
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:289:9
  11:     0x32c2ad82cb07 - <alloc::boxed::Box<F,A> as core::ops::function::Fn<Args>>::call::h0bec7cb0f6b7b94a
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/alloc/src/boxed.rs:2029:9
  12:     0x32c2ad82cb07 - test::test_main::{{closure}}::he7ced423a7faeae3
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/test/src/lib.rs:138:21
  13:     0x32c2adb7a00d - <alloc::boxed::Box<F,A> as core::ops::function::Fn<Args>>::call::hf66dc46e35826ba0
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/alloc/src/boxed.rs:2029:9
  14:     0x32c2adb7a00d - std::panicking::rust_panic_with_hook::hd05c0541950740f4
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:783:13
  15:     0x32c2adb79d52 - std::panicking::begin_panic_handler::{{closure}}::h8bfba3147bcb3614
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:657:13
  16:     0x32c2adb78576 - std::sys_common::backtrace::__rust_end_short_backtrace::h163b8cf687c9f743
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/sys_common/backtrace.rs:171:18
  17:     0x32c2adb79ab0 - rust_begin_unwind
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:645:5
  18:     0x32c2adba0d15 - core::panicking::panic_fmt::h8d1bb268d5ef243e
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/panicking.rs:72:14
  19:     0x32c2ad838f9f - core::panicking::panic_display::h001ba5e4ba9bf4b2
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/panicking.rs:196:5
  20:     0x32c2ad83c91e - assert_cmd::assert::AssertError::panic::panic_cold_display::h6b37e029948dc0d5
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/panic.rs:99:13
  21:     0x32c2ad83ac27 - assert_cmd::assert::AssertError::panic::ha16d1fcdedc6a331
                               at /home/alex/.cargo/registry/src/index.crates.io-6f17d22bba15001f/assert_cmd-2.0.13/src/assert.rs:1033:9
  22:     0x32c2ad843077 - core::ops::function::FnOnce::call_once::h356ba518d73ccf99
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/ops/function.rs:250:5
  23:     0x32c2ad84552f - core::result::Result<T,E>::unwrap_or_else::h659dcae9e2d4db1c
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/result.rs:1426:23
  24:     0x32c2ad83a166 - assert_cmd::assert::Assert::success::h0f4aa7bd61694c1a
                               at /home/alex/.cargo/registry/src/index.crates.io-6f17d22bba15001f/assert_cmd-2.0.13/src/assert.rs:158:9
  25:     0x32c2ad7e9e82 - command_add::command_add::hc9a85be4a188313e
                               at /usr/home/alex/Projects/juliaup/tests/command_add.rs:18:5
  26:     0x32c2ad7e8547 - command_add::command_add::{{closure}}::h0474660538de43c5
                               at /usr/home/alex/Projects/juliaup/tests/command_add.rs:5:17
  27:     0x32c2ad7ea616 - core::ops::function::FnOnce::call_once::h679daccd76ce5bcf
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/ops/function.rs:250:5
  28:     0x32c2ad83238f - core::ops::function::FnOnce::call_once::h73428c76b37975a0
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/ops/function.rs:250:5
  29:     0x32c2ad83238f - test::__rust_begin_short_backtrace::he8ead63f1b14979b
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/test/src/lib.rs:627:18
  30:     0x32c2ad83116e - test::run_test_in_process::{{closure}}::hb19e40931d728242
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/test/src/lib.rs:650:60
  31:     0x32c2ad83116e - <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once::h137e3c5834ce42f2
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/panic/unwind_safe.rs:272:9
  32:     0x32c2ad83116e - std::panicking::try::do_call::h981ec909ebe66d3d
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:552:40
  33:     0x32c2ad83116e - std::panicking::try::h6a8ac355d2c05b51
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:516:19
  34:     0x32c2ad83116e - std::panic::catch_unwind::he5484ce6066eec19
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panic.rs:142:14
  35:     0x32c2ad83116e - test::run_test_in_process::he21ef0196cf852c5
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/test/src/lib.rs:650:27
  36:     0x32c2ad83116e - test::run_test::{{closure}}::h96161358f8f07f3d
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/test/src/lib.rs:573:43
  37:     0x32c2ad7f5e16 - test::run_test::{{closure}}::ha89a98e7aac5a3ca
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/test/src/lib.rs:601:41
  38:     0x32c2ad7f5e16 - std::sys_common::backtrace::__rust_begin_short_backtrace::hf41028e6b16049a3
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/sys_common/backtrace.rs:155:18
  39:     0x32c2ad7fb037 - std::thread::Builder::spawn_unchecked_::{{closure}}::{{closure}}::h7a86dfcd69fe5a2b
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/thread/mod.rs:529:17
  40:     0x32c2ad7fb037 - <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once::h7ef355326916622a
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/panic/unwind_safe.rs:272:9
  41:     0x32c2ad7fb037 - std::panicking::try::do_call::ha2cf9d94c9f940ca
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:552:40
  42:     0x32c2ad7fb037 - std::panicking::try::hb19633da3c7b0a83
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:516:19
  43:     0x32c2ad7fb037 - std::panic::catch_unwind::h33d6f55f15e036bb
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panic.rs:142:14
  44:     0x32c2ad7fb037 - std::thread::Builder::spawn_unchecked_::{{closure}}::h61726f914b2c59c7
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/thread/mod.rs:528:30
  45:     0x32c2ad7fb037 - core::ops::function::FnOnce::call_once{{vtable.shim}}::h79a05a5a909288a3
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/ops/function.rs:250:5
  46:     0x32c2adb7fe85 - <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once::h416b9e2948292dac
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/alloc/src/boxed.rs:2015:9
  47:     0x32c2adb7fe85 - <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once::ha651b059e126a744
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/alloc/src/boxed.rs:2015:9
  48:     0x32c2adb7fe85 - std::sys::unix::thread::Thread::new::thread_start::h83716b035e61a5a7
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/sys/unix/thread.rs:108:17
  49:     0x32cacfcb0a75 - thread_start
                               at /usr/src/lib/libthr/thread/thr_create.c:290:16

failures:
    command_add

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 29.38s

error: test failed, to rerun pass `--test command_add`

Actually the unpacking thing might be a red herring possibly caused by with_context attaching the wrong context to a different error. I removed the ? in https://github.com/JuliaLang/juliaup/blob/20a20b97615eedefc5853d61d5d9b30bcc505b44/src/operations.rs#L48 and now the error is that libjulia-codegen.so.1.12 can't load libLLVM-16jl.so. Last I checked (a day or two ago) I didn't see that locally when manually downloading, unpacking, and using nightly. So still doesn't work but... progress?

Swapping the tar crate for binstall-tar, a fork that fixes https://github.com/alexcrichton/tar-rs/issues/295, fixed the primary failure. The test that fails now is related to pulling versiondb from S3, and there isn't one for FreeBSD there. Perhaps I'll separate out the versiondb changes from this PR so that those can be merged first.

...except it didn't fail on CI, huh. The test I mentioned fails locally.

Some to-do items:

As @davidanthoff and I discussed in Slack, using the binstall-tar crate in place of tar is not ideal since the former seems unmaintained; it reflects tar v0.4.39 with the first commit from https://github.com/alexcrichton/tar-rs/pull/298 applied, but does not include any of the changes made to upstream tar since then. Some options we discussed, which are not necessarily mutually exclusive:

Make binstall-tar a conditional dependency such that it's used for FreeBSD while tar is used for other platforms.
If the author of the linked tar PR doesn't respond, make a new PR based on it with conflicts resolved in order to move forward.
Temporarily maintain our own fork of tar, despite neither David nor I knowing enough about that crate nor the fixes in the linked PR to warrant doing so...
Use binstall-tar on all platforms (currently implemented in this PR). This means we don't benefit from any updates or fixes in upstream tar.

Add FreeBSD to the release building setup.

binstall-tar has now been synced with upstream tar (https://github.com/cargo-bins/tar-rs/pull/1) and a v0.4.42 release has been published. IMO it seems reasonable to switch to binstall-tar (currently implemented in this PR) until tar has been updated to include the necessary fixes.

Everything is working now, though I ended up taking a slightly different approach from when I started this. It looks like it might be a long time before the tar-rs PR that would allow us to properly read tarballs produced by BSD tar is merged, if it ever is. In the meantime, we can simply spawn a tar process to do the unpacking. This seems to work just fine.
I think this is finally ready for review, @davidanthoff. It's worth noting up front that I don't actually know Rust so there may be better ways to implement this approach.

Oh, one more question: so this uses the download script and then the self-update option. I'm wondering whether there is also a system package manager on FreeBSD that we could utilize to distribute things? I think in general my hope is that over time we can utilize system package managers as much as possible to get Juliaup onto user's machines, and only use the download script on platforms where there isn't really a compelling story (ahem, Mac...).

There is, the system package manager is called pkg. They don't typically redistribute third party binaries though, preferring to compile things themselves as part of the "ports" system. (Think macOS Homebrew if there was no --cask option.) It also doesn't seem to be very easy to contribute to, nor to monitor for issues. IMO it's worth using download + self-update in the near term and look into adding a port in the future.

Cleaned up my commit mess and rebased on main to make extra sure things continue to work as expected here with the updated dependencies.

IMO it's worth using download + self-update in the near term and look into adding a port in the future.

Yes, that sounds like a good plan.

They don't typically redistribute third party binaries though, preferring to compile things themselves as part of the "ports" system.

So that might work for us, because we can easily have them compile julialauncher and juliaup etc, right?


Bug 1247559 - [GSS] (6.1.z) Guided Rule editor does not seem to reloa…

…d "eval()" functions correctly while used inside the constraint of a fact
One more Guided Rule Editor bug. Here is the test for it.

Merged and fixed by https://github.com/droolsjbpm/drools/commit/02580f9a5ecf6163e9f100f4cf16e6114af9715a


If request is canceled during retry it reports error that occurred instead of isExplicitlyCancelledError

[x] I've read, understood, and done my best to follow the *CONTRIBUTING guidelines.

What did you do?
I'm using custom RequestInterceptor to retry requests and I noticed that if I cancel a request while it retries with a delay it reports an error that occurred before retry and not isExplicitlyCancelledError as I was expecting. Furthermore, it looks that I can't distinguish between errored requests and canceled requests because of that.
What did you expect to happen?
Not sure if that's expected but looks buggy. I was expecting to receive isExplicitlyCancelledError for canceled requests.
What happened instead?
I received an error that have been retrying.
Alamofire Environment
Alamofire version: 5.4.1
Xcode version: 12.4 (12D4e)
Swift version: 5.3.2 (swiftlang-1200.0.45 clang-1<IP_ADDRESS>)
Platform(s) running Alamofire: iOS 14.3
macOS version running Xcode: Catalina 10.15.6 (19G2021)
Demo Project
https://github.com/anton-plebanovich/SingleView/tree/aca4cb4973953a7d11fa72cccac39748dd788eab

We can fix it by overriding existing error in:
    func didCancel() {
        dispatchPrecondition(condition: .onQueue(underlyingQueue))

        error = AFError.explicitlyCancelled

        eventMonitor?.requestDidCancel(self)
    }

Or by preparing for retry at retry schedule:
    public func retryRequest(_ request: Request, withDelay timeDelay: TimeInterval?) {
        rootQueue.async {
            let retry: () -> Void = {
                guard !request.isCancelled else { return }
                self.perform(request)
            }

            request.prepareForRetry()
            if let retryDelay = timeDelay {
                self.rootQueue.after(retryDelay) { retry() }
            } else {
                retry()
            }
        }
    }

There might be other options that are more valid depending on existing intentions. I am not very familiar with the Alamofire code base.

This was done purposefully: if a Request is cancelled after it had already failed due to an error, we keep the original error. A Request's error is reset when we're actually going to request, not when we ask the retrier whether to retry. If you need to know whether a Request is cancelled in a retrier, you can check the isCancelled property (which is a bit cleaner than checking the error anyway).

@jshier Thanks for the explanation! Sadly, the issue for me is that I need to know if a request was canceled in a response {} closure and I can't get a Request there because I have only DataResponse -> URLRequest.

You can capture the Request you create into the response closure:
let request = AF.request(...)
request.response { response in
    // guard request.isCancelled
}

@jshier Thanks for your guidance, I should be able to resolve this case knowing that 👍


Obtain official LOVs from CRHP

CRHP is the source of truth for LOVs for things like Heritage Functions, https://www.historicplaces.ca/media/5428/doc-standards-en.pdf

Closed in favor of #562


11 safe addresses related to airdrop hunters

11 safe addresses related to airdrop hunters
0xa5df118705be922e0fa6b1f6636418a26c391f75
Related Safe Addresses
0x1a0f7228809f5fe095a55f668eb6c1a86607244c
0x1ac62365602229816c91c947fd149a9885dc6850
0x217ca79588d971d56299b41668d2a248d8778109
0x4dce38029ce64ea5096969659f6731db29b6ee33
0x52a0504aa12bc4b40a8eab2bc69ee04eadb75e26
0x674cd7c3983c484981ac336244de4b84f8b0a951
0x6e483bf5715d984772c341d11224759d90901ead
0x7dda9b908530fc3a14c1f6bc77c999d0fe1512ae
0x849d67a4033f5dd3f1cebff3f24473c68a3a38af
0x9a4d8317a71bae390542dcc03b55c49591fef097
0x9b927668ca0c463e68deaa1f964aeb58a444df03
Reasoning

11 safe address, only 0xa5df118705be922e0fa6b1f6636418a26c391f75 call the safe address.
0xa5df118705be922e0fa6b1f6636418a26c391f75 it's human EOA address, 400+ days not use.
10 safe address, the the nums of txs are  1
11 safe address, all 400+ days have not txs
11 safe address, the balance is 0 eth

safe address,nums of txs
0x1a0f7228809f5fe095a55f668eb6c1a86607244c 1
0x1ac62365602229816c91c947fd149a9885dc6850 1
0x217ca79588d971d56299b41668d2a248d8778109 1
0x4dce38029ce64ea5096969659f6731db29b6ee33 1
0x52a0504aa12bc4b40a8eab2bc69ee04eadb75e26 1
0x674cd7c3983c484981ac336244de4b84f8b0a951 1
0x6e483bf5715d984772c341d11224759d90901ead 1
0x849d67a4033f5dd3f1cebff3f24473c68a3a38af 1
0x9a4d8317a71bae390542dcc03b55c49591fef097 1
0x9b927668ca0c463e68deaa1f964aeb58a444df03 1
0x7dda9b908530fc3a14c1f6bc77c999d0fe1512ae 4
Methodology
download txs of safe addresses use etherscan api ,and check the common action of the txs use python, at last check the transactions on https://etherscan.io/ one by one.
https://etherscan.io/address/0x1a0f7228809f5fe095a55f668eb6c1a86607244c
https://etherscan.io/address/0x1ac62365602229816c91c947fd149a9885dc6850
https://etherscan.io/address/0x217ca79588d971d56299b41668d2a248d8778109
https://etherscan.io/address/0x4dce38029ce64ea5096969659f6731db29b6ee33
https://etherscan.io/address/0x52a0504aa12bc4b40a8eab2bc69ee04eadb75e26
https://etherscan.io/address/0x674cd7c3983c484981ac336244de4b84f8b0a951
https://etherscan.io/address/0x6e483bf5715d984772c341d11224759d90901ead
https://etherscan.io/address/0x7dda9b908530fc3a14c1f6bc77c999d0fe1512ae
https://etherscan.io/address/0x849d67a4033f5dd3f1cebff3f24473c68a3a38af
https://etherscan.io/address/0x9a4d8317a71bae390542dcc03b55c49591fef097
https://etherscan.io/address/0x9b927668ca0c463e68deaa1f964aeb58a444df03
Safe Address
0xd8878417378CB18D315b4768503fC39487f90580

Thanks for the report. Owning several Safes is not airdrop farming per se, but quite common.
The Safes you linked stored quite an amount of USD stable coins for some time, each. Safe as store of value is legitimate usage. Hence closing this.


Add .gitignore for node, .eslintrc.json, and yarn.lock

.gitignore: Ignore node_modules and other node files
.eslintrc.json: Configuration for eslint to match this project's style
yarn.lock: Packages locked to commit hash for the yarn package manager
Also removed two statements that weren't doing anything from getFriends and getMessages according to eslint

Can we accept this? @sentanos

Roblox-js is no longer supported. Pull requests never get merged.


Add CANFD support to Linux CAN

closes  https://github.com/ardera/flutter_packages/issues/24

@ardera  Can you please review this.

Hey @alaa-az sorry for the wait.
What CAN hardware did you test this with?

Hello @ardera on this: https://www.peak-system.com/PCAN-USB-FD.365.0.html?&L=1, also tested on virtual CAN

Fixes are done, Thank you in advance

Sorry I pointed you in the wrong direction before, after this is fixed it's ready to merge :)

Don't worry I should have figured this out by myself.

Perfect solution, it works with Virtual CAN.

merged it
thanks for the contribution!

Thank you for this repo


Fix README example

When running the first README example, slab just hangs without rendering.
Changing this:
let values = data/values.json

to this
let values = ./data/values.json

fixes the problem.
It would be nice if this works without this prefix though.

Thanks a lot!
I think it makes sense to keep some syntactical clue this is a path. Otherwise let values = file.ext could be mistaken for "the field ext in the object file".


together with "flutter_localizations" will disable the RTL change by the "flutter_localizations" ?

Describe the bug
return
MaterialApp(
builder: (BuildContext context, Widget child) {
return child;
//the code below will disable the rtl change to widgets by the flutter_localizations.
//FlutterEasyLoading(
//   child: child,
// );
});

can set the textDirection property to fix this


Future<Either<L,R>> Response type using dartz packages

is it possible to use Response type using a dartz package to return response type of following:
GET("/tasks")
Future<Either<Left,Task>> getTasks(@Header("Content-Type") String contentType );
If there is anything documented on how to use it, would be very helpful. Thanks 🙏

@basnetjiten did you ever find a solution to this?

retrofit.dart depends on json_serializable to handle the serialization
Please refer https://github.com/google/json_serializable.dart/blob/master/example/lib/json_converter_example.dart
it would be helpful


Third-Party Tools Supported by Cockroach Labs Doc Update

Re: Third-Party Tools Supported by Cockroach Labs
Issue Description
this is a great landing page for highlighting every supported third party tool out there. It would be of utmost benefit to add a column for the ability to handle automatic retries.
Suggested Resolution
sqlalchemy, activerecord, a fair amount of go libraries support automatic retries. We should emphasize that in our docs.
See this for more.

@ericharmeling fyi let's prioritize this for the next release since we often get asked how to handle transaction retry


Modification to handle burrow v3 api

Looks like others have already worked on it.

@yhzhao I just merged one into master. Thanks for your submission.


update api version to release-1.4

@jasonwzm: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

gencheck_client-go_release-1.4
7ee81aba17a59e63e47fd9026f1645e170dbdeff
link
/test gencheck_client-go_release-1.4

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

what's new in this version of istio API that warrants an update?

https://github.com/istio/istio/issues/18737 reported the deepcopy method appends repeated fields in protos. The new API version fixed that.

istio/istio#18737

Makes sense, I was telling @rcernich that we should switch to proto.Clone instead of proto.Merge. I'm glad you got to it before me. :)

@jasonwzm not a blocker for this PR but it would be great to have unit tests in this repo to verify deepcopy behavior for generated structs that are known to be problematic.

Unit test was added to the tools repo: https://github.com/istio/tools/blob/master/cmd/protoc-gen-deepcopy/test/deepcopy_test.go#L66 I agree we need to have more tests overall. Created https://github.com/istio/istio/issues/18825 to keep track as a work item.

This change seems to reintroduce the duplicate package names, where the import name is the same as the local package name.

This change seems to reintroduce the duplicate package names, where the import name is the same as the local package name.

This is because the tools change was not cherrypicked to 1.4 branch. Doing that now.

@rcernich @jasonwzm there seems to be some disconnect here, for me release-1.4 works, so I'm not sure what you both are referring to.


update interacting.md docs to explain automatic currying re issue #125

I've had a go at updating interacting.md to explain the points in issue #125 more clearly.
Hope this is useful,
Gary

Thanks for that! I'll review the text a bit and merge it with the docs :)

@alfonsogarciacaro In theory, you should just need to run build PublishDocs to get this on the live site :) let me know if something does not work!

I'll do, thank you! I'll probably have to update the docs again after fixing the bugs reported this week so I'll try this weekend. Thanks to your web, user activity has exploded, I hope I can keep up ;)


dev.boringcrypto branch behind the main releases (1.14.1b4 vs 1.14.2)

Similar to #36611
We are currently on 1.13.8b4 and are looking forward to upgrade to 1.14 so we can take advantage of the improvements, notably the improve management of go.mod.
Since 1.14.2 has a significant amount of bug fixes we want to skip 1.14.0 and 1.14.1 and go straight to 1.14.2.
Can you give us some input on the timeline?
Thanks again for maintaining this great branch!!!

@katiehockman @FiloSottile

The release is in progress, should be done today!

Thanks a lot @FiloSottile !!!


qiita_env drop_env should remove current files

We can add a parameter or not but it will be great to also remove the analysis, tables, etc files from the local installation.

This is an old idea based on the concept of local installs, which has been deprecated. Closing.


Fix inline schema definitions inherited from a parent.

When an inline schema is inherited, the child should reference the parent definition, and not build ain incompatible child version

👍


ECOFlow Powerocean DCFIT | Use Adapter to run DC-Fit without Smart Meter

Dear all
I am thinking of buying a DC Fit to add to my existing Solar System.
Is it possible to read values from the DC Fit and also write Start Charge, Stop Charge, Start Discharge, Stop Discharge all with target values.
Do you think it is possible to run the DC Fit without the Smart Meter when control is executed by this MQTT Adapter? I would like to avoid the expensive Eletrician Installation of the Smart Meter and I have a SMA Sunny Home Manager already that has all the values needed.
Thanks a lot for your help

I can hardly make suggestions, but if you think it fits to you after thorough investigation of the features, then it might be an option. Please consider the following

the power ocean is not part of the official API, so there is not much information around here
The power ocean is using protobuf decoding, where many things are already correctly guessed and implemented, but it’s not complete yet
the commands from the app can be reproduced by the adapter, after some investigation
The adapter uses the unofficial API(same as the App), which might become unavailable
But if we see data and can interpret data, then it can be implemented in the adapter

Thanks a lot.
I spoke with an installer and he mentioned I need to have an electrician work with his app to install it. That makes it really unattractive cost wise.
I check now another battery like sax that is maybe cheaper to install and maybe ac based. That would allow storing net energy as well.


⚠ Processors has degraded performance

In d0ab5b7, Processors ($STATUS_URL) experienced degraded performance:

HTTP code: 200
Response time: 53 ms

Resolved: Processors performance has improved in 6d729db.


Field definition for InterfaceType does not work with callback function

This is possibly related to #22. When I try to define the fields as a callback function for an InterfaceType, I get an error:
Argument 1 passed to GraphQL\Type\Definition\FieldDefinition::createMap() must be of the type array, object given, called in /Users/ivo/Documents/workspace/graphql-relay-php/vendor/webonyx/graphql-php/src/Type/Definition/InterfaceType.php on line 66 and defined

Managed to miss interface field definitions somehow. Thanks for catching!
Should be fixed in https://github.com/webonyx/graphql-php/commit/d37fb34e96d2f399bff8ffa65b897b767133fc32


Automated cherry pick of #3896: Initial notes

Cherry pick of #3896 on release-v3.15.
#3896: Initial notes

Deploy preview for calico ready!
Built with commit 0f955d40e5fa42a99acd239c8bb8a429480ecf46
https://deploy-preview-3897--calico.netlify.app


Sample #12 Connect-pnponline with access token url is not needed

As far as I can see is that when connecting with an accesstoken, the URL isn't taken into account because the url is already included in the accesstoken itself. Providing a different URL still results in a connection to the root site, which in fact can cause terrible mistakes! Don't know if this is a bug in the cmdlet itself or should be explained over here.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 7f910a5c-5883-6394-19a3-4cf1670c431f
Version Independent ID: 4451fe4c-df86-34a8-0db0-46a47e70b5a5
Content: Connect-PnPOnline (sharepoint-pnp)
Content Source: sharepoint/sharepoint-ps/sharepoint-pnp/Connect-PnPOnline.md
GitHub Login: @techwriter40
Microsoft Alias: kirks

@officedocsbot assign @yogkumgit

@get-itips  Thank you very much for the contribution and sharing this explanation. @advdberg
Hope this comment is helpful for you. Thanks for taking out some time to open the issue. Appreciate and encourage you to do the same in future also.


Date Order Groupe by Day of Month

Version 1.21.2
When ordering by Last Modified date, the dates are no longer ordered ascending/descending. The current behaviour is grouping the dates by the day of month:
01/07/2021
01/08/2021
01/09/2021

@lymedo is this for:

blobs
Gen2 blobs
file shares


docs: Add Cargo installation steps to README for scripts and contracts

📄 Description
This PR updates the README file for stark-cairo-nodes to include detailed instructions on installing Cargo, a prerequisite for using Scarb. The update addresses issue #71 by providing clear, platform-specific steps for installing Cargo on Linux, macOS, and Windows. Additionally, it integrates the instructions with the existing setup process for both scripts and contracts.
🛠 Changes Made

Added a section for installing Cargo with platform-specific commands.
Verified and refined the Scarb installation steps.
Improved the overall clarity and flow of the build and test instructions.

✅ Acceptance Criteria

[x] README includes Cargo installation steps for Linux, macOS, and Windows.
[x] All setup instructions are consistent and easy to follow.
[x] Links to official documentation are provided for further reference.

🔗 Related Issue
Closes #71
📜 Additional Notes
This PR ensures that new and existing users can quickly set up their development environment without running into dependency issues.

@danielcdz This PR is ready for review.


multi-agent problem

Sorry to bother you guys, but when I run the example of multi_agent, I always get the ‘not enough clients in the client pool’ error. And I checked the Issues for a solution. But I still don't know how to solve the problem that running the role0 first. So how can I run the multi-agent successfully? Thank you!

Sorry, I did not found a solution yet.

I solved the problem. The issue was that I didn't start two separate instances of Minecraft on different ports. I'm not sure if it helps you, but try starting one instance on port 10000 and another on port 10001. I did it using the Anaconda Prompt tool. Go to your installed Minecraft directory (if you use the Conda environment, it's set to %MALMO_MINECRAFT_ROOT%, so use:
cd %MALMO_MINECRAFT_ROOT%
launchClient.bat -port 10000
In another window, do the same:
cd %MALMO_MINECRAFT_ROOT%
launchClient.bat -port 10001
These steps are also described in the tutorial on the website, but I overlooked them too.
hope this helps you !

It works! Thank you very much!
But I had other problems. Is it right that I can't see how Minecraft works when the program is running? And I was only able to run the multi_agent.py. When I modified the code like changing the env or adding my own code, the terminal always sent errors like INFO:marlo.base_env_builder:Agent missed 4 observation(s). Have you ever encountered the similar problems?

no i try to figure out at the moment how to get the Observations and how many actions are in the Action space. Have you some info about that ?

Sorry i get the same situation that the agents  only look eacht other too. But when i printed the observations, they are changed. So maybe that's what happens when the code runs？You can find some information about the envs in 'marLo-master\marlo\envs' . I get some information in there and hope it'll help you.

Could be possible. Yeah i found the Infos about the envs. But the problem is that i dont find a Proper Doc where the functions to Extract Observations are Explained. Do you know where to look for that ?

Sorry I do not find the doc too. And I have no idea about how to extract the infos. Sorry that I can't help you about this.

observation = env.reset()
observation, reward, done, info = env.step(action)
Thats the normal way. The Observation is a Picture from the Actual game taken at the step. so based on that you can train your agent. action = np.argmax(action_outputs) with that i give actions to the Api. but i didnt get Continouse Movements to work i dont know why. so my agent is really stupid at the moment. There is a kind of hidden doc if you go to Examples and Look how they are Implemented. Hope thats help.


Make CLI version a dotnet tool

[x] Make CLI version a dotnet tool
[x] Handle command-line input

[ ] Load json chat to execute
[ ] Save output to a file

Load input from a file? or multiples adding a header 1/2 2//2 etc.
Only textfiles, code, markdown, json, yml etc.
Thanks for building the neatest desktop client out there!

Load input from a file? or multiples adding a header 1/2 2//2 etc.
Only textfiles, code, markdown, json, yml etc.
Thanks for building the neatest desktop client out there!

Yes this is planned, the details may vary.

@cocoonkid You can try it here https://twitter.com/dotMorten/status/1641188674208661505 soon will release dotnet tool


Find ALL files named *.old, not just *.php.old

There are other files in the vendor folder, they are not only .php files there, and sometimes these files need patching too. For example *.js or *.css files. Since the behavior of only finding *.php.old files is not mentioned in the documentation, nor implied in the package's name ("vendor-patches"), nor particularly useful for anything else than a speed optimization (and probably not even that), I removed this artificial limitation.

The check failed and refers to a repository that no longer exists. The repository you mention in #1 is marked as "read-only". I'm confused and leaving it here.

                 Hi, thank you for your contribution.

                    Unfortunately, this repository is read-only. It's a split from our main monorepo repository.
                    We'd like to kindly ask you to move the contribution there - https://github.com/symplify/symplify.
                    We'll check it, review it and give you feed back right way.
                    Thank you


Formatting issue on TOML and text files links - Newlines removed

Storing files using paste.toml as name and TOML content produces a link to file that displays non valid TOML file with all new lines removed. I've noticed similar issue with text format also. JSON files with .json extension are displayed correctly.
Original toml:
# This is a TOML document

title = "TOML Example"

[owner]
name = "Tom Preston-Werner"
dob = 1979-05-27T07:32:00-08:00

[database]
enabled = true
ports = [ 8000, 8001, 8002 ]
data = [ ["delta", "phi"], [3.14] ]
temp_targets = { cpu = 79.5, case = 72.0 }

[servers]

[servers.alpha]
ip = "<IP_ADDRESS>"
role = "frontend"

[servers.beta]
ip = "<IP_ADDRESS>"
role = "backend"

Result on the link:
# This is a TOML document title = "TOML Example" [owner] name = "Tom Preston-Werner" dob = 1979-05-27T07:32:00-08:00 [database] enabled = true ports = [ 8000, 8001, 8002 ] data = [ ["delta", "phi"], [3.14] ] temp_targets = { cpu = 79.5, case = 72.0 } [servers] [servers.alpha] ip = "<IP_ADDRESS>" role = "frontend" [servers.beta] ip = "<IP_ADDRESS>" role = "backend"

However using the load button inside the editor can still retrieve a well formatted toml file. Issue seems is when you open the file link.
https://nosdav.net/...................../paste.toml

I've tested with json file and there was no issue.

Thanks, I dont yet support .toml mime type, which are listed here:
https://github.com/nosdav/server/blob/gh-pages/index.js#L50
I'll try and fix this later today and redeploy the server

I've compared the source of the web pages between Nosdav and gitlab snippet and found that snippests and other services shows the plain content while Nosdav render it differently:
The content are inserted in html tags. Your test.toml file after saving from the webpage.

<meta http-equiv="content-type" content="text/html; charset=windows-1252"># This is a TOML document

title = "TOML Example"

[owner]
name = "Tom Preston-Werner"
dob = 1979-05-27T07:32:00-08:00

[database]
enabled = true
ports = [ 8000, 8001, 8002 ]
data = [ ["delta", "phi"], [3.14] ]
temp_targets = { cpu = 79.5, case = 72.0 }

[servers]

[servers.alpha]
ip = "<IP_ADDRESS>"
role = "frontend"

[servers.beta]
ip = "<IP_ADDRESS>"
role = "backend"

the view source shows this:

Seems the website is using some type of rendering and not the raw content on the link.
Here is the same content in Gitlab snippet for compression
https://gitlab.com/-/snippets/3708145/raw/main/TOML.toml

Also notice that content-type is text/html while in snippets it's text/plain; charset=utf-8

Also notice that content-type is text/html while in snippets it's text/plain; charset=utf-8

Yes, that could be fixed, do you know the correct mime type of .toml?  My research shows me it is application/toml but im not 100% sure.  But this might trigger a download from the browser, which might even be a worse UX.

My research shows me it is application/toml but im not 100% sure.

True. https://toml.io/en/v0.5.0#mime-type
The link says "file" with download icon so I supposed that is what it should be doing, right?


Print periodic info line at 0.2 Hz

Codecov Report

Merging #443 into master will decrease coverage by 0.3%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #443      +/-   ##
==========================================
- Coverage   73.62%   73.31%   -0.31%
==========================================
  Files         382      382
  Lines       17230    17263      +33
==========================================
- Hits        12686    12657      -29
- Misses       4544     4606      +62

Impacted Files
Coverage Δ

src/system/accountant.cpp
0% <0%> (-24.78%)
:arrow_down:

vast/system/accountant.hpp
10% <0%> (-12.23%)
:arrow_down:

vast/query_options.hpp
61.53% <0%> (-7.7%)
:arrow_down:

src/system/node.cpp
49.63% <0%> (-1.46%)
:arrow_down:

src/system/tracker.cpp
71.58% <0%> (-0.61%)
:arrow_down:

src/system/spawn_node.cpp
0% <0%> (ø)
:arrow_up:

src/system/index.cpp
71.33% <0%> (+0.73%)
:arrow_up:

Continue to review full report at Codecov.

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

Codecov Report

Merging #443 into master will decrease coverage by 0.3%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #443      +/-   ##
==========================================
- Coverage   73.62%   73.32%   -0.31%
==========================================
  Files         382      382
  Lines       17230    17261      +31
==========================================
- Hits        12686    12657      -29
- Misses       4544     4604      +60

Impacted Files
Coverage Δ

src/system/accountant.cpp
0% <0%> (-24.78%)
:arrow_down:

vast/system/accountant.hpp
10% <0%> (-12.23%)
:arrow_down:

vast/query_options.hpp
61.53% <0%> (-7.7%)
:arrow_down:

src/system/node.cpp
49.63% <0%> (-1.46%)
:arrow_down:

src/system/tracker.cpp
71.58% <0%> (-0.61%)
:arrow_down:

src/system/spawn_node.cpp
0% <0%> (ø)
:arrow_up:

src/system/index.cpp
71.33% <0%> (+0.73%)
:arrow_up:

Continue to review full report at Codecov.

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

Codecov Report

Merging #443 into master will decrease coverage by 0.3%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #443      +/-   ##
==========================================
- Coverage   73.62%   73.32%   -0.31%
==========================================
  Files         382      382
  Lines       17230    17261      +31
==========================================
- Hits        12686    12657      -29
- Misses       4544     4604      +60

Impacted Files
Coverage Δ

src/system/accountant.cpp
0% <0%> (-24.78%)
:arrow_down:

vast/system/accountant.hpp
10% <0%> (-12.23%)
:arrow_down:

vast/query_options.hpp
61.53% <0%> (-7.7%)
:arrow_down:

src/system/node.cpp
49.63% <0%> (-1.46%)
:arrow_down:

src/system/tracker.cpp
71.58% <0%> (-0.61%)
:arrow_down:

src/system/spawn_node.cpp
0% <0%> (ø)
:arrow_up:

src/system/index.cpp
71.33% <0%> (+0.73%)
:arrow_up:

Continue to review full report at Codecov.

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

Codecov Report

Merging #443 into master will decrease coverage by 0.3%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #443      +/-   ##
==========================================
- Coverage   73.62%   73.32%   -0.31%
==========================================
  Files         382      382
  Lines       17230    17261      +31
==========================================
- Hits        12686    12657      -29
- Misses       4544     4604      +60

Impacted Files
Coverage Δ

src/system/accountant.cpp
0% <0%> (-24.78%)
:arrow_down:

vast/system/accountant.hpp
10% <0%> (-12.23%)
:arrow_down:

vast/query_options.hpp
61.53% <0%> (-7.7%)
:arrow_down:

src/system/node.cpp
49.63% <0%> (-1.46%)
:arrow_down:

src/system/tracker.cpp
71.58% <0%> (-0.61%)
:arrow_down:

src/system/spawn_node.cpp
0% <0%> (ø)
:arrow_up:

src/system/index.cpp
71.33% <0%> (+0.73%)
:arrow_up:

Continue to review full report at Codecov.

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

Codecov Report

Merging #443 into master will decrease coverage by 0.3%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #443      +/-   ##
==========================================
- Coverage   73.62%   73.32%   -0.31%
==========================================
  Files         382      382
  Lines       17230    17261      +31
==========================================
- Hits        12686    12657      -29
- Misses       4544     4604      +60

Impacted Files
Coverage Δ

src/system/accountant.cpp
0% <0%> (-24.78%)
:arrow_down:

vast/system/accountant.hpp
10% <0%> (-12.23%)
:arrow_down:

vast/query_options.hpp
61.53% <0%> (-7.7%)
:arrow_down:

src/system/node.cpp
49.63% <0%> (-1.46%)
:arrow_down:

src/system/tracker.cpp
71.58% <0%> (-0.61%)
:arrow_down:

src/system/spawn_node.cpp
0% <0%> (ø)
:arrow_up:

src/system/index.cpp
71.33% <0%> (+0.73%)
:arrow_up:

Continue to review full report at Codecov.

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

Codecov Report

Merging #443 into master will decrease coverage by 0.3%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #443      +/-   ##
==========================================
- Coverage   73.62%   73.32%   -0.31%
==========================================
  Files         382      382
  Lines       17230    17261      +31
==========================================
- Hits        12686    12657      -29
- Misses       4544     4604      +60

Impacted Files
Coverage Δ

src/system/accountant.cpp
0% <0%> (-24.78%)
:arrow_down:

vast/system/accountant.hpp
10% <0%> (-12.23%)
:arrow_down:

vast/query_options.hpp
61.53% <0%> (-7.7%)
:arrow_down:

src/system/node.cpp
49.81% <0%> (-1.28%)
:arrow_down:

src/system/tracker.cpp
71.58% <0%> (-0.61%)
:arrow_down:

src/system/spawn_node.cpp
0% <0%> (ø)
:arrow_up:

src/system/exporter.cpp
67.05% <0%> (ø)
:arrow_up:

src/system/index.cpp
71.33% <0%> (+0.73%)
:arrow_up:

Continue to review full report at Codecov.

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

Codecov Report

Merging #443 into master will decrease coverage by 0.3%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #443      +/-   ##
==========================================
- Coverage   73.62%   73.32%   -0.31%
==========================================
  Files         382      382
  Lines       17230    17261      +31
==========================================
- Hits        12686    12657      -29
- Misses       4544     4604      +60

Impacted Files
Coverage Δ

src/system/accountant.cpp
0% <0%> (-24.78%)
:arrow_down:

vast/system/accountant.hpp
10% <0%> (-12.23%)
:arrow_down:

vast/query_options.hpp
61.53% <0%> (-7.7%)
:arrow_down:

src/system/node.cpp
49.81% <0%> (-1.28%)
:arrow_down:

src/system/tracker.cpp
71.58% <0%> (-0.61%)
:arrow_down:

src/system/spawn_node.cpp
0% <0%> (ø)
:arrow_up:

src/system/exporter.cpp
67.05% <0%> (ø)
:arrow_up:

src/system/index.cpp
71.33% <0%> (+0.73%)
:arrow_up:

Continue to review full report at Codecov.

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