Environment:

KubeVirt version (use virtctl version): v1.1.0
Kubernetes version (use kubectl version): v1.28.2
OS (e.g. from /etc/os-release): Ubuntu 22.04.3 LTS
Kernel (e.g. uname -a): Linux k8s-202 5.15.0-88-generic UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
CPU：

processor       : 23
vendor_id       : GenuineIntel
cpu family      : 6
model           : 62
model name      : Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz
stepping        : 4
microcode       : 0x42e
cpu MHz         : 1200.000
cache size      : 15360 KB
physical id     : 1
siblings        : 12
core id         : 5
cpu cores       : 6
apicid          : 43
initial apicid  : 43
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm cpuid_fault pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt dtherm ida arat pln pts md_clear flush_l1d
vmx flags       : vnmi preemption_timer posted_intr invvpid ept_x_only ept_1gb flexpriority apicv tsc_offset vtpr mtf vapic ept vpid unrestricted_guest vapic_reg vid ple
bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit mmio_unknown
bogomips        : 4201.56
clflush size    : 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:

Machine: Dell PowerEdge R620

I have enabled hardware virtualization

I think I find the problem:
kubectl exec -ti virt-launcher-scrapy-8qxlb -n biz-scrapy -- bash
virsh edit biz-scrapy_scrapy

then, I fix the first line
<domain type='qemu'>

to
<domain type='kvm'>

enter :wq for save, It failed：

So, I think the reason is：/usr/libexec/qemu-kvm in quay.io/kubevirt/virt-launcher:v1.1.0 not support kvm

I think there is an issue with kvm capabilities detection on your environment. Could you please provide the following logs:

k logs -n kubevirt virt-handler-... -c virt-launcher
k logs -n kubevirt virt-handler-...
k logs virt-launcher-...

 You need to ensure that apparmor does not block anything on your host. Please refer to https://kubevirt.io/user-guide/operations/installation/#integration-with-apparmor. You can check if apparmor blocks smth by using e.g grep DEN /var/log/audit/audit.log

ok
virt-handler__virt-launcher.log
virt-handler.log
virt-launcher.log
I have disabled apparmor before k8s install with this method（I'm not sure if this method works）:
# cat /etc/default/grub | grep apparmor
GRUB_CMDLINE_LINUX="apparmor=0"

# cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-5.15.0-88-generic root=/dev/mapper/ubuntu--vg-ubuntu--lv ro apparmor=0

