Resources limit and requests are added only to first container inside POD

NRI  adds limits and requests to resources section only to first container within POD. Second container resources are not affected.
Test case:

Run NRI with flag -honor-resources
Create foo and boo CRD networks

apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  annotations:
    k8s.v1.cni.cncf.io/resourceName: example.com/boo
  name: boo-network
  namespace: default
spec:
  config: '{"cniVersion": "0.3.0", "name": "boo-network", "type":"loopback"}'

apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  annotations:
    k8s.v1.cni.cncf.io/resourceName: example.com/foo
  name: foo-network
  namespace: default
spec:
  config: '{"cniVersion": "0.3.0", "name": "foo-network", "type":"loopback"}'

Create POD according to below specification

apiVersion: v1
kind: Pod
metadata:
  annotations:
    k8s.v1.cni.cncf.io/networks: foo-network,boo-network
  name: nri-e2e-test
  namespace: default
spec:
  containers:
  - command:
    - /bin/sh
    - -c
    - sleep INF
    image: docker.io/alpine
    imagePullPolicy: Always
    name: test
  - command:
    - /bin/sh
    - -c
    - sleep INF
    image: docker.io/alpine
    imagePullPolicy: Always
    name: second-name
    resources:
      limits:
        example.com/foo: "9"
      requests:
        example.com/foo: "9"

Verify that resources in both containers are updated. Expected result
First container

    resources:
      limits:
        example.com/boo: "1"
        example.com/foo: "1"
      requests:
        example.com/boo: "1"
        example.com/foo: "1"

Second container
    resources:
      limits:
        example.com/boo: "1"
        example.com/foo: "10"
      requests:
        example.com/boo: "1"
        example.com/foo: "10"

Current result:
apiVersion: v1
kind: Pod
metadata:
  annotations:
    k8s.v1.cni.cncf.io/networks: foo-network,boo-network
  name: nri-e2e-test
  namespace: default
spec:
  containers:
  - command:
    - /bin/sh
    - -c
    - sleep INF
    image: docker.io/alpine
    imagePullPolicy: Always
    name: test
    resources:
      limits:
        example.com/boo: "1"
        example.com/foo: "1"
      requests:
        example.com/boo: "1"
        example.com/foo: "1"
  - command:
    - /bin/sh
    - -c
    - sleep INF
    image: docker.io/alpine
    imagePullPolicy: Always
    name: second-name
    resources:
      limits:
        example.com/foo: "9"
      requests:
        example.com/foo: "9"

NRI logs
# kubectl logs -n kube-system network-resources-injector
I0512 08:43:09.189322       1 main.go:69] starting mutating admission controller for network resources injection
I0512 08:43:09.190627       1 tlsutils.go:120] added client CA to cert pool from path '/var/run/secrets/kubernetes.io/serviceaccount/ca.crt'
I0512 08:43:09.190651       1 tlsutils.go:122] added '1' client CA(s) to cert pool

[root@silpixa00397909 network-resources-injector]# kubectl apply -f pod.yaml
pod/nri-e2e-test created

[root@silpixa00397909 network-resources-injector]# kubectl logs -n kube-system network-resources-injector
I0512 09:02:57.435382       1 webhook.go:725] Received mutation request
I0512 09:02:57.441010       1 webhook.go:698] search v1.multus-cni.io/default-network in original pod annotations
I0512 09:02:57.441039       1 webhook.go:705] search v1.multus-cni.io/default-network in user-defined injections
I0512 09:02:57.441047       1 webhook.go:719] v1.multus-cni.io/default-network is not found in either pod annotations or user-defined injections
I0512 09:02:57.441059       1 webhook.go:698] search k8s.v1.cni.cncf.io/networks in original pod annotations
I0512 09:02:57.441069       1 webhook.go:701] k8s.v1.cni.cncf.io/networks is defined in original pod annotations
I0512 09:02:57.441096       1 webhook.go:257] 'foo-network,boo-network' is not in JSON format: invalid character 'o' in literal false (expecting 'a')... trying to parse as comma separated network selections list
I0512 09:02:57.473200       1 webhook.go:355] network attachment definition 'default/foo-network' found
I0512 09:02:57.473242       1 webhook.go:362] resource 'example.com/foo' needs to be requested for network 'default/foo-network'
I0512 09:02:57.481258       1 webhook.go:355] network attachment definition 'default/boo-network' found
I0512 09:02:57.481289       1 webhook.go:362] resource 'example.com/boo' needs to be requested for network 'default/boo-network'
I0512 09:02:57.481302       1 webhook.go:811] honor-resources=true
I0512 09:02:57.481345       1 webhook.go:821] injectHugepageDownApi=false
I0512 09:02:57.481377       1 webhook.go:879] patch after all mutations: [{add /spec/containers/0/resources/requests map[]} {add /spec/containers/0/resources/limits map[]} {add /spec/containers/0/resources/requests/example.com~1boo {{1 0} {<nil>}  DecimalSI}} {add /spec/containers/0/resources/limits/example.com~1boo {{1 0} {<nil>}  DecimalSI}} {add /spec/containers/0/resources/requests/example.com~1foo {{1 0} {<nil>}  DecimalSI}} {add /spec/containers/0/resources/limits/example.com~1foo {{1 0} {<nil>}  DecimalSI}} {add /spec/containers/0/volumeMounts/- {podnetinfo true /etc/podnetinfo  <nil> }} {add /spec/containers/1/volumeMounts/- {podnetinfo true /etc/podnetinfo  <nil> }} {add /spec/volumes/- {podnetinfo {nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil &DownwardAPIVolumeSource{Items:[]DownwardAPIVolumeFile{DownwardAPIVolumeFile{Path:annotations,FieldRef:&ObjectFieldSelector{APIVersion:,FieldPath:metadata.annotations,},ResourceFieldRef:nil,Mode:nil,},},DefaultMode:nil,} nil nil nil nil nil nil nil nil nil nil nil nil}}}]
I0512 09:02:57.481776       1 webhook.go:397] sending response to the Kubernetes API server

@MichalGuzieniuk all containers in the pod share same network namespace, so I think adding device resource to first container itself would be sufficient.

@MichalGuzieniuk all containers in the pod share same network namespace, so I think adding device resource to first container itself would be sufficient.

Yes, this is true for kernel interface, every container inside Pod namespace would be able to see the attached sriov device, so it becomes less important on which container the resource are injected to.
@MichalGuzieniuk We do have a problem when the resource is userspace device (e.g. DPDK), in which case, the userspace device mounted the first container is invisible to other containers (in the same pod). There is no solution to address this issue yet.

@MichalGuzieniuk We do have a problem when the resource is userspace device (e.g. DPDK), in which case, the userspace device mounted in the first container is invisible to other containers (in the same pod). There is no solution to address this issue yet.

NRI mounts k8s.v1.cni.cncf.io/network-status annotation (which includes device-info) into all containers. wouldn't that suffice (example: to find out pci address of VF)  for userspace device ?


feat: Support Vyper 0.3.10

What I did

fixes: #96 APE-1462
How I did it
Compile each set of contracts separately according to specified optimization level in pragmas.
If no optimization level is there, we fall back to "True" as before.
also, for version pragmas, we support the new format now, looks like #pragma version 0.3.10
How to verify it
Compile any contract with #pragma optimize codesize
Checklist

[X] Passes all linting checks (pre-commit and CI jobs)
[x] New test cases have been added and are passing
[x] Documentation has been updated
[X] PR title follows Conventional Commit standard (will be automatically included in the changelog)

hey to fix the mypy issue (temporarily) just pin pydantic <2 in the lint dependencies with a comment saying it's needed, i did it on core ape and some other repos too


[BUG] [Upgrade] epicli may fail after re-running

Describe the bug
When epicli upgrade fails (e.g. after network issue) and it's re-run, you can get Directory /var/www/html/epirepo/packages must exist error like below:
FAILED! => {"changed": true, "cmd": "set -o pipefail && /tmp/epi-repository-setup-scripts/create-repository.sh /var/www/html/epirepo false |& tee /tmp/epi-repository-setup-scripts/create-repository.log", "delta": "0:00:00.403076", "end": "2021-05-31 15:21:51.253095", "msg": "non-zero return code", "rc": 1, "start": "2021-05-31 15:21:50.850019", "stderr": "", "stderr_lines": [], "stdout": "Loaded plugins: amazon-id, search-disabled-repos, versionlock\nPackage httpd-2.4.6-97.el7_9.x86_64 already installed and latest version\nPackage createrepo-0.9.9-28.el7.noarch already installed and latest version\nPackage yum-utils-1.1.31-54.el7_8.noarch already installed and latest version\nNothing to do\nDirectory /var/www/html/epirepo/packages must exist", "stdout_lines": ["Loaded plugins: amazon-id, search-disabled-repos, versionlock", "Package httpd-2.4.6-97.el7_9.x86_64 already installed and latest version", "Package createrepo-0.9.9-28.el7.noarch already installed and latest version", "Package yum-utils-1.1.31-54.el7_8.noarch already installed and latest version", "Nothing to do", "Directory /var/www/html/epirepo/packages must exist"]}

How to reproduce
Steps to reproduce the behavior:

Run epicli upgrade
Fail after all requirements are downloaded (flag file must already exists: /tmp/epi-download-requirements/download-requirements-done.flag)
Run epicli upgrade again without waiting (since there is default: download_done_flag_expire_minutes: 120)

Expected behavior
No failure.
Environment

Cloud provider: All
OS: All

epicli version: 0.10.0, 1.0.0 and develop branch (1.1.0)
Additional context
Issue introduced with PR #2162.

DoD checklist

[ ] Changelog updated (if affected version was released)
[ ] COMPONENTS.md updated / doesn't need to be updated
[ ] Automated tests passed (QA pipelines)

[ ] apply
[ ] upgrade

[ ] Case covered by automated test (if possible)
[ ] Idempotency tested
[ ] Documentation updated / doesn't need to be updated
[ ] All conversations in PR resolved
[ ] Backport tasks created / doesn't need to be backported

Tested:
:heavy_check_mark: epicli apply -> epicli upgrade -> force stop epicli upgrade -> re-run epicli upgrade -> success 👍


fixing docs

Coverage remained the same at 93.44% when pulling b5511a647ec39e1f14921c29a184267accbdbcd2 on doc-fix into eb008dc159f7bd6f7c5d15da9ab3fe34f5e65416 on master.

:shipit:


Walltime

Somehow I missed there's no walltime option in this version, add?

So I now see in the examples that you can add it on the command line as an option added to the end.
While nice, this makes it less flexible than the original qbatch for the purposes of scripting.
Thoughts?

Yes, I think so. Perhaps -t,--walltime.

