VM controller: add object generations to queued items for future use

What this PR does / why we need it:
The upcoming implementation for [0] will require the ability to compare the previous generation against the current one when changes are made to the VM spec.
That requires the VM informer handlers to communicate those generations to the execution code, via the queued item.
This PR adds that information to the queued items, and reworks the revision code so the specs of former VM generations are available when we need them.
These will be used by the hotplug/rolloutStrategy code in an upcoming PR.
In short, this is preliminary work that should not affect current behavior.
[0] https://github.com/kubevirt/community/pull/242
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
Checklist
This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR.
Approvers are expected to review this list.

[ ] Design: A design document was considered and is present (link) or not required
[ ] PR: The PR description is expressive enough and will help future contributors
[ ] Code: Write code that humans can understand and Keep it simple
[ ] Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
[ ] Upgrade: Impact of this change on upgrade flows was considered and addressed if required
[ ] Testing: New code requires new unit tests. New features and bug fixes require at least on e2e test
[ ] Documentation: A user-guide update was considered and is present (link) or not required. You want a user-guide update if it's a user facing feature / API change.
[ ] Community: Announcement to kubevirt-dev was considered

Release note:

NONE

/cc @vladikr

Switched to draft since this PR appears to conflict with Halted/Always VM strategies.
/test all

Changed course by not forcing execute() to use the specific generation that triggered the add/update.
Not only does it not interact well with run strategies, but it also triggers a lot of update failures.
Both issues are fixable (by using Patch() instead of Update() and relocating the startStop code), but that's out of scope and (hopefully) not necessary for the rolloutStrategy implementation.
Instead, we can just use the correct generations only when needed, i.e. in the hotplug/rolloutStrategy code.

The upcoming implementation for [0] will require the ability to compare the previous generation against the current one when changes are made to the VM spec.

I think we have not taken this strategy when working on the network hotplug.
The change triggered to the spec is not what moves the flow, that is more adequate to a state machine logic.
What triggers the flow is comparing between what is desired (the VM spec) and what is actual (VMI spec & VMI status). The "actual" may change per the controller that is involved (e.g. VM spec being the desired and VMI spec being the actual in the context of a VM controller).
But if we look at the whole system, the actual is represented by the VMI status, i.e. the system is suppose to strive  and reach from the VM spec (desired) to VMI status (actual).
Is the above something that can be agreed on?
Is the work on this PR looking to solve the same in a different manner?

The upcoming implementation for [0] will require the ability to compare the previous generation against the current one when changes are made to the VM spec.

I think we have not taken this strategy when working on the network hotplug. The change triggered to the spec is not what moves the flow, that is more adequate to a state machine logic. What triggers the flow is comparing between what is desired (the VM spec) and what is actual (VMI spec & VMI status). The "actual" may change per the controller that is involved (e.g. VM spec being the desired and VMI spec being the actual in the context of a VM controller). But if we look at the whole system, the actual is represented by the VMI status, i.e. the system is suppose to strive and reach from the VM spec (desired) to VMI status (actual).
Is the above something that can be agreed on? Is the work on this PR looking to solve the same in a different manner?

That's a good point, I should have touched on it in the description, thank you for bringing it up!
This PR was actually created after trying to start implementing VMRolloutStrategy by comparing the VM template spec with the VMI spec, as you suggested.
The problem is that the VMI spec evolves to be very different from the original template, preventing us from diffing both without maintaining a list of sub-elements that stay diff-able.
This is fine for targeted hotplug functions that just compare a few elements, but it's a big problem when trying to generalize that comparison to the whole spec, like VMRolloutStrategy intends to.
With that said, if you still think VMRolloutStrategy can be implemented without something like this PR, please share your thoughts!

Back to draft, some of the logic needs to be adjusted.
We can't expect execute() to run once per update, we instead need to diff the latest VM generation with the last-seen VM generation.
@EdDev this does not invalidate the VM vs VMI thread, please don't hesitate to keep it going.

The problem is that the VMI spec evolves to be very different from the original template, preventing us from diffing both without maintaining a list of sub-elements that stay diff-able. This is fine for targeted hotplug functions that just compare a few elements, but it's a big problem when trying to generalize that comparison to the whole spec, like VMRolloutStrategy intends to.

I think I understand now where this is coming from.
The discussions on the rollout proposal did showed that there is a problem with generalizing things and that each functionality needs to take care of itself, defaulting to requiring a reset when "other" changes occur.
I think this is already visible from the network and storage scenarios and the CPU & memory ones.
Each has its own uniqueness and dependencies.
I think the original proposal started as a general solution to CPU & memory but then adjusted to fit current networking and future storage scenarios as well.
It may be too challenging to discuss this over a PR, perhaps a working-group can be created to brainstorm this feature. In the end, several sigs need to sync with the solution and comply with a common structure and rules, then leave each enough room to have their own uniqueness.

The problem is that the VMI spec evolves to be very different from the original template, preventing us from diffing both without maintaining a list of sub-elements that stay diff-able. This is fine for targeted hotplug functions that just compare a few elements, but it's a big problem when trying to generalize that comparison to the whole spec, like VMRolloutStrategy intends to.

I think I understand now where this is coming from. The discussions on the rollout proposal did showed that there is a problem with generalizing things and that each functionality needs to take care of itself, defaulting to requiring a reset when "other" changes occur.
I think this is already visible from the network and storage scenarios and the CPU & memory ones. Each has its own uniqueness and dependencies. I think the original proposal started as a general solution to CPU & memory but then adjusted to fit current networking and future storage scenarios as well.

Yes. Hopefully the solution of comparing last-seen VM spec with current will be a viable path.

It may be too challenging to discuss this over a PR, perhaps a working-group can be created to brainstorm this feature. In the end, several sigs need to sync with the solution and comply with a common structure and rules, then leave each enough room to have their own uniqueness.

I disagree. This has already been discussed too much IMO, and all those discussions failed to identify the concrete issues found when trying to implement the feature.
I think it's time to give the implementation a try, see what happens and take it from there.

The problem is that the VMI spec evolves to be very different from the original template, preventing us from diffing both without maintaining a list of sub-elements that stay diff-able. This is fine for targeted hotplug functions that just compare a few elements, but it's a big problem when trying to generalize that comparison to the whole spec, like VMRolloutStrategy intends to.

I think I understand now where this is coming from. The discussions on the rollout proposal did showed that there is a problem with generalizing things and that each functionality needs to take care of itself, defaulting to requiring a reset when "other" changes occur.
I think this is already visible from the network and storage scenarios and the CPU & memory ones. Each has its own uniqueness and dependencies. I think the original proposal started as a general solution to CPU & memory but then adjusted to fit current networking and future storage scenarios as well.
It may be too challenging to discuss this over a PR, perhaps a working-group can be created to brainstorm this feature. In the end, several sigs need to sync with the solution and comply with a common structure and rules, then leave each enough room to have their own uniqueness.

@EdDev this PR is part of an exploratory work to understand how changes to the VM object can be recognized (that there was a change and where) in the main sync loop of the VM controller.
This doesn't dictate nor even touch the methods of how one would act on these changes. (I.E should should you compare a filed in the changed struct to a VMI's struct or to a previous VM obj struct version).
I think this will still be decided on a case by cases basis. This will be the next step, not in this PR.

@EdDev to reiterate what the others have said, there's no API change or behavior change afoot. This is simply a means of reliably detecting changes to the VM resource in a general manner.

I disagree. This has already been discussed too much IMO, and all those discussions failed to identify the concrete issues found when trying to implement the feature.
I think it's time to give the implementation a try, see what happens and take it from there.

Well,  IMO this approach has several challenges which may make it hard to work well with the different needs, especially if you need to take into account the network existing hotplug.
I think it is problematic to play with prev and current spec diffs, it is in my view a no-fit to the desired-actual reconciliation of k8s. Or more precisely contradicts the level-triggering concepts K8S is based on.
Said that, experimenting and trying out different approaches is always a good thing.
I just ask to make sure any solution does consider that other SIGs are influenced by the solutions of this feature.
@AlonaKaplan , FYI.

@EdDev to reiterate what the others have said, there's no API change or behavior change afoot. This is simply a means of reliably detecting changes to the VM resource in a general manner.

Right, but I am trying to express that this approach is problematic. It would be great if a WG can share all that was learned so far and continue the discussion given some concerns that are raised.

/test all

/test pull-kubevirt-e2e-k8s-1.28-sig-compute

/test pull-kubevirt-e2e-k8s-1.28-sig-compute

/test pull-kubevirt-e2e-k8s-1.28-sig-compute

@EdDev to reiterate what the others have said, there's no API change or behavior change afoot. This is simply a means of reliably detecting changes to the VM resource in a general manner.

Right, but I am trying to express that this approach is problematic. It would be great if a WG can share all that was learned so far and continue the discussion given some concerns that are raised.

@EdDev I'm happy to discuss this offline, let's set some time next week.
In the meanwhile, just for example, this approach is not uncommon. Take a look at the daemonSets controller or the pools controller
Comparing arbitrary VM object changes to a VMI object (which is completely different) is not feasible for this matter.
However, determining whether a Restart condition should be added, in some cases, can be done based on the VMI structs.

/cc @xpivarc

/retest

@jean-edouard @vladikr can you please add - and justify - to the PR why we must use controller-revisions and can not compare the VM to the VMI.
controler-revisions seem to be expsensive, and naively spoken it loks like comparing VM to VMI would help us to understand what needs to be hotplugged.
I'm mainly insisiting on justifying such an important design decision.
cc @dankenigsberg @EdDev

@jean-edouard @vladikr can you please add - and justify - to the PR why we must use controller-revisions and can not compare the VM to the VMI.
controler-revisions seem to be expsensive, and naively spoken it loks like comparing VM to VMI would help us to understand what needs to be hotplugged.
I'm mainly insisiting on justifying such an important design decision.
cc @dankenigsberg @EdDev

@fabiand We had numerous discussions offline.
VM and the VMI are two very different objects.
To compare both, the VM object must be expanded and all defaults should be applied to its spec.
Some fields must be normalized by removing some of the VMI-specific data.
Even then it won't easily be comparable by calling the deepEqual function. To determine whether there was a change, each struct must be processed separately.
Defaults are also time dependent, since cluster settings may change. The expanded VM object may look entirely different from when the corresponding VMI was created.
The current approach compares the VM object to the last known revision of the VM object - to recognize a change.
Then, a number of handler functions will act on a specific change.
Each handler will be able to act and validate the change independently. If desired, it may compare the changed to field to a specific field in the VMI object. (i.e. maxSockets)
So, in my view, the comparison is between two flows:
VM to VMI:

apply defaults
normalize fileds
process each struct separately

VM to prev. rev. VM:

simple deepEqual
process live updateable fileds

