Guardian Recovery Flow and Chain Calls

1 - Open app - tap "I lost my key" small link somewhere
2 - On "I lost my key" - screen prompting user to enter their username
3 - Wallet creates new keypair and encodes the public key as firebase link - or just direct wallet link. It stores the private key.
4 - Screen prompts user to contact his guardians, and send each of them the recovery link via messenger or another messaging app
5 - App goes inot "recovery mode"- waiting for 3 signatures, displaying the link for copy/paste purposes.
Guardian 1

Taps link gets screen explaining it's very serious and they must be sure they got this link from their friend - ideally make a phone all or message the friend back to verify.
Button "Recover" -> This sends the public key in the link to the guardian contract
An emergency notification is sent to the original account - in case they are still logged in somewhere, they can cancel the recovery and mark it scammy.

Guardian 2 - same thing
Guardian 3 - same thing plus the app notices that the signatures are complete, and fires off the multisig request to change the account key with 24h wait.
Emergency message sent to original account
Original account still logged in

Received emergency message, can stop recovery with button click - call into guardian contract to cancel recovery.

wrong project this is for light wallet


Not found page

Added 404 not found error handling

Just question the need for NotfoundController, everything else okay.

Wrapping it in a controller makes it work with the transitions

We need to seperate FalcorController to inherit from TransitionChild but we can do that in a later commit.


Vulnerability roundup 104: openvpn-2.5.2: 1 advisory [7.8]

search, files

[ ] CVE-2021-3606 CVSSv3=7.8 (nixos-unstable)

CVE details
CVE-2021-3606
OpenVPN before version 2.5.3 on Windows allows local users to load arbitrary dynamic loadable libraries via an OpenSSL configuration file if present, which allows the user to run arbitrary code with the same privilege level as the main OpenVPN process (openvpn.exe).

Scanned versions: nixos-unstable: 1905f5f2e55.
Cc @peterhoeg
Cc @viric

Upstream says "Windows only".


Upgrade version (and upgrade definition-header while we're at it)

Should wait on #32.
If this is merged I will npm publish a new version.

This is no longer relevant.


phyto-matter on smart phone

the website looks messed up when viewed on a smart phone. Can you please offer a simplifies view that shows the home page intro, the video, and says that Phyto-Matter functionality works best from a computer browser?

I will look into it.

Fixed in #22

mobile view still looks funky.

@Meowmir please merge the pr

merged and published, its live

Wonderful! Thanks!


Move CustomHelpController to it's own demo bot

Bug Report
I've commented this out in demo-bot, since it doesn't work with teams.  Can we either fix it, or move to a new project and document it that it only works with Symphony?
I guess it'd be really nice if we had a template for teams too.

It needed a Profile setting fix. Have added that now - This way Custom Help will be triggered when bot is deployed just to Symphony alone.


feat(nx-ghpages): add option to customize commit message to gh-pages

@all-contributors add tinesoft for code


Extract some header-management code [phab:D934]

Created by zarko at 2016-06-16 01:08:41:
This moves most header state extraction/(de)serialization
code to cxx_details.

fromberger commented inline (context lost during migration) at 2016-06-16 13:57:20:
Please document what it means for the state of *this when false is returned. Specifically: Is it essentially garbage at that point, or is it just missing some information?

shahms commented inline (context lost during migration) at 2016-06-16 15:40:16:
system_prefixes.push_back({prefix.Prefix, prefix.IsSystemHeader});

shahms commented inline (context lost during migration) at 2016-06-16 15:40:16:
nit: i says "index" to me; make this iter ?

shahms wrote at 2016-06-16 15:40:16:
Some minor nits

zarko wrote at 2016-06-16 21:08:03:

Address comments.

shahms accepted this revision at 2016-06-16 21:13:45

zarko closed via commit d13e77de59ae8720f143adeed149a314df4f0537 at 2016-06-16 21:14:31


Parse out http/https in the address field when creating custom registries

There have been multiple users who have accidentally put in the http or https in the Address, which has caused their private registry fail to connect.
Add a hint to the user.

https://github.com/rancher/ui/pull/718

why not make it even easier - parse the entered URI and strip it yourself if present. No docs, no hint, not possible errors :)

Version - master 6/9
Hint added, keeping issue open and moving to 1.2.0 for Parsing addition.

Added to validation

Version - master 11/6
Verified fixed


Dispatcher taking ~10min to reconnect after being disconnected

Describe the bug
A clear and concise description of what the bug is.
We have been seeing that the dispatcher taking typically 10min if not longer to reconnect to the rabbitmq cluster server. The disconnect usually happens when the node is being upgraded. We have monitoring on the rabbitmq_detailed_queue_consumers metrics to track when the dispatcher [consumer] is no longer registered with the rabbitmq cluster.
Due to the extended period of time where there is no consumer for a given queue, we naturally see a large backlog of queued messages until we manually restart the dispatcher to re-register the consumer or wait 10+ min for it to see the disconnect.
Expected behavior
A clear and concise description of what you expected to happen.
i expect the dispatcher to more aggressively re-register itself as a consumer when there is a disconnect from the rabbitmq cluster. another option is to have a knob that is configurable to control how quickly it attempts to reconnect.
To Reproduce
Steps to reproduce the behavior.

have knative eventing running with rabbitmq with 3 replicas, with each replica running on a different node
restart or recreate the node current rabbitmq master pod is running on

Knative release version
v1.10.0
Additional context
Add any other context about the problem here such as proposed priority
this is a recurring annoyance as each time our cloud provider upgrade our nodes, we have a message backlog build up.

Hey @k4leung4 ! How are you?
Nice discovery this one, could you possibly attach some logs from the dispatcher and the rabbitmq server while it fails and try to reconnect?
Let's get a bit more context, I'll try to replicate it myself, and then debug

from the rabbitmq metric, it looks like when there was a new leader election, the dispatcher stopped being recognized on the old leader (cluster-server-2), and when the new leader came online it, it took ~10minutes for it to fully registered there (cluster-server-0).
logs from rabbitmq cluster-server
this statefulset has 3 replicas; cluster-server-{0-2}
INFO 2023-07-20T16:10:45.138817761Z [resource.labels.containerName: rabbitmq] 2023-07-20 16:10:45.137884+00:00 [info] <0.703.0> queue 'eventing-system.faux-informer-record-updated.670fedb0-2a88-4e17-a293-d6ab1eba6ff1' in vhost '/': Leader monitor down with shutdown, setting election timeout
INFO 2023-07-20T16:10:45.139339519Z [resource.labels.containerName: rabbitmq] 2023-07-20 16:10:45.138025+00:00 [info] <0.660.0> queue 'eventing-system.faux-informer-record-updated.670fedb0-2a88-4e17-a293-d6ab1eba6ff1' in vhost '/': Leader monitor down with shutdown, setting election timeout
INFO 2023-07-20T16:10:45.184454017Z [resource.labels.containerName: rabbitmq] 2023-07-20 16:10:45.184185+00:00 [info] <0.703.0> queue 'eventing-system.faux-informer-record-updated.670fedb0-2a88-4e17-a293-d6ab1eba6ff1' in vhost '/': granting vote for<EMAIL_ADDRESS>with last indexterm {108392811,104} for term 105 previous term was 104
INFO 2023-07-20T16:10:45.193339224Z [resource.labels.containerName: rabbitmq] 2023-07-20 16:10:45.192967+00:00 [notice] <0.660.0> queue 'eventing-system.faux-informer-record-updated.670fedb0-2a88-4e17-a293-d6ab1eba6ff1' in vhost '/': candidate -> leader in term: 105 machine version: 3
INFO 2023-07-20T16:10:45.193966366Z [resource.labels.containerName: rabbitmq] 2023-07-20 16:10:45.193583+00:00 [info] <0.703.0> queue 'eventing-system.faux-informer-record-updated.670fedb0-2a88-4e17-a293-d6ab1eba6ff1' in vhost '/': detected a new leader<EMAIL_ADDRESS>in term 105
INFO 2023-07-20T16:12:04.009244228Z [resource.labels.containerName: rabbitmq] 2023-07-20 16:12:04.008828+00:00 [info] <0.709.0> queue 'eventing-system.faux-informer-record-updated.670fedb0-2a88-4e17-a293-d6ab1eba6ff1' in vhost '/': detected a new leader<EMAIL_ADDRESS>in term 105

from the dispatcher
INFO 2023-07-20T16:24:28.542120339Z [resource.labels.podName: faux-informer-record-updated-dispatcher-745c7cb87-8j7s5] [resource.labels.containerName: dispatcher] {"caller":"rabbit/connections_handler.go:160", "commit":"d9f5856-dirty", "level":"info", "logger":"rabbitmq-dispatcher", "msg":"stopped watching for rabbitmq connections", "ts":"2023-07-20T16:24:28.541Z"}
INFO 2023-07-20T16:24:30.813907352Z [resource.labels.podName: faux-informer-record-updated-dispatcher-745c7cb87-85dcb] [resource.labels.containerName: dispatcher] {"backoffDelay":0.1, "caller":"dispatcher/main.go:86", "commit":"d9f5856-dirty", "level":"info", "logger":"rabbitmq-dispatcher", "msg":"Setting BackoffDelay", "ts":"2023-07-20T16:24:30.813Z"}
ERROR 2023-07-20T16:24:30.833336141Z [resource.labels.podName: faux-informer-record-updated-dispatcher-745c7cb87-85dcb] [resource.labels.containerName: dispatcher] {"caller":"rabbit/connections_handler.go:147", "commit":"d9f5856-dirty", "level":"error", "logger":"rabbitmq-dispatcher", "msg":"failed to create RabbitMQ connection, error: dial tcp <IP_ADDRESS>:5672: connect: connection refused", "stacktrace":"knative.dev/eventing-rabbitmq/pkg/rabbit.(*RabbitMQConnectionHandler).createConnectionAndChannel knative.dev/eventing-rabbitmq/pkg/rabbit/connections_handler.go:147 knative.dev/eventing-rabbitmq/pkg/rabbit.(*RabbitMQConnectionHandler).Setup knative.dev/eventing-rabbitmq/pkg/rabbit/connections_handler.go:118 main.main knative.dev/eventing-rabbitmq/cmd/dispatcher/main.go:102 runtime.main runtime/proc.go:250", "ts":"2023-07-20T16:24:30.833Z"}
INFO 2023-07-20T16:24:31.867436158Z [resource.labels.podName: faux-informer-record-updated-dispatcher-745c7cb87-85dcb] [resource.labels.containerName: dispatcher] {"caller":"dispatcher/dispatcher.go:92", "commit":"d9f5856-dirty", "level":"info", "logger":"rabbitmq-dispatcher", "msg":"rabbitmq receiver started, exit with CTRL+C", "ts":"2023-07-20T16:24:31.867Z"}
INFO 2023-07-20T16:24:31.867519658Z [resource.labels.podName: faux-informer-record-updated-dispatcher-745c7cb87-85dcb] [resource.labels.containerName: dispatcher] {"caller":"dispatcher/dispatcher.go:93", "commit":"d9f5856-dirty", "level":"info", "logger":"rabbitmq-dispatcher", "msg":"Starting to process messages", "queue":"eventing-system.faux-informer-record-updated.670fedb0-2a88-4e17-a293-d6ab1eba6ff1", "ts":"2023-07-20T16:24:31.867Z", "workers":25}