Same goes as #5 if we support walltime as part of qbatch, the exact batching system can be abstracted away.


TOC: Persistent 32px top padding needed

Detailed description
For max, xlg, lg breakpoints, visual spec says TOC should maintain 32px top padding when user scrolls down.  It does not do so in this example link, rather touches the masthead with 0px padding.

Is this a feature request (new component, new icon), a bug, or a general
issue?

Bug

Is this issue related to a specific component?

Yes, TOC.

What did you expect to happen? What happened instead? What would you like to
see changed?

See this video:
I expect it to follow visual specs and have 32px top padding between TOC and masthead, when scrolling downward, like this:
Viz spec guidance:

Instead, there is 0 padding, see this video:
TOC-32px-padding.zip

What browser are you working in?

Chrome
Steps to reproduce the issue

Go to TOC on this test page: https://ibmdotcom-nextjs-staging.mybluemix.net/solutions.html
Scroll down
View how the TOC behaves with top padding

@larahanlon2 @wonilsuhibm I separated out this bug, so I can move the original TOC bug issue forward to dev.  Please lmk if it this is a bug we want to fix.
CC @RobertaJHahn, if we can get this moving at same time as the original TOC bug, the dev can do them both at once and likely save time.

Currently TableOfContents do have this padding at the top, this bug is happening only on our Next Js page, as the padding, is smaller than the Nav Height.


Question:  Search/Filter All Values?

Is it possible to perform an  ArangoSearch or Filter on all document values without specifying the key?
Preferably with partial matches (ex:  Searching at would return at, cat, attack)
I know I can do this, specifying which keys to check:
FOR item IN items
    FILTER
        CONTAINS(item.name, @searchValue) OR
        CONTAINS(item.jobtitle, @searchValue) OR
        CONTAINS(item.department, @searchValue)
    RETURN item

But is there a way to perform simple query like:
FOR item IN items
    FILTER CONTAINS(item.[*], @searchValue)
    RETURN item

I believe I could use something like this, but it only works for exact matches:
FOR item IN items
    FILTER VALUES(item) ANY == @searchValue
    RETURN item

I am building an internal ticketing system for our company and each ticket may have a slightly different schema.  I'd like to be able to have a general "everything" search, without specifying every potential key in the query.
Is this possible?

This is currently not possible unless you maintain an additional field with all the text in it, which you can then index and search. There is no support for virtual fields yet, but it's on our radar (with no ETA).
For top-level attributes only you could try:
FOR item IN items
  FILTER LENGTH(FOR v IN VALUES(item) FILTER CONTAINS(v, @@searchValue) RETURN true)
  RETURN item

It will obviously have no index acceleration.

@Simran-B Appreciate the response.  Given that my documents are small, I'll include the fields to take advantage of that index acceleration.  There is no reason to sacrifice performance for laziness on my part.

Sorry for digging this up from the grave, but are there any plans to support this type of querying? Coming from one of my other projects which used Elasticsearch doing this was relatively trivial.
{
  "match": {
    "metadata.*": {
      "query": "quick brown fox"
    }
  }
}

Having to store the entire contents of all of these fields (especially in our case where the content of the metadata object is largely user provided seems like a significant waste of space. You also lose the ability to do additional things such as knowing which field matched the query and highlighting.

There are no plans to support searching all document attributes using a wildcard for the attribute key due to performance concerns and because it would be difficult to integrate with other features that work on a per-field basis (scoring, highlighting, etc.). You can index all fields with includeAllFields: true at the top-level but you need to specify the attribute key/field when searching.


Feat/rook ceph

Description
Please don't use the branch, until upcoming branch, for setting up the cluster itself.
Checklist

[ ] The PR branch is set up to merge into feat/k8s instead of dev.

Currently orchest-ctl updates orchest, argo, and the docker registry during an orchest update. Do we want to do the same for ceph and rook? I see that as a possible issue since orchest-ctl mounts the userdir.

Closed the PR as the changes merged by https://github.com/orchest/orchest/pull/742


Browser tests failed in CI:

Describe the bug
In some recent CI runs, Browser tests failed with
@lodestar/utils: 21 11 2022 22:37:17.765:ERROR [launcher]: Cannot start FirefoxHeadless
@lodestar/utils: 	Can not find the binary firefox
@lodestar/utils: 	Please set env variable FIREFOX_BIN
@lodestar/utils: 21 11 2022 22:37:17.767:ERROR [launcher]: FirefoxHeadless stdout:
@lodestar/utils: 21 11 2022 22:37:17.767:ERROR [launcher]: FirefoxHeadless stderr:

for example https://github.com/ChainSafe/lodestar/actions/runs/3518653218/jobs/5897797085
I don't see this error in my local environment
Expected behavior
No error

The error clearly meant that it's Firefox was not installed on the machine, which is very weird as this never happens before and these tests are stable for couple of months.
Will try a re-run it once again to see if it's some weird CI runner issue. If it persists then will debug further.


feat: pkg/util/k8s add ut

Signed-off-by: Meng JiaFeng<EMAIL_ADDRESS>Pre-Checklist
Note: please complete ALL items in the following checklist.

[x] I have read through the CONTRIBUTING.md documentation.
[x] My code has the necessary comments and documentation (if needed).
[x] I have added relevant tests

Description
add more unit test for pkg/util/k8s package
Related Issues
close #1015
New Behavior (screenshots if needed)

Thanks for creating detailed uts for k8s pkg. 👏


Add Stopwatch project

Proposed changes:

Add Stopwatch project

Type of change:

[x] New feature (non-breaking change which adds functionality)

Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings

Nice work


sim: disable sim uart output processing

Summary
Using the host serial port to send data in sim will convert \r to \r\n
When using the host physical serial port in sim, the existing configuration will convert \r to \r\n when sending data.
If the tty device used is not stdin/out, we need to set it to raw format
Impact
none
Testing
sim

[Experimental Bot, please feedback here]
No, this PR does not meet the NuttX requirements.
Missing Information:

Why is the change necessary?  The summary states the "what" but not the "why". Is this a bug fix? A desired behavior change?  Clarity is needed.
What functional part of the code is being changed? Be specific. Which files/modules are affected?
How does the change exactly work? Provide a technical explanation of your solution.
Related Issues: Are there any related issues in the NuttX or NuttX Apps repositories?
Build Host(s): Specify the OS, CPU architecture, and compiler used for testing.
Target(s): Which simulator and configuration were used?
Testing logs:  The provided logs are placeholders. Include actual logs showing the problem before and the solution after your change.

Recommendations:

Expand the Summary: Clearly articulate the problem, the reason for the change, and the specific area of the code being modified.
Explain the Solution: Provide a technical description of how your code change addresses the issue.
Complete Testing Information:  Provide detailed information about your testing environment and include actual logs demonstrating the problem and the successful outcome after applying your changes.
Consider Impact: Even if you believe the impact is minimal, explain your reasoning. For instance, if this change only affects simulated environments, state that explicitly.

By providing the missing information, you will make your PR easier to review and increase the likelihood of it being accepted.


Need a keyboard shortcut to Cycle between multiple opened terminals

Need a keyboard shortcut to Cycle between multiple opened terminals
Clicking and then selecting for seeing each of the terminal is very cumbersome. Please add a shortcut key for the same
Thanks

Here are the ones I use:
{ "key": "ctrl+shift+j",     "command": "workbench.action.terminal.focusNext" },
{ "key": "ctrl+shift+k",     "command": "workbench.action.terminal.focusPrevious" },

See https://code.visualstudio.com/docs/getstarted/keybindings

Thanks,
This was nice information
Regards,
Rajesh
On Wed, Oct 16, 2019 at 6:16 AM Daniel Imms<EMAIL_ADDRESS>wrote:

Here are the ones I use:
{ "key": "ctrl+shift+j",     "command": "workbench.action.terminal.focusNext" },
{ "key": "ctrl+shift+k",     "command": "workbench.action.terminal.focusPrevious" },
See https://code.visualstudio.com/docs/getstarted/keybindings
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vscode/issues/82565?email_source=notifications&email_token=ANPVXMP4ACO62JKQSKVG6PDQOZP7FA5CNFSM4JAYY3K2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBKU7EY#issuecomment-542461843,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ANPVXMMELHPK6XEBCFQO3WDQOZP7FANCNFSM4JAYY3KQ
.


Hides error textview in the header for textInputLayout views.

IMPORTANT: All PRs must be linked to an issue (except for extremely trivial and straightforward changes).
Fixes #1725
Description
Error text view in the header was not hidden for views which shows error text at the bottom of the view. As result it was always showing extra blank space in the header.
Now, error text view in the header is hidden, therefore it will not add extra blank space.
Alternative(s) considered
Have you considered any alternatives? And if so, why have you chosen the approach in this PR?
Type
Choose one: Bug fix
Screenshots (if applicable)
Checklist

[x] I have read and acknowledged the Code of conduct.
[x] I have read the Contributing page.
[x] I have signed the Google Individual CLA, or I am covered by my company's Corporate CLA.
[x] I have discussed my proposed solution with code owners in the linked issue(s) and we have agreed upon the general approach.
[x] I have run ./gradlew spotlessApply and ./gradlew spotlessCheck to check my code follows the style guide of this project.
[x] I have run ./gradlew check and ./gradlew connectedCheck to test my changes locally.
[x] I have built and run the demo app(s) to verify my change fixes the issue and/or does not break the demo app(s).


Rebuild for Python 3.10

Checklist

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

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

@conda-forge-admin, please rerender

@conda-forge-admin, please rerender

What is the current status of this?

Deprecated by #31


Exit block with next not break

Apparently break is specific to #each or something?

Fixes https://rollbar.com/davidjrunger/davidrunger/items/47/


Bug: RemindMe creates duplicate events

Bug: !remindme sends two requests; creates two duplicate events. Replicated with minutes and days.
Describe the solution you'd like: it should create one event : It should create one event : )

This one is happening on every reminder and its quite bizzare

So the current idea is that somehow there was 2 instances of the bot (or something in the bot), which caused the issue.
Truly a bizarre issue, but not directly related to the remind cog.


publicReleaseRefSpec usage

Quite likely that this is user error, so would appreciate any pointers.
I have a project using NB.GV 2.0.41, building with msbuild 15 from the master branch, packing using NuGet 4.3.0.
My version.json includes:
  "publicReleaseRefSpec": [
    "^refs/heads/master",
    "^refs/tags/v\\d+\\.\\d+"
  ]

My .nuspec file includes:
<version>$version$</version>

When I do nuget pack -Build, the resulting file is just MyPackage.1.0.4.nupkg. But NuGet gives me a warning:
WARNING: Issue: Package version not supported on legacy clients.
WARNING: Description: The package version '1.0.4+g2b37059da8' uses SemVer 2.0.0 or components of SemVer 1.0.0 that are not supported on legacy clients. This message can be ignored if the package is not intended for older clients.
WARNING: Solution: Change the package version to a SemVer 1.0.0 string. If the version contains a release label it must start with a letter.

And in fact, the embedded version string in the package does include the git commit hash.
I thought that the point of the publicReleaseRefSpec was to prevent the git hash from appearing in the package (although it does still appear in the AssemblyInformationalVersion is the assembly itself).
Am I misunderstanding, or doing something stupid?

Great question. This was a design point that there was some discussion and research on before it was made in the NB.GV 2.x release. And you can set it to avoid the +g suffix if you want IIRC by setting the nuget package semver version to 1 instead of 2.
What you describe is standard NuGet behavior as far as hiding the build metadata everywhere except inside the nuspec file itself. It's pretty much out of site everywhere (as far as nuget.org and clients) except in the nuspec so that someone who wants to know the git commit that the package came from can do so. We considered that a feature. The publicReleaseRefSpec is designed to control between stable and unstable package versions. If you weren't building out of master or a vX.Y tag spec, you'd get a suffix that starts with a hyphen instead of a plus, and the git commit ID would be obvious to everyone.  And as I said, if the commit ID in the nuspec bothers you, I think you can turn it off with the nuget package semver setting.
Does that help?

Thanks, I understand what you're saying – but I can't seem to get it to work correctly.
If I set nugetPackageVersion.semVer to 1, I still get the +g in the version string. And if I build out of a non-master branch, I do not get the commit ID in the package name. IOW, I seem to be unable to change what I'm getting (clean package name, but +g in the version string).

When you build in a non-master branch, the package ID should stay the same, but the -gCommitId suffix should be added to the version. Is that non happening?

Terminology is a little confusing here! When I say package name, I mean the name of the .nupkg file (MyPkg.1.0.4.nnupkg), which I think is what you also mean by package ID. When I say version string, I mean the string that gets put into the .nuspec file inside the .nupkg.
If I'm understanding correctly, publicReleaseRefSpec is supposed to control whether the commit hash appears in the package name (MyPkg.1.0.4-g12345678.nupkg) and nugetPackageVersion.semVer is supposed to control whether the commit hash appears in the version string.
No matter what I do in terms of changing those two settings, and building in master and non-master branches, I only ever seem to get the same result: The commit hash is always in the version string, and never in the package name.

Can you share a diagnostic or detailed msbuild log?

See attached.
nbgv.zip
Built from branch foo with nuget pack -build -verbosity detailed
Given the settings, I would have expected to see the hash in the package name but not in the version string. Actual result was hash in the version string but not in the package name.

Thanks. Somehow I missed that you were literally using nuget pack. That isn't something I've tested, and is likely what's causing you trouble. Is this a .NET SDK project that you can use msbuild /t:pack with instead? That's how I've tested it before so I'd have more confidence that it works for you.

msbuild /t:pack gives me an error: The target "Pack" does not exist in the project.
I've never tried to use that target before, but this is a brand new Framework project, built with VS2017. https://docs.microsoft.com/en-us/nuget/schema/msbuild-targets says I should be able to use that target with MSBuild >= 15.1, and I have 15.4.8.

I can share the git repo, if that would help, or I'm happy to keep troubleshooting from this end. I appreciate your assistance.

AFAIK the Pack target only exists when using the .NET SDK, which is available in recent versions of MSBuild (like yours). That documentation would suggest you're right though. So it's either very misleading, or there's a bug in msbuild since I'm seeing the same thing you are.
As you say the project is brand new, I would suggest you switch to .NET SDK style projects if you're developing a console app or class library. They're so much nicer. And they define a Pack target. :)