The current approach, in my perspective, is significantly simpler to understand, offers less processing, and allows us to fail fast when we recognize a change that is out of scope.

/approve
From my point of view this is already good and allows us to move on and continue reviewing @11054

@xpivarc what do you think?

/hold
I want to review how this fits to https://github.com/kubevirt/kubevirt/pull/11054

The current approach, in my perspective, is significantly simpler to understand, offers less processing, and allows us to fail fast when we recognize a change that is out of scope
@vladikr I'm not familiar with the relevant code, so I may well be wrong. However, having a single normalization function that takes a VM.spec.template or a VMI.spec and makes them comparable seems to me much simpler than keeping a history of former specs. In general, the only things that matter are the current state and the desired state, not the specific steps that where taken to get from one to another.

For reference, here's a VM vs VMI diff on the very simple cirros example VM:
--- /tmp/a	2024-01-24 08:46:22.974898399 -0500
+++ /tmp/b	2024-01-24 08:46:01.054550370 -0500
@@ -1,6 +1,12 @@
 {
   "architecture": "amd64",
   "domain": {
+    "cpu": {
+      "cores": 1,
+      "model": "host-model",
+      "sockets": 1,
+      "threads": 1
+    },
     "devices": {
       "disks": [
         {
@@ -15,8 +21,22 @@
           },
           "name": "cloudinitdisk"
         }
+      ],
+      "interfaces": [
+        {
+          "bridge": {},
+          "name": "default"
+        }
       ]
     },
+    "features": {
+      "acpi": {
+        "enabled": true
+      }
+    },
+    "firmware": {
+      "uuid": "0d2a2043-41c0-59c3-9b17-025022203668"
+    },
     "machine": {
       "type": "q35"
     },
@@ -26,11 +46,19 @@
       }
     }
   },
+  "evictionStrategy": "None",
+  "networks": [
+    {
+      "name": "default",
+      "pod": {}
+    }
+  ],
   "terminationGracePeriodSeconds": 0,
   "volumes": [
     {
       "containerDisk": {
-        "image": "registry:5000/kubevirt/cirros-container-disk-demo:devel"
+        "image": "registry:5000/kubevirt/cirros-container-disk-demo:devel",
+        "imagePullPolicy": "IfNotPresent"
       },
       "name": "containerdisk"
     },

@jean-edouard this is the diff between a VM and VMI?
Could the managedFields help us to keep track of the stuff which has been provided by the system (aka is NOT user provided) - or other way roun: TRo use them to keep track of user specified items?

@jean-edouard this is the diff between a VM and VMI?

Yes

Could the managedFields help us to keep track of the stuff which has been provided by the system (aka is NOT user provided) - or other way roun: TRo use them to keep track of user specified items?

Good suggestion, unfortunately it doesn't seem like it, managedFields seems to include both things that came from the VM and things that were added later.

With respect to VMRolloutStrategy, there's been some debate about the approach we use to determine if the VM needs a RestartRequired condition imposed on the status. There's been a large amount of conversations in the forming of the VMRolloutStrategy design document, and we tried a few things before landing on the current approach. Here's a couple of competing approaches that we've considered:

VM to VMI translation/comparison
Track the last revision before changes in order to compare VMs

When I say VM to VMI comparison, I want to be clear what's being compared. The theory is this: In order to determine if a VM has changed, we can compare a candidate VM to the existing VMI by simply translating the VM to a VMI by applying defaults. We can then do a deep comparison of the candidate VMI to the existing VMI. This sounds completely reasonable and is in fact the approach we started with when we were implementing a POC of this. Upon implementation we realized there's a couple of critical deficiencies with this approach.

There's no way to determine ground truth. If the cluster defaults change while a VM is running, a VMI generated by applying defaults will also change. This might sound innocuous, but it's a critical flaw in this approach. we cannot know the defaults that were applied to render a given VMI Therefore comparing any two VMIs generated from the same VM cannot be conclusive.

There's other runtime settings injected into a VMI that aren't defaults. They're actual runtime settings. Examples of this are Firmware UUID or SMBios settings. These aren't defaults. They are just runtime values.

While it’s true that we could limit our comparison to specific fields, such as sockets or maxSockets, this still doesn’t work in the general case. Because of nuances that can exist around ordering, once a RestartRequired condition is imposed, it can’t really be reversed,
Again I want to stress we started with comparing VM to VMI. It’s just more complicated. I’d urge other teams using this approach to reconsider.

The current approach, in my perspective, is significantly simpler to understand, offers less processing, and allows us to fail fast when we recognize a change that is out of scope

@vladikr I'm not familiar with the relevant code, so I may well be wrong. However, having a single normalization function that takes a VM.spec.template or a VMI.spec and makes them comparable seems to me much simpler than keeping a history of former specs. In general, the only things that matter are the current state and the desired state, not the specific steps that where taken to get from one to another.

@dankenigsberg - In #10997 (comment) - I point to several issues that I see with the proposed approach and how using revisions makes the comparison simpler. Also, I want to point out that this is a common pattern in k8s and I pointed out on several occasions that multiple controllers act this way. I suggest (again). Please take a look at the daemonSets controller or the pools controller

@dankenigsberg The comparison between VM object revisions is needed to recognize that there was a change in the object.
Otherwise, the normalization function will need to run on every sync loop of the VM controller.
Once we recognize that there was a relevant change, acting on this change will depend on a specific handler.
There will be specific handlers for areas in the spec that we know how to process and update for [CPU/Memory/Affinity/Labels/Network, Storage in the future]
Everything else will be considered as a Guest ABI change that requires a restart.
These handlers will have a dedicated logic. Each can decide on whether/how to act on the change.
For example, the CPU may compare the VM template maxSockets to the VMI maxSockets (the desired state to the current state as you mentioned) and raise the RestartRequired condition or proceed with the update.
@jean-edouard also has this logic implemented in the follow-up PR #11054 (here)
I hope it makes sense.

/lgtm

Just to add to the discussion above, we are already making a revision afaik, but this is nothing new. Merly we are extending what is there and used elsewhere.
This is an implementation detail IMHO and one that can be changed in the future if we find this unreliable.
Also, one possible solution would be to produce a hash of immutable parts of the spec but this doesn't play well with API evolution.

we are already making a revision afaik, but this is nothing new.

I think the question is more: Why do VM to VMI

managedFields seems to include both things that came from the VM and things that were added later.

Yes! but managedFields is a "list of ownerships". Speak multiple owners of fields can be named there.

@jean-edouard  @vladikr @stu-gott please include the comparison if VM/VMI vs ControllerRevisions in the Special notes for your reviewer: of this PR. This is where it should be kept.

A few notes:

VM to VMI comparison, we can possibly find changes and additions by finding the overlap between VM.spec.template and VMI.spec. Then you effectively get a "partial tree" where we could compare values between VM.spec.template and VM.spec. However, this would not allow us to detect removals on the VM side.
Controller Revisions have a price (size), but make all of this self contained on the VM level (less API calls), I do wonder if rapid changes would lead to loosing informations about what was changed.

Just notes from thiking not sure how relevant they are.

Thought experiement of a flawed flow with controller Revisions:
State 0 - iniitkaa
State 1 - Add cpu core
State 2 - Add memory
State 3 - change smbios serial

When working to achieve state 1, then we need to avoid to update controllerRevision to early, because if we do not achieve state 1, but conrollre revision is reflecting this, and a newchange comes in (request state 2).
Then the system assumes State 1, while in reality it is still State 0, and just performs the change for from State 1 to State 2.
IOW there is the risk that the controllerRevisions get out of sync with the object.
This is mostly me thinking out loud. Did we consider this?

This PR is just not necessary anymore, as it is included in https://github.com/kubevirt/kubevirt/pull/11054 which is getting actively reviewed, included on the bits that came from this PR.
This is still a good place to continue the discussion about ways to tell if meaningful generic changes happen in the VM template spec.


Ensure we allow any ExpressionFactoryWrappers to execute before JspAp…

…plicationContext provides any ELContext

This is superseded by #16024, which is the same but just has the JIRA in the commit message.
I'm leaving this open for now just to let CI complete.

Other PR merged.


Default peek lock duration

"The Complete or Deadletter operations as well as the RenewLock operations may fail due to network issues, if the held lock has expired, or there are other service-side conditions that prevent settlement."
What is the default expiry time?

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

ID: c9b369e0-e366-4f99-2f94-b045437d7ce9
Version Independent ID: 5a703706-b745-2486-aa2b-3e4bb9051803
Content: Azure Service Bus message transfers, locks, and settlement
Content Source: articles/service-bus-messaging/message-transfers-locks-settlement.md
Service: service-bus-messaging
GitHub Login: @axisc
Microsoft Alias: aschhab

@shashankkr Thank you for your feedback! We will review and update as appropriate.

@shashankkr The lock duration for both Queues and Subscriptions can be set while creating them or updated after. Usually, this is 30 seconds by default I believe.

This can done from the Azure Portal as above, REST APIs, PowerShell cmdlets, ARM Templates or Management SDK.

@shashankkr Just following up here... Hope my previous comment clears things up.

@PramodValavala-MSFT Thanks Pramod for the detailed explanation. I have one more question. Suppose the subscription is session aware. I send 2 messages to the topic at the exact same time with the same session id. How the service bus will behave in this case?

@shashankkr Glad that we could help you out!
For your follow up query, when messages come in, they are assigned a sequence number which decides their order. And then depending on the filter rules, will copy them to all applicable subscriptions.
Please do note that this repository is primarily for handling doc related issues. For general queries on the product, open a thread on StackOverflow or MSDN.
Since there is no doc update required here, we will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.


feature:S3C-3548 getInformation API w/ static values

Explanation: getInformation() API using static values from application.properties provided during the application startup

rebased the project based on parent

Hello saitharunthodupunuru,
My role is to assist you with the merge of this
pull request. Please type @bert-e help to get information
on this process, or consult the user documentation.
Status report is not available.

Waiting for approval
The following approvals are needed before I can proceed with the merge:

the author

2 peers

/approve

In the queue
The changeset has received all authorizations and has been added to the
relevant queue(s). The queue(s) will be merged in the target development
branch(es) as soon as builds have passed.
The changeset will be merged in:

:heavy_check_mark: development/1.0

There is no action required on your side. You will be notified here once
the changeset has been merged. In the unlikely event that the changeset
fails permanently on the queue, a member of the admin team will
contact you to help resolve the matter.
IMPORTANT
Please do not attempt to modify this pull request.

Any commit you add on the source branch will trigger a new cycle after the
current queue is merged.
Any commit you add on one of the integration branches will be lost.

If you need this pull request to be removed from the queue, please contact a
member of the admin team now.
The following options are set: approve

I have successfully merged the changeset of this pull request
into targetted development branches:

:heavy_check_mark: development/1.0

Please check the status of the associated issue S3C-3548.
Goodbye saitharunthodupunuru.


refactor(DestinationPoint prefab): fix typo to read "lockedCursor"

child object was titled "lockedCUrsor", update to "lockedCursor"

There were the following issues with your Pull Request

Commit: 20ee2c71dc1717692cca2ef30402f13c6d85d10c
Commits must be in the following format: %{type}(%{scope}): %{description}

Guidelines are available at https://github.com/thestonefox/SteamVR_Unity_Toolkit

This message was auto-generated by https://gitcop.com

It looks like you committed a binary file, make sure your project is set to save assets as text files instead. (Edit > Project Settings > Editor IIRC.)

@KavanBahrami thanks for the PR.
I've raised a PR with a fix (which supersedes this PR). hopefully you can see from the other PR the best practice for future pull requests.
As @bddckr said, you need to switch your asset type to text file and ensure the changes are also minimal.
The final thing to consider is the github subject message and description, they need to adhere to a specific format as outlined in the CONTRIBUTING.md file.
Superseding PR -> https://github.com/thestonefox/VRTK/pull/1285

@bddckr @thestonefox Thanks for the tips! Next pull request will be a bit more on target

@KavanBahrami no worries :) when you do your next PR it's a good idea to read through the CONTRIBUTING.md doc first but then after that we're always around to help out with code reviews to make sure everything is good before it's merged :)