timeline as combined from metrics, rabbitmq logs, and dispatcher logs
16:10:45 - leader election transferred dispatcher from cluster-server-2 to cluster-server-0
16:11:xx - metric indicate last consumer registered on cluster-server-2
16:12:04 - dispatcher detected a new leader again on cluster-server-0
16:13:xx - metric indicate last no consumer registered on cluster-server-0
… [no logs from dispatcher or rabbitmq during this timeframe]
… [why did dispatcher not register with cluster-server-0]
16:2[34?] - dispatcher pod was deleted
16:24:38 - dispatcher stopped watching fro rabbitmq connection
16:24:30 - failed to connect to rabbitmq - likely due to istio proxy not ready yet
16:24:31 - establish connection with rabbitmq
16:25:XX - metric indicates consumer registered

I think we noticed the same issue today as well. There was a restart/reschedule of a rabbitmq node and the dispatcher was basically blocked for over 60 minutes until we manually restarted the dispatcher pod.

Seems to be getting a ctx.Done() signal when this happens, I'm currently investigating a bit more and see if I can find a good solution by next week. Thank you very much for the detailed info 🙂

Just to be sure, RabbitMQ credentials are not changing during the restart of the node/??

In my case, no, the credentials are not changing during the restart of the node.

@k4leung4 I'm not able to reproduce this from gcloud, any change I can see your setup/cluster or a custom setup replicating this case? I tried in gcloud upgrading and nothing it reconnects fine.
Some more questions, are you using the RabbitMQ Cluster Operator? or the connection secret?

@gabo1208
we are using the RabbitMQ Cluster Operator.
below is our cluster.yaml
apiVersion: rabbitmq.com/v1beta1
kind: RabbitmqCluster
metadata:
  name: cluster
  namespace: rabbitmq
  annotations:
    rabbitmq.com/topology-allowed-namespaces: "*"
spec:
  # Odd number, tolerant to up to (n - 1 / 2) replicas
  replicas: 3

  override:
    statefulSet:
      spec:
        template:
          spec:
            containers:
            - name: rabbitmq
              resources: {}
              securityContext:
                allowPrivilegeEscalation: false
                runAsNonRoot: true
            initContainers:
            - name: setup-container
              resources: {}
              securityContext:
                allowPrivilegeEscalation: false
                runAsNonRoot: true

  resources:
    requests:
      cpu: "3"
      memory: 6Gi
    limits:
      cpu: "3"
      memory: 6Gi

  rabbitmq:
    additionalPlugins:
      - rabbitmq_prometheus

    # ref: https://www.rabbitmq.com/production-checklist.html
    additionalConfig: |
      # best support when clustering across zones in a single region (which we configure through PAA below)
      # ref: https://www.rabbitmq.com/partitions.html#options
      cluster_partition_handling = pause_minority

      vm_memory_high_watermark_paging_ratio = 0.75

      # ensures new messages are blocked when available disk space blocks below 1.5x the allocated memory
      disk_free_limit.relative = 1.5

      collect_statistics_interval = 10000

      # Log to console and not to file, at `info` level
      log.console = true
      log.file = false
      log.console.level = info

      # Grant default user permission to login to management UI.
      # https://www.rabbitmq.com/management.html#permissions
      default_user_tags.management = true

  persistence:
    # Defined by GKE PD CSI driver for binding to SSD persistent disks
    # We use this over the default HD PD
    storageClassName: premium-rwo
    storage: "250Gi"

  affinity:
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
        # favor pods on different nodes
        - podAffinityTerm:
            labelSelector:
              matchLabels:
                app.kubernetes.io/name: cluster
                app.kubernetes.io/component: rabbitmq
            topologyKey: "kubernetes.io/hostname"
          weight: 100
        # favor pods in different zones
        - podAffinityTerm:
            labelSelector:
              matchLabels:
                app.kubernetes.io/name: cluster
                app.kubernetes.io/component: rabbitmq
            topologyKey: "topology.kubernetes.io/zone"
          weight: 100

---
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: cluster-rollout
  namespace: rabbitmq
spec:
  maxUnavailable: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: cluster
      app.kubernetes.io/component: rabbitmq

hope this doesnt jinx it, but since upgrading to the 1.11.x release, the issue hasnt surfaced again
@lpfann have you had a chance to upgrade to 1.11.x? if so, do you still experience the issue?

Still happening in 1.11 unfortunately. It seems like it is not recovering automatically.
When one of the rabbit nodes goes offline the dispatcher is connected to it will silently stop working.
There are no log messages indicating anything changing in the dispatcher.
This is our cluster config:
apiVersion: rabbitmq.com/v1beta1
kind: RabbitmqCluster
metadata:
  name: {{ .Values.rabbitmq.name }}
  namespace: knative-eventing
  annotations:
    # We allow any Knative Broker of class RabbitMQBroker,
    # in any namespace,
    # to declare objects against this RabbitMQ cluster
    rabbitmq.com/topology-allowed-namespaces: "*"

spec:
  replicas: {{ .Values.rabbitmq.replicas }}
  resources:
    {{- toYaml .Values.rabbitmq.resources | nindent 4 }}
  persistence:
    storageClassName: {{ .Values.rabbitmq.storageClassName }}
    storage: {{ .Values.rabbitmq.storage}}
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
            - key: app.kubernetes.io/name
              operator: In
              values:
              - {{ .Values.rabbitmq.name }}
        topologyKey: kubernetes.io/hostname
  override:
    statefulSet:
      spec:
        template:
          spec:
            containers: []
            topologySpreadConstraints:
            - maxSkew: 1
              topologyKey: "topology.kubernetes.io/zone"
              whenUnsatisfiable: DoNotSchedule
              labelSelector:
                matchLabels:
                  app.kubernetes.io/name: {{ .Values.rabbitmq.name }}
---
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: pdb-rabbitmq-knative-eventing
  namespace: knative-eventing
spec:
  maxUnavailable: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: {{ .Values.rabbitmq.name }}

and broker
apiVersion: eventing.knative.dev/v1
kind: Broker
metadata:
  annotations:
    eventing.knative.dev/broker.class: RabbitMQBroker
  name: {{ .Values.knative.brokerName}}
  namespace: {{ .Values.Namespace}}

I was working on monitoring dashboards for the RabbitMQ metrics today and noticed a think related to this issue.
I was plotting the number of ready and unacked messages in the queues.
While debugging i noticed the timeframe of the last RabbitMQ node restart which leads to the blocking issue described here.
It appears as if the dispatcher did actually reconnect to a node. The number of unacked (in-flight) increased (but the logs did not show any more cloud events getting sent to the sink).
But no messages were acknowledged in that timeframe even though more messages were claimed.
Only restarting the dispatcher pod unblocked the issue.

https://github.com/knative-extensions/eventing-rabbitmq/pull/1215 This pull aims to solve this issue introducing "soft" and "hard" reconnections so edge cases like this one does not affect the overall user experience :)

Next Tuesday this should be released 👍🏼


Community activation concept designs for website

As response to https://github.com/carbon-design-system/carbon-website/pull/1479#discussion_r467232137, we should outline some of the concept work, with screenshots, in an issue (rather than just a Sketch file). Allows for more discussion.

https://www.carbondesignsystem.com/whats-happening/work-in-progress


fix unittests

[x] test_remove_duplicates (TypeError)
[x] test_summarize_ranges (AssertionError)
[ ] test_full_path (AssertionError)
[ ] test_simplify_path (AssertionError)

Working on it

test_full_path (AssertionError)
Is not fixable due to the fact that test created for Unix based systems and the code of full_path.py algorithm uses os library to identify full path.
And since we are using Windows based machines - we have an error during testing.


Camera uses wrong orientation on tablets - Android AND iOS

Steps to Reproduce
I have conducted an evaluation utilizing the test example provided in the repository. When employing CameraAwesomeBuilder.awesome, an observation indicates a 45-degree rotation of the screen. This anomaly is consistently observed on both Android and iOS tablets.
Notably, both the camera view and the AwesomeOrientedWidget appear misaligned. In an attempt to rectify this issue, I experimented with various configurations of the 'getNativeOrientation' function, revealing an apparent reversal in orientations.
If it were a Flutter-related issue, I would be willing to address and resolve the problem. However, it appears that the EventChannel('camerawesome/orientation') is emitting incorrect signals, and I currently lack clarity on how to rectify this issue.
For tablets it seems:
landscape_left corresponds to portrait_up
landscape_right corresponds to portrait_down
portrait_up corresponds to landscape_right
portrait_down corresponds to landscape_left
Expected results
What it should be
Orientations works fine on both android and iOS phones, which is the expected behavior for tablets as well.
Actual results
What you see

About your device

Brand
Model
OS

Emulator
Pixel C
All

Apple
Ipad
All

Your flutter version
Run this in your command line
flutter --version
Flutter 3.10.5 • channel unknown • unknown source
Framework • revision 796c8ef792 (6 months ago) • 2023-06-13 15:51:02 -0700
Engine • revision 45f6e00911
Tools • Dart 3.0.5 • DevTools 2.23.1

Will look if there is a clean way to detect tablets and rotate the preview.

Let me know if I can do anything to help

@g-apparence In progress on this issue?

@g-apparence Are there any progress on this issue? :)