Yes, thanks, I can easily switch this project to SDK. But I'm a little concerned about this issue in other (Framework) projects I have which use GV. Not a big issue for me at the moment, but it does seem as though something in GV is not working as intended.

I emailed the NuGet team to point out the issue in the docs.
I've never tested NB.GV with nuget pack. I'm not 100% confident I'll be able to make it work well with nuget pack -- it will be conditional on how flexible it is to read various properties, and whether NB.GV can detect that that is the scenario we're running in.
I'll leave this issue open to track nuget pack behavior.

I may be running into a similar problem.  I have this:
  "publicReleaseRefSpec": [
    "^refs/heads/master$",
    "^refs/tags/v\\d+\\.\\d+",
    "^refs/tags/v\\d+(?:\\.\\d+){0,2}$"
  ],

With this git log:
commit 8ca433787bfb87874652c6027dbd3052e24b5418 (HEAD -> ASIASETL-994, tag: v1.0.9)
Author: Lucas Theisen<EMAIL_ADDRESS>Date:   Fri Oct 12 14:34:47 2018 -0400

    try again

Notice that the tag is v1.0.9 which matches either of these:
    "^refs/tags/v\\d+\\.\\d+",
    "^refs/tags/v\\d+(?:\\.\\d+){0,2}$"

But when i run dotnet pack:
PS C:\Users\ltheisen\git\asiasetl-data-consumer-registry> dotnet pack --include-symbols --include-source --configuration Release
Microsoft (R) Build Engine version <IP_ADDRESS>72 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  Restore completed in 89.67 ms for C:\Users\ltheisen\git\asiasetl-data-consumer-registry\Mitre.Data.ConsumerRegistry.Test.Integration\Mitre.Data.ConsumerRegistry.Test.Integration.csproj.
  Restore completed in 53.35 ms for C:\Users\ltheisen\git\asiasetl-data-consumer-registry\Mitre.Data.ConsumerRegistry\Mitre.Data.ConsumerRegistry.csproj.
  Restore completed in 53.35 ms for C:\Users\ltheisen\git\asiasetl-data-consumer-registry\Mitre.Data.ConsumerRegistry.Test.Integration\Mitre.Data.ConsumerRegistry.Test.Integration.csproj.
  Mitre.Data.ConsumerRegistry -> C:\Users\ltheisen\git\asiasetl-data-consumer-registry\Mitre.Data.ConsumerRegistry\bin\Release\netstandard2.0\Mitre.Data.ConsumerRegistry.dll
  Successfully created package 'C:\Users\ltheisen\git\asiasetl-data-consumer-registry\Mitre.Data.ConsumerRegistry\bin\Release\Mitre.Data.ConsumerRegistry.1.0.9-g8ca433787b.nupkg'.
  Successfully created package 'C:\Users\ltheisen\git\asiasetl-data-consumer-registry\Mitre.Data.ConsumerRegistry\bin\Release\Mitre.Data.ConsumerRegistry.1.0.9-g8ca433787b.symbols.nupkg'.

You can see that the commit hash is still present on the nupkg: Mitre.Data.ConsumerRegistry.1.0.9-g8ca433787b.nupkg.  However, if I add my current branch name (followed by commit):
  "publicReleaseRefSpec": [
    "^refs/heads/master$",
    "^refs/heads/ASIASETL-994$",
    "^refs/tags/v\\d+(?:\\.\\d+){1,2}$"
  ],

I get the desired results:
PS C:\Users\ltheisen\git\asiasetl-data-consumer-registry> dotnet pack --include-symbols --include-source --configuration Release
Microsoft (R) Build Engine version <IP_ADDRESS>72 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  Restore completed in 52.63 ms for C:\Users\ltheisen\git\asiasetl-data-consumer-registry\Mitre.Data.ConsumerRegistry\Mitre.Data.ConsumerRegistry.csproj.
  Restore completed in 52.97 ms for C:\Users\ltheisen\git\asiasetl-data-consumer-registry\Mitre.Data.ConsumerRegistry.Test.Integration\Mitre.Data.ConsumerRegistry.Test.Integration.csproj.
  Restore completed in 85.48 ms for C:\Users\ltheisen\git\asiasetl-data-consumer-registry\Mitre.Data.ConsumerRegistry.Test.Integration\Mitre.Data.ConsumerRegistry.Test.Integration.csproj.
  Mitre.Data.ConsumerRegistry -> C:\Users\ltheisen\git\asiasetl-data-consumer-registry\Mitre.Data.ConsumerRegistry\bin\Release\netstandard2.0\Mitre.Data.ConsumerRegistry.dll
  Successfully created package 'C:\Users\ltheisen\git\asiasetl-data-consumer-registry\Mitre.Data.ConsumerRegistry\bin\Release\Mitre.Data.ConsumerRegistry.1.0.10.nupkg'.
  Successfully created package 'C:\Users\ltheisen\git\asiasetl-data-consumer-registry\Mitre.Data.ConsumerRegistry\bin\Release\Mitre.Data.ConsumerRegistry.1.0.10.symbols.nupkg'.

With Mitre.Data.ConsumerRegistry.1.0.10.nupkg.
This feels like I must be doing something wrong...

@lucastheisen You're hitting something different. In git, tags can't be "checked out" like branches or commits can be.
During the build, NB.GV can't know that you were building the commit for the sake of the tag or not when you're building locally. If you're building on CI, and the CI knows it's building based on the tag, it will typically set an env var that indicates this. NB.GV will pick up on that (as an example, here is the appveyor-compatible check).
So if you're building locally, and want a public release, and it's not based on a branch you have checked out, you need to build with /p:publicrelease=true. Tags only work on CI servers.

@AArnott , excellent information (and fantastic tool!).  That explains my problem.  I only release off of master so its not a huge problem, it just made things more difficult to test.  Anyway, thank you much!

According to https://docs.microsoft.com/en-us/nuget/reference/nuspec#replacement-tokens nuget pack would use the AssemblyInformationalVersion if present, otherwise AssemblyVersion for the $version$ token. So if AssemblyInformationalVersion is set to the version number including hash, then $version$ will cause this version number to determine the package version.
Is there a recommended way to use NB.GV with old style csproj projects to create NuGet packages?

How do you create nuget packages from old style csproj?

Usually by running nuget pack against a .nuspec file, although you can also run it directly against a .csproj file.

I have never researched how we might make that scenario work. It might be easy. If you want you can open an issue proposing how it can work. I would accept a PR that includes tests. But I won't likely have time to implement it myself.

I'm not sure there's anything for NBGV to do in this case -- I don't think it's invoked during a nuget pack operation. It has already done its job by populating the version fields during the build process. @AArnott Do you know whether this is a true statement?
If it is, I think you would either need to edit the .nuspec after the project is built and set the version property by hand, or pass it in on the command line. You could write a build script that builds the project, reads the properties of the built assembly, determines the desired version string for the package (e.g., AssemblyInformationalVersion 5.6.3+g92b7290530 -> version 5.6.3), and then calls nuget pack, passing in that string on the command line.

We found a workaround/solution for our build process.