Fixes #3344 - label reservations and match against the labels

Attention! This is based on PR #3404. Please review that first.

@kolloch please see my comments above. I commented on the relevant commit therefore it's not nicely displayed here – sorry about that.

Thanks for the comments!

A ship, a ship! Look!
    .  o ..
     o . o o.o
          ...oo
            __[]__
         __|_o_o_o\__
         \""""""""""/
          \. ..  . /
     ^^^^^^^^^^^^^^^^^^^^


[BEAM-13430] Fix broken ULR validates runner tests

Please add a meaningful description for your change here

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Choose reviewer(s) and mention them in a comment (R: @username).
[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI.

Run ULR Loopback ValidatesRunner

R: @ibzib @aaltay

Run Java PreCommit


extract add on crashes with ES6-style imports

If I run the extract add on using the JSX demo, node throws an error:
C:\projects\nano-css-extract-demo\demo>node extract.js
C:\projects\nano-css-extract-demo\demo\src\nano.js:1
(function (exports, require, module, __filename, __dirname) { import { createEle
ment } from "react";
                                                              ^^^^^^

SyntaxError: Unexpected token import
    at createScript (vm.js:80:10)
    at Object.runInThisContext (vm.js:139:10)
    at Module._compile (module.js:616:28)
    at Object.Module._extensions..js (module.js:663:10)
    at Module.load (module.js:565:32)
    at tryModuleLoad (module.js:505:12)
    at Function.Module._load (module.js:497:3)
    at Module.require (module.js:596:17)
    at require (internal/module.js:11:18)
    at Object.<anonymous> (C:\projects\nano-css-extract-demo\demo\extract.js:1:7
6)

Can you provide an updated example that uses the JSX demo?

Use require instead of import as Node does not understand it.
const {createElement} = require('react');

Or, alternatively, you need to transpile your code before you run Node.

Or, instead of running your script with node you can run it with TypeScript ts-node or Bbable babel-node.

Thanks! I was able to get it working using babel-node with the env and react presets:
babel-node --presets=env,react extract.js


ed25519 algo oid is not allowed in v3/lints/cabf_br/lint_subject_public_key_info_improper_algorithm_object_identifier_encoding.go

https://datatracker.ietf.org/doc/html/rfc8410
If trying to lint an x509 certificate with an ed25519 signer the following error is issued,
parse zlint output: Error("invalid type: string \"The encoded AlgorithmObjectIdentifier \\\"300506032b6570\\\" inside the SubjectPublicKeyInfo field is not allowed\", expected a borrowed string", line: 22, column: 124)

It appears the identifier is not included here,
https://github.com/zmap/zlint/blob/ddaf5ccd564ba8e5f1115f2885ac9cc9d6451248/v3/lints/cabf_br/lint_subject_public_key_info_improper_algorithm_object_identifier_encoding.go#L62
var allowedPublicKeyEncodings = [4][]byte{
	// encoded AlgorithmIdentifier for an RSA key
	{0x30, 0x0d, 0x06, 0x09, 0x2a, 0x86, 0x48, 0x86, 0xf7, 0x0d, 0x01, 0x01, 0x01, 0x05, 0x00},
	// encoded AlgorithmIdentifier for a P-256 key
	{0x30, 0x13, 0x06, 0x07, 0x2a, 0x86, 0x48, 0xce, 0x3d, 0x02, 0x01, 0x06, 0x08, 0x2a, 0x86, 0x48, 0xce, 0x3d, 0x03, 0x01, 0x07},
	// encoded AlgorithmIdentifier for a P-384 key
	{0x30, 0x10, 0x06, 0x07, 0x2a, 0x86, 0x48, 0xce, 0x3d, 0x02, 0x01, 0x06, 0x05, 0x2b, 0x81, 0x04, 0x00, 0x22},
	// encoded AlgorithmIdentifier for a P-521 key
	{0x30, 0x10, 0x06, 0x07, 0x2a, 0x86, 0x48, 0xce, 0x3d, 0x02, 0x01, 0x06, 0x05, 0x2b, 0x81, 0x04, 0x00, 0x23},
}

Ed25519 is not permitted by the CABF baseline requirements, so this lint is correct.

@mcpherrinm appreciate the help, that makes much more sense now


Moves notice under h1

One of the linter rules run against this repo requires the README start with an h1. By inserting this notice above in #4152, the linter rule has been broken. This change fixes it.

Proposed Changes

Bring org notice under the h1 of the README file

Readiness Checklist
Author/Contributor

[ ] If documentation is needed for this change, has that been included in this pull request

Reviewing Maintainer

[ ] Label as breaking if this is a large fundamental change
[ ] Label as either automation, bug, documentation, enhancement, infrastructure, or performance

Note: I expect the standard build to fail until #4188 is merged in as well.


Increment version for analysisservices releases

Increment package version after release of Azure.ResourceManager.Analysis

API change check
API changes are not detected in this pull request.


Fix internal error from bad alt id format

If the alt ID isn't formatted properly (<alt_id_type:alt_id>), we get an error:
root@gridd-alpha:/# grid po update PO-NnEyt-xrbP --add-id test_id
{status_code:500,message:An internal error occurred}

Correct format:
grid po update PO-NnEyt-xrbP --add-id test:test_id
Submitting request to update purchase order...

root@gridd-alpha:/# grid po show test_id
{status_code:404,message:Purchase order test_id not found}
root@gridd-alpha:/# grid po show test:test_id
Purchase Order PO-NnEyt-xrbP:
    ...


Introducing claims in ocean protocol

Fixes # .
Changes proposed in this PR:

Signed Claims - Feature Request.docx

Closing this


Feat trial

Codecov Report

Merging #42 into master will increase coverage by 0.02%.
The diff coverage is 100%.

@@            Coverage Diff            @@
##           master     #42      +/-   ##
=========================================
+ Coverage   95.87%   95.9%   +0.02%
=========================================
  Files          14      14
  Lines         291     293       +2
=========================================
+ Hits          279     281       +2
  Misses          7       7
  Partials        5       5

Impacted Files
Coverage Δ

btdate/date.go
100% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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


bug: file cache meta file read guard doesn't fully cover the critical zone

Describe the bug
When get from file cache, meta file read guard cannot be dropped before data is loaded.
To Reproduce
No response
Expected behavior
No response
Additional context
No response

Fixed via #5039


Bug with accordion-group and ng-class

Hi,
since 0.13.3 I am getting parse errors when using accordion-group in combination with ng-class. This is being caused by this change ead15e37 .
You can test this with following example:
...  <accordion-group ng-class="{'test' : isTest}">  ....
This results in following generated code:
...  <accordion-group ng-class="{'test' : isTest} {'panel-open': isOpen}">  ....

I can confirm this behaviour as well. And because of this problem, the class is not added when the panel is open.

Using ng-class on a directive that uses replace is a bad idea.
The best solution is to use the template-url option on the accordion-group directive if you want to eliminate that ng-class usage.

@wesleycho what do you think about adding an expandedClass and/or collapsedClass option to the directive so the fix to #3419 isn't potentially "breaking?"  Seems pretty heavy-handed to force someone to make a new template because of a feature we added.

I'm not against it necessarily, but in increases cumbersomeness of usage. replace is also a potentially dangerous thing in tandem with another directive that mutates the DOM.
If a PR is opened, I'll gladly review and merged though.

Agreed.  I recall a comment in an issue in the angular codebase by @caitp indicating that while replace isn't going anywhere, one needs to be cognizant that using it incorrectly can break the DOM.
I wonder if it would be best to establish best practices (or at least "standards") on a project level and just say "If we do x, then we won't support y."  In this case it could be:  "Because we use replace, to prevent breaking the DOM, we won't support certain, other directives, like ng-class on our components."

I can get behind that, as ideally, you should avoid using directives that mutate the DOM in combination with a directive that uses replace.
One can wrap the element with a div that has the desired ng-class to work around this also.

@wesleycho found this link via #1741.  Look at @caitp's last comment.  If Angular isn't going to address this, I think we can close this issue and #1741 and add a comment to the docs about not supporting certain directives on UI Bootstrap directives that use replace: true.

That settles it for me - closing as won't fix as per resolution in Angular.

Temporary workaround - put your ng-classes in your plain "class" attribute:
Before:
ng-class="{'expanded': status.open}"

After:
class="{{status.open ? 'expanded':''}}"

Then how can I put a custom class on each accordion group?
For example, I used to use ng-class to add an empty class to the accordion group if its children is empty (therefore the panel-body shouldn't have a top border that takes up 1px, causing a tiny animation whenever that empty accordion group is expanded or collapsed.
I think there are real needs for ng-class to work.

I think there are real needs for ng-class to work.

No one argues about it. It is just a technical solution that is missing here. If you've got an idea on how to solve it from the technical point of view, a pull request would be appreciated.

One can use class="{{customClass()}}" to force a custom class according to custom rules.

@wesleycho, works perfectly.  Thanks!

Can someone post example of class="customClass()}}

@malibeg, please do not use the issues forum for support related requests.  Rather, please follow the instructions here.
Additionally, please do not comment on closed issues as it is a very good way for us to miss stuff.

Using ng-class on a directive that uses replace is a bad idea.

The best solution is to use the template-url option on the accordion-group directive if you want to eliminate that ng-class usage.

@wesleycho instead of requiring the users of angular-bootstrap to read the source code and know internal implementation details (use of replace and ng-class element on root of the template), why can't you just add additional div to the template that does not have ng-class?
Rather than requiring library users to know which directives use replace and ng-class or other conflicting builtin directives, I think library designers should avoid using those conflict-prone directives on the root element of the templates.

Additionally, please do not comment on closed issues as it is a very good way for us to miss stuff.

@icfantv With all due respect for great work on the library, in my experience issues get closed before getting feedback from the reporter, so it's quite hard not to comment on closed issues.

@hoxu the problem here is that using ng-class is absolutely recommended against in this exact situation, so even if we did somehow allow ng-class usage here, you will unexpectedly add 4 watchers instead of the desired 1. The pain is much more preferred than allowing the user to do something carelessly unperformant.
In this case, one needs to be familiar with how replace works when using angular, and given that the library uses it (in the future we will remove replace support as it is deprecated), we cannot support ng-class usage as per the angular team's own decision on this situation.
Going to lock discussion on this issue, as what has been said is pretty straightforward & has not been contested - there is no need for further commenting & pinging all prior users.


fix #1651, fix change processor's parallelism on dashboard

Generally +1.
Please do me a favor to edit RestClient in integrationtest, which is also impacted by change.
diff --git a/integrationtest/src/main/scala/io/gearpump/integrationtest/minicluster/RestClient.scala b/integrationtest/src/main/scala/io/gearpump/integrationtest/minicluster/RestClient.scala
index a3ce6a3..61d96cf 100644
--- a/integrationtest/src/main/scala/io/gearpump/integrationtest/minicluster/RestClient.scala
+++ b/integrationtest/src/main/scala/io/gearpump/integrationtest/minicluster/RestClient.scala
@@ -163,8 +163,7 @@ class RestClient(host: String, port: Int) {
   def replaceStreamingAppProcessor(appId: Int, replaceMe: ProcessorDescription): Boolean = try {
     val replaceOperation = new ReplaceProcessor(replaceMe.id, replaceMe)
     val args = upickle.default.write(replaceOperation)
-    val resp = callApi(s"appmaster/$appId/dynamicdag?args=" + Util.encodeUriComponent(args),
-      CRUD_POST + " -F ignore=ignore")
+    val resp = callApi(s"appmaster/$appId/dynamicdag?args=" + Util.encodeUriComponent(args), CRUD_POST)
     upickle.default.read[DAGOperationResult](resp)
     true
   } catch {

Current coverage is 51.77%

Branch #1664 has no coverage reports uploaded yet.

No diff could be generated. No reports for master found.
Review entire Coverage Diff as of 0081c03

Uncovered Suggestions

+0.19% via ...terializerImpl.scala#157...169
+0.18% via .../master/Master.scala#116...127
+0.15% via ...ster/AppMaster.scala#160...169
See 7 more...

Powered by Codecov. Updated on successful CI builds.


Image resize on dynamically added images

how can we use image resizer when image is hidden on initial page load and its coming on some user event

Call the setup script, the first time the user event happens.

Thanks David , but is there any way were we can set up on hidden images ?

The issue is that when you show the image you're resizing it. The image doesn't have a resize event handler that can be used to detect this. Try the dev version which will support you calling the setup every time you unhide the image.
https://github.com/davidjbradshaw/image-map-resizer/tree/dev
If you can find a suitable event handler, please fill free to submit a pull request,

Surely will try the dev version , currently I have achieved the same by
checking if image is present on page then I'm unhiding it and calling
imagemap resizer and then again hiding it which solved my issue. Thanks for
your advice.
On Aug 2, 2015 5:41 PM, "David J. Bradshaw"<EMAIL_ADDRESS>wrote:

The issue is that when you show the image you're resizing it. The image
doesn't have a resize event handler that can be used to detect this. Try
the dev version which will support you calling the setup every time you
unhide the image.
https://github.com/davidjbradshaw/image-map-resizer/tree/dev
If you can find a suitable event handler, please fill free to submit a
pull request,
—
Reply to this email directly or view it on GitHub
https://github.com/davidjbradshaw/image-map-resizer/issues/24#issuecomment-127020333
.


Icon Layer icons are not rendered on map

Description
I am trying to use the getIcon method and provide an external icon as a URL. It seems to be not rendering any marker on the map.  In the following code ICON Mapping implementation with IconAtlas works without any issues but when I am trying to use getIcon method instead of IconAtlas and it seems to be not working for me.
Repro Steps

/** ICON MAPPING WORKS */
const ICON_MAPPING = {
  airplane : {
    x:0,
    y:0,
    width: 512,
    height: 512
    }
 }
/** ICON MAPPING WORKED  END */

new IconLayer({
    id: `path-layer-${fd.slice_id}`,
    data,
    getColor: d =>  sc,
    getPosition: d => {  return d.spatial;},

    /** ICON MAPPING WORKS */
    // sizeScale: 50,
    // iconAtlas : 'https://raw.githubusercontent.com/Swizec/webgl-airplanes-map/master/src/airplane-icon.jpg',
    // iconMapping: ICON_MAPPING,
    // getIcon:d=>"airplane",
    // getSize: d => 1,
    /** ICON MAPPING WORKED */

    /** Get ICON Implementation */
     getIcon: d => ({
       url:"https://raw.githubusercontent.com/Swizec/webgl-airplanes-map/master/src/airplane-icon.jpg",
       height:512,
       width: 512,
       mask:false,
     }),
     sizeScale: 50,
     getSize: d => 1,
    /** Get ICON Implementation END*/

     opacity: 1,
     sizeMinPixels : 30,
     pickable: true,
     visible: true,

  });

Environment (please complete the following information):

Framework Version: [e.g. deck.gl 7.1.7]
Browser Version: [e.g. Chrome 75.0.3770.100 ]
OS: [e.g. Mac OS X 10.14.5]

Logs

@xintongxia  Do you see any issues in the above code?

I tried with your icon params on my end and it is working. I don't know what is the data you are using, so I use our test data instead.
https://codesandbox.io/embed/sad-smoke-khth3

Closing due to inactivity and unable to reproduce any issue.  Please reopen if you feel there is still an issue here.


Vertical Slider issue on IOS devices

The vertical slider doesn't works well in IOS devices. When we touch and scroll it actually scrolls the page and not the slider.
Please let me know if there is a fix for that?
Thanks,
Munir

I have got the same issue. I found out that attaching any touchmove event handler (even an empty one) to slider (within jquery.twentytwenty.js) solves the issue. However I was not yet able to find out why this is the case, would assume a bug in jquery.event.move.
slider.on("touchmove", function(event) {});


Stop testing tchannel in crossdock

The tchannel repos already have OpenTracing crossdock tests. Having them in Jaeger repos as well is legacy code, and it creates unnecessary conflicts, eg in the Go client we are stuck with the old version of thrift, the Node client is not able to run the full test matrix, etc.
Plan to remove tchannel from crossdock is:

[x] remove it from all docker-compose files  first
[x] remove code from the driver
[ ] remove code from clients

[x] go
[x] java
[ ] node
[ ] python

👍

It seems it have been fixed in all linked repositories. I will close this.


Ensure chain schemas have k+1 active slots after intersections

Rebase of #477 on top of genesis/milestone8.
This PR causes chain schemas to have more than $k$ blocks after intersections.
Having more than k blocks after intersections makes the inputs interesting for the long range attack, and for testing that rollbacks of more than $k$ can't happen in caught up nodes.
This guarantee comes from the generation algorithm, which ensures that every $s$ window has exactly $k$ blocks in the honest chain.
For alternative chains, we ensure that the chains have more than s+k+d+1 slots, and we choose the first active slot before this many slots from the end. Then the acceleration bound is before the last k blocks of the alternative chain, which we always set to active.
Race windows do not push the acceleration bound to the last k blocks because the intersections with the honest chain are always behind the last block preceding the last s+k+d+1 slots.

I made an attempt at explaining the minimum schema length in a code note. Let me know if it helps.

Merged as 42bc271 in genesis/milestone-7-9-10.


Skip lines at beginning of csv

I have a csv file with about 20 rows of setup information, followed by a header, and then the data.
Is there a way for CSVReader to read this file ignoring the first 20 rows?  I'm able to parse a file without this setup information.

You can call read_line 20 times.


devspace failing to download bitnami helm chart

What happened?
devspace dev fails to deploy bitnami helm chart with the following error:
Error deploying: Error deploying database: Unable to deploy helm chart: error during '/home/eugene/.devspace/bin/helm upgrade database bitnami/postgresql --namespace testie --values /tmp/524314694 --install --version 10.1.1 --kube-context minikube': Release "database" does not exist. Installing it now.
Error: failed to download "bitnami/postgresql" (hint: running `helm repo update` may help)

What did you expect to happen instead?
devspace dev succeeds, without manually running any helm commands.
How can we reproduce the bug? (as minimally and precisely as possible)

Ensure that ~/.cache/helm and ~/.helm is deleted.

Ensure that  ~/.devspace/bin/helm repo list lists no repos.

Create a simple devspace.yaml containing the following deployment:

   deployments:
 - name: database
   helm:
     chart:
       name: bitnami/postgresql
       version: "10.1.1"
       #repo: https://charts.bitnami.com/bitnami
     values:
       postgresqlDatabase: "my_app_db"
       postgresqlUsername: "my_app_db_user"
       postgresqlPassword: ${DB_PASSWORD}

run devspace dev

Local Environment:

DevSpace Version: 5.3.0
Operating System: linux (ubuntu 20.04)
Deployment method: helm

Kubernetes Cluster:

Cloud Provider: minikube
Kubernetes Version: v1.19.4

Anything else we need to know?

/kind bug

@bynare thanks for reporting this issue! That looks like an helm error to me, does it work if you try to deploy the chart directly via helm (hint: try using the --debug flag for information)?

@FabianKramm I have to manually add the bitnami repo via ~/.devspace/bin/helm repo add.. then do ~/.devspace/bin/helm repo update. After this, devspace dev does its thing. I could not find any documentation (excuse me if I missed it!) referring to manually running these commands, before a helm chart would work?

@bynare if you reference the chart via repo/chart then you have to do this beforehand. Does the error also occur if you do it like this:
deployments:
 - name: database
   helm:
     chart:
       name: postgresql
       version: "10.1.1"
       repo: https://charts.bitnami.com/bitnami
     values:
       postgresqlDatabase: "my_app_db"
       postgresqlUsername: "my_app_db_user"
       postgresqlPassword: ${DB_PASSWORD}

@FabianKramm yeah, as you can see from my initial post, I have given that a try too (see the commented out bit - also used the name as you have it there).

@bynare and if you do:
deployments:
 - name: database
   helm:
     upgradeArgs:
     - --repository-config
     - ''
     chart:
       name: postgresql
       version: "10.1.1"
       repo: https://charts.bitnami.com/bitnami
     values:
       postgresqlDatabase: "my_app_db"
       postgresqlUsername: "my_app_db_user"
       postgresqlPassword: ${DB_PASSWORD}

@FabianKramm thanks, that seems to fix the postgres chart, but now I'm seeing an error elsewhere:
Error: failed to download "https://charts.devspace.sh/charts/component-chart-0.7.0.tgz"
Do I now need to add that upgradeArgs to every deployment?

@FabianKramm looks like when I clear out ~/.config/helm, things work without upgradeArgs even. Just confirming with another colleague..

@bynare yes the problem is usually a corrupted repository that leads to that issue (adding the --repository-config flag basically overrides the corrupted config and hences solves this issue)

I'll close this one for now - thanks for your help @FabianKramm

I'll close this one for now - thanks for your help @FabianKramm


fix(markdown): more markdown fixes

Silenced all missing keys warnings.
Fixed an issue where a mention or a issue link wasn't recognized at the start of a line.
#381 <- should work
@housseindjirdeh <- should work too

Noticed yet a few more problems

Ok, so this is turning out to be more than small fixes for markdown.
I discovered that when we pass the HTML accept header to github API, all markdown gets rendered server side, and a clean HTML transformation is provided in body_html.
So we're getting rid of MarkdownHtmlView in favor of GithubHtmlView.
Still work in progress to fix some small glitches

bummer: syntax highlighting doesn't work anymore.. fixing it now.


Reset Password System

Overview

Closes #39
Description
Functionality when completed, as follows:

Check if a form using the post method has been submitted
Check for validity of the email, and if valid, send the email
Whether there is a query string in the url, display the corresponding form
Display the footer

Release notes

Notes:

Working reset password system
Use the same email and keep your questions
Lets you make a new password

Squash, rebase, or merge?

Rebase please


Replace this one by the one from nl-4-devs

Or can you fix the movement and the kill on nl-4-devs??

I'm making this one by scratch, it's not based on the pets plugin taken from LBCore.

but can you fix the player kill on the pets plugin???
and the movement??


Flutter treeshaking not working with dart:io platform

When compiling this code for android:
import 'dart:io' show Platform;
import 'package:test/androidString.dart';
import 'package:test/iosString.dart';
void main() {
  String a = "Empty";
  if (Platform.isAndroid) {
    a = androidString;
  } else {
    a = iosString;
  }
print(a);
  runApp(MyApp());
}

The problem is that even though never used, the iosString is still included by the compiler.
This can be shown by making the iosString big so that you see a visible increase in size.
The solution is to make the compiler somehow smarter, so that it can know the iosString when compiling for android the iosString is in fact unused. This is crucial especially now that flutter supports the web where a few megabyte in size make a huge difference.

Hi @MainTobias Thanks for filing the issue, could you please share the output of flutter doctor -v and also tell how you are checking the app size.
Thanks.

Flutter doctor says everythings fine and I installes the newest stable version just before running this when I created the issue.

Thanks for the info, but if you could share the output of flutter doctor -v it would help to better diagnose the issue.

Here:
[✓] Flutter (Channel dev, 2.5.0-6.0.pre, on Microsoft Windows [Version 10.0.19042.1165], locale en-DE)
• Flutter version 2.5.0-6.0.pre at C:\Users\tobia\bins\flutter
• Upstream repository https://github.com/flutter/flutter.git
• Framework revision 225a43d941 (3 weeks ago), 2021-08-05 11:32:48 -0700
• Engine revision 07ec4b82c7
• Dart version 2.14.0 (build 2.14.0-383.0.dev)
[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.2)
• Android SDK at C:\Users\tobia\AppData\Local\Android\Sdk
• Platform android-30, build-tools 30.0.2
• ANDROID_HOME = C:\Users\tobia\AppData\Local\Android\Sdk
• Java binary at: C:\Users\tobia\AppData\Local\JetBrains\Toolbox\apps\AndroidStudio\ch-0\202.7486908\jre\bin\java
• Java version OpenJDK Runtime Environment (build 11.0.8+10-b944.6842174)
• All Android licenses accepted.
[✓] Chrome - develop for the web
• Chrome at C:\Program Files\Google\Chrome\Application\chrome.exe
[✓] Visual Studio - develop for Windows (Visual Studio Community 2019 16.10.3)
• Visual Studio at C:\Program Files (x86)\Microsoft Visual Studio\2019\Community
• Visual Studio Community 2019 version 16.10.31424.327
• Windows 10 SDK version 10.0.19041.0
[✓] Android Studio (version 4.2)
• Android Studio at C:\Users\tobia\AppData\Local\JetBrains\Toolbox\apps\AndroidStudio\ch-0\202.7486908
• Flutter plugin version 57.0.2
• Dart plugin version 202.8488
• Java version OpenJDK Runtime Environment (build 11.0.8+10-b944.6842174)
[✓] IntelliJ IDEA Ultimate Edition (version 2021.1)
• IntelliJ at C:\Users\tobia\AppData\Local\JetBrains\Toolbox\apps\IDEA-U\ch-0\211.7628.21
• Flutter plugin can be installed from:
🔨 https://plugins.jetbrains.com/plugin/9212-flutter
• Dart plugin can be installed from:
🔨 https://plugins.jetbrains.com/plugin/6351-dart
[✓] IntelliJ IDEA Ultimate Edition (version 2021.2)
• IntelliJ at C:\Users\tobia\AppData\Local\JetBrains\Toolbox\apps\IDEA-U\ch-0\212.5080.55
• Flutter plugin can be installed from:
🔨 https://plugins.jetbrains.com/plugin/9212-flutter
• Dart plugin can be installed from:
🔨 https://plugins.jetbrains.com/plugin/6351-dart
[✓] VS Code (version 1.59.1)
• VS Code at C:\Users\tobia\AppData\Local\Programs\Microsoft VS Code
• Flutter extension version 3.25.0
[✓] Connected device (5 available)
• Android SDK built for x86 (mobile) • emulator-5554 • android-x86     • Android 8.0.0 (API 26) (emulator)
• Windows (desktop)                  • windows       • windows-x64     • Microsoft Windows [Version 10.0.19042.1165]
• Windows (UWP) (desktop)            • winuwp        • windows-uwp-x64 •
• Chrome (web)                       • chrome        • web-javascript  • Google Chrome 92.0.4515.159
• Edge (web)                         • edge          • web-javascript  • Microsoft Edge 92.0.902.78
• No issues found!

Currently Platform.isAndroid is not a compile-time constant - it's calculated at run time, so tree shaker is not able to remove such code.
Other requests to make Platform.isAndroid constant:
https://github.com/flutter/flutter/issues/14233
https://github.com/dart-lang/sdk/issues/31969
https://github.com/dart-lang/sdk/issues/35705

Thanks Alex, closing this in favor of https://github.com/flutter/flutter/issues/14233


Update information about hosted Bootstrap 4 versions

This commit adds information about 4.1.1 being added to the CDN.
The original tip-off:
https://github.com/aspnet/Templating/pull/595#discussion_r201817830
Thanks!

Internal review link

@peterblazejewicz  Much appreciated.


Unknown Code System URI on a system listed in the Value Set

We got the following warning:

Encounter/I2-FW55JR6L24XECIN7NH6HA4YQWI000000: Encounter.type[0]: [Unable to determine whether the provided codes are in the value set http://hl7.org/fhir/us/core/ValueSet/us-core-encounter-type because the value set or a code system it depends on is not known to the validator, Code System URI 'http://www.ama-assn.org/go/cpt' is unknown so the code cannot be validated]

I went to the Value provided in the description (http://hl7.org/fhir/us/core/ValueSet/us-core-encounter-type). There it says all codes from http://www.ama-assn.org/go/cpt are included.

@KevinCranmer The warning is coming from tx.fhir.org. It looks like tx.fhir.org does not have CPT codes. You can ignore this one for US Core test kit


Configure app engine standard libs and pull them from maven central

fixes #866
Still a couple things left:

Add remaining libs - currently only servlet-api
Add / remove libs via the facet editor

Flow:
User can select libraries in the new project wizard:

User is promted to configure the selected lib to be downloaded from maven central:

Library is on the classpath and visible in the library settings:

User can see and configure the libs from the facet editor:

Also, after speak with @akerekes, we think it could be beneficial for maven projects to add the dependency to the POM rather than "manually" to the classpath like this (giving the user the option). This can be a separate enhancement though.

Yeah for Maven/Gradle projects the build files are the source of truth, and
we should never make any native modifications to the classpath. Supporting
those projects can be a separate enhancement like you said, but I think
what you have here for native projects is good.
On Mon, Sep 19, 2016 at 4:39 PM, Etan Shaul<EMAIL_ADDRESS>wrote:

Also, after speak with @akerekes https://github.com/akerekes, we think
it could be beneficial for maven projects to add the dependency to the POM
rather than "manually" to the classpath like this (giving the user the
option). This can be a separate enhancement though.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/GoogleCloudPlatform/google-cloud-intellij/pull/916#issuecomment-248118779,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHf5Hd7hOsGphWQHY-M292CGU_zQ_pCdks5qrvLngaJpZM4KA7Eh
.

Remaining todos:

How does this functionality interact with maven/gradle projects that may already include these dependencies? In this PR we are not modifying the build files, but we still would need a way to detect if the build systems already include these dependencies and handle it appropriately

Implement facet functionality - checking / unchecking the libs from the facet editor should add / remove the library

Can we hide this UI from Maven and Gradle based projects for now?
On Tue, Sep 20, 2016 at 1:26 PM, Etan Shaul<EMAIL_ADDRESS>wrote:

Remaining todos:

How does this functionality interact with maven/gradle projects that
may already include these dependencies? In this PR we are not modifying the
build files, but we still would need a way to detect if the build systems
already include these dependencies and handle it appropriately
Implement facet functionality - checking / unchecking the libs from
the facet editor should add / remove the library
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/GoogleCloudPlatform/google-cloud-intellij/pull/916#issuecomment-248371451,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHf5Ha8uEeOi5D_Py40UQJhrafo2vDyGks5qsBc9gaJpZM4KA7Eh
.

Yes. That sounds a reasonable solution for this iteration.

I realized that this solution needs to be modified slightly: rather than persisting and loading the facet lib selections via IntelliJ's property mechanism, they need to be synced with the users actual configured libs.
For example, regardless of the user's library selection within the facet, the user can always go into the Library configuration (within the Module config) and manually remove a library. The facet needs to be aware of and synchronized with this.

Yeah that makes a lot of sense.  I was going to review this this afternoon, is it ready for that or should I hold off?

Please hold off. There are a few tricky things related to this syncing that I'm trying to figure out. I'll put out a comment here when its ready.

Syncing between the projects libs and the facet lib UI is implemented.
Remaining todos:

Get library addition/removal via the facet UI working (not new project wizard which is working already).
Set the scope on the loaded libraries

@patflynn @joaoandremartins @aslo
You can start reviewing this. I still have a couple todo's that I'm working on:

Adding new libs via the facet editor throws an exception. Something is not being disposed properly.
Need to suppress this functionality for Maven/Gradle projects to prevent native additions to the classpath that could conflict with the build system.

looks like you have some checkstyle issues.

strange, cause it did the right thing for the form file.
On Sep 28, 2016 12:32 PM, "Etan Shaul"<EMAIL_ADDRESS>wrote:

@etanshaul commented on this pull request.
In google-cloud-tools-plugin/src/com/google/cloud/tools/
intellij/appengine/facet/AppEngineFacetEditor.java
https://github.com/GoogleCloudPlatform/google-cloud-intellij/pull/916:

-import com.intellij.facet.Facet;
-import com.intellij.facet.ui.FacetEditorContext;
-import com.intellij.facet.ui.FacetEditorTab;
-import com.intellij.facet.ui.FacetValidatorsManager;
-import org.jetbrains.annotations.Nls;
-import org.jetbrains.annotations.NotNull;
-import javax.swing.JComponent;
-import javax.swing.JPanel;
-/**

@author nik

*/
-public class AppEngineFacetEditor extends FacetEditorTab {

I'm not totally sure. I did just do a refactor / rename in the ide.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/GoogleCloudPlatform/google-cloud-intellij/pull/916,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHf5HQdcF_MwLDUA8kCT5uv7lVacRcqoks5qupZygaJpZM4KA7Eh
.

Yeah good idea!
On Wed, Sep 28, 2016 at 6:18 PM, João Martins<EMAIL_ADDRESS>wrote:

@joaoandremartins commented on this pull request.
In google-cloud-tools-plugin/src/com/google/cloud/tools/
intellij/appengine/facet/AppEngineStandardLibraryPanel.java
https://github.com/GoogleCloudPlatform/google-cloud-intellij/pull/916:

+import java.util.Set;

+import javax.annotation.Nullable;
+import javax.swing.JCheckBox;
+import javax.swing.JPanel;
+
+/**

UI panel for configuring App Engine standard environment libraries.

*/
+public class AppEngineStandardLibraryPanel {

private JPanel libraryPanel;
private JCheckBox servletApi;
private JCheckBox jstl;
private JCheckBox appEngineApi;
private JCheckBox endpoints;

On top of that, would any kind of metrics here be useful? Like how many
users are using an API?
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/GoogleCloudPlatform/google-cloud-intellij/pull/916,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHf5HVkgLcEQl7PnbGSdLuS5ig4dHP2Yks5quue7gaJpZM4KA7Eh
.

Question now that I've solved the major hurdles with this PR:
Do we want to have any of these libraries selected by default in the new project wizard? I'd expect, at a minimum, the App Engine API to be selected by default. Also, should we rearrange these somehow? Or maybe have a visual distinction between the provided dependency (Servlet API) and the rest?
Here is how it currently looks (note they are all deselected by default):

I would think that Servlet and App Engine APIs would be used by the big majority of app developers in GAE. I would leave the other ones unselected.
I'd also probably place JSTL after App Engine API, since I think it's more likely users will use App Engine APIs rather than JSP?

@ludoch
Actually, now that I think about it. I don't think it even makes sense to
allow the user to not select the servlet and JSP libraries since they're
provided by the runtime environment.
I hear you about the App Engine API.  I'd be tempted to have it checked by
default.
On Thu, Sep 29, 2016 at 2:18 PM, Etan Shaul<EMAIL_ADDRESS>wrote:

Question now that I've solved the major hurdles with this PR:
Do we want to have any of these libraries selected by default in the new
project wizard? I'd expect, at a minimum, the App Engine API to be selected
by default. Also, should we rearrange these somehow? Or maybe have a visual
distinction between the provided dependency (Servlet API) and the rest?
Here is how it currently looks (note they are all deselected by default):
[image: image]
https://cloud.githubusercontent.com/assets/1735744/18966516/7cd594ba-864f-11e6-8987-588471d45316.png
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/GoogleCloudPlatform/google-cloud-intellij/pull/916#issuecomment-250548438,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHf5HdvWlKLBr1S8JvPLaUo497gC7YkYks5qvADZgaJpZM4KA7Eh
.

What's weird with the JSP thing is that they're only provided at runtime if
they're used by including a JSP... So it may make sense to expose that to
the user somehow by giving them the option of not selecting it.
On Thu, Sep 29, 2016 at 2:49 PM, João Martins<EMAIL_ADDRESS>wrote:

I would think that Servlet and App Engine APIs would be used by the big
majority of app developers in GAE. I would leave the other ones unselected.
I'd also probably place JSTL after App Engine API, since I think it's more
likely users will use App Engine APIs rather than JSP?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/GoogleCloudPlatform/google-cloud-intellij/pull/916#issuecomment-250557042,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHf5HQsRYCXAgioxkTYWfX1jqMat7s3iks5qvAg5gaJpZM4KA7Eh
.

@patflynn what do you mean by exposing it by giving them the option of not selecting it? How is that different from just having it unselected by default like it is now?

The library UI is now disabled for Maven modules. The last thing is to disable it for gradle projects as well / see if there is a general mechanism for determining if a module is backed by a build system.
Not a lot will change based on this last todo (it will be contained) so please review. It would also be helpful to test out the UI to get a feel for the experience.

Are you considering adding more unit tests?

yes. working on it. right after I add the gradle detection

Is there any way we can restrict it to only the 2.5 version of the servlet api?

@patflynn it is restricted to 2.5. See AppEngineStandardMavenLIbrary.SERVLET_API

Have you tested local run configs with this change?  Not sure if it's related but I'm noticing that the local server configuration icon has a red 'x' on it, but looking at the configuration doesn't highlight any errors.  Running the config results in:
Error running App Engine Local Server: Error running Google App Engine Dev Server. Exception occurred : java.lang.NullPointerException Exception message : null

I should probably test this on master but I'm also seeing two 'app engine local server' dependencies in the module settings.

I also tried removing the appengine-api sdk dep using the facet editor and now my module shows up as broken with a missing dep.

@patflynn
regarding the app-engine-api removal: were you testing this with an already existing project that had this? This dependency is obsolete and now removed. Instead it comes from maven via the managed dependencies.

No this was a newly created project using the wizard and the facet library
adding feature from this branch.
On Tue, Oct 4, 2016 at 3:12 PM, Etan Shaul<EMAIL_ADDRESS>wrote:

@patflynn https://github.com/patflynn
regarding the app-engine-api removal: were you testing this with an
already existing project that had this? This dependency is obsolete and now
removed. Instead it comes from maven via the managed dependencies.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/GoogleCloudPlatform/google-cloud-intellij/pull/916#issuecomment-251484112,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHf5HWzLccelc_8f5nXIVaZBhKDBPVziks5qwqUcgaJpZM4KA7Eh
.

It is preselected to 2.5, but I can change it.
On Tue, Oct 4, 2016 at 3:04 PM, Etan Shaul<EMAIL_ADDRESS>wrote:

@patflynn https://github.com/patflynn it is restricted to 2.5. See
AppEngineStandardMavenLIbrary.SERVLET_API
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/GoogleCloudPlatform/google-cloud-intellij/pull/916#issuecomment-251481945,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHf5Hd75aOnjZGNrGWPZqDvUE0kon2Uyks5qwqMqgaJpZM4KA7Eh
.

@patflynn, @joaoandremartins, @aslo
I think I've addressed the comments from review as well as the following remaining items:

bug where removing a lib via the new UI doesn't remove it from the module
exclude the new UI from Gradle projects (in addition to Maven)

Only thing left is to look into test coverage. ptal

one thing. I may have missed it, but I didn't see the added tracking for which libraries were 'added'

Do you mean metrics tracking? I can look into this. Although I need to give
some thought to how how we want to track repeated additions: users adds,
removes, adds again etc.
On Thu, Oct 6, 2016 at 9:06 AM Patrick Flynn<EMAIL_ADDRESS>wrote:

one thing. I may have missed it, but I didn't see the added tracking for
which libraries were 'added'
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/GoogleCloudPlatform/google-cloud-intellij/pull/916#issuecomment-251955649,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABp8QHiB15BYfcOEKzvP971b3D7tAWsoks5qxPI5gaJpZM4KA7Eh
.

Keep it simple for now.  Just knowing what the total selects a specific
library in the wizard or facet importer is good enough.
On Thu, Oct 6, 2016 at 9:46 AM, Etan Shaul<EMAIL_ADDRESS>wrote:

Do you mean metrics tracking? I can look into this. Although I need to give
some thought to how how we want to track repeated additions: users adds,
removes, adds again etc.
On Thu, Oct 6, 2016 at 9:06 AM Patrick Flynn<EMAIL_ADDRESS>wrote:

one thing. I may have missed it, but I didn't see the added tracking for
which libraries were 'added'
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<https://github.com/GoogleCloudPlatform/google-cloud-intellij/pull/916#
issuecomment-251955649>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/
ABp8QHiB15BYfcOEKzvP971b3D7tAWsoks5qxPI5gaJpZM4KA7Eh>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/GoogleCloudPlatform/google-cloud-intellij/pull/916#issuecomment-251965773,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHf5HbHhCJf3MmV-ksRXK8Dx6MXscHhRks5qxPu5gaJpZM4KA7Eh
.

@patflynn see https://github.com/GoogleCloudPlatform/google-cloud-intellij/pull/916/commits/1eb9180a55c602665d75bf97af8922b1676929d7 for metrics tracking of library additions.
Note the label will be the name of AppEngineStandardMavelLibrary enum, e.g. SERVLET_API.


[1.11] Bump Mesos to nightly 1.5.x 19d17ce

High-level description
This is a routine bump to the latest Mesos and mesos-modules.
Related JIRA Issues
Checklist for all PRs

[ ] Included a test which will fail if code is reverted but test is not. If there is no test please explain here:
[x] Read the DC/OS contributing guidelines
[x] Followed relevant code rules Rules for Packages and Systemd

Checklist for component/package updates:
If you are changing components or packages in DC/OS (e.g. you are bumping the sha or ref of anything underneath packages), then in addition to the above please also include:

[x] Changelog:
https://github.com/apache/mesos/compare/dd68c0bfb24354d4a0dbad252e1986b33aa9cac6...19d17cec3e797758e76c081efb68867d440ed4d3

[ ] Test Results: [link to CI job test results for component]

[ ] Code Coverage (if available): [link to code coverage report]

@mesosphere-mergebot label Ready For Review


how to get progerss when use SFTP download files?

await file.write(File('${appDocPath}/file.tgz').openRead().cast(), onProgress: (total) => print(total));
I hope this solves your issue . Refer this ticket for more details
https://github.com/TerminalStudio/dartssh2/issues/67


Please document the scale and spiral options

At https://react-wordcloud.netlify.com/props#options:
scale - "Control how words are spaced and laid out." - how exactly?
Same for spiral - how should one think of archimedean vs. rectangular?
I'm trying to produce a 90-degree layout like this, but can't tell how to configure those options.

A compact all-horizontal one would be fine too:

Words are very spaced out though.

Thanks for the feedback!
To be honest with you, I'm not sure how to describe archimedean and rectangular (source reference: https://www.jasondavies.com/wordcloud/).  I think it's a mathematical pattern of laying out the spiral and is somewhat visually noticeable.  When first working on this project, I was implementing features based on Jason Davies' wordcloud generator and kept this feature.  If there's a formal definition for this prop, I would totally be happy to update the Props page lol.
But to get to the two layouts you need, you should use rotationAngles and rotations

https://codesandbox.io/s/react-wordcloud-options-kuswu?file=/src/index.js
https://codesandbox.io/s/react-wordcloud-options-5qnqs?file=/src/index.js

It's covered super sparsely in https://react-wordcloud.netlify.app/usage/options#rotations, and I'll update the docs to include examples of these common layouts.  The way to think about it is: The number of rotations I can use between specified min/max rotation angles.

Closing issues as docs will be updated based on feedback in this issue.  Thanks!


Friday 05-05-2023- rollCall

Roll Call!
Leave a comment with these two things:

A summary of your study using only emojis
Something you'd like to share, anything goes! (within respect)

emoji cheat sheet

Hello everyone.  Let's go to finish our projects 😃 🔥

Good morning

Online

im here

Present!

Good morning

Good morning

Hi

Good morning

Good Morning

good morning

good morning, I am here

good morning

present

present

Morning

i am here

here

I am here


make borgs require prying to open instead of screwing

one step at a time, we will eventually "fix" borgs
About the PR

borgs now require a crowbar to open the panel instead of a screwdriver
Why / Balance

thing 13 does
Technical details

Media

Requirements

[x] I have read and am following the Pull Request and Changelog Guidelines.
[x] I have added media to this PR or it does not require an ingame showcase.

Breaking changes

Changelog

:cl:

tweak: Cyborgs now require being pryed to open/close the panel instead of screwed.

i would consider fixing the rest of it if the rest of it also didn't go
okay so when you emag a borg and succeed it adds the emagged component to it, which blocks future emag attempts
now the problem with that is that breaking the accesses on it would add the emagged component which results in you not being able to emag the borg
plus you currently can't emag an emagged borg which is honestly dumb but like i dunno go fix laws i gues

All other wire panels get opened with a screwdriver, why should it work differently for borgs?
I think this random change will just confuse people and has no benefit.

pbj's been talking about it in vc, dunno, might as well make the pr so it can be talked about?

A better change, feature rather, would be after critting a Borg, being able to use a crobar to destroy the lock so then it's unscrewable. You can't order borgs to unlock themselves anymore so the only way to really get a Borg friend is gambling, being a scientist, killing a scientist or stealing a science I'd, which shouldn't be the only way I dont think.

thieves cant hurt borgs because MobState anyway

thieves cant hurt borgs because MobState anyway

Theives have theiveing gloves, they can easily get their hands on a sci id

I feel like the "why" part could be expanded upon, because I'm confused why it matters

thieves cant hurt borgs because MobState anyway

i am talking about nukies' assault borg

Theives can still work with crew to emag a syndie Borg. I've had it happen to me while the Nuke was armed, I proceeded to solo the last two nukies and disarm the nuke

All other wire panels get opened with a screwdriver, why should it work differently for borgs?

Because they aren't actually wire panels. They're used to swap parts. In fact in SS13 borgs do have an actual wire hacking panel you can open, once you remove the actual cover.

All other wire panels get opened with a screwdriver, why should it work differently for borgs?

Because they aren't actually wire panels. They're used to swap parts. In fact in SS13 borgs do have an actual wire hacking panel you can open, once you remove the actual cover. You need to unlock -> crowbar -> remove battery -> screwdriver to do wire hacking on a borg.

DAMN real and true, owned

Because they aren't actually wire panels. They're used to swap parts. In fact in SS13 borgs do have an actual wire hacking panel you can open, once you remove the actual cover. You need to unlock -> crowbar -> remove battery -> screwdriver to do wire hacking on a borg.

I think we will likely add the actual wires to borgs as well at some point, and internally the current screwdriver step is opening a wire panel for the borg according to the yaml. So instead we should add the part swap panel opened with the crowbar rather than refunctioning the wirepanel.
And these changes should be done in the same PR where such a cover is added. If we change the interaction steps before that it will just confuse players.

So instead we should add the part swap panel opened with the crowbar rather than refunctioning the wirepanel.
And these changes should be done in the same PR where such a cover is added. If we change the interaction steps before that it will just confuse players.

You mean without having the wire panel locked behind opening the cover? Not a good idea, there's distinct sprites so now you'd need to deal with the mental, visual and code complexity of having 2 independent panel states instead of just one like it is in SS13.


Generic !command chat commands

What is the issue, e.g. map voting, you would like to solve?
A lot of servers use chat commands, e.g. !discord, to provide information to players, but SquadJS does not have a plugin to allow this yet.
How would you like us to solve this issue?
Commands will likely fall into one of the following categories:

Player run commands to get info, e.g. !discord to display a Discord invite link.
Admin run commands to announce preset messages, e.g. !seed reminds players of the seeding rules.

For player-run commands, we only need to send the information back to the caller, so warnings can be used. For admin-run commands, we need to send the information to all players so we want to use broadcasts.
However, I think approaching this as generically as possible is best so that we provide flexibility to SquadJS users to configure it exactly how they want in the config. Therefore, I propose that for each command we provide the following options:

Command - The command name, e.g. !discord.
Action Type - Warn or broadcast.
Response - The text to use in the warning/broadcast.
ignoreChats - An array of chats it does not apply to. This can be used to limit it to admins only.

That would look something like this:
    {
      "plugin": "chat-commands",
      "enabled": false,
      "commands": [
        {
          "command": "!discord",
          "type": "warn",
          "response": "discord.io/smoking-rifles",
          "ignoreChats": ["ChatSquad"]
        },
        {
          "command": "!seed",
          "type": "broadcast",
          "response": "Seeding most is active...",
          "ignoreChats": ["ChatAll", "ChatTeam", "ChatSquad"]
        }
      ]

In beta branch for the next release: https://github.com/Thomas-Smyth/SquadJS/pull/56


Tests use sources as test data?

To generate Eclipse projects for Ammonite, I'm using sbteclipse with a special setup, so that Eclipse writes its class files in bin/ instead of overwriting SBT's output — that's even the default since release 4.0.0 of sbteclipse. However, that makes a test fail, because it does not expect ops/bin to exist.
@ import ammonite.ops._
import ammonite.ops._
@ ls! wd/'ops
res1: LsSeq = LsSeq(
  'bin,
  'src,
  'target
)
@ %%ls 'ops
res2: CommandResult =
bin
src
target

Yes, that's how the test works now. Want to fix it by changing the ls to a different folder? Shouldn't be so hard.

I'm not going to fix this, but feel free to send a PR


beautiful work man. loved it. Sorry to open a new issue here :)

Thank you for loving it. Feel free to report a bug or make a suggestion. :)

make me your friend. we can talk and discuss things. And I have a story to tell you too.


PassManagerConfig should accept list for initial qubit layout

Environment

Qiskit Terra version: 1ae663d80295dce1b6ff25cbf29c640bf2ff9952
Python version: 3.9.6
Operating system: RHEL 8.5

What is happening?
Passing a pass manager to transpile gives an error.
How can we reproduce the issue?
from qiskit import QuantumCircuit, transpile
from qiskit.test.mock import FakeMumbai
from qiskit.transpiler import PassManagerConfig
from qiskit.transpiler.preset_passmanagers import level_3_pass_manager

backend = FakeMumbai()
qubits = [0]

circuit = QuantumCircuit(1)
circuit.x(0)

pass_manager_config = PassManagerConfig(initial_layout=qubits, backend_properties=backend.properties())
pass_manager = level_3_pass_manager(pass_manager_config)

transpiled = transpile(circuit, pass_manager=pass_manager, unitary_synthesis_method=None)

---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
Input In [1], in <module>
     12 pass_manager_config = PassManagerConfig(initial_layout=qubits, backend_properties=backend.properties())
     13 pass_manager = level_3_pass_manager(pass_manager_config)
---> 15 transpiled = transpile(circuit, pass_manager=pass_manager, unitary_synthesis_method=None)

File ~/projects/qiskit-terra/qiskit/compiler/transpiler.py:287, in transpile(circuits, backend, basis_gates, inst_map, coupling_map, backend_properties, initial_layout, layout_method, routing_method, translation_method, scheduling_method, instruction_durations, dt, approximation_degree, timing_constraints, seed_transpiler, optimization_level, pass_manager, callback, output_name, unitary_synthesis_method, unitary_synthesis_plugin_config, target)
    264     _check_conflicting_argument(
    265         optimization_level=optimization_level,
    266         basis_gates=basis_gates,
   (...)
    277         target=target,
    278     )
    280     warnings.warn(
    281         "The parameter pass_manager in transpile is being deprecated. "
    282         "The preferred way to tranpile a circuit using a custom pass manager is"
   (...)
    285         stacklevel=2,
    286     )
--> 287     return pass_manager.run(circuits, output_name=output_name, callback=callback)
    289 if optimization_level is None:
    290     # Take optimization level from the configuration or 1 as default.
    291     config = user_config.get_config()

File ~/projects/qiskit-terra/qiskit/transpiler/passmanager.py:225, in PassManager.run(self, circuits, output_name, callback)
    223     return self._run_single_circuit(circuits, output_name, callback)
    224 if len(circuits) == 1:
--> 225     return self._run_single_circuit(circuits[0], output_name, callback)
    226 return self._run_several_circuits(circuits, output_name, callback)

File ~/projects/qiskit-terra/qiskit/transpiler/passmanager.py:278, in PassManager._run_single_circuit(self, circuit, output_name, callback)
    266 """Run all the passes on a ``circuit``.
    267
    268 Args:
   (...)
    275     The transformed circuit.
    276 """
    277 running_passmanager = self._create_running_passmanager()
--> 278 result = running_passmanager.run(circuit, output_name=output_name, callback=callback)
    279 self.property_set = running_passmanager.property_set
    280 return result

File ~/projects/qiskit-terra/qiskit/transpiler/runningpassmanager.py:124, in RunningPassManager.run(***failed resolving arguments***)
    122 for passset in self.working_list:
    123     for pass_ in passset:
--> 124         dag = self._do_pass(pass_, dag, passset.options)
    126 circuit = dag_to_circuit(dag)
    127 if output_name:

File ~/projects/qiskit-terra/qiskit/transpiler/runningpassmanager.py:155, in RunningPassManager._do_pass(self, pass_, dag, options)
    153 # Run the pass itself, if not already run
    154 if pass_ not in self.valid_passes:
--> 155     dag = self._run_this_pass(pass_, dag)
    157     # update the valid_passes property
    158     self._update_valid_passes(pass_)

File ~/projects/qiskit-terra/qiskit/transpiler/runningpassmanager.py:209, in RunningPassManager._run_this_pass(self, pass_, dag)
    206 elif pass_.is_analysis_pass:
    207     # Measure time if we have a callback or logging set
    208     start_time = time()
--> 209     pass_.run(FencedDAGCircuit(dag))
    210     end_time = time()
    211     run_time = end_time - start_time

File ~/projects/qiskit-terra/qiskit/transpiler/passes/layout/full_ancilla_allocation.py:68, in FullAncillaAllocation.run(self, dag)
     65 if layout is None:
     66     raise TranspilerError('FullAncillaAllocation pass requires property_set["layout"].')
---> 68 virtual_bits = layout.get_virtual_bits()
     69 physical_bits = layout.get_physical_bits()
     70 if layout:

AttributeError: 'list' object has no attribute 'get_virtual_bits'

What should happen?
No error.
Any suggestions?
No response

Ok it's because initial_layout is not allowed to be a list. I think it should be allowed to be any type accepted by transpile itself. I've changed the title of this issue accordingly.

Yeah, this is definitely part of a large interface problem surrounding the (complete lack of) separation of responsibilities between PassManagerConfig and transpile.  Really, PassManagerConfig isn't a nice interface as things stand, so the solution to this issue will likely come as larger changes to the whole pipeline come through (see e.g. #6403 for some work, where a similar issue is in the review comments).
A rework of this is definitely on the cards, though when it'll actually materialise is slightly difficult to say.


Code Formatter

Please create a config file for code formatter. You might try using black

@rohitgeddam, I suppose you added pyproject.toml for the black configuration. If done, consider closing the issue.

Yes I have added configuration for Black formatter in pyproject.toml. We need to run Black in command line each time befor e we push to fix all flake8 linting errors.


SEC-132: Changes to 'profile' WRT configuration and credentials outputs.

SEC-132 was branched from SEC-119, so combines SEC-119 branch and SEC-132 features:
From SEC-119:

eliminates six.moves (input library)
cleans us variety of print statements
adds obvious formatting output for --verbose (debug)

From SEC-132:

improved use of clokta configuration file: one file (~/.clokta/clokta.cfg), multiple config profiles
automatically creates source-able ~/.clokta/.sh file and docker compose-compatible ~/.clokta/.env files

Two changes:

If okta_password or multifactor_preference are completely omitted from the DEFAULT section, the program fails with an enigmatic key error.  Omitting fields from DEFAULT should have the same behavior as putting them in with an empty value.
Don't create two variable files.  We don't need the .sh one.  The .env one can be sourced just as easily.

@rantonucci-washpost
Issue 1 is fixed. While testing I also encountered an issue adding new profiles to an existing clokta.cfg file; now fixed. If clear, I can squash the commits into another branch or you can opt for squash-and-merge option from the 'Merge' button dropdown.


Nicer (& fixed up) help texts for space views

Introduced a little utility for this purpose. Not very well-rounded, but a good starting point I like to think :)
Help texts for different space views:
3D:

2D:

Bar chart:

Time series:

Checklist

[x] I have read and agree to Contributor Guide and the Code of Conduct
[x] I've included a screenshot or gif (if applicable)

on the 3D it says holding alt instead of holding option despite me being on a mac.
https://github.com/emilk/egui/pull/2981 fixes this!


[feature] Prometheus metrics

Is your feature request related to a problem? Please describe.
I want to pull some data through Prometheus.
But I found that easegress did not expose the data in Prometheus model.
Describe the solution you'd like
I think we can add a path to APIServer.
eg: /metrics

I have some problems while developing.I want to count the QPS and request time of each HTTPServer, HTTPPipeline. Implement wants to build on the existing HTTPStat. Prometheus has a label.
I need a different name to set the label. But now HTTPStat does not have this parameter. And now it’s not easy to get the name when doing the stat.
eg: this code. The HTTPPipeline name is not get here.
I hope to get some suggestions from you to implement this metrics.

Yes, have some problems when passing in the name parameter.
Because now some HTTPStat belongs to a pool. When creating a pool, you cannot get the HTTPPipeline name directly, and how to distinguish while multiple pools in a HTTPPipeline.
So I want you to help  see how to better achieve statistical traffic(HTTPServer or HTTPPipeline) metrics.

Thanks, we will check that and get back to you.

Proxy has access to the name of the pipeline and it's own name:
pipelineName := b.filterSpec.Pipeline()
proxyName := b.filterSpec.Name()

. In order to pass the names to each pool, proxy.newPool could take them as a parameter and pass it to HTTPStat that is created there. To distinguish different pools, we could concatenate pipelineName + "|" +  proxyName + "|" + tagPrefix. (tagPrefix is provided here and it's different for each pool of one proxy) Then in following example:
name: http-pipeline-1
kind: HTTPPipeline
flow:
  - filter: proxy
filters:
  - name: proxy-a
    kind: Proxy
    mainPool:
      servers:
      - url: http://<IP_ADDRESS>:9095
      loadBalance:
        policy: roundRobin
    candidatePools:
      servers:
      - url: http://<IP_ADDRESS>:9094
      loadBalance:
        policy: roundRobin

we'll have two names for HTTPStat:

http-pipeline-1|proxy-a|proxy#main
http-pipeline-1|proxy-a|proxy#candidate#0

And of course then we should add a name to HTTPStat struct. @suchen-sci What do you think about this design? @brzyangg Would this help you to fill the Prometheus label?

@samutamm Thanks, I think this can help me.


[ja] Following the upstream for content/ja/_index.md && minor fixes

Describe your changes
Following the upstream

update contributors/maintainers
the paragraph addition regarding the Emeritus Maintainers

minor fixes

remove comma
change the period to the kutenn(。)
add the newline at the end of the file.

Related issue number or link (ex: resolves #issue-number)

GitHub comment: https://github.com/cncf/glossary/pull/2809#issuecomment-1895363180
Slack: https://cloud-native.slack.com/archives/C02N2RGFXDF/p1706511157815389?thread_ts=1706414657.825829&cid=C02N2RGFXDF

Checklist before opening this PR (put x in the checkboxes)

[x] This PR does not contain plagiarism

don’t copy other people’s work unless you are quoting and contributing it to them.

[x] I have signed off on all commits

signing off (ex: git commit -s) is to affirm that commits comply DCO. If you are working locally, you could add an alias to your gitconfig by running git config --global alias.ci "commit -s".

/cc @seokho-son
I have created this PR to update content that had become outdated. Sorry for the delay.
Best regards :)

not a review, but LGTM! :)


Code interpretability

Opening this as a place to collect loose thoughts on the ease with which the source code can be read, understood and worked with.

Starting from the top, I guess that most users that just naively want to know what the code does, would open MicroHH.jl and try to figure out what happens from there. That file, to me, would ideally serve as a table of contents for the rest of the code. Put differently, I'd like to open that file and immediately see the flow of the program, and where the different modules of the code are called in that main flow.
I think it already does this really well. You could consider:

moving the I/O stuff out of this file
giving step_model a more central place, e.g. at the very top after you've defined the model.
order the 'main' functions so that they come in 'chronological' order, i.e. something like:

function Model
function prepare_model
function step_model
function calc_rhs
Other supporting functions. Maybe this is not possible if the supporting functions need to be defined before they can be called (I don't know if this is the case in Julia?), but you get the idea.

The structs (Fields, Grid...) are a great choice to pass information around. It very pleasant to read things like m.fields[i].u; this works very well.

The passing around of the Parallel may feel a little cumbersome, but it actually reads quite well. It's very explicit now when a function needs to account for the parallelisation, even if just to print. Making this global is something to consider, but I wouldn't say it's broken at the moment.

StencilBuilder.jl is very nice, but rather abstract. So if I wanted to implement my own advection scheme for instance, I really would have trouble starting with that. Prefacing this with a little comment on how the stencil builder works would be really useful. In general, you could consider having documentation on a per file basis, where you spend a few sentences just explaining the general idea. This would especially be useful for the more complex modules (Pressure.jl is another good example).

I was also wondering why you would gather all the dynamics in a single expression. It somehow feels more intuitive to have advection in one file, diffusion in another, i.e. just one file for each process on the RHS of the equations. That would presumably make it easier to integrate an SFS model in the future, e.g.. This is a really small point, of course.

StencilBuilder.jl is very nice, but rather abstract. So if I wanted to implement my own advection scheme for instance, I really would have trouble starting with that. Prefacing this file with a little comment on how the stencil builder works would be really useful. In general, you could consider having documentation on a per file basis, where you spend a few sentences just explaining the general idea and contents of each file.

I was wondering if you'd considered using https://github.com/eth-cscs/ImplicitGlobalGrid.jl for the underlying grid datastructure and stencil operations on it?
This is really cool stuff @Chiil !

@leifdenby Thanks, Leif. It is more or less a small-scale hobby project. Julia has some cool features that makes life a lot simpler with respect to C++. I did not know this package, I will have a look!


This commit fixes some style issues noticed after #1345 was merged.

Changes
This adds missing docstrings to the new interface methods and changes the way
TaskSpec is passed so it can't be mutated.
Submitter Checklist
These are the criteria that every PR should meet, please check them off as you
review them:

[X] Includes tests (if functionality changed/added)
[X] Includes docs (if user facing)
[X] Commit messages follow commit message best practices

See the contribution guide for more details.
Double check this list of stuff that's easy to miss:

If you are adding a new binary/image to the cmd dir, please update
the release Task to build and release this image.

Reviewer Notes
If API changes are included, additive changes must be approved by at least two OWNERS and backwards incompatible changes must be approved by more than 50% of the OWNERS, and they must first be added in a backwards compatible way.

Thanks @dlorenc ! :heart:

/lgtm


Bower "main" section includes minified and non-minified files

My build system is picking up both versions of the script because both are in bower.json's main section. It doesn't make sense to me that both would be needed. Please see this issue on another repo: https://github.com/patternfly/angular-patternfly/issues/27

Hi, can you provide a PR for this, I'll be happy to merge it