@g-apparence Hi! Our clients are getting more and more impatient about this issue, since a lot of them uses iPads in their day-to-day work, and they feel like they have been patient until now :(
Do you have any way to prioritize this issue? Thank you in advance.

I know that is because camera awesome has the orientation fixed to portrait up, and that works really well on phones, since the buttons only need to rotate in their own axis.
However in tablets, there is a roatation and displacement of the layout, you can see the animation if you open the native camera and rotate it in a tablet.
You could make a workaround by having widgets to appear and dissapear depending on the orientation, and locking and unlocking screen rotation on demand, but it's only a workaround.
There should be a different type of rotation for bigger screens like tablets, since locking and unlocking the rotation makes quite annoying animations that affect user experience. For example when you try to open the gallery while having the orientation fixed in the camera screen, locks also the orientation of the gallery and it's annoying. Hope they make a proper solution in the near future. But it's understandable that don't make it as fast since they probably have other issues and commitments apart from the plugin itself. Just be patient :)

I achieved a solution for this

Took me a couple of hours and that's not that easy to have time these days.
As DevNim told you I don't get any money from this plugin. I'm still working on it but I have a lot of work aside.
Anyway I've posted the current fix #432 here.
Please test it before I can merge. I have tested this on emulators but as I don't have any real device I would prefer some real tests before merging it.

I achieved a solution for this

Took me a couple of hours and that's not that easy to have time these days. As DevNim told you I don't get any money from this plugin. I'm still working on it but I have a lot of work aside.
Anyway I've posted the current fix #432 here. Please test it before I can merge. I have tested this on emulators but as I don't have any real device I would prefer some real tests before merging it.

I will look into testing this as soon as possible.

Should be fixed with last PR #448

Should be fixed with last PR #448

I've attempted updating to 'camerawesome: ^2.0.1', yet the issue persists. When I lock the OS orientation to portrait mode and then switch to landscape, it functions as expected - the camera button rotates correctly. However, relying on this workaround isn't feasible. I'm beginning to believe we need to do like the 'camera' package where the orientation doesn't seem to be locked, to achieve the desired behaviors.
Please consider opening the issue again, as the problem as not been fixed.
@g-apparence

I still get the issue event with your latest commit on master (d1ebd5cf214fc9291d416c1b9b0bcff6f9b43513), do you plan to work on it ?

@g-apparence sorry to bother you with this again, but the problem still persists. Could you please reopen this issue? We tried forking the project to solve it ourselves but are clearly not camera-experts enough to solve it, sorry :(


[BUG]:Mandatory parameters in a yaml based build/release task extension is not being validated during parsing, and gets detected only during runtime unlike its behavior in the classic pipeline.

Task name
No response
Task version
No response
Environment type (Please select at least one enviroment where you face this issue)

[ ] Self-Hosted
[x] Microsoft Hosted
[ ] VMSS Pool
[ ] Container

Azure DevOps Server type
dev.azure.com (formerly visualstudio.com)
Azure DevOps Server Version (if applicable)
No response
Operation system
All
Task log
-

Relevant log output
-

Aditional info
Mandatory parameters in a yaml based build/release task extension is not being validated during parsing and gets detected only during runtime unlike the classic pipeline. We have published a task extension in msazure org, which a lot of teams would be leveraging for pre-prod (shift-left) validation of their services. (https://marketplace.visualstudio.com/manage/publishers/azconductor/extensions/azconductor-wf-trigger-task/hub)

This gives a varying user experience for the users of our task extension. Our component preprod-validation task extension is plugged in at the far end of a build pipeline of several services, few of which will have their pipelines in classic and other in yaml based. The mandatory params validation kicks off only after the entire pipeline run and then fails the task, and we lose that build event which has repercussions for us.

      So similar to classic pipeline, could the save be enabled only if the parsing and validation succeeds? Currently the Validation button just checks for cursory syntax errors, highlights if the value of a dropdown is different and does not leverage the task.json like the classic pipeline does.

Hi @a-aarchana could you please share more details about your issue?
Do you mention the need to validate parameters directly in the YAML editor?

Behavior of parameter validation in classic/yaml based:
Classic: In the task.json file if a field is marked as mandatory, one cannot save the pipeline or create a release unless the field value is entered.
Yaml Based: With/without the use of assistant, yaml editor allows the creation/edit of pipeline and hence a run of it, even if the mandatory fields are missing or its value is not entered, it prompts in few cases but not all. The VALIDATE button does not validate the yaml, like the classic pipeline. So, the absence of a mandatory field can be caught only during the run and not instantly, during the create/edit of pipeline.
Hope this explains the issue. I tried several options but couldn't find any solution to this.

As an eg: build id is a mandatory field, and its value is empty in the yaml editor, nevertheless validation passes and absence of it is caught during runtime

@a-aarchana thanks for the detailed description.
This issue seems to be related to AzureDevOps. I suggest opening a ticket on https://developercommunity.visualstudio.com/AzureDevOps as this repo is mostly for pipeline tasks

I am closing this for now.
If you have any additional questions feel free to reopen it.


Enable snapshotter to make snapshots without pulling the contents

This commit allows snapshotter to prepare snapshots as well as to prevent the
client from downloading the layer's contents. This hopefully enables to reduce
time for pulling the image. The client passes basic information of the image
layer(ref, digest) to the snapshotter as labels and the snapsohtter can use or
simply ignore it.
This commit also includes changes on ctr command to make using this
functionality easier.
This commit depends on PR #3793 because the implementation uses the target snapshot reference functionality. So this is a little bit early, but I raised this PR also for discussion based on the concrete implementation.
This functionality enables remote snapshots(discussed on the issue #3731) and you can test it with current remote snapshotter implementation on:

https://github.com/ktock/remote-snapshotter/tree/filter-by-snapshotter-test

The step of the demo:

https://github.com/ktock/remote-snapshotter/tree/filter-by-snapshotter-test#demo

Codecov Report

Merging #3846 into master will increase coverage by 0.1%.
The diff coverage is 60.46%.

@@            Coverage Diff            @@
##           master    #3846     +/-   ##
=========================================
+ Coverage   42.27%   42.37%   +0.1%
=========================================
  Files         130      131      +1
  Lines       14577    14663     +86
=========================================
+ Hits         6162     6214     +52
- Misses       7501     7533     +32
- Partials      914      916      +2

Flag
Coverage Δ

#linux
45.81% <61.53%> (+0.08%)
:arrow_up:

#windows
37.44% <60.46%> (+0.16%)
:arrow_up:

Impacted Files
Coverage Δ

snapshots/handler/handler.go
60.46% <60.46%> (ø)

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 383f4a7...27deca8. Read the comment docs.

@dmcgowan Thank you very much for the discussion on the mini-summit@kubecon! This PR is related to the discussion and your #3793, could you look at this?

#3793 is merged

This should completely address #3731 right?

@siscia Yes, this PR is for #3731 and current remote snapshotter implementation is https://github.com/ktock/remote-snapshotter .
But this PR implementation is a little bit more general because we can leverage this functionality also for other kinds of optimization e.g. discussed in https://github.com/containerd/containerd/pull/3846#discussion_r350118476

Many thanks!
I want to take another round of implementation to make this remote snapshotter work on CVMFS, it won't be immediate because I see a lot of changes from my last attempt but it seems like all the pieces are in place. Hopefully I will report a success! :)

@ktock thanks for opening this!
I am currently working on an unpacker refactor which may allow this to be even easier. I will update more next week.

Will the interfacce stay the same or it will be a completely new interface?
In other words, does it make sense that I work toward a cvmfs snapshotter or it will be a water effort?

@siscia just refactoring some of the client side unpack code, the snapshotter interface will not be changing. Let me know if you have any issues with implementing the latest snapshotter updates related to managing the ref label.

Based on the code from @ktock I wrote a small PR that should enable to work also on /cvmfs
https://github.com/ktock/remote-snapshotter/pull/4
It is still a work in progress with hardcoded path, but it should be the way forward IMHO.
It still doesn't work as I expected, giving error: "Too many levels of symbolic links" which is a quite standard error when playing with this things...

Let me report that the remote-snapshotter seems to work also for our use case.
The error I reported above was due to autofs and it was easily fixed using the :shared flag in the volume that bindmount cvmfs inside the container. And this should be necessary only because I was using docker-compose.
The PR I provided is not yet in shape to be merged, but honestly we would need a little bit of discussion on our side to understand what is best. Anyhow the PR is trivial and does not even need to be inside the repository in my understanding.

Big thanks for your testing remote snapshotter and the API!

I'm thinking to fix this patch leveraging https://github.com/containerd/containerd/pull/3870 as mentioned here. The most part will remain unchanged but be simpler. The patch PoC is here and you can test it on this remote snapshotter branch.

@ktock is the main thing that is missing from the other PR the ability to set the extra labels on prepare? I was wondering if we can define a way to propagate some annotations as labels, that would allow intercepting handlers to inject information using the normal handler approach

@dmcgowan Yes. Do you have any idea about the definition of some annotations? I first thought about using containerd's local content store as a propagation media(using content labels which are currently disabled by default). Is it an acceptable design? If so, I'm willing to post another PR. Or, do you have other ideas?

Or, if we allow users to provide a handler which will be wrapped by unpackWrapper, we can add extra ocispec.Descriptor.Annotations in the handler, which can be easily passed to the backend snapshotter.
(so unpackWrapper(USER_WRAPPER(h)) not USER_WRAPPER(unpackWrapper(h)) in the code snippet below)
https://github.com/containerd/containerd/blob/30d92eff1c61d012be0053467f619974ad841698/pull.go#L80-L86

@dmcgowan Based on the discussion above I rewrote the PoC of the patch. Then this became very simpler! This is great! You can test it on this remote snapshotter branch. If it's an acceptable design, I'll update this PR.

I posted new PR https://github.com/containerd/containerd/pull/3911 leveraging #3870. Could you review it?


transcript notifications

Pre-Flight checklist

[ ] Screenshots and design review for any changes that affect layout or styling

[ ] Desktop screenshots
[ ] Mobile width screenshots

[ ] Migrations

[ ] Migration is backwards-compatible with current production code

[ ] Testing

[ ] Code is tested
[ ] Changes have been manually tested

[ ] Settings

[ ] New settings are documented and present in app.json
[ ] New settings have reasonable development defaults, if applicable
[ ] Opened issue for DevOps regarding necessary configuration changes to deployed environments

What are the relevant tickets?
(Required)
What's this PR do?
(Required)
How should this be manually tested?
(Required)
Where should the reviewer start?
(Optional)
Any background context you want to provide?
(Optional)
Screenshots (if appropriate)
(Optional)
What GIF best describes this PR or how it makes you feel?
(Optional)

Codecov Report

Merging #797 (b5cc94f) into master (d945f3f) will increase coverage by 3.11%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #797      +/-   ##
==========================================
+ Coverage   91.52%   94.64%   +3.11%
==========================================
  Files         190       94      -96
  Lines        7105     2670    -4435
  Branches     1120      583     -537
==========================================
- Hits         6503     2527    -3976
+ Misses        523      141     -382
+ Partials       79        2      -77

Impacted Files
Coverage Δ

main/settings.py

videos/tasks.py

websites/api.py

websites/messages.py

websites/views.py

content_sync/serializers.py

ocw_import/conftest.py

websites/apps.py

main/constants.py

content_sync/pipelines/base.py

... and 86 more

Continue to review full report at Codecov.

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


expose the protocolManagerFactoryStr property in the RA

@jmesnil  awesome.. it was on my list of TODOs :)


Empty list

Description
This problem occurs only on iOS. If a finite list of suggestions (for example 5) is provided, the whole screen will be filled, after those suggestions, with empty rows.
Steps to Reproduce

Use nugget on iOS and provide a custom item source.

Basic Information

Version with issue: 1.1.0
Last known good version: -
IDE: Visual Studio 2019, 16.5.1
Platform Target Frameworks:

iOS: 13.4

Screenshots

This is the behavior that iOS has for the selection list

Duplicate of #48

hi doMorten,
if you are using ListView for opening the dropdown then set empty footer like footer="" in list Xaml.
I think your issue resolved with this query.


[EVENT REQUEST] Change Parameter to var on an Event

Describe the request
Hey everyone,
we need to change two Eventparameters to VAR-reference in the Event OnAfterInitNewWhseShptLine in Codeunit "Sales Warehouse Mgt.".

Actually they are without an VAR-reference :(

Would be nice if we can get it in the next CU Updates for BC23.
Thank you.
Additional context
We already suggested this Event. But i think we doesnt mentioned the change of the VAR-reference directly (or not clear enough) here:
https://github.com/microsoft/ALAppExtensions/issues/24028
We want to skip the creation depending on the deliverability calculation assigned to WhseShptLineQty and WhseShptLineQtyBase

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.
Build ID: 14309.


Penis emoji

Like many actual objects throughout history, many emojis have been used as phallic symbols, most prominently the Aubergine/Eggplant 🍆, Banana 🍌 and Corn/Maize Cob 🌽 emojis, but also Hotdog/Sausage 🌭 #40, Mushroom 🍄, Cucumber/Gherkin/Pickle 🥒, Carrot 🥕, Baguette Bread 🥖, Shrimp 🍤, Oden 🍢, Popping Wine Bottle 🍾, Lipstick 💄, Nose 👃, Necktie 👔, Sagittarius ♐, Snake 🐍, Unicorn 🦄, Rocket 🚀, Locomotive/Train 🚂🚅, Tower 🗼, Joystick 🕹, Tools 🔧🔨⛏, Screw/Bolt 🔩, Gun/Pistol 🔫, Dagger 🗡, Pill 💊, Pen/Pencil/Nib/Brush ✏🖊🖋✒🖍🖌, Ruler 📏, Pushpin 📍, Chart 📈, Cherries 🍒 (for testicles) and possibly other emojis for their graphic appearance as well (some depending on the vendor image, e.g. for the Bug 🐛). They mostly represent an Erect Penis or even, in case of the popping bottle or Spouting Whale 🐳, an Ejaculating Penis, which is otherwise usually indicated by an adjacent Sweat, Drop, Drip or Splash symbol 💦💧, or an Explosion 💥 or Sparkles ✨ for orgasm. The existing Umbrella emojis can represent the three penile states: lush 🌂, stiff ☂, cumming ☔ (but at least the latter is propagated as a metaphorical Condom emoji instead). Dildos and Vibrators have been pictured by much the same emojis, but also the Cactus 🌵 for instance. In the context of fellatio, even more emojis may also be used for the Penis, e.g. an Ice Cream Cone 🍧, a Lollipop / Sucker 🍭 or a Candy Bar 🍫.
Linguistic metaphors depend on the language of the context. They may coincide with the graphic ones mentioned already, but also include, for instance, the Cock(erel/Rooster) 🐓 in English and the Monkey 🐒 or Sprout 🌱 elsewhere.
Classic ASCII line art varies significantly, especially to emphasize exceptional short or long sizes. Normalized to a two-character shaft length, they may look like these: <==3, 3==D, 3==>, 3==0, 3==O. The digit three 3 is canonically used to represent the testicles, but the glans (tip or head) has a larger number of symbolic characters. Dripping Sperm (“Cum”) or Urine (“Pee”) may be indicated by an added tilde character ~.
Genitalia emojis are already in scope of body-parts.proposal.md, body-parts.md, sexting.md and sexual-activities.md.

penal -> penile

The link to body-parts.proposal.md is down.


docs: Fix tip content in quickstart test

There is only one version of the "tip" on the quickstart test page, but it should contain different method / function names for Go, Node.js, and Python. This PR places the tip in each tab with correct method names (as well as fixes one or two other typos on the page).

Thanks for those fixes @steverusso !


fix: log error instead of warn on 500s

addresses https://github.com/pinojs/hapi-pino/issues/74

Coverage remained the same at 98.808% when pulling 7823a6d32fde14bc666dd72dddfd8fcbf3f9b846 on ryanhallcs:master into d50a86766932b0d7b5b168c963f4cc66d4be2aa7 on pinojs:master.


Upon RLMObject mutation, UI gets blocked completely

hi @bigfish24 ,
Currently i'm using RBQFetchedResultsController in a project, all went smoothly except one issue i have right now, in one viewController i have contains a tableView which shows too many objects ( 250+ ) and those objects are fetched via RBQFRC , now when i modify an object to mark as favorite, i get the whole UI freezing for ~3 second and then becomes responsive again, i'm using:
RLMRealm *rlm = [RLMRealm defaultRealm];
[rlm beginWriteTransaction];
[objectToFavorite changeWithNotification:^(ObjectSubclass *__object){
         __object.favorite = !__object.favorite;
}];
[rlm commitWriteTransaction];

Freeze time increases as number of objects go up, so any suggestion how to avoid blocking the UI ?
Thank you

I would recommend doing any Realm mutation on a background thread that will notify an RBQFRC instance. Note too (it's on the bottom of the README in more detail) that you need to restrict the mutations to either main thread or background thread, if you do some on background and some on main, a deadlock can occur. So the recommended best practice is always background thread when editing a Realm object with a notification.

thanks @bigfish24 for the fast reply.
Actually i'm moving all the -fetch and mutation to a custom RACScheduler which is a background scheduler, i have 2 issues here:

the UI still gets blocked
the optimum way to handle jumping to mainThread again, so for example i have a mark as favorite RACCommand which is triggered from mainThread anyway, so should i pass the objectId here to the foreground thread, refetch that specific object from Realm (on main thread ) and -commitTransaction again ? would it be reflected in fetchedObjects immediately ?

thanks.

Can you go into further detail regarding how/why a deadlock can occur if you mix background and main thread transactions? I think fixing this library (if possible) is preferable to worrying about what thread Realm transactions are done through a whole project. One of the big attractions of Realm is its simpler threading model, it would be shame to complicate it.

@LeffelMania happy to explain!
The first "problem" is that the index change calculation based off which objects were edited needs to happen synchronously after the Realm write transaction. If it were async then it is possible the index change calculation would overlap with another Realm write, resulting in index values that are based off of a mix of two database states.
The second "problem" is that after the FRC calculates the index changes, it then passes those to the delegate. If the original write and processing (synchronously from the write caller) was on a background thread, then the delegate call is async'd to the main thread... however, the FRC has to wait for the final delegate call (controllerDidChangeContent:) to return on the main thread before it can return.
The reason for this is that this is where you would call endUpdates on the tableview, which will then trigger calls to numberOfSectionsInTableView:, numberOfRowsInSection:, etc. All of those will then ask the FRC for the appropriate values, which means the FRC must still be in the same state as the most recent change processing. If controllerDidChangeContent: was called async, a new write could occur triggering the FRC to process the change and update its internal state (which manages the sections), causing an assertion failure from the table view, which expects the FRC to return the correct values based off of which changes were passed to it between beginUpdates and endUpdates.
Hopefully this makes sense, but the gist is that the Realm write--> FRC processing --> delegate calls --> tableview update all need to occur synchronously so that the state doesn't change out from under it.
The deadlock then can happen if you perform a background write, which means the FRC delegate calls happen as dispatch_async to the main thread, but if a main thread write had queued up in the middle of the various delegate calls, it will be waiting on the Realm background write to finish which is waiting on the FRC to finish which is waiting on the async delegate calls to finish, which are behind the main thread Realm write.... hence a dead lock.
To prevent this all of your changes can be on the main thread or all on a background thread, but it the mixing of the two that can result in a deadlock.

At a high level I understand I think, but I'd have to dig in for a while to fully grok it. Is it your position, then, that this problem is unsolvable due to the necessity of synchronous execution here? Or would it be possible to add some state to the calculation logic to prevent deadlock?

@LeffelMania I was editing my post to add info specific to that question:
The proper way to fix this is through version pinning within Realm. If it were possible to have two Realm instances that were pinned to the before and after state of a specific commit you could do all the FRC processing for that commit async, allowing Realm to advance and trigger its own FRC processing off the before/after state for the new commit.
The current Realm Cocoa API doesn't really offer a good way to do this, even though internally Realm has versioning. I could drop down and use Realm Core's C++ API to accomplish this, but it would be redundant since a colleague at Realm is working on that for fine-grained notifications.
Once that is released (most likely late Feb), you could switch and not use RBQFRC unless you need sectioning (since Realm results don't yet support grouping).
In the mean time, the simplest is just to do all Realm writes that trigger FRC processing on a background thread.

@haitham-reda I am not that familiar with ReactiveCocoa, but this is the ideal pattern:

Perform Realm mutation on background thread (via transaction)
On commit of the transaction, FRC synchronously processes changes on the same background thread
Changes are passed async onto the main thread from FRC
FRC delegates call necessary UITableView methods to apply changes on the main thread
Final FRC delegate controllerDidChangeContent: calls UITableView endUpdates and returns, which ultimately allows the original Realm transaction to return since the FRC is waiting on this

As long as all Realm mutations that will trigger the FRC occur on a background thread, this process will occur and no deadlocks happen.

@bigfish24 , i have tried a lot of solutions for background threading, finally i've got back to - (void)changeWithNotificationInTransaction:(RBQChangeNotificationBlock)block, steps:
RLMRealm *rlm = [RLMRealm defaultRealm];
Song *songToFollow = [Song objectInRealm:rlm forPrimaryKey:[self.viewModel.model.songId copy]];
[songToFollow changeWithNotificationInTransaction:^(Song*  _Nonnull _song) {
 _song.favorite = FAVORITE_REVERSED(_song.favorite);
}];

then updating results in 2 views.
so, as i have more than 8,000 objects without fetchLimit, i get the UI blocked completely for 6-7 seconds ( iPhone 6+ ) and huge disk IO , as in the screenshot:

am i getting it wrong ?

What is FAVORITE_REVERSED() function doing?

ah sorry, it's a macro to check nullability and reverse status ( 0 <--> 1 ).
i've been digging more, and the block is in -[RBQRealmNotificationManager sendNotificationsWithRealm:entityChanges:]  method, it takes 28 seconds

@haitham-reda well that method is where RBQRealmNotificationManager is passing the changes from the current Realm write transaction to listeners, of which RBQFetchedResultsController registers itself as a listener, so it takes the changes and then processes them to identify the index changes.
If this processing is taking awhile, my best guess is that you are passing a lot of changes and thus RBQFRC is going through them as expected. The way RBQFRC is designed is that the change processing is based primarily on the number of changes, versus how many objects are in the fetch.
Another thought I have though is that you might not have RBQFRC setup correctly, so it is recreating its internal cache for every change, versus simply using the existing cache and processing the change.
Is there any way you can share more of the code/project with me? It is hard to debug without more detail...

@bigfish24 objects changes are not many, usually 1 object, but it's definitely the number of objects in the fetch, as i've using it app wide without any issues, but only in my full list tableView which are 8,000+ objects this problem occurs ( it's a business requirement to fetch them all in list ) , so please advice building up RBQFRC correctly so it doesn't rebuild cache each time, as possibly that's what's happening now form the amount of data written to disk ( ~ 14MB )
i can share snippets privately if you want to .

@haitham-reda yeah happy to handle it privately, send what you are comfortable with to<EMAIL_ADDRESS>I did a quick test with the example app, which by default creates 1000 objects for the fetch and splits them into two sections 10 in the first section and the remaining in the second. For the first test, I adjusted the total number of objects but simply deleted the objects in the first section:
Processing Diff: 0.019833 (1k objects, with 10 changes)
Processing Diff: 0.076833 (10k objects, with 10 changes)
This test, I adjusted the deletion to be the second section, which highlights that lots of changes are the main contributor to the processing time:
Processing Diff: 0.089898 (1k objects, with 990 changes)
Processing Diff: 1.731977 (10k objects, with 9990 changes)

i wish to see those numbers here :)  mine is 28 seconds.
thank you for your time, i will email you some snippets, meanwhile is there any way to prevent cache rebuilding ?

When you create an instance of RBQFRC, if you pass a cache name the cache will be persisted to disk, but even if you don't the cache is held in-memory, so that is why I am a bit stumped on why the cache would be gone...
But if it is gone, then it would lead to very slow processing since the cache has to go through every object. If it is rebuilding the cache for every change, then this would quickly balloon into the 28 seconds you are seeing.
Are you using a cacheName in initWithFetchRequest:sectionNameKeyPath:cacheName:?

i'm pretty sure it re-writes it every time, that's the only explanation to the 14MB IO to disk i attached in yesterday's screen shot.
yes, HYG:
RLMRealm *realm = [RLMRealm defaultRealm];
    self.predicate = [NSPredicate predicateWithFormat:@"song_id != nil"];
    self.fetchRequest = [RBQFetchRequest fetchRequestWithEntityName:[Song entityName]
                                                            inRealm:realm
                                                          predicate:self.predicate];

    self.desc = [RLMSortDescriptor sortDescriptorWithProperty:@"artist_name" ascending:YES];
    [self.fetchRequest<EMAIL_ADDRESS>
    _fetchedResultsController = [[RBQFetchedResultsController alloc]
                                     initWithFetchRequest:self.fetchRequest
                                     sectionNameKeyPath:@"artist_name"
                                     cacheName:kRBQCacheNameForFullList];

    [_fetchedResultsController setDelegate:self];

Can you run the time profiler to better pin point the method that is taking awhile?
Also, are you calling performFetch multiple times? This method triggers the cache to be rebuilt if the number of items in the cache doesn't match the number returned from Realm.

no it's called only once, i will proceed with time profiling as soon as i get to work computer tomorrow morning for developer key :S
but as i'm digging, it's really deleting the cache each time due to difference in fetchRequest.hash

That's very odd, as I am not sure how it is possible for the cache to be deleted and rebuilt without calling performFetch multiple times.
Are you deleting Song objects in Realm without notifying RBQFRC?

Not actually,  all deletions are using
[obj changeWithNotificationInTransaction:^(Song*  _Nonnull object) {
                    object.favorite = @(NO);
                }];

but i add objects from the API without notifying RBQFRC, parse JSON to model then using
-createOrUpdateInRealm

Can you use the notification method for the createOrUpdate? This does mean the cache is getting out of date.

createOrUpdate happens only one time till user pull to refresh which invalidates cache anyway because i receive all objects again from the API.
But after more digging i could spot the problem, there are 2 issues:

the cache was rebuilt each time, because i have 2 tabs, 1st tab for favorite songs only ( favorite = @(YES)) and the other for full list of Songs, those are the 2 views where i -performFetch, the cache was rebuilt each time because the entityName is the same but the count is different ( i.e 7 favorite songs in the 1 view meanwhile i have 8,000 songs in the second view tableView ), so it rebuilds it due to count difference while matching entityName.

even when manually commented out cache rebuild, the real problem that takes time is - (RBQSectionChangesObject *)createSectionChangesWithChangeSets:(RBQChangeSetsObject *)changeSets                                                        state:(RBQStateObject *)state

the for loop in there for sectionNames if sectionNameKeyPath is present takes ~27 seconds ( 3321 sections :S ) and that's the real issue, unable to think how to resolve it yet. I guess the timings you posted yesterday for section-less objects or very few of them. any suggestions ?

Any update on the deadlock situation?  I'm doing a new project with Realm, using RealmTableViewController (https://github.com/bigfish24/ABFRealmTableViewController.git) which uses RBQFetchedResultsController under the sheets.  Multiple instances of the RealmTableViewController end up deadlocking down in RBQFetchedResultsController.

@jaylyerly i think it's different situation than what i had here, this issue was mainly due to the huge object/tableView section numbers : ( 3,000+ ) sections, which i ended up using core data.
However i still believe that Realm & RBQFRC are great, i won't hesitate using them again with smaller object graph/count.


Position stuck in Rollover state

I just noticed that my position is not rolling over as it should be.

2024-02-03_132323.log

According to the logs, it looks like I've started the process of rolling over.
[DEBUG] TIME: 2024-02-02T15:33:03.259879Z r: Asking coordinator for rolling over DLC channel channel_id: 8f10da041a7e2de08dd906edbb2ca8448f8189d659417a59963b4493e3e244b6
[DEBUG] TIME: 2024-02-02T15:33:03.355903Z AppLifecycleState changed to: AppLifecycleState.resumed
[DEBUG] TIME: 2024-02-02T15:33:03.419191Z r: Response status code 200 OK
[DEBUG] TIME: 2024-02-02T15:33:03.419436Z r: Successfully uploaded backup of ln/monitors/2b5ff594f8318ead5a79cb3eba978f9a8ba62e9a313e05fd728f4558b03e2792_0.
[DEBUG] TIME: 2024-02-02T15:33:03.797024Z r: Setting up connection peer: 022ae8dbec1caa4dac93f07f2ebf5ad7a5dd08d375b79f11095e81b065c2155156@<IP_ADDRESS>:9045
[DEBUG] TIME: 2024-02-02T15:33:03.828293Z r: Connection setup completed peer: 022ae8dbec1caa4dac93f07f2ebf5ad7a5dd08d375b79f11095e81b065c2155156@<IP_ADDRESS>:9045
[DEBUG] TIME: 2024-02-02T15:33:03.828599Z r: Waiting to confirm established connection peer: 022ae8dbec1caa4dac93f07f2ebf5ad7a5dd08d375b79f11095e81b065c2155156@<IP_ADDRESS>:9045
[INFO] TIME: 2024-02-02T15:33:03.856463Z r: Sent rollover request to coordinator successfully
[DEBUG] TIME: 2024-02-02T15:33:03.861593Z r: lightning::ln::peer_handler: Finished noise handshake for connection with 022ae8dbec1caa4dac93f07f2ebf5ad7a5dd08d375b79f11095e81b065c2155156
[INFO] TIME: 2024-02-02T15:33:03.891784Z r: lightning::ln::peer_handler: Received peer Init message from 022ae8dbec1caa4dac93f07f2ebf5ad7a5dd08d375b79f11095e81b065c2155156: DataLossProtect: required, InitialRoutingSync: not supported, UpfrontShutdownScript: supported, GossipQueries: not supported, VariableLengthOnion: required, StaticRemoteKey: required, PaymentSecret: required, BasicMPP: supported, Wumbo: supported, AnchorsNonzeroFeeHtlcTx: not supported, AnchorsZeroFeeHtlcTx: not supported, ShutdownAnySegwit: supported, Taproot: not supported, OnionMessages: not supported, ChannelType: supported, SCIDPrivacy: supported, ZeroConf: supported, unknown flags: none
[DEBUG] TIME: 2024-02-02T15:33:03.892136Z r: lightning::ln::channelmanager: Generating channel_reestablish events for 022ae8dbec1caa4dac93f07f2ebf5ad7a5dd08d375b79f11095e81b065c2155156
[INFO] TIME: 2024-02-02T15:33:03.892341Z r: Peer connected! inbound: false,their_node_id: 022ae8dbec1caa4dac93f07f2ebf5ad7a5dd08d375b79f11095e81b065c2155156
[DEBUG] TIME: 2024-02-02T15:33:03.894283Z r: Sending last dlc message last_outbound_serialized_dlc_message.message_type: RenewFinalize,peer: 022ae8dbec1caa4dac93f07f2ebf5ad7a5dd08d375b79f11095e81b065c2155156
[INFO] TIME: 2024-02-02T15:33:03.998732Z r: Processing message from: 022ae8dbec1caa4dac93f07f2ebf5ad7a5dd08d375b79f11095e81b065c2155156,kind: ChannelRenewRevoke
[DEBUG] TIME: 2024-02-02T15:33:03.999377Z r: Received message that has already been processed, skipping. kind: ChannelRenewRevoke,node_id: 022ae8dbec1caa4dac93f07f2ebf5ad7a5dd08d375b79f11095e81b065c2155156
[INFO] TIME: 2024-02-02T15:33:04.830723Z r: Connection established peer: 022ae8dbec1caa4dac93f07f2ebf5ad7a5dd08d375b79f11095e81b065c2155156@<IP_ADDRESS>:9045

Position seems to be stuck in Rollover on the coordinator
 505 | BtcUsd          |               2 |      500 | long      |             42722.5 |         28481.666 | Rollover       |             585172 | 2024-02-02 14:32:30.289431+00 | 2024-02-11 15:00:00+00 | 2024-02-02 15:33:03.872054+00 | 030087a46872f7b73d8c5bbfd0009ca41883c28cd607f299e041d5e14bc1f2f386 | 28fc0e8c84d53de29352434254319ed9bb711358d79d2fa3b2e87f9573be6766 |                  |              -5806 |               |                    2 |        585172 | f

On reconnect I get a ChannelRenewRevoke which I've apparently already processed.
[INFO] TIME: 2024-02-03T12:33:41.811896Z r: Processing message from: 022ae8dbec1caa4dac93f07f2ebf5ad7a5dd08d375b79f11095e81b065c2155156,kind: ChannelRenewRevoke
[DEBUG] TIME: 2024-02-03T12:33:41.812261Z r: Received message that has already been processed, skipping. kind: ChannelRenewRevoke,node_id: 022ae8dbec1caa4dac93f07f2ebf5ad7a5dd08d375b79f11095e81b065c2155156

Also can't close the position:

My channel details:

{
    "dlc_channel_id": "8f10da041a7e2de08dd906edbb2ca8448f8189d659417a59963b4493e3e244b6",
    "counter_party": "030087a46872f7b73d8c5bbfd0009ca41883c28cd607f299e041d5e14bc1f2f386",
    "channel_state": "Signed",
    "signed_channel_state": "Closing",
    "update_idx":<PHONE_NUMBER>10647,
    "fee_rate_per_vb": 38,
    "funding_txid": "7a0837ff5c180ad8acbd319c9c238947129ca45249dfa71b6b2e9013f44d9d28",
    "contract_id": "2518826a511146d3e5da61ba4f2549d44c383b9cac7aa374a7a3acdccdad5189",
    "temporary_contract_id": "5f10b5950d094c0b49675026d306c0935ea49fcee5a5046fcc8d3ccf39e0cca3",
    "contract_state": "Confirmed",
    "offered_collateral_sats": 600240,
    "accepted_collateral_sats": 603841,
    "user_email"<EMAIL_ADDRESS>    "user_registration_timestamp": "2023-09-01T06:47:01.162916Z"
  },

I believe this is the force close transaction: https://mempool.space/tx/7907057ba156aa6f57987639dbd8801b59be22fa032fe273be9e6c50ec4960e1

One thing I'm wondering is which state was force closed... will I have to wait a week or until tomorrow? :)

We also need some kind of clean up after a force closure. Your position is still in Proposed which will definitely lead to issues once you've created a new dlc channel with an new position.

My theory about what happened is the following.

The coordinator sent the renew offer (which hasn't been inserted to the dlc messages because of a bug, not yet fixed in prod).
The app disconnected before processing the RenewOffer message.
On reconnect the coordinator resend the last known message which has been the old RenewRevoke message from when the position got opened.
Since this message has already been processed the message got skipped and the protocol has no way to continue.
After not receiving a response for over 3600 seconds the coordinator force closed the channel.

This issue should be fixed with

Check if the DLCs were spent

CET has been spent: https://mempool.space/tx/30b333accdf6b00f55592f3bbaa398074524dcf9e82d0708bdad42c5af296be9

I've spent it already and the coordinator also received his funds


Documentation

Could always be better:
Setup guide.
Setup video?

Working on putting things into the Wiki.


fix(helm): wrong secret name in certificate

What type of PR is this?
/kind bug
What this PR does / why we need it:
Without these changes the integration with cert-manager is not working
Does this PR introduce a user-facing change?
NONE

/ok-to-test

/release-note-edit
Helm Chart: Fix a bug that the kueue does not work with the cert-manager.

/cherry-pick release-0.6

@EladDolev Could you create a cherry-pick PR? This script would be helpful.

Hi @tenzen-y and thanks for your help 🙏
Have opened this PR using the tool. Hope that's okay

/release-note-edit
Helm: Fix a bug that prevented Kueue to work with the cert-manager.


ShaderKnowladge: confirm current impelementation is correct

and document how do we transform UV.

We may: add matrix2x3 and utility functions for _ST


docker-compose: switch to using newer HA deployment model

Description
It turns out that the HA test script was still working under the old HA
model, so it had to be reworked.
Merge requirements
Please take into account the following non-code changes that you may need to make with your PR:

[ ] CHANGELOG entry for user-facing changes
[ ] Updated the relevant documentation

FYI this is a rework/resubmit of this PR started by @paulfantom: https://github.com/timescale/promscale/pull/1249


testCredGen: testCredGen.sh fails to generate ca

Following testCredGen README results in a build failure when generating ca:
~/genivi/cdsp/cdsp/cdsp/automotive-viss2/testCredGen$ ./testCredGen.sh ca
Generating RSA AES-256 Private Key for Root Certificate Authority
genrsa: Can't open "ca/Root.CA.key" for writing, No such file or directory
Generating Certificate for Root Certificate Authority
Can't open ca/Root.CA.key for reading, No such file or directory
140055842022720:error:02001002:system library:fopen:No such file or directory:../crypto/bio/bss_file.c:69:fopen('ca/Root.CA.key','r')
140055842022720:error:2006D080:BIO routines:BIO_new_file:no such file:../crypto/bio/bss_file.c:76:
unable to load Private Key
Done!

Appears Root.CA.key can not be generated as ca directory does not exist.
Workaround: manually create ca subdirectory and rerun script

Fixed in PR#90


add --sentry option to public nodes

Closes #21

We can still keep the increased in-peers.

I was seeing the public nodes having an increased CPU usage with --in-peers 500, now without it it's much better, do you think it is related?

I'm going to merge as is, we can disscuss --in-peers on a follow up.


error: could not find when-cli in registry crates-io with version *

When trying to install when-cli using cargo, I am getting this output
❯ cargo install when-cli
    Updating crates.io index
error: could not find `when-cli` in registry `crates-io` with version `*`

Can you let me know, what am I doing wrong?

I cannot answer this question. I assume this might have been a temporary caching issue on crates.io. I cannot reproduce this. Please reopen if this still happens.

I had the same problem... I think you have to switch to the nightly rust toolchain.

Unable to specify edition2021 in order to use unstable packages in Rust

rustup default nightly && rustup update

Note also that you may need the to run the toolchain with this command on Ubuntu:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

I had to update the toolchain as described above, then make sure that my path was picking up the right toolchain.
This is kind of a hack, but I had to install with this command after updating the toolchain:

PATH=~/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin:${PATH} cargo --verbose install when-cli


Replace 'localhost:8000' with 'pokeapi.co' in page templates

Replace 'localhost:8000' with 'pokeapi.co' in page templates, hopefully fixes #189

💥 nice one @ineffyble !!


Incorrect comment reformatting in DNS zonefile

Steps to reproduce
Create test.zone with content
$ORIGIN example.com.

; example really long line example really long line example really long line example really long line example really long line

With cursor on the last line, press gqq to reformat the comment.
Expected behaviour
Expecting:
; example really long line example really long line example really long line
; example really long line example really long line

Current result - comment line not prefexed with ;
; example really long line example really long line example really long line
example really long line example really long line

This is with formatoptions=tcq.
Version of Vim
9.0.1499
Environment
Debian 12 stock Vim
Logs and stack traces
No response

Well, there are several problems here.

Vim does not yet detect .zone files as bind config files. It currently uses various patterns, see here: https://github.com/vim/vim/blob/0e17f7e97290f81ff55743ab5cdc69ef118be080/runtime/filetype.vim (search for bindzone).

Even if it did detect bind files correctly we don't have a proper filetype plugin for bind config files.

Here is a tested quick fix to set filetype based on your preferred file extension:
au BufNewFile,BufRead *.zone setf bindzone

vim.cmd "au BufNewFile,BufRead *.zone setf bindzone"

Based on @chrisbra very helpful debugging.


[Transaction] Fix transaction coordinator handleEndTransaction behavior and migrate tests

Motivation
Currently, KoP support transaction but don't have units test to cover transaction coordinator handleEndTransaction  behavior, for future maintain, we should add units test from Kafka.
Modification

Fix handleEndTransaction  behavior.
Add units test to ensure behavior same as Kafka.

@BewareMyPower @gaoran10 PTAL, Thanks.


Search and replace of a text only on selected code lines

Prerequisites

[ ] Can you reproduce the problem with Debug -> Reload Without Extensions?
[ ] Did you perform a cursory search to see if your bug or enhancement is already reported?
[ ] Did you read the Troubleshooting guide?

For more information on how to write a good bug report read here
For more information on how to contribute read here
Description
[Description of the bug or feature]
Steps to Reproduce

[First Step]
[Second Step]
[and so on...]

Expected behavior: [What you expected to happen]
Actual behavior: [What actually happened]
Versions
Please include the OS and what version of the OS you're running.
Please include the version of Brackets. You can find it under Help -> About Brackets (Windows and Linux) or Brackets -> About Brackets (macOS)

Sometimes I just need to find the keywords in some paragraphs of code, not in whole code.
It's useful just to select part of a text and find that I need


Magical Track Ideas

[ ] Invisible
[ ] floating (air/liquid)
[ ] conjuration (Think creating tracks under a moving cart as it goes)
[ ] Cart matcher (Activate on specific cart types)
[ ] Hydrophobic
[ ] Short Range Teleport (Think through walls)

 Additional Tracks

While you're at it,
Brass Tracks which are always on low speed versions of Vanilla's powered tracks.
Tracks which when they have a proper bed of blocks protect their carts from interuption while they have them


Async scene loading

Closes #15.
We can make subsequent trigger classes that utilize this one.
public class Door : SceneLoader
{
    private void SomeTriggerFunction()
    {
        LoadSceneAsync();
    }
}

#2 will be closed when we start making levels and connect them between eachother.

Found a better way to do it

Interesting. This seemed like the simplest solution.

Approved ✅

I'm getting ready to merge and updating the change log - please @me if any other changes are pushed.


opt: populate autocommit correctly under EXPLAIN

PR: https://github.com/cockroachdb/cockroach/pull/42500
From release notes:

EXPLAIN (VERBOSE) now indicates if auto-commit will be used for mutations. [#42500][#42500] {% comment %}doc{% endcomment %}

Explain https://airtable.com/tblD3oZPLJgGhCmch/viwNg2fK3NU3DUY6Z/rec4nN8PXF6Tkge92

Hi @RaduBerinde
I have questions about the "auto-commit added to EXPLAIN" functionality after looking at the PR cockroachdb/cockroach#42500:

I found a comment in pkg/sql/tablewriter.go that says "An auto-txn can commit the transaction with the batch. This is an optimization to avoid an extra round-trip to the transaction coordinator."  This makes it read like "auto-commit" is an optimization in the transaction protocol.  Is that correct?
In general, these sorts of optimizations are something that I would consider internal, not user-facing.  Especially at the level of a user looking at an EXPLAIN statement, I would not expect them to be able to jump down layers conceptually to the transaction protocol and the transaction coordinator.  Do you agree with this assessment?
In the PR you (seem to?) say the purpose is "We can now test the planning part of auto commit without using traces".  This also makes it seem like the change is for internal testing purposes, not necessarily for users.

All of the above add up to me thinking this is not something that should end up in SQL-user-level EXPLAIN docs, and we can close this issue.  Do you agree?  Or am I missing something?

I agree - this is mostly for our benefit and for internal testing.


EGL  library and color space issue

Hello,
I tried to run the "bash ./run_attacks_2D_MIM.sh" file, and, since I can not install  EGL on my computer, I needed to change "RasterizeGLContext" to "RasterizeCudaContext" in the following file:
"AT3D/AT3D/utils/nvdiffrast.py"
I attached the resulting image, which I think has weird color in the attacked areas.
Could you please tell me if the color is ok? If not, do you have some suggestions for modifying the color space just for the attacked parts?

BR,
Sahar

The 1st problem: there may be a problem if you cannot install EGL, since I directly used the code AT3D/AT3D/utils/nvdiffrast.py in https://github.com/sicxu/Deep3DFaceRecon_pytorch/blob/master/util/nvdiffrast.py and I'm not sure how to solve this problem. But it seems that the solution you adopted works. Can you make a PR to my repo?
The 2nd problem: 2D attack using MIM methods is one of the baselines in our work, and you can refer the paper here. The results it got are not so "realistic" and a little noisy.

It seems that pr #1 can resolve the first environment setup problem, so close the issue now.


Add upstream WebAssembly patch

Includes an upstream patch for WebAssembly in libcxx.

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.
I do have some suggestions for making it better though...
For recipe:

Using toolchain directly in this manner is deprecated.  Consider using the compilers outlined here.

Ha! Turns out this is already in 6.0.1. Closing.


Disagreement about the necessity and behavior of a cast between analyzer and CFE/backends

There is a disagreement between the analyzer and the CFE (or the backends) around type promotion. My first instinct was that the analyzer was incorrect and the unnecessary_cast should not be reported, since the cast does impact behavior in the CFE.
We can see the difference in behavior without the cast by printing the static type that was filled in by inference.
I also comparing the runtime behavior of printing the static type to the IDE hover type information.
class Foo<T> {}

class C<T extends Object> {
  void something(T? Function() read) {
    var argumentValue = read();
    if (argumentValue is! Foo<String>) {
      return;
    }
    printStaticType(argumentValue);
    var fooValue = argumentValue as Foo<String>;
    //             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ unnecessary_cast
    printStaticType(fooValue);
    printStaticFooType(fooValue);
  }
}

void printStaticType<T>(T t) {
  print(T);
}

void printStaticFooType<T>(Foo<T> f) {
  print(T);
}

void main() {
  C<Foo<String>>().something(() => Foo<String>());
}

This prints
Foo<String>?
Foo<String>
String

Using hover information in the IDE, analyzer reports the type of argumentValue where it is printed as T & Foo<String>,  and reports the type of fooValue as Foo<String>
If I remove the "unnecessary" cast by running the quick fix, the behavior changes, and it prints:
Foo<String>?
Foo<String>?
dynamic

This CFE behavior is a little confusing, because if fooValue is statically inferred as Foo<String>?, there should have been an error at the call to printStaticFooType which takes a non-nullable Foo.

I'm also confused by the impact of adding an && in the conditional. Is there an easy to understand explanation for why the extra condition impacts inference in this way?
diff --git a/foo.dart b/foo.dart
index ebc2e52..923fdd8 100644
--- a/foo.dart
+++ b/foo.dart
@@ -3,7 +3,7 @@ class Foo<T> {}
 class C<T extends Object> {
   void something(T? Function() read) {
     var argumentValue = read();
-    if (argumentValue is! Foo<String>) {
+    if (argumentValue != null && argumentValue is! Foo<String>) {
       return;
     }
     printStaticType(argumentValue);

When I make this change and remove the cast, the call to printStaticFooType(fooValue) becomes a static error. "The argument type T? cannot be assigned to the parameter type Foo<dynamic>". The CFE and analyzer agree on this error.
The CFE thinks the variables have type Foo<String>? (by running the code), and the analyzer thinks they have type T? (by hovering in IDE).

The promotion from T? by is Foo<String> should, by logic, promote to T & Foo<String>.
As such, the "unnecessary cast" warning is consistent, you get that warning for all up-casts, whether they affect type inference or not.
If you don't do the cast, the static type of fooValue it's derived from T & Foo<String>. I don't remember if the type becomes T or Foo<String>, but it can't be the intersection type. Problemet the former. It's then immediately assignment promoted to T & Foo<String>.
That's what's supposed to happen. I think.
What it actually happening seems to be that the promoted type is T? & Foo<String>. Which is not a type in the Dart type system at all. (I remember reporting diverging like that before.)
That explains the behaviors.
That intersection type is erased when the static type is captured, so it prints T?, which happens to be Foo<String>?.
The call to printStaticFooType gets confused, and infers dynamic, I can't blame it when faced with s type that doesn't exist, but the argument is a static intersection type where the second half makes it a subtype of Foo<String>, so it's valid as argument.
We need to fix the invalid intersection types. Somehow.

About the &&, that's on the escape branch. The continuation branch is guarded by the negation of that test, which is effectively
if (argumentValue == null || argumentValue is Foo<String>) ...

We don't do promotion on "or" tests in general (we could here, the LUB is still a type of interest), so you get no promotion, and the type is still T?, which is Foo<String>? at runtime because of the actual type argument.

Existing related issues are #50676 and #50677.

Interesting, @natebosch!
I'd note that it is slightly dangerous to use functions like printStaticType and printStaticFooType, because they receive a reified type argument, and hence we'll never see the promoted (intersection) type of the actual argument, just the erasure (and in situations like this that might be significant). That's the reason why I've used X x = argumentValue; and T t = argumentValue; to verify that argumentValue had the type X & T at some point in a similar situations (X and T do not have any other non-bottom subtypes than X & T).
Here is the discrepancy again, in a slightly smaller example:
// ignore_for_file: unused_local_variable

void f<X>(X? arg) {
  if (arg is int) {
    // Check that `arg` has type `X & int`.
    X x = arg;
    int i = arg;
    // Show the run-time value of the erased static type of `arg`.
    var xs = [arg];
    print(xs.runtimeType); // `List<Object?>`.
    // List<X> ys = xs; // CFE reports error, analyzer accepts.
    List<X?> ys = xs; // Accepted by both.
  }
}

void main() {
  f<Object>(1);
}

So the analyzer as well as the CFE accept arg as the initializing expression of both x and i, which is basically proof that arg has the type X & int at that point.
However, when the list literal is created it gets the actual argument type Object?, which is not the erasure of X & int. I would have expected a List<X>, which in the given invocation would have been a List<Object>, but the printed run-time type as well as the following declarations reveal that the CFE considers xs to have type List<X?>.
Looks like the CFE used the declared type of arg rather than the erasure of the promoted type at that point.

Side note: this issue initiated an interesting discussion, which resulted in https://github.com/dart-lang/language/issues/3239.


Allow adding a dat.json file inside a directory

And from that gather all information about the dat URL and which directory corresponds to it.

I don't think I get that correctly, what would be the steps?

read a directory
if there is a dat.json, parse it and find the dat to add?

IMO it's out of scope. You may have another tool that just parses a dat.json and instruct the daemon to add stuff via tcp?

No, the steps would be datdaemon add /path/to/dat.json. And then datdaemon would read dat.json, get URL from url field, and use /path/to/ for directory.
Currently I am using this script but I I really think reading a standard dotproject manifest file should be part of this project here.
Then I could do: find . -name dat.json -exec datdaemon add {} ';'

What is resolution here?


⚠ AVS (kty) has degraded performance

In fc4cb54, AVS (kty) (https://avus.com.br) experienced degraded performance:

HTTP code: 200
Response time: 8429 ms

Resolved: AVS (kty) performance has improved in a92078c.


Unit tests should fail under Python 3.8

The unit tests currently pass under Python 3.8.
But... when you actually attempt to run Datasette you get an error:
~/Dropbox/Development/datasette $ venv-py3.8.0/bin/datasette --memory -p 8855
Serve! files=() (immutables=()) on port 8855
Traceback (most recent call last):
  File "venv-py3.8.0/bin/datasette", line 11, in <module>
    load_entry_point('datasette', 'console_scripts', 'datasette')()
  File "/Users/simonw/Dropbox/Development/datasette/venv-py3.8.0/lib/python3.8/site-packages/click/core.py", line 764, in __call__
    return self.main(*args, **kwargs)
  File "/Users/simonw/Dropbox/Development/datasette/venv-py3.8.0/lib/python3.8/site-packages/click/core.py", line 717, in main
    rv = self.invoke(ctx)
  File "/Users/simonw/Dropbox/Development/datasette/venv-py3.8.0/lib/python3.8/site-packages/click/core.py", line 1137, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/Users/simonw/Dropbox/Development/datasette/venv-py3.8.0/lib/python3.8/site-packages/click/core.py", line 956, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/Users/simonw/Dropbox/Development/datasette/venv-py3.8.0/lib/python3.8/site-packages/click/core.py", line 555, in invoke
    return callback(*args, **kwargs)
  File "/Users/simonw/Dropbox/Development/datasette/datasette/cli.py", line 365, in serve
    uvicorn.run(ds.app(), host=host, port=port, log_level="info")
  File "/Users/simonw/Dropbox/Development/datasette/venv-py3.8.0/lib/python3.8/site-packages/uvicorn/main.py", line 279, in run
    server.run()
  File "/Users/simonw/Dropbox/Development/datasette/venv-py3.8.0/lib/python3.8/site-packages/uvicorn/main.py", line 305, in run
    self.config.setup_event_loop()
  File "/Users/simonw/Dropbox/Development/datasette/venv-py3.8.0/lib/python3.8/site-packages/uvicorn/config.py", line 218, in setup_event_loop
    loop_setup()
  File "/Users/simonw/Dropbox/Development/datasette/venv-py3.8.0/lib/python3.8/site-packages/uvicorn/loops/auto.py", line 3, in auto_loop_setup
    import uvloop
  File "/Users/simonw/Dropbox/Development/datasette/venv-py3.8.0/lib/python3.8/site-packages/uvloop/__init__.py", line 7, in <module>
    from .loop import Loop as __BaseLoop  # NOQA
  File "uvloop/includes/stdlib.pxi", line 114, in init uvloop.loop
AttributeError: module 'sys' has no attribute 'set_coroutine_wrapper'
~/Dropbox/Development/datasette $

If Datasette doesn't work under Python 3.8 the tests should fail.

I'm giving up on this. I spent a bunch of time trying to get it to work and couldn't.
My final attempt was inspired by https://github.com/encode/uvicorn/blob/e821fd1ff5653f989d500d41fa6ba070858f6843/tests/test_main.py#L10-L32
Here's the code that didn't work:
def test_asgi_app(app_client):
    from uvicorn.config import Config
    from uvicorn.main import Server

    class CustomServer(Server):
        def install_signal_handlers(self):
            pass

    def run_server():
        asyncio.set_event_loop(asyncio.new_event_loop())
        print("ooh new loop")
        config = Config(app=app_client.asgi_app, limit_max_requests=1, port=8642)
        config.load()
        server = CustomServer(config=config)
        server.run()

    with concurrent.futures.ThreadPoolExecutor(max_workers=1) as executor:
        future = executor.submit(run_server)
        future.result()
        while not server.started:
            print(server.__dict__)
            time.sleep(0.01)
        assert 200 == urllib.request.urlopen("http://localhost:8642/").status
        # This line will raise if there's an exception:
        future.result()

I got RuntimeError: There is no current event loop in thread 'ThreadPoolExecutor-1_0'


Issue with Aqara wall switch QBKG11LM (Single with L+N)

Hi
I have the same problem as https://github.com/Koenkk/zigbee-shepherd-converters/issues/405
Maybe need to do the same fix for QBKG11LM.
Apr 23 23:26:12 Khadas npm[4738]: zigbee2mqtt:debug 4/23/2019, 11:26:12 PM Received zigbee message of type 'attReport' with data '{"cid":"genMultistateInput","data":{"presentValue":1}}' of device 'lumi.ctrl_ln1.aq1' (0x00158d000211434a) of endpoint 5

Or need a PR with a patch?

Yes, please make a pr

Created.

Fixed https://github.com/Koenkk/zigbee-shepherd-converters/pull/420


Interaction record page

closes #300
Please note the accidental typo in the branch name when checking out locally (interaciton)

looks good, let me know if you want any guidance on getting backend tests set up for that new query -- I can also add a commit myself if you're pressed for time


Actually it's not related to this library,  I would suggest to contact customer support to review any specific order if you have concern on that.


chore: upgrade webchat and emotion

Description

Upgrade WebChat packages to fix accessibility issues
Upgrade emotion due to WebChat emotion bump
Refactor codebase to meet emotion@11 requirements
Include required types for tsc to pass type checks

#minor

Coverage remained the same at 55.871% when pulling 7667a357887a2663503d0ce19940396e3e852edd on OEvgeny:a11y/webchat into 169112f73da82f717d3e3d9af3c5cbd122bd9095 on microsoft:main.


build: Change OS selection order to prioritize small OSes

Depending on how an OS builds for native, Soletta may still pass the
Linux detection test. Leaving Linux as the last OS to check for in
Kconfig allows any other OS to be used regardless of that test.

We could do better than that later, but +1 for now

ack


allow await value in Template

What problem does this feature solve?
So far  a hack such as
<template>
{{foo}}
</template>

//js
var promise = new Promise(s=>setTimeout(s(1)))
{
    data:{foo:''},
    computed:{
        async bar(){
            return await promise
        }
    },
    watch:{
        async bar(){
            this.foo = await bar
        }
    }
}

What does the proposed API look like?
<template>
{{await foo}}
</template>

//js
var promise = new Promise(s=>setTimeout(s(1)))
{
    computed:{
        async foo(){
            return await promise
        }
    },
}

find duplicate issue https://github.com/vuejs/vue/issues/4083
so will consider it achieve in vue 3+ ?

Duplicate of https://github.com/vuejs/vue/issues/7520


Support reflection hint with modes = Mode.FUNCTIONAL

Tomcat hints introduced with https://github.com/spring-projects-experimental/spring-graalvm-native/commit/3260317ff675d4a1033d6571904fab7fd96c7b5e seems to work on springmvc-tomcat but not with jafu-webmvc.

I know we talked about an additional attribute indicator that the trigger should be treated as a presence indicator, but in the interim whilst we bake the idea I did something simpler: if your hint trigger is not a 'spring thing' (configuration/importregistrar/importselector/condition or marked AtImport) then it treats it as a presence checking trigger, and if around on a particular run the hint will apply. If it hangs together I will make it a more first class choice via another indicator flag.
So the 'default hints' that apply are those that have no trigger or have a trigger that is not a well known spring thing and that don't exclude themselves by any mode constraint they specify. This latter check enables us to activate some types required for annotation based configuration to work (they have no trigger but they specify they are only valid in non functional modes).
Seems to behave at the moment. Will revisit if functional init sample not working.


PHOENIX-7130 Add maven profile to support skipping of shade sources j…

…ar creation

Hi @stoty are we good here? Also please let me know if should take this to 5.1. Will need to raise another PR  as seems an additional file change is needed in branch-5.1.

Please donot push this to 5.1, have raised another PR for 5.1 as code is a bit different.

I have tested this now, but the shading time difference is seems to be minimal.
On my machine it takes ~3:20 with the shaded sources, and ~3:05 without them.
I don't have a problem with committing this, but I wander what kind of improvement do you see with the patch, @NihalJain  ?
Also I have just merged phoenix-client-lite, you may want to update the patch to add same change there.

I have tested this now, but the shading time difference is seems to be minimal. On my machine it takes ~3:20 with the shaded sources, and ~3:05 without them.

In our internal jenkins, which is based on branch-5.1, the difference is substantial. Maybe because we download all jars for every build and also possibly our local artifactory + VPN is not as fast, so downloading the source jars take almost 33% of build time.
Without  -PskipShadeSources -Dmaven.source.skip=true
.
.
[INFO] Phoenix Client ..................................... SUCCESS [22:40 min]
[INFO] Phoenix Client Embedded ............................ SUCCESS [08:56 min]
[INFO] Phoenix Server JAR ................................. SUCCESS [01:54 min]
[INFO] Phoenix Assembly ................................... SUCCESS [ 38.548 s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  36:06 min
[INFO] Finished at: 2024-01-03T10:55:52Z
[INFO] ------------------------------------------------------------------------

Vs
With  -PskipShadeSources -Dmaven.source.skip=true
.
.

[INFO] Phoenix Client ..................................... SUCCESS [09:37 min]
[INFO] Phoenix Client Embedded ............................ SUCCESS [08:14 min]
[INFO] Phoenix Server JAR ................................. SUCCESS [01:49 min]
[INFO] Phoenix Assembly ................................... SUCCESS [ 38.593 s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  24:08 min
[INFO] Finished at: 2024-01-03T11:29:24Z
[INFO] ------------------------------------------------------------------------

Also I have just merged phoenix-client-lite, you may want to update the patch to add same change there.

Sure let me rebase and make appropriate changes, if any

Ouch.
That's extremley slow.
Is it on a spinning rust HDD ? Or some slow NAS ?

(Note that we're waiting on #1736 before merging since it's a blocker.)

This is a pom only change, and #1736 doesn't touch the poms, so I wouldn't expect them to confict in any way.

I think it's fine to merge this since it adds the option to skip the shaded jar creation.

Also, I'm going to merge the phoenix-server shading refactor soon (another pom only change), It would probably be a good idea to  add this change there as well.

pom changes are fine so far, but yeah any other big changes or feature changes that have potential to cause any additional issues (more than what is known with #1736 and make it worse) are potential blockers e.g. JSON support, which is technically ready for merge (though still in final review phase) but i would like to block it.

Rebased code and updated all new instances of createSourcesJar in code. Could you please review and merge this.?
CC: @gjacoby126 @stoty @virajjasani

Since build failures are not related this. Merging


Implementing the LISTA Network for Sparse Reconstruction

Hi,
I am trying to implement the Learned Iterative Shrinkage and Thresholding Algorithm (LISTA) proposed in Gregor and LeCun 2010, "Learning Fast Approximations of Sparse Coding". LISTA aims to solve a sparse reconstruction problem using the network structure as shown in the figure.

Here W and S are to be learned from training data. Note that the matrix S at different "layers" should have the same parameters. My first thought is to use a Graph model with shared nodes. However, to define the shared node S, its second input (z2) should be defined first. But z2 is not defined until S is defined. Thus, defining S is problematic using this approach.
I am wondering if there is some way to work around the problem and allow the S in the two stages to have the same weights.
Thank you,
Chuyang

yeah, try the new functional api and just repeat the operations a couple of times
for i in range(3):
    x = dec(x1)  # `e` and `S` operations
    x1 = merged([x, x1], "sum")  # sum

btw, doesn't that look a lot like a resnet?

Thanks for the reply! Could you please tell me more about the dec() function? Where can I import it? Also, by "merged()", do you mean keras.layers.merge or is there a function named "merged" exactly?
The structure does look similar to a residual network because of the "add" node.

Thanks for the reply!
I believe the difference between LISTA and resnet is that Wx' (x' is the x in the figure) instead of the x1 in your code is added to x (this is the x in your code) at the end of each stage. Therefore, it seems to me that the loop should be
x2 = Wx
x1 = x2
for i in range(3):
    x = dec(x1)  # `e` and `S` operations
    x1 = merged([x, x2], "sum")  # sum

By "merged" did you mean keras.layers.merge or is there a function named exactly "merged"? Also, I am curious how this code ensures that the same S is applied (i.e. S is a shared node and it has the same parameters at each layer).

I mean keras.layers.merge, sorry!

@EderSantana Could you please tell me more about how S is ensured to have the same weights at different layers here? It seems to me that the loop does not explicitly force it. Thank you!

you define the dec layer before the inner loop, so the weights never change. the layer is just reapplied over and over. you are just reusing a layer which the new functional api allows you to do

Thanks! It makes perfect sense!


Searched users should be shown in alphabetical order

Hi Christian,
Could you describe in more detail about this issue and where I can search for users?

@gerlou I've added a description above.

I changed the code but I'm not sure where to test it. I tried this link http://localhost:8080/admin/auth/user/ but it seems like it's always ordered by the username instead of the first and last name.


3.0.0 version has no i18n files.

3.0.0 version has no i18n files.
https://i.gyazo.com/e2d121688da90ac1ce1a487a73bb3e8c.png

What version of Grails are you using?

Grails version is 3.1.0.M3

I think you're seeing https://github.com/grails/grails-core/issues/9459 which was fixed after M3 was released. The plugin jar does include the properties files and they're correctly resolved in 3.0, so regardless this is a Grails issue. Until it's fixed you can copy the plugin's files into your app's i18n folder

thank you :)


Coverage Data

Is it possible to calculate coverage data using govendor?
I tried govendor test -coverprofile profile.out +local
but that produces the error: 'cannot use test profile flag with multiple packages'
Is this somehow possible?

I think that is a limitation of the cover tool. I think there are other
tools you can use to get multi-package cover profiles.
On Fri, Nov 11, 2016 at 8:29 AM anopheles<EMAIL_ADDRESS>wrote:

Is it possible to calculate coverage data using govendor?
I tried govendor test -coverprofile profile.out +local
but that produces the error: 'cannot use test profile flag with multiple
packages'
Is this somehow possible?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/kardianos/govendor/issues/244, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAuFsXto6A-JPrNAPZrqUu5lDlANHryYks5q9JgCgaJpZM4Kv6SY
.

Do you have any pointers to multi-package coverage profile tools which handle vendoring, i.e. they ignore the vendor folder?

You could use any tool that allows that, then pass in the package list from govendor list -no-status +local

Perfect! That's what I was looking for :+1:


Add Omega's Stockalike Utility Vehicles from SpaceDock

This pull request was automatically generated by SpaceDock on behalf of Omega482, to add Omega's Stockalike Utility Vehicles to CKAN.
Mod details:
name = /mod/2005/Omega%27s%20Stockalike%20Utility%20Vehicles
author = Omega482
abstract = A mod that closely replicates the yellow utility vehicles seen around the KSC.
license = Attribution-NonCommercial-NoDerivatives 4.0 International (CC BY-NC-ND 4.0)
Homepage =
description = Omega's Stockalike Utility Vehicles
A vehicle mod replicating the Yellow utility vehicles as parts.

Features:

15 Vehicle parts for the yellow utility vehicles

Parts include Mesh Switchable crates and container props!

Stockalike, uses the internal squad textures! Can't get much more stock than that!

Low RAM usage. No textures are needed for this mod. It should be very low impact on load times.

This mod aimed to give the player access to the Yellow utility vehicles seen around KSC. These are however SQUAD assets and so I cannot distribute the models or textures.
This mod uses a plugin called AdvancedTextures that allows parts to use the internal KSP textures without having to distribute them. I then carefully re-created the models for the Vehicles in sketchup.

Please direct questions about this pull request to Omega482.

This was added in #6850.


performance difference between jetson nano and PC

face_recognition version: 1.2.3(both)
Python version: 3.5.2
Operating System: windows10 and ubuntu

Description
When I ran my test code on Windows, the test images worked perfectly.  After I ported the code to jetson nano（ubuntu）, face_recognition could not recognize the picture at all.
当我在windows下测试人脸识别的时候，代码很完美的识别人脸，但是将代码移植到jetson nano（ubuntu）后，完全不能识别。
What I Did
My code:
`# Optional - the bounding boxes of each face if you already know them.
known_image1 = face_recognition.load_image_file("images/lv/微信图片_20190603103821.jpg")
known_image2 = face_recognition.load_image_file("images/lv/424.jpg")
known_image3 = face_recognition.load_image_file("images/lv/微信图片_20190603150416.jpg")
unknown_image = face_recognition.load_image_file("test_image/微信图片_20190603195500.jpg")
up_samples = 2
boxes1 = face_recognition.face_locations(known_image1)
boxes2 = face_recognition.face_locations(known_image2)
boxes3 = face_recognition.face_locations(known_image3)
un_boxes = face_recognition.face_locations(unknown_image)
print('start encoding')
known_image_en1 = face_recognition.face_encodings(known_image1, boxes1)[0]
known_image_en2 = face_recognition.face_encodings(known_image2, boxes2)[0]
known_image_en3 = face_recognition.face_encodings(known_image3, boxes3)[0]
unknown_image_en = face_recognition.face_encodings(unknown_image, un_boxes)[0]
know_faces = [
known_image_en1,
known_image_en2,
known_image_en3
]
face_distances = face_recognition.face_distance(know_faces, unknown_image_en)
result = face_recognition.compare_faces(know_faces, unknown_image_en)
print(result)`
The result is [True, True, True]. But in Jetson nano, I got [False, False, False]. I didn't change images

After I print face_encodings. I found the encodings is different from windows when I use same jpg.

Hi @lfjd05,
Yes, this is a real bug. The issue is that the Jetson Nano CUDA libraries actually have a bug in them that causes the convolutions to be calculated incorrectly. The solution (until Nvidia fixes the CUDA implementation on Jetson) is to re-compile dlib on the Jetson Nano to force dlib to use a different method to calculate convolutions.
Luckily, the fix is simple to do. I cover it in my article here: https://medium.com/@ageitgey/build-a-hardware-based-face-recognition-system-for-150-with-the-nvidia-jetson-nano-and-python-a25cb8c891fd
Here's the relevant part cut and pasted from the article:
There is currently a bug in Nvidia’s own CUDA libraries for the Jetson Nano that keeps it from working correctly. To work around the bug, we’ll have to download dlib, edit a line of code, and re-compile it. But don’t worry, it’s no big deal.
In Terminal, run these commands:
wget http://dlib.net/files/dlib-19.17.tar.bz2
tar jxvf dlib-19.17.tar.bz2
cd dlib-19.17

That will download and uncompress the source code for dlib. Before we compile it, we need to comment out a line. Run this command:
gedit dlib/cuda/cudnn_dlibapi.cpp

This will open up the file that we need to edit in a text editor. Search the file for the following line of code (which should be line 854):
forward_algo = forward_best_algo;

And comment it out by adding two slashes in front of it, so it looks like this:
//forward_algo = forward_best_algo;

Now save the file, close the editor, and go back to the Terminal window. Next, run these commands to compile and install dlib:
cd dlib
sudo python3 setup.py install

This will take around 30–60 minutes to finish and your Jetson Nano might get hot, but just let it run.
Finally, we need to install the face_recognition Python library. Do that with this command:
sudo pip3 install face_recognition

Thank you very much. I've got the right results in Jetson nano by your article.