According to the could build documentation there are options to have NB.GV emit variables containing the proper version strings.
According to the nuget pack reference there are options to pass a version into nuget pack command which overrides the version information from the .nuspec file. This avoids the problem that NuGet tries to resolve the package version via the AssemblyInfo.

In Azure DevOps we now use nbgv cloud --all-vars to determine the version for the build label and the version variables. We then use a NuGetCommand@2 to perform a pack command with

versioningScheme: byEnvVar
versionEnvVar: NBGV_NUGETPACKAGEVERSION

You can probably also just use something like nuget pack -Version %NBGV_NUGETPACKAGEVERSION% or whatever is appropriate in your build system to achieve the same result. Also other version strings are available.

You could write a build script that builds the project, reads the properties of the built assembly, determines the desired version string for the package

@asherber I would never go to all that trouble. I would just use the nbgv tool or query the project itself for the version properties. No need to build the dll or reflect over it just to get the version info out. Plus, the version fields in an assembly aren't necessarily what the user wants for a package version, which can be formatted in several ways. Using NB.GV to get the actual package version is the best way to be consistent.
What @michael-x suggests is a very reasonable approach, particularly if the repo has a common version for all projects. If you need a specific per-project version for a specific package, you can query the individual project or use nbgv for that particular project and it will give you the variables for it (optionally without setting cloud variables).

@AArnott I forgot about using the nbgv tool to read version info, since you can't use it to install nbgv for old-style csproj files. You're right that that's a better solution.


Wait to signal to the extHostTerminalService that the terminal is opened until the terminal has a name.

Also added a change listener for title. Fixes #53057

Tested with
const shell = vscode.window.createTerminalRenderer('fake shell');
shell.write('Type and press enter to echo the text\r\n\r\n');
shell.terminal.show();
setTimeout(() => {
shell.name = 'new name';
setTimeout(() => console.log(shell.terminal.name), 500);
}, 500);
and by checking the terminal name in onDidOpenTerminal


Should spawn create a child in the parent?

When we are inside an operation, and we have received a Controls, then we have the ability to spawn a new context, this context is currently a child of the current operation, however I don't think this is ever what we want. In almost all cases, we actually want the spawned context to be a sibling of the current operation. This seems a bit a bit counterintuitive at first, but it makes sense if we look at it as suspending something into the background. If the spawned context is a child of the current operation, then it can't ever outlive it.
It's worth noting that we've done various weird workarounds in a lot of places to actually spawn a sibling instead. For example in Effection's own fork implementation and in watch in bigtest server.
Here is some example code illustrating this point:
import { Controller, monitor, main } from 'effection';

function createChild() {
  return ({ resume, spawn }) => {
    let runChild: Controller = ({ ensure }) => {
      console.log("starting child");
      ensure(() => {
        console.log("finishing child");
      });
    };
    resume(spawn(monitor(runChild)));
  }
}

main(function*() {
  console.log("starting main");

  yield createChild();

  console.log("finishing main");
});

This currently prints:
starting main
starting child
finishing child
finishing main

Since the child is immediately killed after being spawned. But we really want the child to outlive the yield point and to only be killed at the end of main.
It's interesting to note that this combination also solves our desire to do RAII-like patterns, without actually having to expose the parent. Just spawning a monitor in the parent will tie the resulting resource to the lifetime of the parent. No need to be able to even see the parent context.

Maybe it would actually be sensible to have two separate methods, spawnChild and spawnSibling? At the moment I can't really come up with a use-case for spawning a child though.

The only place I can see that you want to spawn in the current context is if your operation is serving in a supervisory role. So for example, if you have one operation that manages 10 operations, restarting them at appropriate times, then you want to be spawning children, but for most "atomic" operations what you really want, as you say, is to be spawning siblings.
An example of spawning children, not siblings, in the current codebase is in the implementation for the Generator control function which makes sense since it is a supervisory operation.
For now, I think having spawn create a sibling makes sense, and then having a separate method spawnChild or even newContext. However, something about this tickles me as being similar to solving the "rightward drift" problem of moving down a tree, and while still fuzzy in my head, I wonder if  perhaps their is a similar solution of "returning the next promise" as a way for an operation to participate in the level above it.
promise:
await $.ajax.get('/jwt/token')
  .then(token => {
    return $.ajax.post('/signed-upload-urls/')
  })
  .then(({ url }) => {
    return $ajax.put(url, imageData);
  });

By returning a promise each time, that promise is executed in the context level above it rather than creating a new one.
I wonder if there is a shared solution here of perhaps returning a new operation from the control function (instead of void), then that operation is run in the parent context.
type Controller = Controls => (Operation | void)

If we do make spawn operate on the parent, then we also need to somehow make the parent resume and fail functions available from the spawn so that you can link the new sibling back to the parent.

I think that our interface to the parent should be pretty limited. Being able to call resume on the parent seems dangerous. A child should be able to bubble up an error to its parent, but not change its return value, imo. Then we'd be sort of back to the behaviour of 0.4 where any child could randomly resume its parent, which I don't think is good.

With the advent of context returns and resources, this is no longer relevant.


Skip Connection Support

Hi @titu1994! Really appreciate your works! Currently, I'm inspecting NAS code but I'm confused of adding skip connections to the state_space. Can you point out some directions? Thank you!

I've been wondering the same thing actually. I have kinda given up on the code cause ENAS by Google is publically available and so much cleaner than this.
It has significant overhead to understand what is going on, but after that it can find powerful architectures in just 1 day. It's my current go to for NAS work.


operators: Add configuration options

OSBS-8637

Add operator_manifest configuration to container.yaml
This was already added to atomic-reactor, but container.yaml validation
has since been moved to osbs-client
Signed-off-by: Adam Cmiel<EMAIL_ADDRESS>Maintainers will complete the following section:

[ ] Commit messages are descriptive enough
[x] "Signed-off-by:" line is present in each commit
[ ] Code coverage from testing does not decrease and new code is covered
[ ] JSON/YAML configuration changes are updated in the relevant schema
[ ] Changes to metadata also update the documentation for the metadata
[ ] Pull request includes link to an osbs-docs PR for user documentation updates

See https://github.com/containerbuildsystem/atomic-reactor/pull/1389/commits/c9a24e5dddce58522d9df724dc6fa2a58bc0b90f
Do we test the schema here? I did not find any tests.

@chmeliik; I feel like the PR title/commit message/actual code changes are describing different things.
What I see in the code changes is validation of configuration options schema. When I saw "Add configuration options", I was expecting something involving new CLI options, or new YAML, or something :)

@ben-alkov fair point, is this better?


Error in new code after update Build.gradle (app) file

Hello,
Today on 19 October 2019. I have been updated build. gradle file's dependency. But after update this I got these errors. You can check it in a screenshot and also dependency below.
    implementation 'com.google.firebase:firebase-ml-vision:24.0.0'
    implementation 'com.google.firebase:firebase-ml-vision-image-label-model:19.0.0'
    implementation 'com.google.firebase:firebase-ml-vision-face-model:19.0.0'
    implementation 'com.google.firebase:firebase-ml-model-interpreter:22.0.0'
    implementation 'com.google.firebase:firebase-ml-natural-language:22.0.0'
    implementation 'com.google.firebase:firebase-ml-natural-language-language-id-model:20.0.7'
    implementation 'com.google.firebase:firebase-ml-natural-language-smart-reply-model:20.0.7'
    implementation 'androidx.multidex:multidex:2.0.1'
    implementation 'com.google.firebase:firebase-ml-natural-language:22.0.0'
    implementation 'com.google.firebase:firebase-ml-natural-language-translate-model:20.0.7'

@KanwarpartapSinghBimrah the latest version of ML Kit introduced some breaking changes. These changes are documented on the release notes

@rosariopfernandes I checked the release notes and I was confused. let me know how to fix this. Have any solid example.

@KanwarpartapSinghBimrah you can find the solution for TranslateViewModel on StackOverflow.
Now in order to fix your CustomModelActivity, you'll need to change the options you're using to create an interpreter. It would be something like this:
val localSource = FirebaseCustomLocalModel.Builder()
            .setAssetFilePath("my_model.tflite")
            .build()
// There's no need to register your model anymore
val options = FirebaseModelInterpreterOptions.Builder(localModel).build()
val interpreter = FirebaseModelInterpreter.getInstance(options)

@rosariopfernandes I tried to sort out this error with the help of your example code. But sorry to say that I have an error in the below code. I mean only localModel in getting the error.
val options = FirebaseModelInterpreterOptions.Builder(localModel).build()

@rosariopfernandes Hi thanks for providing the solution on this topic now its working fine.

Hi!
Does someone has an example of a AutoML LocalModel working at com.google.firebase:firebase-ml-vision v24.0.0? Only my RemoteModel is working at the moment, and I didn't find any documentation about it on v24.0.0. I also tried to read the release notes of v24.0.0 but it didn't worked
My actual code is:
    FirebaseAutoMLRemoteModel remoteModel = new FirebaseAutoMLRemoteModel.Builder(REMOTE_MODEL_NAME).build();

    FirebaseAutoMLLocalModel localModel = new FirebaseAutoMLLocalModel.Builder()
            .setAssetFilePath("automl/manifest.json")
            .build();

    FirebaseVisionOnDeviceAutoMLImageLabelerOptions.Builder optionsBuilder =
            new FirebaseVisionOnDeviceAutoMLImageLabelerOptions.Builder(remoteModel)
                    .setConfidenceThreshold(0.8f);

    detector = FirebaseVision.getInstance().getOnDeviceAutoMLImageLabeler(optionsBuilder.build());

When I pass localModel to FirebaseVisionOnDeviceAutoMLImageLabelerOptions.Builder constructor, the image isn't shown or detected


Get CHANGELOG.md up to date, update README.md and build.sbt to be mor…

…e correct.

Retargeting to master

Hey, thanks for all your contributions! I've just merged gilt-master into master and thinking of dropping the gilt-master branch. Could you resubmit this PR against master? Also, I've just released v0.6.9 with your upgrade to jackson 2.7 see https://oss.sonatype.org/content/repositories/releases/com/gilt/jerkson_2.11/0.6.9/

Thanks for the release!


Add neuron mutation

It's currently hard to test since yane preferce to just remove all hidden neurons since we can train only one input and output.
We should definitely watch it again as soon as we can add more training data.

But sometimes a hidden neuron survives if there are a lot of output but only one input neuron


npm install warnings and a failing npm audit