# dmesg | grep -i apparmor
[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-5.15.0-88-generic root=/dev/mapper/ubuntu--vg-ubuntu--lv ro apparmor=0
[    0.262339] Kernel command line: BOOT_IMAGE=/vmlinuz-5.15.0-88-generic root=/dev/mapper/ubuntu--vg-ubuntu--lv ro apparmor=0
[    6.212408] evm: security.apparmor
[   20.361988] systemd[1]: systemd 249.11-0ubuntu3.11 running in system mode (+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY -P11KIT -QRENCODE +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified)

/var/log/audit/audit.log is not exist
# grep DEN /var/log/audit/audit.log
grep: /var/log/audit/audit.log: No such file or directory

and journalctl -b | grep DEN can't get any output

Thanks, it works.


Is jedis cluster support pipeline?

hi, is jedis cluster support pipeline?
If supported, how to use it?

No, it doesn't. This has been discussed before, I recommend searching in the current issues and mailing list to understand the reason why it's not supported.


Fix zero vesting period test

The zero vesting period tests in Mina_base.Test were bit-rotted, and not being run.
Fixed:

the JSON for the zkApp was updated with the current syntax for account preconditions
the tests were converted from ppx_test inline tests to Alcotest format, added to main.ml

Tested by running:
dune exec src/lib/mina_base/test/main.exe -- test '^zero vesting period$'

Output:
...
[OK]                zero vesting period          0   Zero vesting period is error.
[OK]                zero vesting period          1   Nonzero vesting period is OK.
...

Also, I temporarily changed the successful branches in the test to run assert false, and Alcotest reported the failures.

!ci-build-me

Discovered that dev and devnet profiles have different account creation fees, need to adjust test for that.

!ci-build-me

!approved-for-mainnet


Capturing start and stop time of events

I'm having a scenario where we are capturing the start event and stop event continuously. Where start is considered as value 1 and stop is considered as value 0. We would  like to record one start and one stop as a combined columns to determine the time elapsed between these two events using Kapacitor with stream. Any pointers which would help.

The problem I'm trying to solve is similar to this https://github.com/influxdata/kapacitor/issues/643

@seesiva Yes, #643 will enable start event stop event detection.


happy coding

Your pull request is currently considered invalid for the following reason(s):

Your filename must be ducthuan-2712.html
Your file does not have the .html extension.

Once you have resolved the issues, comment on this request to be re-judged
This is an automated response, beep boop.
if you think there is a mistake, contact a maintainer

d26c6dc1fd672142a5f785ddeeac82edcec5cf1c

The last message was > 24h ago, this pr is now considered idle and will be closed. Feel free to re-open.


nullref exception was thrown when doing schema compare on databases with graph tables

repro steps:

run the following script to create a database with graph tables
compare it with another empty database

expected: show the changes
actual:

Script to create the test database, copied from: https://docs.microsoft.com/en-us/sql/relational-databases/graphs/sql-graph-sample?view=sql-server-ver15#sample-script
-- Create a graph demo database
IF NOT EXISTS (SELECT * FROM sys.databases WHERE NAME = 'graphdemo')
	CREATE DATABASE GraphDemo;
GO

USE GraphDemo;
GO

-- Create NODE tables
CREATE TABLE Person (
  ID INTEGER PRIMARY KEY,
  name VARCHAR(100)
) AS NODE;

CREATE TABLE Restaurant (
  ID INTEGER NOT NULL,
  name VARCHAR(100),
  city VARCHAR(100)
) AS NODE;

CREATE TABLE City (
  ID INTEGER PRIMARY KEY,
  name VARCHAR(100),
  stateName VARCHAR(100)
) AS NODE;

-- Create EDGE tables.
CREATE TABLE likes (rating INTEGER) AS EDGE;
CREATE TABLE friendOf AS EDGE;
CREATE TABLE livesIn AS EDGE;
CREATE TABLE locatedIn AS EDGE;

-- Insert data into node tables. Inserting into a node table is same as inserting into a regular table
INSERT INTO Person (Id, name)
	VALUES (1, 'John')
		 , (2, 'Mary')
		 , (3, 'Alice')
		 , (4, 'Jacob')
		 , (5, 'Julie');

INSERT INTO Restaurant (Id, name, city)
	VALUES (1, 'Taco Dell','Bellevue')
		 , (2, 'Ginger and Spice','Seattle')
		 , (3, 'Noodle Land', 'Redmond');

INSERT INTO City (Id, name, stateName)
	VALUES (1,'Bellevue','wa')
		 , (2,'Seattle','wa')
		 , (3,'Redmond','wa');

-- Insert into edge table. While inserting into an edge table,
-- you need to provide the $node_id from $from_id and $to_id columns.
/* Insert which restaurants each person likes */
INSERT INTO likes
	VALUES ((SELECT $node_id FROM Person WHERE ID = 1), (SELECT $node_id FROM Restaurant WHERE ID = 1), 9)
		 , ((SELECT $node_id FROM Person WHERE ID = 2), (SELECT $node_id FROM Restaurant WHERE ID = 2), 9)
		 , ((SELECT $node_id FROM Person WHERE ID = 3), (SELECT $node_id FROM Restaurant WHERE ID = 3), 9)
		 , ((SELECT $node_id FROM Person WHERE ID = 4), (SELECT $node_id FROM Restaurant WHERE ID = 3), 9)
		 , ((SELECT $node_id FROM Person WHERE ID = 5), (SELECT $node_id FROM Restaurant WHERE ID = 3), 9);

/* Associate in which city live each person*/
INSERT INTO livesIn
	VALUES ((SELECT $node_id FROM Person WHERE ID = 1), (SELECT $node_id FROM City WHERE ID = 1))
		 , ((SELECT $node_id FROM Person WHERE ID = 2), (SELECT $node_id FROM City WHERE ID = 2))
		 , ((SELECT $node_id FROM Person WHERE ID = 3), (SELECT $node_id FROM City WHERE ID = 3))
		 , ((SELECT $node_id FROM Person WHERE ID = 4), (SELECT $node_id FROM City WHERE ID = 3))
		 , ((SELECT $node_id FROM Person WHERE ID = 5), (SELECT $node_id FROM City WHERE ID = 1));

/* Insert data where the restaurants are located */
INSERT INTO locatedIn
	VALUES ((SELECT $node_id FROM Restaurant WHERE ID = 1), (SELECT $node_id FROM City WHERE ID =1))
		 , ((SELECT $node_id FROM Restaurant WHERE ID = 2), (SELECT $node_id FROM City WHERE ID =2))
		 , ((SELECT $node_id FROM Restaurant WHERE ID = 3), (SELECT $node_id FROM City WHERE ID =3));

/* Insert data into the friendOf edge */
INSERT INTO friendOf
	VALUES ((SELECT $NODE_ID FROM Person WHERE ID = 1), (SELECT $NODE_ID FROM Person WHERE ID = 2))
		 , ((SELECT $NODE_ID FROM Person WHERE ID = 2), (SELECT $NODE_ID FROM Person WHERE ID = 3))
		 , ((SELECT $NODE_ID FROM Person WHERE ID = 3), (SELECT $NODE_ID FROM Person WHERE ID = 1))
		 , ((SELECT $NODE_ID FROM Person WHERE ID = 4), (SELECT $NODE_ID FROM Person WHERE ID = 2))
		 , ((SELECT $NODE_ID FROM Person WHERE ID = 5), (SELECT $NODE_ID FROM Person WHERE ID = 4));

-- Find Restaurants that John likes
SELECT Restaurant.name
FROM Person, likes, Restaurant
WHERE MATCH (Person-(likes)->Restaurant)
AND Person.name = 'John';

-- Find Restaurants that John's friends like
SELECT Restaurant.name
FROM Person person1, Person person2, likes, friendOf, Restaurant
WHERE MATCH(person1-(friendOf)->person2-(likes)->Restaurant)
AND person1.name='John';

-- Find people who like a restaurant in the same city they live in
SELECT Person.name
FROM Person, likes, Restaurant, livesIn, City, locatedIn
WHERE MATCH (Person-(likes)->Restaurant-(locatedIn)->City AND Person-(livesIn)->City);

-- Find friends-of-friends-of-friends, excluding those cases where the relationship "loops back".
-- For example, Alice is a friend of John; John is a friend of Mary; and Mary in turn is a friend of Alice.
-- This causes a "loop" back to Alice. In many cases, it is necessary to explicitly check for such loops and exclude the results.
SELECT CONCAT(Person.name, '->', Person2.name, '->', Person3.name, '->', Person4.name)
FROM Person, friendOf, Person as Person2, friendOf as friendOffriend, Person as Person3, friendOf as friendOffriendOfFriend, Person as Person4
WHERE MATCH (Person-(friendOf)->Person2-(friendOffriend)->Person3-(friendOffriendOfFriend)->Person4)
AND Person2.name != Person.name
AND Person3.name != Person2.name
AND Person4.name != Person3.name
AND Person.name != Person4.name;

needs to be fixed in DacFx

This is working in the latest insiders, but I couldn't find a specific commit in DacFx that might have fixed this. Closing since it no longer repros.

@kisantia I think I have fixed the issue in dacfx a while back.

to be more specific, i think it is this commit: https://msdata.visualstudio.com/SQLToolsAndLibraries/_git/DacFx/commit/f1d0e44376452adae1b42b1de847e9ac49a11f59


Provide method of comparing currently deployed revisions

I was writing a notify task for Shipit and realized there was no way to get the SHA of deployed revisions.
In Capistrano, a REVISION file is created in the deploy path containing the SHA.
This allows us to set something like shipit.currentRevision / shipit.previousRevision, so, e.g. one could use them to compare with git log and print out a nice list of commits included in the current release.
It would also allow for methods like pending to show what hasn't been deployed yet.
I can work on PR for this, but let me know if this is something you'd merge in. Otherwise I'll just use shipit-deploy's event hooks and do it somewhere else

FYI - most of the methods necessary to do this already exist in the rollback task.

@timkelty I think it's a good idea, OK for me, if it's a breaking change do it in v2, else you can do it in master.

Sounds good.


Language Server references for COBOL and PL/I

Added entries for IBM's free COBOL and PL/I language servers.

The sorting is by language and not product name as people would look for the language.


new "view" mount type

Rename BackendConfig to MountConfig, since a view is a mount, but not a backend. New subtype, ViewConfig, holding a (parsed) query and optional temporary path. The codec translates between that and the URI syntax, which looks like sql2:///foo/bar?q=select+*+... (note: always three slashes, whether or not there is a temp path present, because a name after the second slash is interpreted as a "host" by standard parsers.)
The /mount API now handles reading, validating, and writing view mounts and will persist them in the config file, but they are otherwise ignored, pending SD-977 and SD-978.

Review by @wemrysi (I can't seem to assign the PR to you at the moment).

Current coverage is 85.13%

Merging #966 into master will increase coverage by +0.17% as of 2ca86b4

@@            master    #966   diff @@
======================================
  Files            7       7
  Stmts          592     592
  Branches        36      36
  Methods          0       0
======================================
+ Hit            503     504     +1
  Partial          0       0
+ Missed          89      88     -1

Review entire Coverage Diff as of 2ca86b4

Powered by Codecov. Updated on successful CI builds.

More generally, what is the benefit of merging this now, with stubbed implementations and TODOs, vs just waiting to include the changes in this PR with the rest of the implementation?

That's a fair question. In fact, I held back on updating the README because this commit provides essentially no useful functionality. The only reason to merge it as is would be for the satisfaction of closing SD-977 (a sub-task).
If you think it makes more sense, I'll close this PR and submit one soon with another commit closing 976, which will eliminate the TODOs and be useful enough to document.

I think I'd prefer that, if you don't mind, just to try and keep master as tidy/release-ready as possible (not that this commit is necessarily harmful).

New PR coming up soon.


Add GitHub Actions, Development Container, Remove CircleCI

This PR:
Adds three GitHub Actions:
00-azure.yaml: Authenticates against Azure and successfully runs simem (via the test test command).
00-azure-empty.yaml: triggered by workflow_dispatch, authenticates against Azure, and is able to clean up infrastructure by using az deployment group create to deploy an empty Bicep template.
deploy-image.yaml: Builds and pushes an image to GitHub Container Registry from the latest branch. For this we made a copy of Dockerfile_cli as a default Dockerfile, which we can probably clean up. The build is currently broken.
Adds the development container (see: .devcontainer/) that @UmakanthOS and I used to hack on this project in GitHub Codespaces.
Removes CircleCI.

Awesome!!! thank you. @jasonmesser7 can you shepherd this through please. This sounds fantastic.

I was able checkout the PR and implement the code in my own fork and it worked great!

The way the secrets work with the Service Principal is a little different so I will need to spend some time figuring that out, but otherwise it LGTM. Will merge tomorrow when I have time to set up the service principal with our main branch.


Make XMonad.Prompt.Pass traverse symlinks for its tab completion

Description
Include a description for your changes, including the motivation
behind them.
Checklist

[X] I've read CONTRIBUTING.md

[ ] I tested my changes with xmonad-testing

[X] I updated the CHANGES.md file

Thanks!


linux specific command to catch a segfault during whl tests

@iscai-msft Got some advice from Johan, going to try this to get you additional detail on linux machines.

Can one of the admins verify this patch?


Feature request: Mirroring / flip images.

Hi guys and girls.
I miss an option to mirror an image in openSeadragon.
I use an IIIF image server as image source, and in IIIF land, mirroring an image is as simple as prefixing an exclamation mark to the rotation degree. Unfortunately the openSeadragon "degrees" configuration option can't cope with that. There would also be need of a mirroring button in the control panel.
I regret that I don't have the time to implement this myself right now, but in order not to forget it, I post this feature request instead.
/O-Zone

Interesting idea! It looks like flipping an image when drawing to canvas is as simple as context.scale(-1, 1). Trickier (or at least more involved) would be flipping around all the tile math, as well as all the conversion routines for coordinates. Also, I suppose we'd need to think about whether we flip just individual images or the entire viewport, and what anchor point do we flip things around.
@avandecreme has done a lot with the rotation code... any thoughts about the implications of mirroring?

I can't think of any issue involving mirroring and rotation.
I can think of one with clipping however. Should just the clipped region be mirrored? If so, in place or relative to the entire image?
If flipping per image, the easiest implementation would be to just draw normally in the sketchCanvas and then draw the sketch canvas in the main canvas with mirroring.

I can't think of any issue involving mirroring and rotation.

Cool. I guess I was thinking of mirroring as being similar to rotation, so maybe there are issues you ran into with rotation that we'll also have to deal with in mirroring.

I can think of one with clipping however. Should just the clipped region be mirrored? If so, in place or relative to the entire image?

I suppose this would only be a question if we mirrored the image rather than the whole world. That said, mirroring the image is probably what we want.
I think in general I want clipping to not change the geometry of the image... it should just be a visual difference. So no, the whole image should be mirrored and then it should be clipped after that. Of course, if you can specify the point around which the image is mirrored, you can take the clipping into account if you want to.

If flipping per image, the easiest implementation would be to just draw normally in the sketchCanvas and then draw the sketch canvas in the main canvas with mirroring.
Hum, actually not. Only works if the image is entirely visible.

I went through that exact thought process!

I need mirror/flip instrument too.

+1

We would need this also. We could contribute to the project, but not really familiar with the library internally so some guidance and ideas would come handy.
Quickly prototyped and flipping the image is the easy part but navigation is more tricky. Managed to get zoom-in with scroll to work (so that it doesn't zoom to opposite direction) by adding logic height - point.y here and there, but I bet there might be some easier way.

@ernoaapa Great!
Sounds like you're working on flipping the entire world, not individual images, is that correct? I assume that's what your use case requires? Have you thought about the pros and cons of each approach?
We're happy to help with guidance... if you want you could start a "work in progress" pull request so we can be looking at the same code. Anyway, do you have specific questions? For more general guidance, perhaps @avandecreme could weigh in with lessons learned from his recent rotation patch (#1006).

I'm sorry actually I realised that I don't need flipping, rotating is enough. Would be nice to have flipping support though, but maybe later when more familiar with openseadragon.

We have a similar usecase here: https://github.com/ProjectMirador/mirador/pull/1296
We don't actually need openseadragon to flip anything, but we are using CSS to invert the element and need a way to intercept mouse events so they map correctly to the flipped version. Perhaps clipping one of OSD's generated container elements might also fix it. Any ideas for either catching events to re-write them for osd before they're interpreted, or for inverting a specific target element, for instance?

@aeschylus Neat!
We don't really have a mechanism for this exactly, but looks like it's fairly easy to monkey patch:
var originalDragHandler = viewer.innerTracker.dragHandler;
viewer.innerTracker.dragHandler = OpenSeadragon.delegate(viewer, function(event) {
    event.delta.x = -event.delta.x;
    originalDragHandler(event);
});

See here for other handlers you might want to patch:
https://github.com/openseadragon/openseadragon/blob/master/src/viewer.js#L276-L289

Thanks @iangilman. We'll give this a try.

Okay, sounds reasonable. Let's continue the conversation over in #1441... Anyone else from this thread who wants to weigh in can come over there.

shouldn't this issue be already closed?
#1441

Indeed, good catch!


WLAN Parity C# <> LabVIEW

A variety of changes to achieve parity with C#. Many files were renamed, and some parameters modified. SEM was added.

@smooresni The bulk of changes for this one is in LabVIEW. I've attached the automated diff for you: CodeDiff.zip. A few notes:

I have ignored some differences between LO stuff at the moment because those will be removed anyway from one of Michael's later commits
I have ignored differences for power servo (including autolevel config) because that will be stripped out when a TxP servo is implemented

@mdwhitten i noticed you made a push for #36. I think what you meant to do was this:

That is, read the detected properties and propagate those through. Also, does the same need to happen to C# for parity?
I'd be okay accepting this pull request if you want to back out the change and submit a new pull request for the bug fix for #36.


non existent sites

I noticed there are some non existent sites in the hosts list. For example, the very first entry: n2019cov.000webhostapp.com
Is the list checked for non existent sites at all?
If not, what would be the best way to check that programmatically?

Hi @AdKiller,
The domain n2019cov.000webhostapp.com exists 😄 see below.
Our friend Nissar @funilrys has some neat resources for checking these things.

Just to clarify it says:
Website is no longer available
The authors have deleted this site.
Start your website

Feel free to open a feature request on https://github.com/funilrys/PyFunceble to detect non-existent but still not dead sites.


chore: bump EnzymeCore compat

coverage: 97.067%. remained the same
when pulling 75c98f8e2279ddd075bbdb7e90a097965d618bc3 on avik-pal:patch-1
into dc8e0805a78e453236aefc5f03509624673cb102 on MilesCranmer:main.

Thanks! It seems like dependabot wasn’t activated for some reason? Or maybe it just updated?

The update is a couple of days old. Maybe compathelper is disabled? (it gets auto-disabled by GitHub after some inactivity period)


[PiHole v5] 2 domains invalid

After the PiHole update to v5, two domains are listed as invalid:

румайнкрафт.рф
mytripland.com:80

fixed !
thanks

Thanks!


Ability to define source

Hey,
The ability to define the source (IRR) would be very helpful as well.
Thanks!

What would be the usecase? I can't envision how it would produce useful or complete output

To specify where it pulls the information from, particular if you run your own IRRd without having a default output source defined.

That is already supported: irrtree -h $your_own_irrd_host -p $port AS-COLOCLUE

Let's chat on IRC, maybe I don't understand.

Added support for sources specification in 795c50e07b150da360924a0dbdfbab4023ab17e7


trace sampling decision is not forwared when using mixer's Zipkin adapter

Bug description
When using mixer-based tracing with the zipkin adapter, traces are successfully sampled as defined by my rules, handlers and instances, but envoy always sets the x-b3-sampled Header to 0. This means that proxied applications cannot re-use the sampling decision to forward application-level spans for sampled traces.
I am aware, that this is probably by design (AFAIK requests to istio-telemetry are non-blocking, so envoy cannot know what sampling decision mixer made). I would like to find either a solution that changes this implementation or a workaround.
Affected product area (please put an X in all that apply)
[ ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[x] Policies and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
Expected behavior
The x-b3-sampled header should be set to 1 when a trace is sampled.
Steps to reproduce the bug
Set global.tracer to zipkin, pilot.traceSampling to "0.0" and deploy a handler, instance and rule (make sure to set your zipkin url in the handler). Then deploy an application that generates traces and observe that header x-b3-sampled  is always set to 0.
Manifest

apiVersion: "config.istio.io/v1alpha2"
kind: instance
metadata:
  name: default-tracespan
  namespace: istio-system
spec:
  compiledTemplate: tracespan
  params:
    traceId: request.headers["x-b3-traceid"]
    spanId: request.headers["x-b3-spanid"] | ""
    parentSpanId: request.headers["x-b3-parentspanid"] | ""
    spanName: request.path | "/"
    startTime: request.time
    endTime: response.time
    clientSpan: (context.reporter.kind | "inbound") == "outbound"
    rewriteClientSpanId: "false"
    httpStatusCode: response.code | 0
    sourceName: (source.workload.name | "") + "." + (source.workload.namespace | "")
    sourceIp: source.ip | ip("<IP_ADDRESS>")
    destinationName: |
      (destination.workload.name | "") + "." + (destination.workload.namespace | "")
    destinationIp: destination.ip | ip("<IP_ADDRESS>")
    requestSize: request.size | 0
    requestTotalSize: request.total_size | 0
    responseSize: response.size | 0
    responseTotalSize: response.total_size | 0
    apiProtocol: api.protocol | ""
    spanTags:
      http.method: request.method | ""
      http.status_code: response.code | 200
      http.url: |
        (request.scheme | "") + "://" + (request.host | "") + (request.path | "")
      request.size: request.size | 0
      response.size: response.size | 0
      user_agent: request.headers["user-agent"] | ""
      source.principal: source.principal | ""
      source.version: source.labels["version"] | ""
---
apiVersion: config.istio.io/v1alpha2
kind: rule
metadata:
  name: collect-traces
  namespace: istio-system
spec:
  actions:
  - handler: jaeger-collector
    instances:
    - default-tracespan
---
apiVersion: config.istio.io/v1alpha2
kind: handler
metadata:
  name: jaeger-collector
  namespace: istio-system
spec:
  compiledAdapter: zipkin
  params:
    url: "zipkin:9411" # Replace with your URL
    sampleProbability: 1.0

Version (include the output of istioctl version --remote and kubectl version)
istioctl version --remote
client version: 1.2.6
citadel version: 1.2.6
galley version: 1.2.6
galley version: 1.2.6
pilot version: 1.2.6
pilot version: 1.2.6
policy version: 1.2.6
policy version: 1.2.6
sidecar-injector version: 1.2.6
sidecar-injector version: 1.2.6
telemetry version: 1.2.6
telemetry version: 1.2.6

kubectl version
Client Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.1", GitCommit:"d647ddbd755faf07169599a625faf302ffc34458", GitTreeState:"clean", BuildDate:"2019-10-02T17:01:15Z", GoVersion:"go1.12.10", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.3", GitCommit:"2d3c76f9091b6bec110a5e63777c332469e0cba2", GitTreeState:"clean", BuildDate:"2019-08-19T11:05:50Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"linux/amd64"}

How was Istio installed?
Using the helm-chart
Environment where bug was observed (cloud vendor, OS, etc)
Bare-metal kubernetes cluster

Alternatively can you set pilot's tracing sampling rate to the desired value and config mixer rule to match based on header value of x-b3-sampled?

That would be possible, but I would also have to define a zipkin url of /dev/null for proxies only, otherwise spans would be sent twice (by proxy and by mixer).
I would also lose the option to define different sampling rates for different namespaces, which would be rather important. A solution without that compromise would be preferred.

IIRC, to make envoy only generate b3 headers but not send out spans, you could set global.enableTracing as true but set global.proxy.tracer to empty string.
If finer grained sampling rate is the reason why you are using mixer pipeline, you could consider using EnvoyFilter API to achieve this: https://github.com/istio/istio/wiki/EnvoyFilter-Samples#tracing-and-access-logging.

@maxbischoff this is a known limitation with using Mixer for tracing. As @bianpengyuan relates, there are workarounds that allow the sampling rate to match and to prevent Envoy from generating traces. With 1.3, the EnvoyFilter API provides the namespace-scoping functionality you desire (although, it is worth noting that a sampling decision is sticky when considering cross-namespace traffic).
As Mixer is being replaced in the Istio architecture, I'm going to close this issue. Please feel free to reopen if you don't believe this is the correct action.


pull request for e2e test at 11/05/2016 20:25:59

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

optest/docs/updated_at.md
:white_check_mark:Succeeded

Details

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


making repo python3 compatible

Thanks for the PR. As you can imagine, I haven't used this in a while. Now that we are long past the sunset of python2, is there any point in keeping sys.version_info based support for that version anymore? Why not replace it with just the python3 code? And based on a quick look, some old style print statements are still present in the code. It would be great if you can handle them as well.

@amarghosh made changes as mentioned in your comment.

@amarghosh Any feedback?

Thanks for the PR and the comments, and apologies for the delay in response. I took a quick look at the changes and it looks fine, and ran it against few mp4 files and it seems to work fine. I am merging it in.


Warning Messages: Request and mkdirp no longer supported

An upstream library on many of our libraries is no longer supported, which results in many warnings when installing and building the application:
yarn install v1.21.1
info No lockfile found.
[1/5] Validating package.json...
[2/5] Resolving packages...
warning<EMAIL_ADDRESS>request has been deprecated, see https://github.com/request/request/issues/3142
warning restify > bunyan > mv ><EMAIL_ADDRESS>Legacy versions of mkdirp are no longer supported. Please update to mkdirp 1.x. (Note that the API surface has changed to use Promises in 1.x.)
warning lerna > cmd-shim ><EMAIL_ADDRESS>Legacy versions of mkdirp are no longer supported. Please update to mkdirp 1.x. (Note that the API surface has changed to use Promises in 1.x.)
warning mocha ><EMAIL_ADDRESS>Legacy versions of mkdirp are no longer supported. Please update to mkdirp 1.x. (Note that the API surface has changed to use Promises in 1.x.)
warning ts-node ><EMAIL_ADDRESS>Legacy versions of mkdirp are no longer supported. Please update to mkdirp 1.x. (Note that the API surface has changed to use Promises in 1.x.)
warning tslint ><EMAIL_ADDRESS>Legacy versions of mkdirp are no longer supported. Please update to mkdirp 1.x. (Note that the API surface has changed to use Promises in 1.x.)
warning webpack ><EMAIL_ADDRESS>Legacy versions of mkdirp are no longer supported. Please update to mkdirp 1.x. (Note that the API surface has changed to use Promises in 1.x.)
warning webpack > watchpack > chokidar > fsevents > node-pre-gyp ><EMAIL_ADDRESS>Legacy versions of mkdirp are no longer supported. Please update to mkdirp 1.x. (Note that the API surface has changed to use Promises in 1.x.)
warning webpack > watchpack > chokidar > fsevents > node-pre-gyp > tar ><EMAIL_ADDRESS>Legacy versions of mkdirp are no longer supported. Please update to mkdirp 1.x. (Note that the API surface has changed to use Promises in 1.x.)
warning webpack > watchpack > chokidar > braces > snapdragon > source-map-resolve ><EMAIL_ADDRESS>Please see https://github.com/lydell/urix#deprecated
warning webpack > watchpack > chokidar > braces > snapdragon > source-map-resolve ><EMAIL_ADDRESS>https://github.com/lydell/resolve-url#deprecated
warning workspace-aggregator-3854782d-270e-4be3-bfdd-828ab0a6c179 ><EMAIL_ADDRESS>request has been deprecated, see https://github.com/request/request/issues/3142
warning workspace-aggregator-3854782d-270e-4be3-bfdd-828ab0a6c179 > autotest ><EMAIL_ADDRESS>request has been deprecated, see https://github.com/request/request/issues/3142
warning workspace-aggregator-3854782d-270e-4be3-bfdd-828ab0a6c179 > portal-backend ><EMAIL_ADDRESS>request has been deprecated, see https://github.com/request/request/issues/3142
warning workspace-aggregator-3854782d-270e-4be3-bfdd-828ab0a6c179 > autotest > mocha ><EMAIL_ADDRESS>Legacy versions of mkdirp are no longer supported. Please update to mkdirp 1.x. (Note that the API surface has changed to use Promises in 1.x.)
warning workspace-aggregator-3854782d-270e-4be3-bfdd-828ab0a6c179 > autotest > ts-node ><EMAIL_ADDRESS>Legacy versions of mkdirp are no longer supported. Please update to mkdirp 1.x. (Note that the API surface has changed to use Promises in 1.x.)
warning workspace-aggregator-3854782d-270e-4be3-bfdd-828ab0a6c179 > autotest > nyc ><EMAIL_ADDRESS>Legacy versions of mkdirp are no longer supported. Please update to mkdirp 1.x. (Note that the API surface has changed to use Promises in 1.x.)
warning workspace-aggregator-3854782d-270e-4be3-bfdd-828ab0a6c179 > autotest > coveralls ><EMAIL_ADDRESS>request has been deprecated, see https://github.com/request/request/issues/3142
warning workspace-aggregator-3854782d-270e-4be3-bfdd-828ab0a6c179 > autotest > mocha-junit-reporter ><EMAIL_ADDRESS>Legacy versions of mkdirp are no longer supported. Please update to mkdirp 1.x. (Note that the API surface has changed to use Promises in 1.x.)
warning workspace-aggregator-3854782d-270e-4be3-bfdd-828ab0a6c179 > portal-backend > awesome-typescript-loader ><EMAIL_ADDRESS>Legacy versions of mkdirp are no longer supported. Please update to mkdirp 1.x. (Note that the API surface has changed to use Promises in 1.x.)
warning workspace-aggregator-3854782d-270e-4be3-bfdd-828ab0a6c179 > autotest > nyc > caching-transform ><EMAIL_ADDRESS>Legacy versions of mkdirp are no longer supported. Please update to mkdirp 1.x. (Note that the API surface has changed to use Promises in 1.x.)
warning workspace-aggregator-3854782d-270e-4be3-bfdd-828ab0a6c179 > autotest > nyc > find-cache-dir ><EMAIL_ADDRESS>Legacy versions of mkdirp are no longer supported. Please update to mkdirp 1.x. (Note that the API surface has changed to use Promises in 1.x.)
warning workspace-aggregator-3854782d-270e-4be3-bfdd-828ab0a6c179 > autotest > nyc > istanbul-lib-report ><EMAIL_ADDRESS>Legacy versions of mkdirp are no longer supported. Please update to mkdirp 1.x. (Note that the API surface has changed to use Promises in 1.x.)
warning workspace-aggregator-3854782d-270e-4be3-bfdd-828ab0a6c179 > autotest > nyc > spawn-wrap ><EMAIL_ADDRESS>Legacy versions of mkdirp are no longer supported. Please update to mkdirp 1.x. (Note that the API surface has changed to use Promises in 1.x.)
warning workspace-aggregator-3854782d-270e-4be3-bfdd-828ab0a6c179 > autotest > nyc > istanbul-lib-source-maps ><EMAIL_ADDRESS>Legacy versions of mkdirp are no longer supported. Please update to mkdirp 1.x. (Note that the API surface has changed to use Promises in 1.x.)
warning workspace-aggregator-3854782d-270e-4be3-bfdd-828ab0a6c179 > autotest > dockerode > tar-fs ><EMAIL_ADDRESS>Legacy versions of mkdirp are no longer supported. Please update to mkdirp 1.x. (Note that the API surface has changed to use Promises in 1.x.)
[3/5] Fetching packages...
warning<EMAIL_ADDRESS>Invalid bin entry for "sha.js" (in "sha.js").

Request has also been recently deprecated, which is pretty significant. It will have to be replaced, as it is no longer being supported.

@winstan See above.

After giving this a preliminary look, mkdirp is still being used by many downstream libraries. I will have to wait a bit longer until newer packages are published for our NPM library that eliminates the use of mkdirp deprecated dependencies.

Note: It looks like some our of libraries have been eliminating the deprecated mkdirp dependency in their libraries, as I am seeing far less warnings.

https://github.com/ubccpsctech/classy/pull/108

Request issue mostly dealt with here.

There is still a deprecated request reference in one of the libraries that we use. This can be resolved in a separate PR.

Remaining mkdirp issue removed by upgrading Mocha. No mkdirp warning exists in build now:
Back-end:

AutoTest:


Ability To Export Kube Config Manually

NOTE: on the surface this may seem extremely close to #766, but I promise it is distinct enough to warrant discussion

Is your feature request related to a problem? Please describe.
I regularly work with multiple kubernetes clusters (think local <orbstack> vs prod <eks>) and prefer to keep ~/.kube/config "empty" and instead have a discrete config file for each cluster. Granted this does require me to either set a KUBECONFIG variable or pass a --kubeconfig argument, but the flip side is it's much harder for me to accidentally nuke a cluster (or simply apply a manifest unintentionally).
Currently, the only options for actually get a hold of the kube config for orbstack's cluster appear to be tied to having docker.set_context set to true in orbstack's config which is in turn (appears to be) hard coded to update the file at ~/.kube/config.
Describe the solution you'd like
It would be nice to have a dedicated export command (i.e. orbctl config show --kube) similarly to how k3d exposes this kind of functionality [ref]. I think a more ideal solution might be to give kubernetes-related commands their own "namespace" in orbctl and use that as the primary means of exposing kubernetes functionality, up to and including treating orb k8s ... as a sort of alias for running whatever ... is in the k8s "vm" (the same way orbctl handles running stuff in "regular" linux vms). That would make it possible to just do something similar to what the k3s docs show [ref] (i.e. orbctl k8s cat /path/to/orbctl/kubeconfig.yaml).

Running commands in the machine would be possible with orb -m k8s ... but that's disabled because paths and other properties of the machine setup are implementation details that are prone to change.
An orb k8s command will be added to accommodate this, similar to the existing orb docker and orb ssh.

@kdrag0n That sounds ideal. For the sake of clarity - the aforementioned orb k8s command will include some method of exporting the kube config? Also, is there a potential timeline on the feature release (even if it's an extremely rough one)?

Added for the next version. ~/.orbstack/k8s/config.yml instead of having to use a command.

Released in v1.2.0.


Fix through association nested preloads

Closes https://github.com/elixir-ecto/ecto/issues/4112
I didn't add tests yet because I wanted to see what you thought about the solution presented here and the alternative solution. This one is really tricky.
Background
When using Repo.preload, it is possible for through associations to lose their nested preloads like this
  from c in Comment,
    join: t in ThroughAssoc,
    on: c.through_id == t.id,
    join: u in User,
    on: t.user_id == u.id,
    preload: [through_assoc: {t, [:some_other_assoc, user: u]}]

What happens is this:

The join preloads put User into ThroughAssoc and ThroughAssoc into Comment
The separate query preload puts :some_other_assoc into ThroughAssoc. However, it does this by generating the association chain and then putting it into the through field. This association chain does not have User inside of ThroughAssoc so that nested preload is lost.

Solution
The solution in this PR is pretty simple. If the through association is already loaded then we preload directly into it. The same way we do for embeds. When determining whether to put the association chain into the through field, we simply don't put the association chain into the through field if it has already been loaded. However, the chain is still calculated and put into the "regular" association fields.
The drawback of this method is that we are adding additional queries for the loaded through associations. Taking into account nested associations, this could end up with a decent amount of extra queries.
Alternative Solution
The alternative solution is to not preload the association chain if the through association has been loaded. I tried this out first but it gets quite complex to the point where I'm not sure there is any sane way to do it. There are two main issues:

Different through associations can overlap in their association chains. For example:

posts => author => location
posts => author => company => department
posts => author => company => manager => director

Depending on which of these 3  through fields are already loaded, we would have to keep track of which sub-preloads at each nested layer are to be kept.

Building off of point (1), the chain of preloads is dependent on which struct you are looking at. Since each struct can have different fields loaded/unloaded, not every one will have the same chain of nested preloads. This goes against the current flow in the code which assumes each struct in a give layer has the same sub-preloads.

It also means we have to carry over information several layers deep. For example, a field on post might control whether manager is preloaded. But by the time we get to manager we've lost all the post information because we preload recursively.

Awesome. This looks good to me but it feels it could be slightly backwards compatible, right? Previously we were always preloading through (as it force: true) and now it make it behave like (force: false), right?

Yeah definitely it changes the behaviour. In addition to the change of force behaviour it also changes some of the nested preload behaviour. For example, if you had this:
schema "posts" do
  has_many :comments_authors, through: [:comments, :authors]
  has_many :comments
end

schema "comments" do
  belongs_to :author
end

schema "authors" do
  has_one :permalink
  has_many :posts
end

post = Repo.preload(post, :comments_authors)
post = Repo.preload(post, [comments_authors: [:permalink], comments: [authors: [:posts]]])

In the second preload the :comments_authors gets expanded to its association chain and :permalink and :posts end up getting put into the authors struct. Since we were forcing an overwrite in the past, :posts would also be nested inside of :comments_authors even though it wasn't explicitly set. But with the change it won't get put there.
Now that you mention forcing, if we go ahead with this then I should also take it into account and allow the overwrite if force is true.

Maybe an alternative solution here is to know if the association has been loaded because it happens via Repo.preload or if it happens via query (i.e. preload+join)?
If the preload is filled because of a preload+join, then we can apply the heuristic in this patch, because the user is explicitly saying they want their given struct to win (i.e. it is force: false).
If it is a Repo.preload, then can keep the current semantics of filling in the association chain?

That's a really good idea. What do you think about the last commit? If you like it, I can write the integration tests.

Wait a second, you mentioned that in this case we will no longer have authors and posts in comments or something.

post = Repo.preload(post, [comments_authors: [:permalink], comments: [authors: [:posts]]])

But wouldn't we be able to know if comments_authors was set before hand (before calling preload) or set by preload itself? In this case, we could:

If it was set before hand, we keep whatever is there, excepting forcing
If it is was not set, we preserve today's behaviour

Would this be able to reduce the backwards incompatible changes without adding a new option?

Sorry I probably am not understanding properly. Would this be the same as my original commit or something different?

Sorry, I am telling you my conclusions but not my thought process. There are two concerns in this PR, as far as I know:

force_through changing the behaviour from true to false

post = Repo.preload(post, [comments_authors: [:permalink], comments: [authors: [:posts]]]) not getting expanded into the authors struct

What I am saying is that, we only need to change the behaviour of preload: [...] with joins in them, we can keep everything else behaving the exact same. And we can probably do that by passing some additional information here: https://github.com/elixir-ecto/ecto/blob/master/lib/ecto/repo/queryable.ex#L238

Oh I see what you mean now. There is a case to change the behaviour for Repo.preload as well. The reason is to keep parity with non-through preloads. For example
post = Repo.preload(post, [non_through_assoc: [:nested_assoc]])
post = Repo.preload(post, :non_through_assoc)

In the case above, post will still keep :nested_assoc. But for the case below it will not because the through field is wiped by the preload chain of "regular" assocs:
post = Repo.preload(post, [through_assoc: [:nested_assoc]])
post = Repo.preload(post, through_assoc)

I don't personally see a reason to expect non-through and through assocs to behave differently here. But to maintain backwards compatibility I thought it might be worth giving them an option instead of outright changing the behaviour.

Actually I misspoke a bit for this example:
post = Repo.preload(post, [through_assoc: [:nested_assoc]])
post = Repo.preload(post, through_assoc)

This will still have :nested_assoc. It only won't if you reset the "regular" assoc that is part of the through assoc. So for instance if you have this
schema "posts" do
  has_many :through_assoc, through: [:through1, through2]
  has_one :through1
end

Then if you do this, the nested assoc would disappear:
post = Repo.preload(post, [through_assoc: [:nested_assoc]])
post = Ecto.reset_fields(post, [:through1])
post = Repo.preload(post, through_assoc)

I think what you said makes sense then. As long as you are using Repo.preload normally and not resetting random fields it will behave consistently. I'll change the PR.

WDYT?

The only chance in behaviour is when you preload a through with joins and regular assocs, which was broken anyway (i.e. it was the original bug report)?

Yeah exactly. The following are backwards compatible:

Everything with Repo.preload
Everything with Ecto.Query.preload not involving throughs
Everything with Ecto.Query.preload involving throughs not used in joins
Everything with Ecto.Query.preload involving throughs used in joins as long as they don't have separate query preloads

The following is not backwards compatible:

Ecto.Query.preload when a through association is used in a join and has a nested separate query preload

In this case, the differences are:

the association chain is no longer preloaded and we simply preload directly onto the loaded through association.
as an additional consequence of 1, if the user goes out of their way to specify both the through association and the individual through components in the preload list,there won't be any merging of the sub-preloads here: https://github.com/elixir-ecto/ecto/blob/1e9b87bb08b579ee1e3932c239853f57bc79e5aa/lib/ecto/repo/preloader.ex#L673

Before I merge, could you confirm ^ is ok with you as well? Thanks!

Yup, it is all good to me. Beautifully done!


Deploy DMN to Camunda is broken

Describe the Bug
When trying to deploy a DMN diagram do Camunda Platform and having Enable Usage Statistics on, the deployment fails and an error is thrown.
Relevant sentry issue: https://sentry.io/organizations/camunda-modeling/issues/2359365986/?project=5223041&query=is%3Aunresolved&statsPeriod=14d
Steps to Reproduce

Enable Usage Statistics
Have Camunda Platform running
Create new DMN file
Try to deploy via Deploy Dialog
Error:

    at error (index.esm.js?e7ad:64)
    at eval (index.esm.js?e7ad:895)
    at new Promise (<anonymous>)
    at Reader.fromXML (index.esm.js?e7ad:880)
    at BpmnModdle.fromXML (index.esm.js?1ef9:58)
    at getDefinitions (parse.js?dede:29)
    at getEngineProfile (parse.js?dede:35)
    at DeploymentEventHandler.eval [as getEngineProfile] (DeploymentEventHandler.js?9650:73)
    at EventEmitter.eval (DeploymentEventHandler.js?9650:113)

The root cause appears to be quite obvious: we are trying to parse the engineProfile, but don't store it for DMN files.
Expected Behavior
Deployment of DMN to Camunda Platform is possible.
Environment

OS: Arch Linux
Camunda Modeler Version: 4.7.0
Installed plug-ins: n/a

Closed via https://github.com/camunda/camunda-modeler/pull/2244


refactor(api)!: update annotations used for user -> sa mappings

Encountered this while working on docs...
Since these annotations accept multiple comma-delimited values, it seems to makes more sense if the keys end with plural nouns to reflect that.

After offline discussion with @jessesuen, we've decided there's a benefit to keeping these annotations such that they match the corresponding OIDC claim names.
Closing.


parsing error

Type of bug
Parsing error
Version
0.1.1
Did you test against master?

[ ] Certainly

Error message (if not timeout)
dconf2nix: "dconf.settings" (line 263, column 34):
unexpected "{"
expecting "<("
CallStack (from HasCallStack):
  error, called at src/DConf2Nix.hs:35:16 in dconf2nix-0.1.1-Kj3okwrvVsmLXSmJ1JaeH6:DConf2Nix

DConf input
[org/gnome/shell]
app-picker-layout=[{'Utilities': <{'position': <0>}>}]

Additional context
No response

I've managed to work around this by deleting that setting from the file using the crudini tool for performing CRUD operations on INI files. I am not sure whether the output format of dconf dump is valid INI, but crudini can handle it just fine.
Example:
dconf dump / > dconf.settings
crudini --del dconf.settings 'org/gnome/shell' 'app-picker-layout'
dconf2nix -i dconf.settings -o dconf.settings.nix

I used sed:
mike-nixos  main @ 44750a0 ⩮∽+⇡ ❄ flakeShell-env! dconf dump / | sed '/</d' > dconf.ini


Falco Driver for ECS Fargate in Oct. 2024?

The documentation for Falco says to use PDIG as the driver for Falco when running on AWS ECS with Fargate.
The falcosecurity/pdig repo is archived.
in 2024, October what's the best option for running Falco on ECS Fargate?
Thank you kindly! I  :heart: Falco!
~G

Thanks for your kind support :heart:
For now, we don't have any good solution for ECS. The pdig project has been archived because of a lack of contributors,  and the bad perfs with the underlying use of ptrace (the running process is stopped at every syscall to emit the trace).
AWS mentioned in the past they were ready to open the gate to the use of eBPF for the Fargate but they changed their mind.


Template support (like arm templates)

Is your feature request related to a problem? Please describe.
nope
Describe the solution you'd like
When creating resources with az you can create each resource manually or via a powershell/bash script.
ARM has templates, why not support an option like "az template <file.yml>"
Yaml could be formatted like this: (kinda like Ansible syntax)
---
vars:
  foo: "bar"
  number: 42

var_files:
  - ./vars/myvars.yml

resources:
  group:
    create:
    - name: "MyResourceGroup1"
	  location: "westeurope"
    - name: "MyResourceGroup2"
	  location: "westeurope"
	  resource-type: "Microsoft.web/site"
  vm:
    create:
	- name: MyVm
	  resource-group: "MyResourceGroup"
	  public-ip-address: ""
	  image: "Win2012R2Datacenter"
	  nic:
	    - nic_name1
	    - nic_name2
	  disk_attach:
	    - name: "disk_{{ foo }}"
		  new: true
		  size-gb: {{ number }}
		  sku: "Standard_LRS"

Describe alternatives you've considered
You could use az deployment and use ARM templates and this could also be used in terraform or ansible. However when starting with ARM they can look quite daunting I think this yaml is more readable and cleaner.
You can also create a script for deployment. When creating a script you have to choose upfront if you want Bash or Powershell and they are not interoperable in the way variables are defined.
Additional context
Other non-platform specific tools like terraform or ansible depend on azure cli or the azure cli python library. When new features are made available through ARM they first need to be incorporated in AZ and python libs. Only then those tools can incorporate those features into their platform before they are available to the users of those tools.
This serial development takes time and often not all features are incorporated.
When those tools could offload commands to native tools like azure cli you cut some development time and use the full feature set azure cli offers
@ansible-collections

ARM

@yonzhan . You mean ARM as a tag or in a sense that ARM should be used / provides this function already?

@bvduijn Do you want to use yaml file to configure deployed resources instead of ARM template?

@zhoxing-ms  Yes that's the idea. ARM templates can get quite Big for small things you want to do. You need to define your parameters, dependencies and referencing these is a syntax on its own.  Like so :
"storageUri": "[concat('http://',variables('diagStorageAccountName'),'.blob.core.windows.net')]"

Very easy to overlook an ( of ] whereas with yaml with Jinja2 :
"storageUri": "http://"{{ diagStorageAccountName }}.blob.core.windows.net"

And dependencies could be defined just by identation
Az takes a lot of those troubles of working with ARM away and I understand it's implementation as a form of backward compatibility.

I suggest that this new feature should be implemented by ARM service:

The parsing and deployment of ARM template is implemented by ARM service, and the parsing and deployment of yaml file should be similar.
If CLI parses yaml file, and then send some separate requests to REST to deploy resources, there will be complex issues of performance and cross RP collaboration.
If ARM service supports this feature, then multiple teminals (PowerShell, Terraform) can use this feature, not only CLI.

So it need the support from ARM service team.


Support for JWKS refresh in Istiod when a non cached KID is seen in JWT token

(This is used to request new product features, please visit https://discuss.istio.io for questions on using Istio)
Describe the feature request
IdP such as Azure AD will do key rotation unannounced. When a new public key is introduced to jwks, new JWT tokens are signed with this new private key almost immediately.
How it will manifest as an issue:
Clients will get new JWT tokens signed by the newly introduced private key and the new KID will show up in their JWT tokens.
This new KID will not be in the Istiod JWKS cache for 20 minutes. This interval can be set small if desired.
However setting cache interva smalll doesn't entirely get rid of the problem.
The right solution would be for Istiod to refresh JWKS when it sees a new KID which is not in JWKS cache.
Pilot variable PILOT_JWT_ENABLE_REMOTE_JWKS  now support Envoy as an option however whether JWKS refresh happens on a cache miss of KID is not clear is still unknown. Does it? Or Does Istiod now does JWKS refresh upon a KID miss in cache?
Describe alternatives you've considered
Run a very cache refresh interval such as 1 minute or so. But kind of defeats the purpose of cache and not addressing the root cause.
set to 1minute or less  PILOT_JWT_PUB_KEY_REFRESH_INTERVAL
Affected product area (please put an X in all that apply)
[ ] Ambient
[ ] Docs
[ ] Dual Stack
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Extensions and Telemetry
[X ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
Affected features (please put an X in all that apply)
[ ] Multi Cluster
[ ] Virtual Machine
[ ] Multi Control Plane
Additional context
Azure AD doc describing the issue and requirement from the key verifier
Eg:
https://learn.microsoft.com/en-us/entra/identity-platform/signing-key-rollover
Quoting relevant info from above doc
For security purposes, the Microsoft identity platform’s signing key rolls on a periodic basis and, in the case of an emergency, could be rolled over immediately.
"Checking every 24 hours for updates is a best practice, with throttled (once every five minutes at most) immediate refreshes of the key document if a token is encountered that doesn't validate with the keys in your application's cache."
Essentially: the key verifier (envoy or istiod) should do immediate jwks refresh when a new KID

will change PILOT_JWT_ENABLE_REMOTE_JWKS to envoy help?

PILOT_JWT_ENABLE_REMOTE_JWKS - As far as I know, this merely handoff the JWKS fetching from Pilot to Envoy and pass the responsibility of caching and keeping public keys (jwks) refreshed to Envoy.
However unclear How envoy does JWKS refresh. ?
Does envoy fetch a new JWKS if it receives a JWT with a KID which is not cached in envoy. (default 10m jwks envoy cache)
So the issue is not going away with this setting: PILOT_JWT_ENABLE_REMOTE_JWKS
It merely hand off the responsibility from Pilot to envoy.
As per this envoy issue, this "new KID" is still an outstanding issue -
https://github.com/envoyproxy/envoy/issues/14557#issuecomment-754325193
Is there anything Istiod can do in the meantime to address this "new KID" issue

IMO, envoy async fetch mode is the future, if envoy doesn't, istio should wait for envoy first.
WDYT @istio/wg-security-maintainers

The right solution would be for Istiod to refresh JWKS when it sees a new KID which is not in JWKS cache.

How does istiod get to know when it is refreshed.? I donot think we can do this.

The right solution would be for Istiod to refresh JWKS when it sees a new KID which is not in JWKS cache.

How does istiod get to know when it is refreshed.? I donot think we can do this.
true...If Istiod doesn't see the JWT token it cant possibly know when a new KID arrives.

Just a thought:-
envoy sees to be recording jwt verification status code and message in failed_status_in_metadata as per envoy doc below
https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/http/jwt_authn/v3/config.proto
The values of this field will be code and message and they will contain the JWT authentication failure status code and a message describing the failure.
I ran a test against Istio by manipulating the jwt header for a KID I know doesn't exist in JWKS and I get a clear message in my http call to the service
"Jwks doesn't have key to match kid or alg from Jwt". I am thinking this is coming from envoy
If Istiod can get the verification error status from envoy and finding the status message related to non-matching kid, proceeds to do a jwks refresh and send out the refreshed jwks to all the envoys.
It wont be the perfect solution as few verification requests will fail while istiod refreshes the cache and push it out. (Apps can retry with same jwt token). And it would be better than waiting for the next periodic cache refresh interval.

Istiod cannot get that error message. Even if istiod can get that error, i donot think it should be responsible do that. This can cause DDOS vulnerability

Envoy gets a JWT, decodes the JWT - and finds the issuer and KID.
At this point it has the JWTs that Istiod has pushed - or it can fetch JWT from 'remoteJWKS' if that's how it is configured.
Istiod has no visibility into the JWT the each envoy sees - it can't check the status or errors in envoy.
Assuming Envoy code is handling this properly - or it can be fixed, the correct behavior would be for Envoy to
attempt to fetch the JWTs from the remoteJWKS URL if the KID is unknown.
This has some unfortunate effects - an attacker can do a DOS by sending a lot of JWTs with invalid signature but different KIDs, causing all envoys that get this request to fetch from the OIDC well known - with the retries we do it's an amplification attack, so hopefully envoy has code to not fetch too often. But it may work.
If Envoy does not have permissions to connect to the remoteJWKS - and user expects Istiod ( which presumably has the network permissions ) - we may be able to point remoteJWKS to an egress gateway or use Istiod as a cache.
The other approach - which is probably much better but requires issuers/IDPs to do the right thing - is to not issue tokens with the new key immediately, but instead distribute the new key and wait for some time (1h, 1 day ?) before
starting to use it.
I suspect the best short term option is to configure JWT fetching from envoy and make sure envoy is fetching with some rate limitting if KID not found.

I understand the DOS possibility you explained which is very valid especially if the Istio Ingress is exposed publicly.
The short term approach you described would be great if it can be implemented in envoy
ie. fetch JWKS with some rate limit . Also give a flag to turn on/off that feature for customer (preferably on a workload selector basis )
The flag could allow customers to decide whether to turn off/on depending on whether envoy is not exposed publicly( no bad actors) vs public (bad actors).
As far as IdPs not to issue tokens with new key immediately - that is how most IdPs do key rotation. However IdP warn consumers not to rely on that mechanism. Since there may be occasions where an immediate key rotation may be needed such as compromised key. For eg. Azure AD describe this in their signing key rollover document

The other approach - which is probably much better but requires issuers/IDPs to do the right thing - is to not issue tokens with the new key immediately, but instead distribute the new key and wait for some time (1h, 1 day ?) before
starting to use it.

Sorry, but I have to respectfully disagree with you. There is an official spec for OIDC protocol that defines this behaviour: https://openid.net/specs/openid-connect-core-1_0.html#RotateEncKeys
The official (and globally accepted) spec says literally:

The signer can begin using a new key at its discretion and signals the change to the verifier using the kid value. The verifier knows to go back to the jwks_uri location to re-retrieve the keys when it sees an unfamiliar kid value.

I fully understand that istio as project has its own security things to take into account and it's totally right, but suggesting to IdPs to not follow the standard isn't the right way to handle things outside istio scope.
An Identity Provider has the right to rotate/revoke/disable a signing key for multiple reasons, all of them related with the security.
Although for "regular operation", an IdP can generate they with enough time before using the new key, the current scenario could be treated as a potential security risk as an attacker who get access to the signing keys can issue valid tokens that istio will accept until the cache expires despite the OIDC spec already defines a security mechanism to prevent this. So, If I gain access to the signing key, actually nothing can be done from the IdP because istio/envoy is catching the revoked key as still valid.

This issue is still relevant:

Although for "regular operation", an IdP can generate them with enough time before using the new keys, the current scenario could be treated as a potential security risk as an attacker who get access to the signing keys can issue valid tokens that istio will accept until the cache expires despite the OIDC spec already defines a security mechanism to prevent this. So, If I gain access to the signing key, actually nothing can be done from the IdP because istio/envoy is catching the revoked key as still valid.


Do not enforce loopfunc when the function is not capturing any variable from the enclosing scope

eg:
var array = [1, 2, 3];
function test() {
  for (var i = array.length - 1; i; i--) {
    usefulBehaviour(function(message) {
      return message.id;
    });
  }
}

usefulBehaviour is not capturing anything from the outer scope and therefore is completely safe.

The original case is fixed, the 2nd is not.


Move Metadata Extraction Logic From load_data Method in Project Model to its Own Method

Context

The load_data method inside the Project model accomplishes a variety of different tasks. Among those tasks includes generating readmes, combining metadata, and creating computed files.
Metadata is received in the form of three files: project_metadata.csv, samples_metadata.csv and within each sample (/ library) a SCPCL<library_number>_metadata.json file. Inside the load_data method, each of these files is parsed, the metadata is collected and combined at the sample level, and an accumulated single_cell_metadata.tsv file is created and outputted (or spatial_metadata if the project/sample is of the spatial modality).
Problem or idea

The metadata extraction logic is too tightly coupled with the other tasks within the load_data method.
Solution or next step

The solution is to bundle together all of the logic associated with metadata extraction within theload_data method, and move it to its own method within the Project model.

This sounds right. I think we should limit this issue to handling these lines. And just extracting the nested logic into multiple functions.

https://github.com/AlexsLemonade/scpca-portal/blob/dev/api/scpca_portal/models/project.py#L859-L992

I think we should just write another issue for handling moving the metadata processing into another function.

https://github.com/AlexsLemonade/scpca-portal/blob/dev/api/scpca_portal/models/project.py#L807-L848

I agree with you on this. It makes sense to leave get_samples for another issue.
I think the following lines should also be included in the current issue:

https://github.com/AlexsLemonade/scpca-portal/blob/dev/api/scpca_portal/models/project.py#L1116-L1138

@davidsmejia With single-cell data we receive the three metadata files listed above and output a single_cell_metadata.tsv file, but with spatial data we output both the combined spatial_metadata.tsv file and the input library json file (unmodified). Is that by design or a bug?

This was addressed in #652
Will move last question about spatial to another issue.


fix(utils): relocate file location isDifferentArray function

Overview
I think a function called isDifferentArray should be utils function. I moved the location of the file because I thought it would be good for many people to use it in @toss/utils, not dependent on the @toss/error-boundary package.
question
The name of the test file does not seem to be unified in various packages.
*.spec.ts *.test.ts which one should i take?!
if there is any convention please tell me !
PR Checklist

[x] I read and included theses actions below

I have read the Contributing Guide
I have written documents and tests, if needed.

Yes, this change seems right. Actually we don’t have an explicit convention for test files right now. (Personally, I prefer *.spec.ts 😄) We will discuss and build a convention and let you know in this pull request. (cc. @HoseungJang @changyoungoh )


Missing primitives in rely with JSOO

Hy I wanted to update https://github.com/bryphe/reason-gl-matrix to rely. I was able to convert to rely natively but I can't run when building with JSOO.
I have some repro on my fork on branch Et7f3/test/switch_to_rely or commit instead https://github.com/Et7f3/reason-gl-matrix/commit/ec2fd9d2c5ea8ddc6f5172435cb49551e8db8aec
I quote some message from discord (https://ptb.discordapp.com/channels/235176658175262720/469417973820686336/641021659989540925).
Me:

For info it run fine on native with dune. I have tried only with a empty file that include Rely and I get some strange error maybe linked to str

@bandersongit

You can also look at https://github.com/aweis/irmin-web as a currently working example (though it does appear to be pinned to an older version of Rely)

Me:

I have seen in irmin-web they have added --profile=release flag. When I add it I get some other error.

@bandersongit

Looks like the issue with re is solveable by releasing a new version of Pastel

Pastel version should do it, got it working with a link to current master

also had to add a stub for unix_isatty for pastel,
I used

//Provides: unix_isatty

function unix_isatty (f) {
    return false;
};

I also changed your Testramework to

module MockSnapshotIO = {
  let readSnapshotNames = _ => [];
  let readFile: string => string = s => s;
  let removeFile: string => unit = _ => ();
  let writeFile: (string, string) => unit = (_, _) => ();
  let existsFile: string => bool = _ => false;
  let mkdirp = _ => ();
};
/* Snapshots will be virtual-modulified at some point, until then we need to inject
 * something custom with RelyInternal to make JSOO happy because the default snapshot
 * implementation uses the Unix module  */
include RelyInternal.TestFramework.MakeInternal(
          MockSnapshotIO,
          {
            let config =
              RelyInternal.TestFrameworkConfig.TestFrameworkConfig.initialize({
                snapshotDir: "test/__snapshots__",
                projectDir: "",
              });
          },
        );

@Et7f3 A new version of Pastel has been released. I'll spend some time in the next couple days making it so that snapshots don't cause these errors if they aren't being used.

I filed https://github.com/ocsigen/js_of_ocaml/issues/913 to add unix_is_atty to JSOO along with my thoughts on implementation.
I've verified that your example now works if you provide a manual stub for unix_isatty, use the latest version of Pastel, and create a snapshot directory.

I'm blind I don't see where you fix str issue 👀.

I'm blind I don't see where you fix str issue 👀.

https://github.com/facebookexperimental/reason-native/commit/d3203eaeb05b49837fa85b1daed4b31390b64e27


Installation instructions don't work

The documentation encourages the usage of:
// pick a date util library
import DateFnsUtils from '@material-ui-pickers/adapter/date-fns';

Unfortunately, it doesn't seem to work: https://codesandbox.io/s/ecstatic-solomon-v4gvv.
Environment

Tech
Version

@material-ui/pickers
v4.0.0-alpha.5

Haha typo -> @material-ui/pickers/adapter/date-fns

Oh god, I forgot to fix this before release

@dmtrKovalenko I think that it's fine, it's an alpha anyway. I would be more in favor of making released on a fixed schedule than aiming for releasing a specific set of features :).

Could we please release next alpha with this.

@mifrej a new alpha version has been release with the changes.

Already on it! Keep the great work! Thanks


Is there a way to use a UDF or lambda in groupby agg?

The following code doesn't work. Thank you!
@pandas_udf('string')
def as_set(x):
    return str(set(x))
spark.udf.register('as_set', as_set)

kdf = ks.DataFrame(
    {'a': [1, 2, 2, 4, 5, 6],
     'b': ["one", "one", "one", "two", "two", "two"]},
    index=[10, 20, 30, 40, 50, 60]
)
kdf.groupby(['b']).agg({'a', as_set})

ValueError: aggs must be a dict mapping from column name to aggregate functions (string or list of strings).

Thanks for the report, @kylegilde !
And currently the Koalas project is only in maintaining mode, so the response could be quite delayed.
The Koalas project is currently being managed more actively in PySpark under the name of "pandas API on Spark" (you can simply re-use the existing Koalas code by importing import pyspark.pandas as ks)
So if you're going to continue using Koalas, I recommend using PySpark! (You can get a quicker response if you report the issue to the Apache Spark JIRA)


question about subscriptiongroup

A broker id will be selected when creating a consumer group.Does this mean that consumers in the consumer group only consume data on the selected broker?

no，only when you turn on slaveReadEnable and other configurations will you pull messages from the configured whichBrokerWhenConsumeSlowly and brokerId


code review comments are not the same as formal code review

Look at this ticket: https://github.com/zerocracy/judges-action/pull/294 Here, only one formal code review was submitted (by @Suban05), while other two participants (@yegor256 and @Yegorov) only posted comments. However, the github-events.rb script created three pull-was-reviewed facts. This is a mistake, only one fact should have been created.

@yegor256 I can help

@rultor release, tag is 0.0.48

@rultor release, tag is 0.0.48

@yegor256 OK, I will release it now. Please check the progress here

@rultor release, tag is 0.0.48

@yegor256 Done! FYI, the full log is here (took me 30min)


Add submitSuccess as props available, onSubmitFail not works

There are now in 5.1 new callback events. But it's not possible to check in the form for "submitSuccess". Because !submitFailed is not necessary a successful submit.
ps: onSubmitFail is not called in 5.1 when promise is rejected, onSubmitSuccess will when it's resolved.
edit: I found it out because I tried to provide manually an submitSuccess prop to the form and listen to the onSubmitFail event to reset my custom submitSuccess prop.

📟 @puradox

Fix published as v5.1.1. Please verify.


evaluate with usb camera not worked

Hello,thanks for your research first ~
I am the student in graduate school now. I am very interested in this paper.
I would like to use usb camera to evaluate model,so I ran the following command depends on your Readme.md file.
python eval.py --coco_transfer --trained_model=weights/yolact_edge_54_800000.pth --score_threshold=0.3 --top_k=100 --video_multiframe=2 --video=0

But after I ran the command,I found the model read the json file and start calibration dataset for backbone of 100 images,it seems not evaluate with camera. (Like the following picture)

Was the result progress correct ?   Could you tell me what's probably going on?
Thanks you, Have a nice day,and Happy new year!!
(P.S. Why use "--coco_transfer " ? what did the option mean? thanks for your help!!)

Hi there! Did the code throw an error or did it just seem stuck in converting to TensorRT? Note that if this is the first time converting the model to TensorRT the calibration will take a long time. For example, on a Jetson AGX Xavier it took me 25 minutes to convert the entire model to TensorRT. On my side the code finished calibrating but then I ran into another issue when evaluating with a webcam. You'll want to run the following command:
python eval.py --coco_transfer --trained_model=weights/yolact_edge_54_800000.pth --score_threshold=0.3 --top_k=100 --video_multiframe=1 --video=0

The "video_multiframe" argument had to be changed to "1". This is because when we convert to TensorRT we're using batch sizes of one. We will add in an option that does the TRT conversion with higher batch sizes in order to support higher batch sizes during evaluation on videos / webcams. We will also change the README so that others don't get confused.
The "--coco_transfer" flag is used to make models that were trained with YOLACT compatible with YolactEdge.

Hi there! Did the code throw an error or did it just seem stuck in converting to TensorRT? Note that if this is the first time converting the model to TensorRT the calibration will take a long time. For example, on a Jetson AGX Xavier it took me 25 minutes to convert the entire model to TensorRT. On my side the code finished calibrating but then I ran into another issue when evaluating with a webcam. You'll want to run the following command:
python eval.py --coco_transfer --trained_model=weights/yolact_edge_54_800000.pth --score_threshold=0.3 --top_k=100 --video_multiframe=1 --video=0

The "video_multiframe" argument had to be changed to "1". This is because when we convert to TensorRT we're using batch sizes of one. We will add in an option that does the TRT conversion with higher batch sizes in order to support higher batch sizes during evaluation on videos / webcams. We will also change the README so that others don't get confused.
The "--coco_transfer" flag is used to make models that were trained with YOLACT compatible with YolactEdge.

The README and code has been updated to support higher batch sizes than 1 with TRT. The following command should work:
python eval.py --coco_transfer --trained_model=weights/yolact_edge_54_800000.pth --score_threshold=0.3 --top_k=100 --video_multiframe=2 --trt_batch_size 2 --video=my_video.mp4

The README and code has been updated to support higher batch sizes than 1 with TRT. The following command should work:
python eval.py --coco_transfer --trained_model=weights/yolact_edge_54_800000.pth --score_threshold=0.3 --top_k=100 --video_multiframe=2 --trt_batch_size 2 --video=my_video.mp4

Thanks for your reply,I will try it immediately!!
Have a nice day ~~

Thanks for your reply,I will try it immediately!!
Have a nice day ~~

Sorry when I ran the command,the command show some "UserWarning" after loading the model,could you tell me what this warning mean to be ?

And It stuck on converting to TensorRT about 5 minutes, It showed killed.
I think the setup is not properly..
I use anaconda environment to build the code,did it probably cause the problem?
Here`s my environment setup , please take a look at~~
Thanks a lot.
_libgcc_mutex             0.1                 conda_forge    conda-forge
_openmp_mutex             4.5                       1_gnu    conda-forge
absl-py                   0.11.0                   pypi_0    pypi
appdirs                   1.4.4                    pypi_0    pypi
ca-certificates           2020.12.5            ha878542_0    conda-forge
cachetools                4.2.0                    pypi_0    pypi
certifi                   2020.12.5        py37h89c1867_0    conda-forge
chardet                   4.0.0                    pypi_0    pypi
cudatoolkit               10.2.89              h8f6ccaa_6    conda-forge
cudnn                     8.0.0                cuda10.2_0    nvidia
cycler                    0.10.0                   pypi_0    pypi
cython                    0.29.21                  pypi_0    pypi
decorator                 4.4.2                    pypi_0    pypi
future                    0.18.2                   pypi_0    pypi
gitdb                     4.0.5                    pypi_0    pypi
gitpython                 3.1.11                   pypi_0    pypi
google-auth               1.24.0                   pypi_0    pypi
google-auth-oauthlib      0.4.2                    pypi_0    pypi
graphsurgeon              0.4.5                    pypi_0    pypi
grpcio                    1.34.0                   pypi_0    pypi
idna                      2.10                     pypi_0    pypi
importlib-metadata        3.3.0                    pypi_0    pypi
kiwisolver                1.3.1                    pypi_0    pypi
ld_impl_linux-64          2.35.1               hea4e1c9_1    conda-forge
libblas                   3.9.0                6_openblas    conda-forge
libcblas                  3.9.0                6_openblas    conda-forge
libffi                    3.3                  h58526e2_2    conda-forge
libgcc-ng                 9.3.0               h5dbcf3e_17    conda-forge
libgfortran-ng            9.3.0               he4bcb1c_17    conda-forge
libgfortran5              9.3.0               he4bcb1c_17    conda-forge
libgomp                   9.3.0               h5dbcf3e_17    conda-forge
liblapack                 3.9.0                6_openblas    conda-forge
libopenblas               0.3.12          pthreads_h4812303_1    conda-forge
libstdcxx-ng              9.3.0               h2ae2ef3_17    conda-forge
mako                      1.1.3                    pypi_0    pypi
markdown                  3.3.3                    pypi_0    pypi
markupsafe                1.1.1                    pypi_0    pypi
matplotlib                3.3.3                    pypi_0    pypi
ncurses                   6.2                  h58526e2_4    conda-forge
numpy                     1.19.4           py37haa41c4c_2    conda-forge
oauthlib                  3.1.0                    pypi_0    pypi
opencv-python             <IP_ADDRESS>                 pypi_0    pypi
openssl                   1.1.1i               h7f98852_0    conda-forge
pillow                    8.1.0                    pypi_0    pypi
pip                       20.3.3             pyhd8ed1ab_0    conda-forge
protobuf                  3.14.0                   pypi_0    pypi
pyasn1                    0.4.8                    pypi_0    pypi
pyasn1-modules            0.2.8                    pypi_0    pypi
pycocotools               2.0                      pypi_0    pypi
pycuda                    2020.1                   pypi_0    pypi
pyparsing                 2.4.7                    pypi_0    pypi
python                    3.7.9           hffdb5ce_0_cpython    conda-forge
python-dateutil           2.8.1                    pypi_0    pypi
python_abi                3.7                     1_cp37m    conda-forge
pytools                   2020.4.4                 pypi_0    pypi
readline                  8.0                  he28a2e2_2    conda-forge
requests                  2.25.1                   pypi_0    pypi
requests-oauthlib         1.3.0                    pypi_0    pypi
rsa                       4.6                      pypi_0    pypi
setuptools                49.6.0           py37he5f6b98_2    conda-forge
six                       1.15.0                   pypi_0    pypi
smmap                     3.0.4                    pypi_0    pypi
sqlite                    3.34.0               h74cdb3f_0    conda-forge
tensorboard               2.4.0                    pypi_0    pypi
tensorboard-plugin-wit    1.7.0                    pypi_0    pypi
tensorrt                  <IP_ADDRESS>                  pypi_0    pypi
termcolor                 1.1.0                    pypi_0    pypi
tk                        8.6.10               h21135ba_1    conda-forge
torch                     1.6.0                    pypi_0    pypi
torchvision               0.7.0                    pypi_0    pypi
typing-extensions         <IP_ADDRESS>                  pypi_0    pypi
uff                       0.6.9                    pypi_0    pypi
urllib3                   1.26.2                   pypi_0    pypi
werkzeug                  1.0.1                    pypi_0    pypi
wheel                     0.36.2             pyhd3deb0d_0    conda-forge
xz                        5.2.5                h516909a_1    conda-forge
zipp                      3.4.0                    pypi_0    pypi
zlib                      1.2.11            h516909a_1010    conda-forge

Sorry when I ran the command,the command show some "UserWarning" after loading the model,could you tell me what this warning mean to be ?

And It stuck on converting to TensorRT about 5 minutes, It showed killed.
I think the setup is not properly..
I use anaconda environment to build the code,did it probably cause the problem?

But, Here's some question I want to ask :

The command called train_model : yolact_edge_54_800000.pth  to evaluate
Can I called the  trt model ( convert result) to evaluate?

I want to do transfer learning on COCO person dataset(means only 1 person label), what can I do?
Can I just used the method mentioned by YOLACT (https://github.com/dbolya/yolact/issues/36)
and set 'start_iter=0' to train model?

3.After that,I will try to compile the code with ROS wrapper,just like 'yolact_ros'(https://github.com/Eruvae/yolact_ros),Did you have any idea to compile with ROS?
I will try my best to compile with ROS. If you have interested,I can share the code .
Thanks for your supply~~

Sorry to bother you, @haotian-liu  I run the code successful without conda environment!

But, Here's some question I want to ask :

The command called train_model : yolact_edge_54_800000.pth  to evaluate
Can I called the  trt model ( convert result) to evaluate?

I want to do transfer learning on COCO person dataset(means only 1 person label), what can I do?
Can I just used the method mentioned by YOLACT (https://github.com/dbolya/yolact/issues/36)
and set 'start_iter=0' to train model?

3.After that,I will try to compile the code with ROS wrapper,just like 'yolact_ros'(https://github.com/Eruvae/yolact_ros),Did you have any idea to compile with ROS?
I will try my best to compile with ROS. If you have interested,I can share the code .
Thanks for your supply~~

Cool and thank you for your interests. For your questions:

After the model parts is compiled to TensorRT (backbone, protonet, etc.), the network will store the cache alongside with the model. So you can call the trt model (cache) to evaluate. However, just to note that this cache is mainly used to save time of re-evaluation (so that we avoid conversion of backbone over and over again), some modules are not stored as the cache and are compiled in every runs. Besides, another information I could provide is that the TensorRT converted .trt models seems device- (or at least GPU-) dependent, and when I tried to inference on Jetson with the TensorRT model converted on RTX 2080 Ti, it will raise an error.
Yes you should be able to do the same for fine-tuning as YOLACT.
Since I am not familiar with ROS, I am unable to provide as much information on this.

Cool and thank you for your interests. For your questions:

After the model parts is compiled to TensorRT (backbone, protonet, etc.), the network will store the cache alongside with the model. So you can call the trt model (cache) to evaluate. However, just to note that this cache is mainly used to save time of re-evaluation (so that we avoid conversion of backbone over and over again), some modules are not stored as the cache and are compiled in every runs. Besides, another information I could provide is that the TensorRT converted .trt models seems device- (or at least GPU-) dependent, and when I tried to inference on Jetson with the TensorRT model converted on RTX 2080 Ti, it will raise an error.
Yes you should be able to do the same for fine-tuning as YOLACT.
Since I am not familiar with ROS, I am unable to provide as much information on this.

Thanks for your quick reply, please let me ask you another question 😅
If I want to catch the mask information directly , where can I find in eval.py ?
After I research the code,I think the following part is about mask information,but I have no idea how to get the mask information only.
The thing I want to do is get the mask information ,so I can use opencv to draw it with only black image (cv::Mat(zeros))
 First, draw the masks on the GPU where we can do it really fast

    # Beware: very fast but possibly unintelligible mask-drawing code ahead
    # I wish I had access to OpenGL or Vulkan but alas, I guess Pytorch tensor operations will have to suffice
    if args.display_masks and cfg.eval_mask_branch:
        # After this, mask is of size [num_dets, h, w, 1]
        masks = masks[:num_dets_to_consider, :, :, None]
        # Prepare the RGB images for each mask given their color (size [num_dets, h, w, 1])
        colors = torch.cat([get_color(j, on_gpu=img_gpu.device.index).view(1, 1, 1, 3) for j in range(num_dets_to_consider)], dim=0)
        masks_color = masks.repeat(1, 1, 1, 3) * colors * mask_alpha
        # This is 1 everywhere except for 1-mask_alpha where the mask is
        inv_alph_masks = masks * (-mask_alpha) + 1
        # I did the math for this on pen and paper. This whole block should be equivalent to:
        #    for j in range(num_dets_to_consider):
        #        img_gpu = img_gpu * inv_alph_masks[j] + masks_color[j]
        masks_color_summand = masks_color[0]
        if num_dets_to_consider > 1:
            inv_alph_cumul = inv_alph_masks[:(num_dets_to_consider-1)].cumprod(dim=0)
            masks_color_cumul = masks_color[1:] * inv_alph_cumul
            masks_color_summand += masks_color_cumul.sum(dim=0)
        img_gpu = img_gpu * inv_alph_masks.prod(dim=0) + masks_color_summand

Thanks for your quick reply, please let me ask you another question 😅
If I want to catch the mask information directly , where can I find in eval.py ?
After I research the code,I think the following part is about mask information,but I have no idea how to get the mask information only.
The thing I want to do is get the mask information ,so I can use opencv to draw it with only black image (cv::Mat(zeros))
 First, draw the masks on the GPU where we can do it really fast

    # Beware: very fast but possibly unintelligible mask-drawing code ahead
    # I wish I had access to OpenGL or Vulkan but alas, I guess Pytorch tensor operations will have to suffice
    if args.display_masks and cfg.eval_mask_branch:
        # After this, mask is of size [num_dets, h, w, 1]
        masks = masks[:num_dets_to_consider, :, :, None]
        # Prepare the RGB images for each mask given their color (size [num_dets, h, w, 1])
        colors = torch.cat([get_color(j, on_gpu=img_gpu.device.index).view(1, 1, 1, 3) for j in range(num_dets_to_consider)], dim=0)
        masks_color = masks.repeat(1, 1, 1, 3) * colors * mask_alpha
        # This is 1 everywhere except for 1-mask_alpha where the mask is
        inv_alph_masks = masks * (-mask_alpha) + 1
        # I did the math for this on pen and paper. This whole block should be equivalent to:
        #    for j in range(num_dets_to_consider):
        #        img_gpu = img_gpu * inv_alph_masks[j] + masks_color[j]
        masks_color_summand = masks_color[0]
        if num_dets_to_consider > 1:
            inv_alph_cumul = inv_alph_masks[:(num_dets_to_consider-1)].cumprod(dim=0)
            masks_color_cumul = masks_color[1:] * inv_alph_cumul
            masks_color_summand += masks_color_cumul.sum(dim=0)
        img_gpu = img_gpu * inv_alph_masks.prod(dim=0) + masks_color_summand

Please refer to this block of code where you can get mask information.

Please refer to this block of code where you can get mask information.


A few more @swift3_migration attribute updates for swift-2.3-branch

What's in this pull request?

Resolved bug number: (SR-)

Before merging this pull request to apple/swift repository:

[ ] Test pull request on Swift continuous integration.

Triggering Swift CI
The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:
Smoke Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please smoke test
    All supported platforms     | @swift-ci Please smoke test and merge
    OS X platform               | @swift-ci Please smoke test OS X platform
    Linux platform              | @swift-ci Please smoke test Linux platform

A smoke test on macOS does the following:

Builds the compiler incrementally.
Builds the standard library only for macOS. Simulator standard libraries and
device standard libraries are not built.
lldb is not built.
The test and validation-test targets are run only for macOS. The optimized
version of these tests are not run.

A smoke test on Linux does the following:

Builds the compiler incrementally.
Builds the standard library incrementally.
lldb is built incrementally.
The swift test and validation-test targets are run. The optimized version of these
tests are not run.
lldb is tested.

Validation Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please test
    All supported platforms     | @swift-ci Please test and merge
    OS X platform               | @swift-ci Please test OS X platform
    OS X platform               | @swift-ci Please benchmark
    Linux platform              | @swift-ci Please test Linux platform

Lint Testing
    Language     | Comment
    ------------ | -------------
    Python       | @swift-ci Please Python lint

Note: Only members of the Apple organization can trigger swift-ci.

rdar://problem/27932410

@swift-ci Please test

@moiseev could you please review?

Build failed
Jenkins build - Swift Test Linux Platform
Git Commit - 66483615c52afd10dea8b454fd2edb47c89081d3
Test requested by - @benlangmuir

:shipit:

build-script: error: unrecognized arguments: --skip-build-lldb
@shahmishal did we break testing 2.3 again?

@benlangmuir Look into the failure.
16:54:49 usage: build-script [-h] [-l] [-b] [-p] [--xctest] [--foundation] [-c]
16:54:49                     [--export-compile-commands] [-d | -r | -R] [--debug-llvm]
16:54:49                     [--debug-swift] [--debug-swift-stdlib] [--debug-lldb]
16:54:49                     [--debug-cmark] [--debug-foundation]
16:54:49                     [--assertions | --no-assertions] [--cmark-assertions]
16:54:49                     [--llvm-assertions] [--no-llvm-assertions]
16:54:49                     [--swift-assertions] [--no-swift-assertions]
16:54:49                     [--swift-stdlib-assertions] [--no-swift-stdlib-assertions]
16:54:49                     [--lldb-assertions] [--no-lldb-assertions] [-x] [-X] [-m]
16:54:49                     [-e] [-t] [-T] [-o] [-S] [-i] [--tvos] [--watchos]
16:54:49                     [--build-subdir PATH] [-j BUILD_JOBS]
16:54:49                     [--darwin-xcrun-toolchain DARWIN_XCRUN_TOOLCHAIN]
16:54:49                     [--cmake CMAKE] [--extra-swift-args EXTRA_SWIFT_ARGS]
16:54:49                     [build_script_impl_args [build_script_impl_args ...]]
16:54:49
build-script: error: unrecognized arguments: --skip-build-lldb

its due to https://github.com/apple/swift/commit/272587b12ce0be4628b0ec54c989f0bc6eb417ce, its should be fixed now with https://github.com/apple/swift/pull/4425