$ nvm use 8
Now using node v8.15.0 (npm v6.4.1)
$ export NODE_ENV=production
$ npm install --ignore-optional
npm WARN<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>but none is installed. You must install peer dependencies yourself.
npm WARN<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>but none is installed. You must install peer dependencies yourself.
npm WARN<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>but none is installed. You must install peer dependencies yourself.
npm WARN<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>but none is installed. You must install peer dependencies yourself.
npm WARN The package truffle-assertions is included as both a dev and production dependency.
npm WARN The package truffle-flattener is included as both a dev and production dependency.
npm WARN optional SKIPPING OPTIONAL DEPENDENCY<EMAIL_ADDRESS>(node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for<EMAIL_ADDRESS>wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})

audited 196719 packages in 49.369s
found 1644 vulnerabilities (6 low, 1025 moderate, 610 high, 3 critical)
  run `npm audit fix` to fix them, or `npm audit` for details

When I ran npm audit, I got another error:
npm ERR! code ELOCKVERIFY
npm ERR! Errors were found in your package-lock.json, run  npm install  to fix them.
npm ERR!     Invalid: lock file's<EMAIL_ADDRESS>does not satisfy<EMAIL_ADDRESS>
npm ERR! A complete log of this run can be found in:
npm ERR!     /root/.npm/_logs/2019-02-26T01_52_37_837Z-debug.log

I'm sure most of these vulnerabilities are not relevant to this code, but I'm not sure what they even are because of that truffle-assertions error.
What is your plan for keeping dependencies up-to-date?

Thanks for the report, we will take care if it.

as part of this work.
please see if any tool can recognize unused packages and remove them.

PR to development: https://github.com/KyberNetwork/smart-contracts/pull/474
Some packages are removed:
solium
ethereumjs-abi
ethereumjs-tx
ethereumjs-util

Currently with master should use npm ci and not npm i
npm audit shows:
found 4 low severity vulnerabilities in 70208 scanned packages
4 vulnerabilities require manual review. See the full report for details.


[fix][#4313] syntax check error

Coverage decreased (-0.004%) to 84.978% when pulling b97beef5cf268c61e836d923797e9d63eca6dff0 on fix-4313 into 2f77c681bc3ff9cc3c026860c0d6a75d3eb90185 on master.


Silence unrecognized annotation processor option during incremental processing

Context
See #8128
Contributor Checklist

[x] Review Contribution Guidelines
[x] Make sure that all commits are signed off to indicate that you agree to the terms of Developer Certificate of Origin.
[x] Check "Allow edit from maintainers" option in pull request so that additional changes can be pushed by Gradle team
[x] Provide integration tests (under <subproject>/src/integTest) to verify changes from a user perspective
[ ] Provide unit tests (under <subproject>/src/test) to verify logic
[ ] Update User Guide, DSL Reference, and Javadoc for public-facing changes
[x] Ensure that tests pass locally: ./gradlew <changed-subproject>:check

Gradle Core Team Checklist

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation
[ ] Recognize contributor in release notes

Please have a look at the failing test.

Should be fixed.


flirt: match references without disassembly

this script: https://github.com/williballenthin/viv-utils/blob/master/viv_utils/scripts/show_flirt_references.py
shows how flirt references are embedded within instructions:
matching function: 0x40141e
  candidate match: 0x40141e: FlirtSignature("?")
  references:
  - 0x40141f: ??1exception@std@@UAE@XZ
    loc: 0x40141e
    delta: 0x1
    bytes: e900000000
             ^
    insn: jmp 0x00401423
    xrefs:
    - 0x401423
matching function: 0x40aeb2
  candidate match: 0x40aeb2: FlirtSignature("__fptrap")
  references:
  - 0x40aeb5: __amsg_exit
    loc: 0x40aeb4
    delta: 0x1
    bytes: e8969effff
             ^
    insn: call 0x00404d4f
    xrefs:
    - 0x404d4f
matching function: 0x403951
  candidate match: 0x403951: FlirtSignature("__snprintf_c_l")
  references:
  - 0x403965: __vsnprintf_c_l
    loc: 0x403964
    delta: 0x1
    bytes: e876eeffff
             ^
    insn: call 0x004027df
    xrefs:
    - 0x4027df
matching function: 0x405bfb
  candidate match: 0x405bfb: FlirtSignature("??3@YAXPAX@Z")
  references:
  - 0x405c00: _free
    loc: 0x405bff
    delta: 0x1
    bytes: e86cffffff
             ^
    insn: call 0x00405b70
    xrefs:
    - 0x405b70
matching function: 0x40c210
  candidate match: 0x40c210: FlirtSignature("??0?$_Complex_base@M@std@@QAE@ABM0@Z")
  references:
  - 0x40c212: __imp_??0?$_Complex_base@M@std@@QAE@ABM0@Z
    loc: 0x40c210
    delta: 0x2
    bytes: ff25a4d04000
               ^
    insn: jmp dword [0x0040d0a4]
    xrefs:
    - 0x40d0a4

if there's only a handful of instructions that are seen during references (e.g. call and jmp) then we can hardcode some basic logic to resolve references. like: "disasm from -1 and if is call, then ..., else disasm from -2 and if is jmp then ...".

in dc25e9da8d0134ba3c3ae1b2ba9d5de8a705ec7a we use zydis to disassemble backwards from the reference, looking for instructions with operands that start at the reference and point to valid memory. we pick the first candidate, which seems to work well, given that most call/jmp instructions are found 1-2 bytes before the reference.


Solution for pattern letter I in Java

Issue Id you have worked upon -
#307
Briefly explain your program logic -
Running 2 for loops - one for row and one for column and I'm taking the height as input from user and based on the condition if the row loop is 0 or equal to the height of the alphabet I'm printing "$" except for the middle position and else I'm printing "##".
Screenshots(Attach 2 screenshots of your own input and output) -
Attach here

Checklist:
Eg - If your code follow the below guidelines. Kindly change [] to [x]
All the conditions should be fulfilled for considering your code for merging -

[x] I have mentioned the question as comment in my solution file.

[x] My code follows the guidelines of this project.

[x] I have performed a self-review of my own code.

[x] I have commented my code.

x[] My code gives the correct output.

[x] I confirm that I have not copied the code from anywhere. In case its found that I have copied even after successful merge then I can be banned from the repository and hacktoberfest.

[x] I affirm that I strictly follow contributing guidelines and code of conduct.

@iravimandalia,
Happy to see your dynamic approach towards the problem.


To2NAF()api + use in scalar mul

Scalar multiplication as a gadget uses api.ToBinary() to decompose the scalar. We should implement and use api.To2NAF(). This should further lower the scalar mul number of constraints, and consequently the Groth16 verifier gadget for example.

Worth it only if scalars are scanned bit-by-bit and Select conditional used. Now, we used 2-bit windowed methods with Lookup2.


Adopt ESLint core sort-imports rule into import/order

The core eslint rule will support most TS usecases, but it won't support "import equals" and it won't allow different treatment of type/value imports.
That being said - there are so many different sorting rules and plugins honestly I wouldn't want to add an extension rule to ts-eslint.
There are better alternatives like import/order or simple-import-sort/imports for example.
We already made this mistake with the no-duplicate-imports rule (import/no-duplicates is a much better version, and we'll be deleting our version in the next major).
Originally posted by @bradzacher in https://github.com/import-js/eslint-plugin-import/issues/2520#issuecomment-1208750865

cc @bradzacher @ljharb
Let's continue the discussion here.

What features does the core rule have that we lack?
The only one I'm aware of off the top of my head is the ability to sort named imports within a single import (or possibly export) statement.

I think the important first task will be to thoroughly audit the core rule, and figure out what the actual missing feature comparisons are.

For me personally, I only need a ignoreMemberSort option, and it should be false by default.

I think that you mean the reverse? a enforceMemberSort option that's false by default?

I think that you mean the reverse? a enforceMemberSort option that's false by default?

That would be great, I just want to point out how ESLint core handle this in sort-imports rule.

@ljharb Are we in agreement? (Is this change accepted? I'd like to work on this, if so.)

I'd first like to understand what are all the feature gaps - if we're trying to replace the core rule, then we'd need to account for all of its use cases.

I'd first like to understand what are all the feature gaps - if we're trying to replace the core rule, then we'd need to account for all of its use cases.

Did you mean https://eslint.org/docs/latest/rules/sort-imports#options?

Yes, and in particular, the use cases provided for by the various combinations of options.

Yes, and in particular, the use cases provided for by the various combinations of options.

So I'm still not for sure what's the next action to do? Maybe what options should be provided?

One thing I would not like to see is for import/order to adopt the behavior of sort-imports where sorting by member syntax appears to be mandatory and memberSyntaxSortOrder, if provided, must be an array containing all four values. I don't understand why enforcing a specific ordering between imports with a single named import and imports with multiple named imports is desirable, much less mandatory.
Aside from the mentioned ignoreMemberSort, I guess the other option that sort-imports has that import/order does not is ignoreDeclarationSort: import/order lets you sort by import path, but not by import name (though personally I'm not sure sorting by import name makes much sense).

The next action is "research" :-) someone needs to do the work to figure out an exhaustive list of what is possible with the core rule, and with the import rule, and then figure out how we can close the gap.
@ehoogeveen-medweb yes, I definitely agree that it's better that we're more flexible.
The main thing is, that if we provide a migration path for every user of sort-imports, then eslint will likely deprecate the rule and point people to us instead - that seems like a useful goal.

One thing I would not like to see is for import/order to adopt the behavior of sort-imports where sorting by member syntax appears to be mandatory and memberSyntaxSortOrder, if provided, must be an array containing all four values. I don't understand why enforcing a specific ordering between imports with a single named import and imports with multiple named imports is desirable, much less mandatory.

So there really isn't a lot of overlap between the two, but sorting names inside a named import would be a nice `enhancement.

Yes adding a member sort alphabetically is a very good choice.
There is also one good functionality in sort-imports, which allows you to specify memberSyntaxSortOrder, and sometimes it is mandatory because it looks good if all the multiple members are in the bottom ( sort by import path again ).
Currently, I can not use that because it conflicts ( import is using a path where sort-imports uses a name )

The issue I observed is that when import/order perform auto fix, the named import are sorted with type comes first. e.g.:
import { type $Else,type $Then, type IsBigint, testType } from '../index.js'

But VSCode organize import will sort them with type comes last:
import { testType, type $Else, type $Then, type IsBigint } from '../index.js'

It would be great if they are consistent.


readData.json

Used pretty frequently in these hurricane vizzies so makes sense to include in the package. Wasn't sure if mimetype needed to be included. I believe it's mimetype/javascript?

Coverage decreased (-0.2%) to 73.712% when pulling 73a4dc49a7ce831663a53ce0add231b89176fb86 on lindsaycarr:master into c88ccee1981ff96ae6fe237447d55bb3c41306b0 on USGS-VIZLAB:master.

I guess I'm not quite sure what exactly mimetype is doing here. In some readData functions it is a control for how to read the type of data, but for json, there's only the one way.

I think mimetype would mostly be useful here: https://github.com/USGS-VIZLAB/vizlab/blob/master/R/readData.R#L200-L216 to help with routing the default readData - adding it to that lookup would allow vizlab users to specify mimetype only and have the reader get discovered by this function.

Coverage decreased (-0.4%) to 73.516% when pulling 3739d46056f0566a49cc385bad20945592b4b00c on lindsaycarr:master into c88ccee1981ff96ae6fe237447d55bb3c41306b0 on USGS-VIZLAB:master.

so would get added here: https://github.com/USGS-VIZLAB/vizlab/blob/67e4a89cb839c9663d8533de996de4e757c5eb76/inst/mimetypes.default.yaml to match the json reader to the mimetype.
i'm seeing application/json for json mimetype (https://stackoverflow.com/a/477819/3203184)

hmmm application/javascript is what I saw in hurricane-irma: https://github.com/USGS-VIZLAB/hurricane-irma/blob/master/viz.yaml#L353-L361

That was a hack (at least it was in Harvey) because we didn't have a proper json reader!

ah OK, so it just propagated through to maria

https://github.com/USGS-VIZLAB/hurricane-matthew/blob/master/viz.yaml#L219

Coverage decreased (-0.4%) to 73.516% when pulling 6bd349df993157b9fa80b3909e0ec419b4d148fa on lindsaycarr:master into c88ccee1981ff96ae6fe237447d55bb3c41306b0 on USGS-VIZLAB:master.


Error with nanopolish variants

I'm encountering an error when running nanopolish vcf2fasta.
nanopolish vcf2fasta -g /Sample/Ref/annotation/NC_000964.3.fa /VCF/MW01_Q9_variants_polished.*.vcf > /Sample/nanop
olish/MW01/fasta/ref-A/MW01_Q9_polished_genome.fa
[E::fai_build_core] Format error, unexpected "#" at line 1
error: could not detect polishing window from input file VCF/MW01_Q9_variants_polished.NC_000964.3:0-50200.vcf
I tried running nanopolish variants using the --consensus flag but received a similar error.
nanopolish variants --verbose --faster --consensus -o /Sample/nanopolish/MW01/fasta/polished.vcf
-w ":0"
-r /Sample/Q9Filter/MW01/MW01_Q9.fq
-b /Sample/samtools/MW01_Q9_polished.NC_000964.3_A.sorted.bam
-g /Sample/Ref/annotation/NC_000964.3.fa
[E::fai_build_core] Format error, unexpected "#" at line 1
Segmentation fault
Any advice you can offer would be much appreciated!

[E::fai_build_core] is a message that the FASTA indexing step prints out. This should only be run on the reference genome -g /Sample/Ref/annotation/NC_000964.3.fa, so it makes me suspect there is a problem with your reference.
Thanks
Jared

When I run that command, it returns:
/ # head /Sample/Ref/annotation/NC_000964.3.fa
##gff-version 3
#!gff-spec-version 1.21
#!processor NCBI annotwriter
#!genome-build ASM904v1
#!genome-build-accession NCBI_Assembly:GCF_000009045.1
##sequence-region NC_000964.3 1 4215606
##species https://www.ncbi.nlm.nih.gov/Taxonomy/Browser/wwwtax.cgi?id=224308
NC_000964.3	RefSeq	region	1	4215606	.	+	.	ID=id0;Dbxref=taxon:224308;Is_circular=true;Name=ANONYMOUS;gbkey=Src;genome=chromosome;mol_type=genomic DNA;strain=168;sub-species=subtilis
NC_000964.3	RefSeq	gene	410	1750	.	+	.	ID=gene0;Dbxref=GeneID:939978;Name=dnaA;gbkey=Gene;gene=dnaA;gene_biotype=protein_coding;locus_tag=BSU00010
NC_000964.3	RefSeq	CDS	410	1750	.	+	0	ID=cds0;Parent=gene0;Dbxref=Genbank:NP_387882.1,GeneID:939978;Name=NP_387882.1;Note=binds to the dnaA-box as an ATP-bound complex at the origin of replication during the initiation of chromosomal replication%3B can also affect transcription of multiple genes including itself.;gbkey=CDS;gene=dnaA;inference=ab initio prediction:AMIGene:2.0;product=chromosomal replication initiator protein DnaA;protein_id=NP_387882.1;transl_table=11
Thank you so much for your time and help!

That is a GTF file, your reference genome should be a FASTA file.

Thank you! I'm trying it now and will get back to you if I have further issues.
Thanks again for your help!

No problem


ODL service not starting for Ubuntu 14.04

Using the new Docker-based Beaker tests for Ubuntu 14.04
[~/puppet-opendaylight]$ bundle exec rake ubuntu_1404_docker

Everything seems to work except for starting ODL's service via Upstart.
Failures:

  1) opendaylight class testing install methods should work idempotently with no errors
     Failure/Error: apply_manifest(pp, :catch_failures => true)
     Beaker::Host::CommandFailure:
       Host 'ubuntu-1404-docker' exited with 6 running:
        puppet apply --verbose --detailed-exitcodes /tmp/apply_manifest.pp.KRCklq
       Last 10 lines of output were:
        Info: /Stage[main]/Opendaylight::Config/File[org.apache.karaf.features.cfg]: Filebucketed /opt/opendaylight/etc/org.apache.karaf.features.cfg to puppet with sum 2a4fb152cf5561dfca0ffec6de946602
        Notice: /Stage[main]/Opendaylight::Config/File[org.apache.karaf.features.cfg]/content: content changed '{md5}2a4fb152cf5561dfca0ffec6de946602' to '{md5}a6974cc13166b3e24a819a4ba9158067'
        Notice: /Stage[main]/Opendaylight::Config/File[org.apache.karaf.features.cfg]/owner: owner changed 'root' to 'odl'
        Notice: /Stage[main]/Opendaylight::Config/File[org.apache.karaf.features.cfg]/group: group changed 'root' to 'odl'
        Info: Class[Opendaylight::Config]: Scheduling refresh of Class[Opendaylight::Service]
        Info: Class[Opendaylight::Service]: Scheduling refresh of Service[opendaylight]
        Error: /Stage[main]/Opendaylight::Service/Service[opendaylight]: Could not evaluate: undefined method `[]' for nil:NilClass
        Notice: /Stage[main]/Opendaylight::Service/Service[opendaylight]: Triggered 'refresh' from 1 events
        Info: Creating state file /var/lib/puppet/state/state.yaml
        Notice: Finished catalog run in 601.72 seconds

     # /home/daniel/.gem/ruby/gems/beaker-2.29.1/lib/beaker/host.rb:311:in `exec'
     # /home/daniel/.gem/ruby/gems/beaker-2.29.1/lib/beaker/dsl/helpers/host_helpers.rb:73:in `block in on'
     # /home/daniel/.gem/ruby/gems/beaker-2.29.1/lib/beaker/shared/host_manager.rb:115:in `run_block_on'
     # /home/daniel/.gem/ruby/gems/beaker-2.29.1/lib/beaker/dsl/patterns.rb:35:in `block_on'
     # /home/daniel/.gem/ruby/gems/beaker-2.29.1/lib/beaker/dsl/helpers/host_helpers.rb:63:in `on'
     # /home/daniel/.gem/ruby/gems/beaker-2.29.1/lib/beaker/dsl/helpers/puppet_helpers.rb:469:in `block in apply_manifest_on'
     # /home/daniel/.gem/ruby/gems/beaker-2.29.1/lib/beaker/shared/host_manager.rb:115:in `run_block_on'
     # /home/daniel/.gem/ruby/gems/beaker-2.29.1/lib/beaker/dsl/patterns.rb:35:in `block_on'
     # /home/daniel/.gem/ruby/gems/beaker-2.29.1/lib/beaker/dsl/helpers/puppet_helpers.rb:398:in `apply_manifest_on'
     # /home/daniel/.gem/ruby/gems/beaker-2.29.1/lib/beaker/dsl/helpers/puppet_helpers.rb:476:in `apply_manifest'
     # ./spec/spec_helper_acceptance.rb:72:in `block in install_odl'

  2) opendaylight class testing install methods Service "opendaylight" should be running
     Failure/Error: it { should be_running }
       expected Service "opendaylight" to be running

     # ./spec/spec_helper_acceptance.rb:97:in `block (2 levels) in generic_validations'

  3) opendaylight class testing install methods Process "java" should be running
     Failure/Error: it { should be_running }
       expected Process "java" to be running

     # ./spec/spec_helper_acceptance.rb:126:in `block (2 levels) in generic_validations'

#116 should cover this :+1:


any plans to run digest cycle in a web worker?

Feature Request / Road Map
Any plans to include ability to run digest cycle in a web worker (in 1.x)? something like http://slides.com/bahmutov/run-digest-cycle-in-web-worker#/

There are no plans, and such wide-ranging architecture changes are out of scope for AngularJS.

I agree with @Narretz.
Besides, just having the Scope $digest run in a web worker won't work, if your app doesn't run in the web worker too, because the type of data you can send over is limited. So, in order to get proper web worker support, we need to run the whole app on the web worker and just have the DOM-related parts of the framework live in a separate script that runs on the page (not the web worker) and is able to communicate with the web-worker bit. Considering how tightly AngularJS's $compile is coupled to the DOM, this would require a heavy refactoring of the internal logic. (Actually, this is already done. It's called Angular (2+) 😛)
That said, for AngularJS, it makes more sense to run specific, computationally heavy tasks on a web worker imo. AngularJS doesn't have to know anything about this - you can implement it independently.


Cannot generate time series files for all variables

Trying to generate time series files for all variables in a set of input files. With ncclimo, this is accomplished by simply omitting the -v command line option.
Unfortunately, this is not possible in zppy because zppy will always add that option and automatically populate it with an atmosphere default list.

@golaz It looks like climo already had the ability to generate all variables, by specifying "" for vars. I do the same for ts in #453.


fix: type when merging optional properties of a record

fix #451

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#452  👈
#450
#449
#448
#447
#446
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @RebeccaStevens and the rest of your teammates on  Graphite

Merge activity

May 19, 6:59 AM EDT: @RebeccaStevens started a stack merge that includes this pull request via Graphite.


fix: invalid macro names

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: mrgian
Once this PR has been reviewed and has the lgtm label, please assign leogr for approval. For more information see the Kubernetes Code Review Process.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Welcome @mrgian! It looks like this is your first PR to falcosecurity/testing 🎉

LGTM label has been added.  Git tree hash: c38ea3712cfebd8ed7b4714fb651c43ab524629a


Added info on GoStudyGroup-India

[x] Tested page build and visual elements with Hugo
[x] Tested all links

Wooooo! I'm super excited about this, thank you for adding GoStudy Group India to the site! 🎉


FAQGen Megaservice

Description
This PR introduces FAQGen Megaservice in GenAIExamples. Dependent on PR 318
 in GenAIComps
Issues
n/a
Type of change
List the type of change like below. Please delete options that are not relevant.

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds new functionality)
[ ] Breaking change (fix or feature that would break existing design and interface)

Dependencies
List the newly introduced 3rd party dependency if exists.
Tests
Test files to test on Xeon and Gaudi nodes

CI for this image only able to be test after https://github.com/opea-project/GenAIComps/pull/318 merged.

CI for this example only able to be test after opea-project/GenAIComps#318 merged.

@chensuyue I have the tests updated to pull the Comps from the PR itself, the tests run fine locally on Xeon and Gaudi. Not sure why they are failing here.

The UI code (React, Svelte) is almost just renamed and copied from the content of docSum. So, what is the purpose of FAQGen? What improvements have been made, and are these improvements necessary to be provided to users as a complete repository? If the modifications are minor, can improvements be made in docSum or explained in docSum?

@WenjiaoYue , Since FAQGen needs special prompts to generate FAQs from the data, it is currently implemented as a different example. There is an ongoing discussion on consolidating the LLMs in upcoming releases.  Later, we can update docsum to do summarization, FaqGen, meeting summary and other data insights from the same example.


docs: fix tip formatting

📚 Description
Fix formatting of https://nuxt.com/docs/getting-started/data-fetching#usefetch docs by removing one to many : in tip block.

Summary by CodeRabbit

Documentation

Enhanced explanations of data fetching in Nuxt, focusing on useFetch, useAsyncData, and $fetch.
Expanded sections on the necessity of using useFetch and useAsyncData to prevent issues like double fetching.
Introduced a new section on Suspense for managing asynchronous data.
Added examples for useFetch and useAsyncData, including handling loading states and caching.
Included detailed explanations on passing headers, cookies, and serialization of data.
Added practical use cases in the recipes section, such as consuming Server-Sent Events (SSE).

thank you ❤


[web] Switch to v9 compat libaries

Currently we recommend that users install the v8 Firebase SDK:
<script src="https://www.gstatic.com/firebasejs/8.6.1/firebase-app.js"></script>

With v9 released which no longer supports the window object, we will need to switch to the compat versions across all plugins.
<script src="https://www.gstatic.com/firebasejs/9.0.2/firebase-app-compat.js"></script>

The API is the same but uses the v9 SDK under the hood.

FYI https://github.com/FirebaseExtended/flutterfire/issues/6967

Hey @ChristianEdwardPadilla, I'm happy to keep this channel updated with a list of packages completed, and the package that is currently being worked on so you guys can track progress.
Completed
Core
Analytics
App Check
Firestore
Auth
Database
In Progress
Functions (very near completion)
To Be Completed
Performance
Messaging
Remote Config
Storage
We're happy for you to help if you wish 😄. You just need to branch off v9/core branch, select a package to be completed, and update this channel/open draft PR 👍

Has V9 support been added to the main FlutterFire branch? I am trying to implement it in a Flutter project and was wondering if there has been any documentation added for using V9 modular imports for a Flutter project. Thanks!

@m6keller We have all the PRs in review. Once they're approved, we'll merge into v9/core branch and test them all together. It won't be part of the main release just yet, but it will be available for users to test out.

@russellwheatley Ok, thanks!

Seems this is done or obsolete since https://github.com/firebase/flutterfire/pull/8235? Great work!

Yes, we've decided to make it part of the normal release cycle considering our CI was passing, and it was the underlying implementation that had changed, not the user facing API. Except for auth and messaging which have breaking changes and will both have a major version change.

@russellwheatley Wanting to followup on this thread. I am wondering how the flutter web plugins can pick up the js defined functions for interop? The ES6 exports symbol exports the js to other js files but doesn't define them on window for the flutter web plugin to interop with correct?

Answered my own question! the *-compat.js Firebase files handle exporting on window :)


chore(package): update dependencies

Codecov Report

Merging #11 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #11   +/-   ##
=======================================
  Coverage   73.73%   73.73%
=======================================
  Files          11       11
  Lines         217      217
  Branches       33       33
=======================================
  Hits          160      160
  Misses         45       45
  Partials       12       12

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 0469c62...3bf67a0. Read the comment docs.


Class Inheritance

Well, there is another one.
class "Main"
function Main:handleEvent()
    self:onAnyEvent()
end
Main:seal()

class "Parent" extends "Main"
function Parent:onAnyEvent()
    print("Hey from Parent")
end
Parent:seal()

class "Child" extends "Parent"
function Child:onAnyEvent()
    print("Hey from Child")
    print( tostring( self.super ) )
end
Child:seal()

c = Child()
c:handleEvent()

You would expect that when c:handleEvent() is executed "Super Parent blah blah" would be output to the screen... in-fact 'nil' is output. What?
To further confuse things the Parent event is never called, this is not some back and forth action. It is simply skipping over Parent:onAnyEvent().
This one... might take a while.

I think the problem originates from the following:
Instance proxies only set the super of the instance to number 1 (lowest) when the method being called is a getter, if its just a function they don't care. Therefore the super is going unchanged which explains why its nil (because the Main class has no super and the call starts from that point).
To fix this I will be returning a wrapper from the instance proxies much like the supers do.
This might not be the cause and this fix might not work, we'll see

This fix was successful in fixing this particular bug.
Before committing I will check to make sure it doesn't resurrect any old bugs.

All good, closing


What about changing the output path to an *.ifc file when /module:export is specified?

I would like to know this because I want to have it output to $(OutputPath) not sure why it does not default to that in the first place???

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

ID: 4938a042-e5db-4f9c-2288-930b904e888c
Version Independent ID: 6db1e386-22e4-4940-cc2c-bdeaa5883299
Content: How to: Change the build output directory - Visual Studio
Content Source: docs/ide/how-to-change-the-build-output-directory.md
Product: visual-studio-windows
Technology: vs-ide-compile
GitHub Login: @gewarren
Microsoft Alias: gewarren

@AraHaan Thank you for the feedback.
This sounds more like a feature request then an issue with the documentation.
Please use the Suggest a Feature option in the Visual Studio forums to get the most traction.

Also it seems that program db for edit and comtinue (when module:export is set) causes the compiler to ICE as well saying it is not implemented yet.
Also is there a way that (for the reason of vs not having a way to provide module:export automatically when it sees someone type export module <module name> to if the compiler reads that and sees it is not specified; to warn that it was not and to have it then export then as of it was specified? For the case of the option not existing yet in vs2019 that I know of. But ye I think each one can be suggested individually there. If only there was a way to suggest it from my iphone as rn my laptop does not have internet rn (I use public wifi rn to go on it to do just that). Unless you guys can help file them there for me?


[ENGINE] Fix build failures on newer GCC versions

Newer GCC versions (13 onwards) have changed the transitive includes of standard library headers causing code that previously worked "accidently" to no longer compile. In this specific case I was getting errors compiling files due to not finding std::remove. This PR adds #include <algorithm> where required to fix the issue.

cc @Victor-Jung

Thanks for your fix !


Reliably, destructively, replace Tasks

Tasks which were in the state TASK_LOST, weren't being handled properly by destructive killing.  They weren't getting marked as permanently failed because they were being detected as not needing to be killed because they weren't TASK_RUNNING.
There was also a conflation between Tasks being in states which required recovery and being in a terminal state.  These have been clarified.
Integration tested by having Kafka consume this change, terminated a AWS instance, had a Broker go to TASK_LOST.  dcos kafka broker replace <id> worked as expected.  It did not work as expected before this change.
Note: test coverage goes from 79.3% to 79.6% in this PR.

@mesosphere-ci: retest this please


Allow retry of network requests

Clownflare seems to be randomly dropping connections from some networks The more domains are required to be verified in a request the more likely it is for the script to fail. While sometimes the problem happens early on I've mostly seen it on verifying the second or third domain. There doesn't seem to be any impact of excessive re-running of the script - a request for 4 domains went through after a bit over 100 tries, without sleeps in between.
As a quick workaround I've added the following in _do_request:
except SocketError as e:
      time.sleep(5)
      return _do_request(url, data, err_msg, depth)

With this a request for 14 names went through, at 13 retries unevenly spaced out.
Having something similar with a configurable amount of retries and maybe a default retry count of 3 (all my requests would've gone through with that) would help dealing with unreliable upstream.

:+1: for the issue
Recently, I got the following HTTP error from the server, my certificates got expired without any notice.
    signed_crt = get_crt(args.account_key, args.csr, args.acme_dir, log=LOGGER, CA=args.ca, disable_check=args.disable_check, directory_url=args.directory_url, contact=args.contact)
  File "/etc/letsencrypt/acme-tiny/acme_tiny.py", line 164, in get_crt
    certificate_pem, _, _ = _do_request(order['certificate'], err_msg="Certificate download failed")
  File "/etc/letsencrypt/acme-tiny/acme_tiny.py", line 46, in _do_request
    raise ValueError("{0}:\nUrl: {1}\nData: {2}\nResponse Code: {3}\nResponse: {4}".format(err_msg, url, data, code, resp_data))
ValueError: Certificate download failed:
Url: https://acme-v02.api.letsencrypt.org/acme/cert/xxx
Data: None
Response Code: 502
Response: {'type': 'urn:acme:error:serverInternal', 'detail': 'The service is down for maintenance or had an internal error. Check https://letsencrypt.status.io/ for more details.'}

I think I'd rather network interruptions raise a hard fail instead of blindly retrying multiple times, since significant retries can lead to banning/rate-limiting on networks that watch for spammy behavior.

As I was writing in the initial comment, the problem gets worse the more domains you have in a request - you typically can get 3-4 domains verified after a few tries, but if you have more the chance of having all verified successfully drops with each domain you add.
If I have 5 domains, and no retry capability in the script I need to run verification against all of them until all succeed. Assuming I need 20 tries to finish that (which in my experience is on the lower end when hitting this issue), and on average it drops out at the 3rd domain I end up with 60+ verification requests.
Now if the script has retry support it'll just retry for the failing domain, which - outside of very rare circumstances - will usually go through within 2-3 tries. So we have 60+ calls vs. less then 10 calls - having retry support in the script would significantly reduce the chance of getting banned or rate limited, and is far simpler than having to script the same logic in a wrapper around the script. Also, if you're hitting this problem with more then about 5 domains retry inside of the script is the only way to get a request through.


Fix headless window transparency

What does the pull request do?

Fixes rendering headless windows that have transparent backgrounds, to actually render as transparent.
What is the current behavior?

The background of the rendered bitmap is white, although the Window's Background is set to "Transparent".
This makes it so if the user wants a transparent background, they can use TransparencyLevelHint where it previously was never transparent.
What is the updated/expected behavior with this PR?

The background is transparent if specifying it with TransparencyLevelHint and Background="Transparent"
How was the solution implemented (if it's not obvious)?

Changed the TransparencyLevel to Transparent to allow for transparent rendering.
Checklist

[ ] Added unit tests (if possible)?
[ ] Added XML documentation to any related classes?
[ ] Consider submitting a PR to https://github.com/AvaloniaUI/avalonia-docs with user documentation

Breaking changes

Obsoletions / Deprecations

Fixed issues

@Rosentti,
Please read the following Contributor License Agreement (CLA). If you agree with the CLA, please reply with the following:
@cla-avalonia agree

Contributor License Agreement
Contribution License Agreement
This Contribution License Agreement ( “Agreement” ) is agreed to by the party signing below ( “You” ),
and conveys certain license rights to the AvaloniaUI OÜ ( “AvaloniaUI OÜ” ) for Your contributions to
AvaloniaUI OÜ open source projects. This Agreement is effective as of the latest signature date below.
1. Definitions.
“Code” means the computer software code, whether in human-readable or machine-executable form,
that is delivered by You to AvaloniaUI OÜ under this Agreement.
“Project” means any of the projects owned or managed by AvaloniaUI OÜ and offered under a license
approved by the Open Source Initiative (www.opensource.org).
“Submit” is the act of uploading, submitting, transmitting, or distributing code or other content to any
Project, including but not limited to communication on electronic mailing lists, source code control
systems, and issue tracking systems that are managed by, or on behalf of, the Project for the purpose of
discussing and improving that Project, but excluding communication that is conspicuously marked or
otherwise designated in writing by You as “Not a Submission.”
“Submission” means the Code and any other copyrightable material Submitted by You, including any
associated comments and documentation.
2. Your Submission. You must agree to the terms of this Agreement before making a Submission to any
Project. This Agreement covers any and all Submissions that You, now or in the future (except as
described in Section 4 below), Submit to any Project.
3. Originality of Work.  You represent that each of Your Submissions is entirely Your
original work. Should You wish to Submit materials that are not Your original work,
You may Submit them separately to the Project if You (a) retain all copyright and
license information that was in the materials as you received them, (b) in the
description accompanying your Submission, include the phrase "Submission
containing materials of a third party:" followed by the names of the third party and any
licenses or other restrictions of which You are aware, and (c) follow any other
instructions in the Project's written guidelines concerning Submissions.
4. Your Employer. References to “employer” in this Agreement include Your employer or anyone else
for whom You are acting in making Your Submission, e.g. as a contractor, vendor, or agent. If Your
Submission is made in the course of Your work for an employer or Your employer has intellectual
property rights in Your Submission by contract or applicable law, You must secure permission from Your
employer to make the Submission before signing this Agreement. In that case, the term “You” in this
Agreement will refer to You and the employer collectively. If You change employers in the future and
desire to Submit additional Submissions for the new employer, then You agree to sign a new Agreement
and secure permission from the new employer before Submitting those Submissions.
5. Licenses.
a. Copyright License. You grant AvaloniaUI OÜ, and those who receive the Submission directly
or indirectly from AvaloniaUI OÜ, a perpetual, worldwide, non-exclusive, royalty-free, irrevocable
license in the Submission to reproduce, prepare derivative works of, publicly display, publicly perform,
and distribute the Submission and such derivative works, and to sublicense any or all of the foregoing
rights to third parties.
b. Patent License. You grant AvaloniaUI OÜ, and those who receive the Submission directly or
indirectly from AvaloniaUI OÜ, a perpetual, worldwide, non-exclusive, royalty-free, irrevocable license
under Your patent claims that are necessarily infringed by the Submission or the combination of the
Submission with the Project to which it was Submitted to make, have made, use, offer to sell, sell and
import or otherwise dispose of the Submission alone or with the Project.
c. Other Rights Reserved. Each party reserves all rights not expressly granted in this Agreement.
No additional licenses or rights whatsoever (including, without limitation, any implied licenses) are
granted by implication, exhaustion, estoppel or otherwise.
6. Representations and Warranties. You represent that You are legally entitled to grant the above
licenses. You represent that each of Your Submissions is entirely Your original work (except as You may
have disclosed under Section 3 ). You represent that You have secured permission from Your employer to
make the Submission in cases where Your Submission is made in the course of Your work for Your
employer or Your employer has intellectual property rights in Your Submission by contract or applicable
law. If You are signing this Agreement on behalf of Your employer, You represent and warrant that You
have the necessary authority to bind the listed employer to the obligations contained in this Agreement.
You are not expected to provide support for Your Submission, unless You choose to do so. UNLESS
REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING, AND EXCEPT FOR THE WARRANTIES
EXPRESSLY STATED IN SECTIONS 3, 4, AND 6 , THE SUBMISSION PROVIDED UNDER THIS AGREEMENT IS
PROVIDED WITHOUT WARRANTY OF ANY KIND, INCLUDING, BUT NOT LIMITED TO, ANY WARRANTY OF
NONINFRINGEMENT, MERCHANTABILITY, OR FITNESS FOR A PARTICULAR PURPOSE.
7. Notice to AvaloniaUI OÜ. You agree to notify AvaloniaUI OÜ in writing of any facts or
circumstances of which You later become aware that would make Your representations in this
Agreement inaccurate in any respect.
8. Information about Submissions. You agree that contributions to Projects and information about
contributions may be maintained indefinitely and disclosed publicly, including Your name and other
information that You submit with Your Submission.
9. Governing Law/Jurisdiction. This Agreement is governed by the laws of the Republic of Estonia, and
the parties consent to exclusive jurisdiction and venue in the courts sitting in Talinn,
Estonia. The parties waive all defenses of lack of personal jurisdiction and forum non-conveniens.
10. Entire Agreement/Assignment. This Agreement is the entire agreement between the parties, and
supersedes any and all prior agreements, understandings or communications, written or oral, between
the parties relating to the subject matter hereof. This Agreement may be assigned by AvaloniaUI OÜ.
AvaloniaUI OÜ dedicates this Contribution License Agreement to the public domain according to the Creative Commons CC0 1.

@cla-avalonia agree


devicetree: add DT_COMPAT_ON_BUS()

And implement DT_ANY_INST_ON_BUS() in terms of it.
This makes some error messages quite a bit shorter by avoiding
UTIL_LISTIFY(), which has a nasty temper and tends to explode if not
treated gently.

rebased

@galak ping


add calculator of length of travers common tangent of circle

Proposal
(A clear and concise description of what the proposal is.)

i like to work on it


Request: Option to have kick messages deleted, as well as entry.

I appreciate the inclusion of the command to delete the entry message of beings that have been booted due to failing the captcha. I would like to be able to also auto-delete the removal messages (separate from the delete entry message option), as my channel is getting so inundated that the messages are disrupting the log. It's better with the entry messages removed, but I would like to be able to make it a non-event if you didn't notice while it was happening. Some people might like to leave them, which is why I think it should be a separate option.
Thank you very much for making Shieldy!

Hm, interesting. I'll see what I can do.

Should be working now.


python311Packages.tf2onnx: mark as broken

Description of changes
Broken because tensorflow is too old and does not support recent versions of protobuf.
Running phase: pythonCatchConflictsPhase
Found duplicated packages in closure for dependency 'protobuf':
  protobuf 4.24.4 (/nix/store/8g2k3idj2f4kbvra98clakdlcvsy6f2y-python3.11-protobuf-4.24.4)
    dependency chain:
      this derivation: /nix/store/r9fq9spwzn87ad0k4npbw487q2zbgryx-python3.11-tf2onnx-1.16.1
      ...depending on: /nix/store/73g093ny57lfgnrbx6lmvphj8y7j5826-python3.11-onnx-1.15.0
      ...depending on: /nix/store/8g2k3idj2f4kbvra98clakdlcvsy6f2y-python3.11-protobuf-4.24.4
  protobuf 4.21.12 (/nix/store/2lk63v57qnqp8n3ydvx0ja61ij2bxv35-python3.11-protobuf-4.21.12)
    dependency chain:
      this derivation: /nix/store/r9fq9spwzn87ad0k4npbw487q2zbgryx-python3.11-tf2onnx-1.16.1
      ...depending on: /nix/store/kngclwr5xpl63vwccpj05drfg60nfh5b-python3.11-tensorflow-2.13.0
      ...depending on: /nix/store/2lk63v57qnqp8n3ydvx0ja61ij2bxv35-python3.11-protobuf-4.21.12

cc @happysalada
Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

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


Ensure all service tree metadata and changes in metadata are synced to ADO work items

Requirement:  Ensure that all of the relevant service tree metadata is in ADO and the field values are updated when there are changes to metadata in service tree.
Service Partner Feedback:  Service teams keep bringing to our attention that the dates and state of their products in ADO are incorrect.
Azure SDK Stakeholders/TypeSpec Feedback:  The product launch dates and overall state of the product are not accurate which causes confusing and frustration in using the queries.
### Tasks
- [ ] See spreadsheet - https://microsoft-my.sharepoint.com/:x:/p/ladonnaquinn/ETD9YCt4cfxHlL4mC1KlVygBIQss1mm6NMIpu3_BdOJhJQ?e=fybges&nav=MTVfe0NFNEU1NTIwLUExRjYtNDRFNy1BRTI0LUVFRTRCMzlBNjg3Mn0.
- [x] When the product or service name metdata changes, also update the title of all of the existing ADO work items (triage, epic-product, epic-service, release plans).

Private preview date, public preview date and GA date are now synced from service tree to work items daily if it changes in service tree. RP name and Service RPs fields still require confirmation.

See spreadsheet

The ServiceTreeData tab doesn't have color green. If I understand correctly we need to wait until it is green before we should look into it, right?

The orange/gold rows require a change and there are GitHub issue links with requirement info and to track completion.

[ ] This issue was for the dates, which we can close now.  Praveen redesigned to handle the date format issue with ADO (which is not something he discovered in implementation) https://github.com/Azure/azure-sdk-tools/issues/7509
[ ] This is outstanding yet and we need to queue it up for a work session with engineering to discuss -  https://github.com/Azure/azure-sdk-tools/issues/7503
[ ] This request was to reduce duplication of data field values - https://github.com/Azure/azure-sdk-tools/issues/7508  I am not sure if this done yet, I will check.

Outstanding work will be tracked here - https://github.com/Azure/azure-sdk-tools/issues/7495


[WIP] Updates for bazel and the cloud-create script

Parameterizing Builds
More tweaks to cloud-create

Dev cluster is not functional at this point since elasticsearch is not loading  correctly.  Staging is functioning.

please test this

test this please

test this please