Possibility to download language translated patch

I would like to use the tool to download language translated patch (e.g. E-Business Suite patches). For example, I could download patch
35697293  with the following command:
java -jar oraclePatchDownloader-1.0.1.jar -u<EMAIL_ADDRESS>-p  -x 35697293 -t 226P -d .
but language translated patch require a "platform" value like for example 108L;Italian (I), 2L;French (F) as in the "old" getMOSPatch.
Would it be possible to add this feature?
Regards,
Marzio

I would like to use the tool to download language translated patch (e.g. E-Business Suite patches). For example, I could download patch 35697293 with the following command:
java -jar oraclePatchDownloader-1.0.1.jar -u<EMAIL_ADDRESS>-p -x 35697293 -t 226P -d .
but language translated patch require a "platform" value like for example 108L;Italian (I), 2L;French (F) as in the "old" getMOSPatch.
Would it be possible to add this feature? Regards, Marzio

i will look on it .... should not be a big issue, but i never worked with the tanguage translated patches of oracle.

I checked the fixed version, works for me now .
you can select a list of -t --plattforms now, comma separated.. for your example
java -jar oraclePatchDownloader-1.0.1.jar -u<EMAIL_ADDRESS>-p -x 35697293 -t 226P,4L,2L -d .
can you please try and close afterwords if its ok?

Hi, and sorry for the delay in my answer. I could test the new version only today and It works fine for me using comma separated platform codes. Thank you for adding this feature!


typo in Readme.md

In Getting Started:
FlowRouter.redirect = '/notFound';
Should read:
FlowRouter.Auth.redirect = '/notFound';
Thanks for the package.

thank you ^^


Kotlin scripting

Some thoughts on how we could use kotlin scripting in lantern to replace the current JSON + groovy scripting config files.
Vanilla JSON data packs will still be supported, everything else will be replaced by this kind of scripts. It's more powerful and it reduces the amount of work we have to put into parsing the config files. There will always a learning curve to write configs/scripts, then it's probably better to invest the time in a easy to use (but powerful) scripting API.
It also allows you to use a IDE (intellij) to write these scripts, providing a easy to use environment to write these scripts isn't in the scope of this PR. This will be a separate project/PR in the future. This is purely for scripting capabilities.
Currently built on top of the behaviors branch because there were changes I needed.

Just thought of this: https://kotlinlang.org/docs/reference/whatsnew13.html#scripting-update
I don't what useful for you and what not.


Parsing error loading recipe supertools:platinum_sickle

Describe the bug
Error when loading the mod:
Versions
Forge version: forge-1.15.1-30.0.19
Supertools version: 1.0b_1.15.1
To Reproduce
Steps to reproduce the behavior:

Start the server
See the log
find this: ```text/plain
[Server thread/ERROR] [minecraft/RecipeManager]: Parsing error loading recipe supertools:platinum_sickle
com.google.gson.JsonSyntaxException: Unknown item 'simplyplatinum:platinum_ingot'

**Expected behavior**
Either the recipe should load, and a dependency mod is required, or the recipe is invalid.

**Additional context**
The mod still works, but this should not happen.

It happens, as the platinum sickle is a addon for the mod "Simple Platinum". Super Tools does not have a platinum ingot on its own.


Solution: Unclear how to build Error Handling for Jobs

This extra documentation is supposed to show a user of this library on how to build a supervision tree for all cron jobs.
Solves #158

Coverage remained the same at 98.361% when pulling 089863e24026b3c27bcb745c7ae24ab147e3ffb1 on jshmrtn:feature/supervised_error_handling_docs into a70031294cbb46d63edb49524c6f014453ef46ae on c-rack:master.

@c-rack This depends on if you like the proposition in #162. Otherwise it needs to be in README.

Coverage remained the same at 98.333% when pulling 68806bf451010293bffe65c1efef6719fc5596fd on jshmrtn:feature/supervised_error_handling_docs into 845f2a73e76bf5713daaf0bc6f7834039a0e570b on c-rack:master.

Coverage remained the same at 98.333% when pulling 5d0b8b5042c1995b32308c19f568fdbb5e2a5b51 on jshmrtn:feature/supervised_error_handling_docs into 845f2a73e76bf5713daaf0bc6f7834039a0e570b on c-rack:master.

Coverage remained the same at 98.333% when pulling 5d0b8b5042c1995b32308c19f568fdbb5e2a5b51 on jshmrtn:feature/supervised_error_handling_docs into 845f2a73e76bf5713daaf0bc6f7834039a0e570b on c-rack:master.

Coverage remained the same at 98.333% when pulling 5d0b8b5042c1995b32308c19f568fdbb5e2a5b51 on jshmrtn:feature/supervised_error_handling_docs into 845f2a73e76bf5713daaf0bc6f7834039a0e570b on c-rack:master.


Create example on using multiple save results

possible prerequirement: improve python client code to support this

There is now support in the python client for this: https://github.com/Open-EO/openeo-python-client/issues/391


Add setting to support different file extension

Would like to be able to us "ts" instead of "tsx" or "js" instead of "jsx"
Fixes: https://github.com/yeet-bix/create-react-component-vscode/issues/12
Create a PR for it 😉

Sweet! 🥳


Investigate Kumu mapping of the diagram

experiment with having the data migrated into Excel and try kumu for mapping this information.
https://www.kumu.io/

I created a diagram in parallel using Excel as a data source and kumu to render. The results were impressive.
https://www.kumu.io/michaelruminer/vc-spec-map#map-GLvw45PH
I will at least add in the excel spreadhseet to the repo which can render on demand when uploaded to kumu a new map. If kumu becomes the new render format then I will likely add the full json backup. which memorializes the render configurations and not just the data. A promotion strategy would need to be developed but that is for a different issue if it were to come to pass.
The downside is it is bound to kudu and to have a persistent rendering of it would need to be under a kudu account. I'll ask the DIF admin(s) if there is a DIF kudu account (a free one will work) vs using a personal account. Then maintainers could be added as contributors to a new workspace. This would remove the downside.
The upside is that it could be much more easily maintained via a CSV or excel file and republished to kumu on release.

As of release v1.2.0 the map is being released to kumu.io and the former draw.io diagram has been obsoleted and deleted from the workspace.
As of the time of this comment the deployed path under kumu is https://www.kumu.io/michaelruminer/vc-spec-map
This comment closes this issue.


Partial performance improvement for #114

I was starting to work towards #94 but hit some performance issues and found open issue #114. I took a couple hours to understand the code then took a shot at minimizing the number of git calls (I think I've reduced the 5 or 6 calls to 1 or 2).
I didn't delete as much code from GitExtensions.cs as I'd like to since there were a lot of unit tests using the code. If this PR looks good, I can also reduce the code in GitExtensions.cs (and GitExtensionsTests.cs) to clean up the bit of duplication between VersionOracle.cs and GitExtensions.cs remaining.
Note, there are a couple code clean up commits in the PR. The performance improvement commit is in the middle. I tried to be pretty detailed in the commit message on that commit.

Thanks, @robmen! I look forward to reviewing this... probably tomorrow.
Did you happen to measure the perf impact of the change? Was the perf on your repo bad before? If so, do you attribute it to the number of projects building or the number of commits that are counted when calculating the git version height?

I didn't measure exactly (it was late) but each "call" to git to find the version file would end up walking the git tree to find the matching version. It isn't just calculating the height. There was lots of duplicate work when I was stepping through debugger.
I found it because the VersionOptions were recreated and compared with the working tree in many places. I was experimenting with a feature to override the BuildNumberOffset passed in via MSBuild property (conversation for a different pull request). I stopped counting after finding 5 different instances VersionOptions (all read from the same version.json) whereI had to overwrite the offset to make it "stick". That's how I ended up walking all the way down the tree in the debugger and why I created a repo with a bunch of commits to see if I was seeing things correctly and walking down even deeper loops in the debugger and then finding performance issue #114 on GitHub and finally saying to myself, "Oh, this is doing a lot more work than necessary" (and this is a crazy run on sentence).
I believe this change also has the possibility to reduce a lot of code. I left it all in because there were so many unit tests using the code. I didn't know if you wanted the code factored that way (for example, if the NB.GV assembly was being used for other things). Basically everything is public so hard to know the desired surface area. :smile:

Basically everything is public so hard to know the desired surface area.

I had this idea that the library that the MSBuild task calls into would be itself useful. So ya, a lot is public.
But what really needs to be public is whatever the MSBuild task, the two ps1 scripts, and the NPM module needs to function.

That's exactly what it looked like. And the "API" provided by that NB.GV assembly is pretty friendly for one-off requests but if you need to do several operations (like the MSBuild task does) you end up with lots of repeat (and potentially costly) git work. As you'll see my change reduces calls to the NB.GV assembly.
If you don't want the public surface going forward, I can reduce the overall code count quite a bit. But that's up to you. So far, it sounds like I guessed correctly. 😉

This PR has test failures that should be dealt with. One of them is #125 and can be ignored. But there is another test failure that I haven't seen before on this PR build.

I do not understand why these failures are happening on the build machine but not locally. I'll make the changes above and try to reproduce the issue.

Actually, I can reproduce with all the latest changes all integrated. Investigating now.

Okay, I simplified this PR down to just the optimization (which is the most important part). It should be much easier to see changes now. Good call.
Also, I now understand how GitExtensions.cs has an API surface that is larger than what NB.GV needs and that explains a lot of the "dead code" I was tripping across.

Thanks, @robmen. This iteration looks much easier to assess. 🙂

Thanks again.


remove auto_start_request parameter

What problem is this trying to fix -- PyMongo 3.x compatibility?

yes, it's for pymongo 3.0 compatibility.

Got it.
Flask-PyMongo is not (yet?) PyMongo 3.x compatible. I've released 0.3.1 today which locks the requirements back to the 2.x series of PyMongo, but if you need 3.0, that won't help you. As time permits (or as people submit patches that maintain 2.x and add 3.x compatibility) I'll eventually cut a release that works with 3.x, too.

FYI by accepting this PR you would make Flask-PyMongo compatibile PyMongo 3.0. As far as I can tell, PyM3 is backward compatible except for this nuisance (they deprecated a lot of things though, although according to their own word the old API will be supported at least until 4th generation drivers).
My Flask-PyMongo clone, which has this line removed, runs 561 tests on MongoDB 3.0 w/PyMongo 3.0.1. However, being Flask-PyMongo requirements pinned to PyMongo 2.x, I cannot release  a PyMongo 3.0 compatible Eve package.

Maybe this should be superceeded by #63


Please add group by route function

please help add group by route function. it would be easy for organize our route if we have big project and a lot of route. anyway thanks you for working hard on this package

Thanks for suggesting, will accept a PR, not so free in 2025 so can't promise if I can push this feature on my own.


Stack creation error: Requires capabilities : [CAPABILITY_NAMED_IAM]

Hi Team,
I am facing issue while writing CF template to create rolese as it now requires "CAPABILITY_IAM" parameter. i got lot of answers over how to slve this by CLI but am looking for answer of what code do i include in my CloudFormation template to get over this.
Thanks.
Below is my code that fails while creating stack using CF yaml template.
AWSTemplateFormatVersion: '2010-09-09'
Description: 'Lambda Function from Cloud Formation by Shyam - Code in S3 ZipFile'
Resources:
Lambda1:
Type: "AWS::Lambda::Function"
Properties:
Code:
S3Bucket: "test-source-bucket"
S3Key: "lambda-function.zip"
Description: Test with Cloud Formation
FunctionName: lambda-function
Handler: lambda_function.lambda_handler
## enter your role arn here
Role: arn:aws:iam:::role/service-role/role-name
Runtime: python2.7
Steps to reproduce the issue:

Run the above YML template using CF.

Observed result:

It looks like you are using the CloudFormation console to deploy this stack, is this correct?
The documentation has the following instructions for granting this capability via the console:

In the AWS CloudFormation console, on the Review page of the Create Stack or Update Stack wizards, choose I acknowledge that this template may create IAM resources.

This should fix this capability issue.


GateIo incomplete order book

Describe the bug
Gate io has incomplete order book

Steps To Reproduce
// A concise description of the steps to reproduce the buggy behavior:
run orderbook --live and check against exchange order book
Here are the steps to reproduce the issue (see attachments in the section below):
start any strategy and run orderbook of gate io
Screenshots
// If applicable, add screenshots to help explain your problem.
Release version
dev-1.0.0
Attachments
// Please attach your config file and log file to help us debug. It would be difficult for us to help you without those!
WARNING: Do NOT publish any exchange API keys or your wallet's private key. Whoever has access to them may steal your assets!
Optional: your discord username:

This issue is still the same issue as https://github.com/hummingbot/hummingbot/issues/4710
Based on the comments, it seems there is still a desynchronization issue.
Could further efforts be made to continue fixing this issue?
This issue made many gate io markets unusable for me as I rely mostly on the order book depth.
I am not familiar with the connector part of the code yet so if can let me know a rough idea of what might be the problem and I can also try to debug from there.
I tried further increasing the past diff window but it does not help.
https://github.com/hummingbot/hummingbot/pull/4756

Hi @leastchaos, just checking again if this is still an ongoing issue? We looked in this issue on our staging branch and seems to be working ok atm. Please let us know if this persists. Thank you


New package: SimpleMock v0.1.0

UUID: a896ed2c-15a5-4479-b61d-a0e88e2a1d25
Repo: https://github.com/christopher-dG/SimpleMock.jl.git
Tree: 3de42e4532b7c38dbac702a188212b07c1007032
Registrator tree SHA: f50e50c1d2a1b9694b1d5749fdb25fef2ca4c291

Whoops. I meant to open this PR against my prototype registry.


Cotary Create: Hours field looks messed up in Advanced view

Hours field looks messed up in Advanced view

Also these should not have AM or PM, as they are just a number of hours in addition to the number of days. --> This part is fixed.
Need to fix this --> Overall it is pretty difficult and glitchy trying to edit the days/hours values.

In V1, we just have number fields as normal text fields, and an error is thrown if it isn't a valid number

In V1, we just have number fields as normal text fields, and an error is thrown if it isn't a valid number

I believe this is possible because v1 was using Material-ui?


tool: dupl

a tool for code clone detection:
https://github.com/mibk/dupl

Interesting tool, but it gives a great number of false positives for me. And even the ones that are duplicates end up being copy-and-paste code due to Go's lack of generics.
But the biggest problem is that the output format is not conducive to stateless parsing. eg.
$ dupl -t=20
found 2 clones:
  loc 1: main.go, line 487-490,
  loc 2: main.go, line 492-495,
found 2 clones:
  loc 1: main.go, line 147-147,
  loc 2: main.go, line 154-154,

I've filed a ticket to see if a more useful format can be output.

I would like to see this integrated too. dupl looks like very interesting tool.

The dupl guys have added a -plumbing flag to generate machine-readable output, and I've integrated it into gometalinter.


Expose object tracker for fake clientsets

Not every object kind can be registered via tracker .Add() called as part of
SimpleClientset initialization. This is because .Add() relies on
UnsafeGuessKindToResource to convert object kinds into resource type names,
which is broken for some resources. An example of an affected kind is
NetworkAttachmentDefinitions CRD that uses network-attachment-definitions as
its resource type name. When UnsafeGuessKindToResource is called for this kind,
it returns networkattachmentdefinitions (without dashes).
As per the comment inside .Add, kinds affected by UnsafeGuessKindToResource
deficiencies should instead register objects using tracker .Create() method.
Problem is, current SimpleClientset struct definition doesn't expose the object
tracker in any way, which makes it impossible to properly register these kinds
at all.
To address the issue, this change modifies the definition of SimpleClientset
struct to expose the object tracker used via Tracker() method.
Sorry, we do not accept changes directly against this repository. Please see
CONTRIBUTING.md for information on where and how to contribute instead.

CLA signed as an individual contributor. Thanks.

Sorry for posting here, the right location: https://github.com/kubernetes/kubernetes/pull/71049


http.client.RemoteDisconnected: Error During attaching an instance of a container

Hi,
I have a problem with disconnecting during attaching the instance of a container.
I have gone through all steps successfully from this tutorial: https://docs.microsoft.com/en-us/azure/container-registry/container-registry-tutorial-quick-task
And almost at the end, you need to attach container instance. During this process image is pulled successfully and MySQL server is starting ...
After few minutes it get disconnected with error: 1.) http.client.RemoteDisconnected: Remote end closed connection without response
and with another linked errors in sequence:
2.) urllib3.exceptions.ProtocolError: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response',))
3.) requests.exceptions.ConnectionError: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response',))
4.) knack.util.CLIError: Please ensure you have network connection. Error detail: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response',))
... of course I have network connection.
Whole log in attachment
Container Attach logs.txt
Does anyone have a solution for this ? It looks like a perf or timeout problem on the Azure Cloud server side. I browse the net and didnt find anything related to this issue with correct solution or response.
Thank you in advance :-)
BR
Michal.

Thanks for the feedback! We are currently investigating and will update you shortly.

@MichalBecko I ran through this doc and was able to successfully complete the steps
micah@Azure:~/acr-build-helloworld-node$ az container attach --resource-group $RES_GROUP --name acr-tasks
Container 'acr-tasks' is in state 'Running'...
(count: 1) (last timestamp: 2018-10-11 19:21:09+00:00) pulling image "micahacr.azurecr.io/helloacrtasks:v1"
(count: 1) (last timestamp: 2018-10-11 19:21:16+00:00) Successfully pulled image "micahacr.azurecr.io/helloacrtasks:v1"
(count: 1) (last timestamp: 2018-10-11 19:21:16+00:00) Created container with id 54bc220db132d1312230c33af4df761fc85778fe125ee52df1982f3101855050
(count: 1) (last timestamp: 2018-10-11 19:21:16+00:00) Started container with id 54bc220db132d1312230c33af4df761fc85778fe125ee52df1982f3101855050

Start streaming logs:
Server running at http://localhost:80

I did run the steps through the Azure Cloud Shell rather than on prem. Are you using a local instance of Azure CLI? Could you try the doc using Cloud Shell to see if it works?

Hi,
thanks for response :-)
I use web based Azure Cloud Shell. I Tried a local, but there is problem right et the begining with the commands of creating group, etc. So I focuse to he web Azure Cloud Shell.
But lets get back to the issue. Issue complains about starting MySQL server on a Azure Cloud.
Our App contains MySQL DB which has been correctly build to image and pushed to specific container.
Yesterday I tried to build image of our App without MySQL DB. Of course it doesnt work well but the Image has been built well, the image has been pushed to container and the container has been after a long time (Almost 30 minutes) attached and We could see the app on the cloud of FDQN URL.
So the problem has to be somewhere at MySQL server starting on Azure Cloud.
Today I tried again to attach the container with image of App with MySQL so lets see if something new wont happen.
Now I run the command for attaching the container and now Iam waiting on this part of process with starting MySQL daemon:
Container 'acr-tasks' is in state 'Running'...
(count: 1) (last timestamp: 2018-10-10 15:31:13+00:00) pulling image "junoacrname10.azurecr.io/junooimage10:v1"
(count: 1) (last timestamp: 2018-10-10 15:35:44+00:00) Successfully pulled image "junoacrname10.azurecr.io/junooimage10:v1"
(count: 1) (last timestamp: 2018-10-10 15:35:44+00:00) Created container with id 0a9497d6f41f8f05e2c66fb94af130543526cdf3a4f0f7738eb186139179af74
(count: 1) (last timestamp: 2018-10-10 15:35:44+00:00) Started container with id 0a9497d6f41f8f05e2c66fb94af130543526cdf3a4f0f7738eb186139179af74
Start streaming logs:
Installing database...
Starting MySQL server...
Waiting for database server to accept connections.
Creating debian-sys-maint user...
mysql: [Warning] Using a password on the command line interface can be insecure.
2018-10-10T15:36:31.345713Z mysqld_safe Logging to syslog.
2018-10-10T15:36:31.362943Z mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
Thanks for reviewing our issue.
Best Regards
Michal.

@MichalBecko thanks for the extra details.
Seems there might be something regarding your specific account setup as I cannot seem to repro this issue.
Can you email me at<EMAIL_ADDRESS>and provide me with your SubscriptionID and link to this issue? I can enable your subscription for a support request so we can get you in contact with a support engineer to work 1:1 with to get this sorted out.
I will close this issue as there are not doc updates needed. But will be on the lookout for your email :)


Render the UI

Notables

The UI is all rendered with HTML and CSS.
This may turn out to be heavier than a solution rendered to the canvas, but it eliminates the need to handle a lot of the interaction mechanics the way we'd need to with canvas-rendered UI.
Scaling is now handled with CSS
All of our JavaScript rendering can be done on an actual pixel scale to the shadow canvas. The game is then scaled up using a CSS transform.
The map has been replaced by a grid
This isn't because we don't want the map, but the grid was helpful in making sure all of the UI was right.

The grid rendering will still need to be adjusted. We should have at least 8 pixels above the grid to handle rendering tiles and entities, but I didn't account for that yet.

Images can be imported directly
This was already being handled in CSS by the MiniCSSExtractPlugin, but I've added support for it to our JavaScript, too. We'll want to toy with the output from this eventually to make sure it's crushing our images into oblivion.
Fonts were abstracted
We now have the font renderer, but each font also has its own file. It'd be nice to remove any unused characters, but I figured we could worry about that closer to submission.
Observable settings
The settings object can be imported and modified directly. We can also watch for/react to changes in the settings object with settings.on('change', ({ detail }) => {}).
Sass support
I added Sass support because writing all of it in plain CSS was killing me. I'm mostly just leveraging the nesting, though we could probably benefit from Sass variables (CSS custom properties will end up adding a lot more weight than they would save).

Build size
Current build is 5015 bytes, or 37.67% of our total available build size.

A couple other notes:
I did leave the fitToScreen method in there even though it's not currently doing anything. I figured that we could use it if we end up actually implementing the autoscale setting.
I also left the drawGrid method in, even though it's not currently doing anything. I commented out all of the code so we can use it for guidance when refactoring the map/grid rendering.


RUM-5524: Make ImagePrivacy clearer

What does this PR do?
Changes MASK_CONTENT to MASK_LARGE_ONLY, to make the ImagePrivacy api clearer about what is actually happening.
Motivation
Clearer api for the users.
Additional Notes
Anything else we should know when reviewing?
Review checklist (to be filled by reviewers)

[ ] Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
[ ] Make sure you discussed the feature or bugfix with the maintaining team in an Issue
[ ] Make sure each commit and the PR mention the Issue number (cf the CONTRIBUTING doc)

Since the decision has been made, the PR looks good to me.
Just a question by curiosity, it seems to be a breaking change in terms of API, do we need any additional action on this kind of PR?


[DM-27979] Rename nginx-ingress to ingress-nginx

Make the name of the chart match the upstream subchart, since
otherwise Helm adds nginx-ingress- as a prefix to the name of
every resource, resulting in obnoxiously long resource names and
some confusion.

That looks good to me, and while it's a tricky change, I feel better knowing that minikube did a test deploy.  Approved!

That looks good to me, and while it's a tricky change, I feel better knowing that minikube did a test deploy.  Approved!


add EMBOSS build

Add build instructions for EMBOSS
To get it running you need to:

export LD_LIBRARY_PATH=/home/user/emboss-6.6.0-Linux-x86_64/lib/:$LD_LIBRARY_PATH
export EMBOSS_ACDROOT=/home/user/emboss-6.6.0-Linux-x86_64/share/EMBOSS/acd

@bgruening One minor suggestion, if you set a runtime linker path using $ORIGIN like so, you don't need to set $LD_LIBRARY_PATH:
ORIGIN='$ORIGIN' &&
export ORIGIN &&
LDFLAGS='-Wl,-rpath,$${ORIGIN}/../lib' ./configure --prefix ${build}/dest --without-x &&
make && ...

Thanks @natefoo! Hope this works now!


WIP: Sync RTE with NFD

Sync podres package
Bump NRT API to latest:
Update vendor files
Fix code to match the new API
This patch is following the way of how the new API integration was done on NFD:
It assumes capacity is equal to allocatable and in a subsequent patch
we need to account for kube-reserved and system reserved to determine the
allocatable, as allocatable = capcity - kube-reserved/system-reserved

The available accounting will be added on a separate commit

The available accounting will be added on a separate commit

Just an FYI, the scheduler plugin uses available field to make its NUMA aware scheduling decision, so we need to make sure that available field is populated to make sure that it works with the latest version of the scheduler plugin.

This is going to be part of this PR but in a separate commit for readability porpuses

@swatisehgal @fromanirh FYI the Allocatable field in RTE is behaving as the Available filed in NFD
I just tested it on my setup, one you deploy/delete a guaranteed pod, the values under Allocatable are changing.
https://github.com/k8stopologyawareschedwg/resource-topology-exporter/blob/master/pkg/resourcemonitor/resourcemonitor.go#L171
is it intentional?

@swatisehgal @fromanirh FYI the Allocatable field in RTE is behaving as the Available filed in NFD.
I just tested it on my setup, one you deploy/delete a guaranteed pod, the values under Allocatable are changing, while it shouldn't, becuase it should reflect the amount of capacity - reserved and it doesn't depend on the number of running pods in the cluster.
As you can see: https://github.com/k8stopologyawareschedwg/resource-topology-exporter/blob/master/pkg/resourcemonitor/resourcemonitor.go#L171
is this change in the behavior is intentional?

 Sorry I wasn't aware of that.

the podres sync patch can be a separate PR which we can merge quickly.

good enough, we can improve in followup PRs.


Add fortran-lang/stdlib package.

Description
Now stdlib can be used as a fpm dependency for your fpm project.
(see build with fpm)
So I now submit fortran-lang/stdlib to fpm-registry. (close #54 )

Looks like it's failing because the fpm.toml file doesn't specify the maintainer key. This is an issue with the validation script, see #24.

Um, it looks like it is.
https://github.com/fortran-lang/fpm-registry/blob/88fb232c0b832bd0dc7ae3a8f6fbed94c58a86b7/fpm_validate.py#L36
    # Must be present, copied to json
    required_keys = ["name", "version", "license", "author",
                       "maintainer", "copyright"]

see stdlib fpm.toml


use 'onReady' player event to add listeners

#1043

Thanks for your pull request. Is this your first contribution to a Snowplow open source project? Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).
:memo: Please visit https://docs.snowplowanalytics.com/docs/contributing/contributor-license-agreement/ to learn more and sign.
Once you've signed, please reply here (e.g. I signed it!) and we'll verify. Thanks.


Smarty substitutions seems to 'eat' random characters

Describe the bug
When using smarty substitutions, characters that should be left untouched disappear from the output.

    $Parser->setSetting('smarty', [
    'substitutions' => [
        'left-double-quote' => '"', // Double bottom quote
        'right-double-quote' => '"', // Double top quote
        "ndash"=> '–',
        "mdash" =>'—',
        "left-single-quote" => "'",
        "right-single-quote" => "'",
        "left-angle-quote" => '«',
        "right-angle-quote" => '»',
        "ellipses"=> "..."
    ],

    "enabled" => true
    ]);

Upon disbling smarty, everything works fine (expect substitutions of course).
Expected Behavior
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct

Can I get you to post the text from your image, it makes it a bit easier to debug

Sure, do you want the full document ? (sorry for the delay)

It unfortunately is, but testing with a test file containing solely the line below triggers the bug :
# Linéariser les équations d'évolution de la position $r$ de la bille et de la position angulaire $varphi$ du rail autour de $r=r_0=0.25m$ et $varphi=0$. Montrer qu'on peut les écrire sous le formalisme d'état.

Fixed in release 1.2.7


getTextFrom() grabTextFromAll() should return element's text with space if it is divided in multiple span

What are you trying to achieve?
I am trying to get indexed element from the page, which is divided in two spans, first span contains index and second contains text.
e.g.:

"1"
"One"

The output should be:
1 One
What do you get instead?
1One

Provide console output if related. Use --verbose mode for more details.

# paste output here

Provide test source code if related

// paste test

Details

CodeceptJS version:3.5.8
NodeJS Version: 18.18.0
Operating System: Windows
puppeteer || webdriverio || testcafe version (if related)
Configuration file:

# paste config here

Why shoud it work this way?
I.grabTextFromAll returns an array of text grabbed by a loctor.
So, in your case, you could retrieve the text
const cellValues = await I.grabTextFromAll('h2 span');

and then join the way the context requires. Just the same as spans can serve different purposes, for spacing, or for line breaks
const cellValue = cellValues.join(' ');

or
const cellValue = cellValues.join('\n');


Codable with IGListDiffable

New issue checklist

[x] I have reviewed the README and documentation
[x] I have searched existing issues and this is not a duplicate

General information

IGListKit version:
iOS version(s):11.4
Xcode version: 9.0+
Related issues:

I have some models which conform to Swift's Codable protocol. Tried using them with IGListDiffable, but it seems like that won't work. What do?
class Person: NSObject, Codable {
    @objc dynamic var id: Int = 0
    @objc dynamic var image_url: String?

    private enum PersonCodingKeys: String, CodingKey {
        case id
        case image_url
    }

    convenience init(personId: Int, image_url: String) {
        self.init()
        self.id = personId
        self.image_url = image_url
    }

    convenience required init(from decoder: Decoder) throws {
        let container = try decoder.container(keyedBy: PersonCodingKeys.self)
        let id = try container.decode(Int.self, forKey: .id)
        let image_url = try container.decode(String.self, forKey: .image_url)
        self.init(personId: id, image_url: image_url)
    }

    override init() {
        super.init()
    }
}

Seems particularly that it won't work with Optional type in the Codable.

Never mind, I think I got it.
class Person: NSObject, Codable {
    @objc dynamic var id: Int = 0
    @objc dynamic var image_url: String?
    @objc dynamic var custom_obj_array: [CustomType]?

    private enum PersonCodingKeys: String, CodingKey {
        case id
        case image_url
        case custom_obj_array
    }

    convenience init(personId: Int, image_url: String, custom_obj_array: [CustomType]) {
        self.init()
        self.id = personId
        self.image_url = image_url
        self.custom_obj_array = custom_obj_array
    }

    convenience required init(from decoder: Decoder) throws {
        let container = try decoder.container(keyedBy: PersonCodingKeys.self)
        let id = try container.decode(Int.self, forKey: .id)
        let image_url = try container.decode(String.self, forKey: .image_url)
        let custom_obj_array = try container.decodeIfPresent([CustomType].self, forKey: .custom_obj_array) ?? []
        self.init(personId: id, image_url: image_url, custom_obj_array: custom_obj_array)
    }

    override init() {
        super.init()
    }
}

Changed the way I am accessing the key custom_obj_array with decodeIfPresent.


Title is misleading

File: compose/startup-order.md
Please add info about shutdown order or remove this from the title.

Could you elaborate what kind of information you're looking for? I see this as the first paragraph;

You can control the order of service startup and shutdown with the depends_on option. Compose always starts and stops containers in dependency order, where dependencies are determined by depends_on, links, volumes_from, and network_mode: "service:...".

Thanks for sharing the issue. Closing this as stale. If issue is still applicable, please provide the details requested in the previous comment.


AutoComplete Auto-Entry on Tab

There is no easy way to choose an AutoComplete name aside from tapping the one we want. Pressing Tab when the AutoComplete elements are open should put the first name in the list in the reply box.

When you say it should is that because it's not done yet? If I remember right TAB is a tricky key to get hold of cross-browser, maybe space or enter would work better? I'm at the stage I want to do the same thing in the Dark Social I'm working with. At the moment I don't even have an autocomplete it simply reverts back to the previous known one if it doesn't exist.
I might go a fixing this one...

This issue has been resolved with @mttmccb's recent commit.
Thanks, Matt :)


Added Hover effects on scrollbar thumb

Pull Request
Description
Added cursor pointer make color some dull when hover on thumb.
Closes #1453
Type of change

[ ] Adding a new Resource
[ ] Adding a new Category
[ ] Documentation enhancement or fixes
[x] Website enhancement or fixes

Checklist:

[x] I read carefully CONTRIBUTING.md
[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

Screenshots (if appropriate):
When hover on thumb of scrollbar

@jfmartinz Please check it and merge !


Metrics improvement

should fix #223. Furthermore it adds additional jvm specific metrics.

Adopted. Now using star-imports.


Bone attachment GlobalTransform rotation treats z as up

Godot version:
95cfa9bf74774110ba01a3987a22c9d7d616c1c6
OS/device including version:
Arch Linux
Issue description:
BoneAttachments treat z as up when their GlobalTransforms are read directly.  The resulting position is correct but the rotation is wrong.
Steps to reproduce:

Add a BoneAttachment to a skeleton and set its bone target
Copy the GlobalTransform of the bone attachment to a mesh
Observe that it is facing the wrong direction

Minimal reproduction project:
BoneAttachmentRotation.zip
This project copies the GlobalTransform from a BoneAttachment to a mesh that is facing up (according to godot).  It should start facing up because the bone is also facing up, but it actually points ~forward (into the screen)~ out of the screen.
It includes the blend file that generated the .dae containing the skeleton

BoneAttachment just copies the transform of the bone, which isn't warranted to be anything in particular.
Simply put another node as child of BoneAttachment and re-orient it the way you want.


Improve CI documentation

Remove incorrect sentence
Add link to GCP IAM Roles

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

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

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

GitHub Actions Tests Status (on master branch)

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

R: @aaltay @tysonjh @kamilwu

Thanks!


How to invoke a method that implicit cast string, such as XElment.Elements(XName name)

Firstly,I try to use Linq xml in my Script,such as:
var XDocument=clr.System.Xml.Linq.XDocument var doc = XDocument.Load(xmlPath); var root = doc.Root; var patients = root.Elements('patient');
And it makes error.It seems that 'string' cannot be implicit  to the 'XName'.
So I have to write as
var patients = root.Elements(Lib.GetXName('patient'));
public XName GetXName(string name)         {             return (XName)name;         }
Is there any more elegant way?As 'XName' is used frequently.
Thank you very much

Hi @dwanboweb,
Currently ClearScript doesn't support implicit conversion operators for method arguments. Specifically, the call binds to the correct method, but ClearScript's invocation code can't perform the required conversion. We'll add that capability in the next release.
What you're doing is exactly the workaround we'd recommend. You could make the conversion syntax slightly simpler by providing a wrapper function or extending the String prototype, but that's really a matter of preference.
Thanks for reporting this!

ClearScript 5.6 adds support for implicit conversion operators for host method arguments.

wow ,I just need this!


how to delete records from the stream using custom field

I want to delete records from a space based on some batch id using python.
(My space contains multiple batch data, ask is to overwrite the existing data by removing the existing batch id.)
Can you please help with the query or what approach should we take?
Thanks,
Ankit

Also, if I see this 'Delete' Section on this https://kb.timebase.info/community/technology/apis/tickstream#delete
I cant find any python implementation.
Is it available for python?


Publish checksums for local repositories

Fix for #22482

@ljacomet I made this as an alternative fix for #22482, as I couldn't see anything wrong with adding it. Is there any reason not to do this, when mvn install -DcreateChecksum=true would do the same thing, and Maven downloads hashes from the remote to there anyways?

@bot-gradle test this

OK, I've already triggered the following builds for you:

PullRequestFeedback build

Hey Octavia,
I am not sure actually. Given that we really want folks to learn to stop using Maven local as a full fledged Gradle repository, making it easier feels a bit counterproductive.
At the same time, I agree that the fix is very small.
I think it makes sense for the JVM team to take a stance as part of the publication work. So my opinion is above, but feel free to go through with the change if you think it best.

I am not sure actually. Given that we really want folks to learn to stop using Maven local as a full fledged Gradle repository, making it easier feels a bit counterproductive.

I think there are two parts of this:

Using Maven local to share artifacts built by Gradle with Maven.
Using Maven local to share artifacts built by Gradle with Gradle.

I think it's OK to suggest people can do (1), so we should be able to publish to Maven local.
Consider how do we want Maven to see Gradle populated artifacts in m2. If we had published the Gradle built artifacts to a repository and then Maven had resolved them, m2 would have checksums.  Possibly, we should emulate the resolve behavior (populate with checksums) and not the mvn install behavior to be less Maven like and more consistent internally.
We don't want people to do (2) because we want people to use composite builds where possible. We want to discourage the use of Maven local for resolution. I don't know if this change would affect this way or the other.

@bot-gradle test this

OK, I've already triggered the following builds for you:

PullRequestFeedback build

After discussing with the JVM team, we decided the original issue does not provide sufficient justification to make this change now. If another use case comes up that isn't better solved by publishing to a file:// URL, we may revisit this.


Provide a reproducer for a PomResolver issue

An issue reproducer:
https://github.com/openrewrite/rewrite/issues/2603

Thank you for the reproducer, this was VERY helpful.  I have added this test (along with a fix) to this commit: https://github.com/openrewrite/rewrite/commit/4c6baf199762bb89cf288010740faf8084d4e44e


azure-servicebus Samples issues

Section link1, link2:

Suggestion:
Update code to:
print(str(message))

@jongio for notification.


Better receiver Main code

Proposed Changes

:broom: Cleanup receiver Main, added some comments
:broom: Moved counter creation to ReceiverVerticleFactory

/retest
Webhook flaky


Dead URLs

In this repo, mcr.microsoft.com/aks/samples/voting/app:1.0 and mcr.microsoft.com/aks/samples/voting/app:2.0 are dead. Please fix.

The mcr.microsoft.com entries are being removed for these images.


Consider updating Winston logger

Winston@1 is getting long in the tooth, the project is at v3
https://github.com/winstonjs/winston/blob/master/CHANGELOG.md

When I last looked into this there was some reason it wasn't a trivial update.  I'm forgetting the details.  Likely related to the scary clustering aggregation logging code.  It would also be good to see if there are more modern approaches that would simplify that code.

@mattcollier can this be closed now?

@aljones15 correct, thanks for pointing it out. This landed: https://github.com/digitalbazaar/bedrock/blob/master/CHANGELOG.md#400---2020-12-07


refactor: typed solc ast

Motivation
Working with the Solc AST right now is not super ergonomic and it's making it hard to provide support for library coverage in Foundry, since for that feature we would need to walk out to each call expression node and parse the type name. It's doable currently, but a lot of the nice information in the AST is rolled into other, so it's not super easy or maintanable.
Solution
Replace the AST abstraction with more strict types. Each node gets its own type loosely based on https://github.com/OpenZeppelin/solidity-ast which claims to have a wide Solidity version support. I'll also add a Visitor trait with some walk_* helper functions for easier traversal.
I've opened up this PR because I am currently at an impasse: I've started implementing macros to generate some of the common fields in the different nodes, but we could also use struct composition instead.
The downside of struct composition is that you have to "reach" and I am having some struggle coming up with nice names. For example, the two most common fields are id and src... we could call these "meta", but then what about the expression meta-fields? If we called them "node", then it's a bit awkward since you'd probably have a lot of code doing things like node.node.id.
If we called these fields "meta", and the common expression fields "expression", then you'd instead have a lot of code doing expr.expression.
The downside of macros is that it might be slow to compile, too opaque or too inflexible.
Thoughts @mattsse @gakonst?
(Docs + doc comments and so on coming later, this is very much a WIP)
PR Checklist

[ ] Added Tests
[ ] Added Documentation
[ ] Updated the changelog

Yep concept ack

It may be worthwhile to explore https://github.com/ConsenSys/solc-typed-ast to compare OZs implementation against

I'm already comparing against a typed implementation as described in the PR

I'm already comparing against a typed implementation as described in the PR

The repo i linked provides an ast with "xpath" support, its used in scribble to help provide instrumentation coverage, should have mentioned that too sorry.

I think xpath support is out of scope for this PR since it is a bigger feature and the most immediate need here is supporting some coverage features

Just added some test fixtures from Solmate, will try to slim it down lmfao

Very nice work, I would say that the PR came at the perfect time.
Just curious on how do you plan to visit the nodes, as the nodes types are all different

@mattsse any preference on how we safeguard against breaking stuff in solc? rn if the AST won't deserialize everything breaks, but it is used by ethers-solc in at least one place, so either we find a way to replace that, or we try to deserialize to a smaller ast on failure?

As a note here, I gave up on supporting the legacy AST layout. At first I thought it was just some properties that were lifted into a nested attributes object, but it turns out that all related nodes are also shifted into a children array. For comparison, the current layout of a binary expression in the AST is something like
{
  type: 'BinaryExpression',
  leftExpression: Expression,
  rightExpression: Expression,
}

where left and right expression in the legacy AST would be in children[0] and children[1]. It gets even more complicated with other AST nodes, and some properties have undergone refactors and renames beyond that as well. As far as I can tell, a lot of 0.4.x Solidity versions support the "modern"/current AST, so we should be good for somewhere from 0.4.x to now, which I think is OK?

As far as I can tell, a lot of 0.4.x Solidity versions support the "modern"/current AST, so we should be good for somewhere from 0.4.x to now, which I think is OK?

Yeah I think for coverage-related stuff we can afford to say "this is for after solidity version XXX"
what's the next step after this PR? integrate in coverage?

Yes, integrate into coverage to get library coverage

@mattsse any preference on how we safeguard against breaking stuff in solc? rn if the AST won't deserialize everything breaks, but it is used by ethers-solc in at least one place, so either we find a way to replace that, or we try to deserialize to a smaller ast on failure?

perhaps upcoming generics will break some things here, how we handled semver incompatible CompilerInput is by cleaning it up depending on the version. This is not possible here.
I think we just have to maintain compatibility via custom deserde moving forward, unfortunately...

bump @onbjerg

Imo, it makes sense to have this, if someone is going to use this, they can improve this where necessary

The ast was very well done with the macros it makes totally sense. I have fixed some bugs because of needing it, I can add them to the branch

@iFrostizz yes that would be great. keen to get this over the line, so if you want to submit a new branch (or something that forks off this PR) that works! thank you

@iFrostizz yes that would be great. keen to get this over the line, so if you want to submit a new branch (or something that forks off this PR) that works! thank you

I've opened the PR.
Haven't got any serde json serialization issues since, but there could be other occurrences eventually

sgtm! lets do that.
unsure about foundry impact, most likely coverage.

superseded by #1943


translatable element names in item-chat

#I would like item-chat to be able to translate the name of the item when using [item], for example:
using [item] in a diamond pickaxe comes out [diamond pickaxe] and with "translatable element" the article can  be translated into Spanish and get [pico de diamante]

Are you saying that you want to use a translations API to translate the text? Because item display names that have been modified aren't compatible with the namespaced key translations system that clients use. It's embedded in the client, not the server so players who aren't using the Spanish locale would see it in Spanish despite using English.

This has been done! Thanks for the suggestion.


chore(deps): update module go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploghttp to v0.7.0

This PR contains the following updates:

Package
Type
Update
Change

go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploghttp
replace
minor
v0.3.0 -> v0.7.0

go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploghttp
require
minor
v0.3.0 -> v0.7.0

Release Notes

open-telemetry/opentelemetry-go (go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploghttp)
v0.7.0
Compare Source
This release implements the v0.5.0 version of the OpenTelemetry specification.
Added

The othttp instrumentation now includes default metrics. (#861)
This CHANGELOG file to track all changes in the project going forward.
Support for array type attributes. (#798)
Apply transitive dependabot go.mod dependency updates as part of a new automatic Github workflow. (#844)
Timestamps are now passed to exporters for each export. (#835)
Add new Accumulation type to metric SDK to transport telemetry from Accumulators to Processors.
This replaces the prior Record struct use for this purpose. (#835)
New dependabot integration to automate package upgrades. (#814)
Meter and Tracer implementations accept instrumentation version version as an optional argument.
This instrumentation version is passed on to exporters. (#811) (#805) (#802)
The OTLP exporter includes the instrumentation version in telemetry it exports. (#811)
Environment variables for Jaeger exporter are supported. (#796)
New aggregation.Kind in the export metric API. (#808)
New example that uses OTLP and the collector. (#790)
Handle errors in the span SetName during span initialization. (#791)
Default service config to enable retries for retry-able failed requests in the OTLP exporter and an option to override this default. (#777)
New go.opentelemetry.io/otel/api/oterror package to uniformly support error handling and definitions for the project. (#778)
New global default implementation of the go.opentelemetry.io/otel/api/oterror.Handler interface to be used to handle errors prior to an user defined Handler.
There is also functionality for the user to register their Handler as well as a convenience function Handle to handle an error with this global Handler(#778)
Options to specify propagators for httptrace and grpctrace instrumentation. (#784)
The required application/json header for the Zipkin exporter is included in all exports. (#774)
Integrate HTTP semantics helpers from the contrib repository into the api/standard package. #769

Changed

Rename Integrator to Processor in the metric SDK. (#863)
Rename AggregationSelector to AggregatorSelector. (#859)
Rename SynchronizedCopy to SynchronizedMove. (#858)
Rename simple integrator to basic integrator. (#857)
Merge otlp collector examples. (#841)
Change the metric SDK to support cumulative, delta, and pass-through exporters directly.
With these changes, cumulative and delta specific exporters are able to request the correct kind of aggregation from the SDK. (#840)
The Aggregator.Checkpoint API is renamed to SynchronizedCopy and adds an argument, a different Aggregator into which the copy is stored. (#812)
The export.Aggregator contract is that Update() and SynchronizedCopy() are synchronized with each other.
All the aggregation interfaces (Sum, LastValue, ...) are not meant to be synchronized, as the caller is expected to synchronize aggregators at a higher level after the Accumulator.
Some of the Aggregators used unnecessary locking and that has been cleaned up. (#812)
Use of metric.Number was replaced by int64 now that we use sync.Mutex in the MinMaxSumCount and Histogram Aggregators. (#812)
Replace AlwaysParentSample with ParentSample(fallback) to match the OpenTelemetry v0.5.0 specification. (#810)
Rename sdk/export/metric/aggregator to sdk/export/metric/aggregation. #808
Send configured headers with every request in the OTLP exporter, instead of just on connection creation. (#806)
Update error handling for any one off error handlers, replacing, instead, with the global.Handle function. (#791)
Rename plugin directory to instrumentation to match the OpenTelemetry specification. (#779)
Makes the argument order to Histogram and DDSketch New() consistent. (#781)

Removed

Uint64NumberKind and related functions from the API. (#864)
Context arguments from Aggregator.Checkpoint and Integrator.Process as they were unused. (#803)
SpanID is no longer included in parameters for sampling decision to match the OpenTelemetry specification. (#775)

Fixed

Upgrade OTLP exporter to opentelemetry-proto matching the opentelemetry-collector v0.4.0 release. (#866)
Allow changes to go.sum and go.mod when running dependabot tidy-up. (#871)
Bump github.com/stretchr/testify from 1.4.0 to 1.6.1. (#824)
Bump github.com/prometheus/client_golang from 1.7.0 to 1.7.1 in /exporters/metric/prometheus. (#867)
Bump google.golang.org/grpc from 1.29.1 to 1.30.0 in /exporters/trace/jaeger. (#853)
Bump google.golang.org/grpc from 1.29.1 to 1.30.0 in /exporters/trace/zipkin. (#854)
Bumps github.com/golang/protobuf from 1.3.2 to 1.4.2 (#848)
Bump github.com/stretchr/testify from 1.4.0 to 1.6.1 in /exporters/otlp (#817)
Bump github.com/golangci/golangci-lint from 1.25.1 to 1.27.0 in /tools (#828)
Bump github.com/prometheus/client_golang from 1.5.0 to 1.7.0 in /exporters/metric/prometheus (#838)
Bump github.com/stretchr/testify from 1.4.0 to 1.6.1 in /exporters/trace/jaeger (#829)
Bump github.com/benbjohnson/clock from 1.0.0 to 1.0.3 (#815)
Bump github.com/stretchr/testify from 1.4.0 to 1.6.1 in /exporters/trace/zipkin (#823)
Bump github.com/itchyny/gojq from 0.10.1 to 0.10.3 in /tools (#830)
Bump github.com/stretchr/testify from 1.4.0 to 1.6.1 in /exporters/metric/prometheus (#822)
Bump google.golang.org/grpc from 1.27.1 to 1.29.1 in /exporters/trace/zipkin (#820)
Bump google.golang.org/grpc from 1.27.1 to 1.29.1 in /exporters/trace/jaeger (#831)
Bump github.com/google/go-cmp from 0.4.0 to 0.5.0 (#836)
Bump github.com/google/go-cmp from 0.4.0 to 0.5.0 in /exporters/trace/jaeger (#837)
Bump github.com/google/go-cmp from 0.4.0 to 0.5.0 in /exporters/otlp (#839)
Bump google.golang.org/api from 0.20.0 to 0.28.0 in /exporters/trace/jaeger (#843)
Set span status from HTTP status code in the othttp instrumentation. (#832)
Fixed typo in push controller comment. (#834)
The Aggregator testing has been updated and cleaned. (#812)
metric.Number(0) expressions are replaced by 0 where possible. (#812)
Fixed global handler_test.go test failure. #804
Fixed BatchSpanProcessor.Shutdown to wait until all spans are processed. (#766)
Fixed OTLP example's accidental early close of exporter. (#807)
Ensure zipkin exporter reads and closes response body. (#788)
Update instrumentation to use api/standard keys instead of custom keys. (#782)
Clean up tools and RELEASING documentation. (#762)

v0.6.0
Compare Source
Added

Support for Resources in the prometheus exporter. (#757)
New pull controller. (#751)
New UpDownSumObserver instrument. (#750)
OpenTelemetry collector demo. (#711)
New SumObserver instrument. (#747)
New UpDownCounter instrument. (#745)
New timeout Option and configuration function WithTimeout to the push controller. (#742)
New api/standards package to implement semantic conventions and standard key-value generation. (#731)

Changed

Rename Register* functions in the metric API to New* for all Observer instruments. (#761)
Use []float64 for histogram boundaries, not []metric.Number. (#758)
Change OTLP example to use exporter as a trace Syncer instead of as an unneeded Batcher. (#756)
Replace WithResourceAttributes() with WithResource() in the trace SDK. (#754)
The prometheus exporter now uses the new pull controller. (#751)
Rename ScheduleDelayMillis to BatchTimeout in the trace BatchSpanProcessor.(#752)
Support use of synchronous instruments in asynchronous callbacks (#725)
Move Resource from the Export method parameter into the metric export Record. (#739)
Rename Observer instrument to ValueObserver. (#734)
The push controller now has a method (Provider()) to return a metric.Provider instead of the old Meter method that acted as a metric.Provider. (#738)
Replace Measure instrument by ValueRecorder instrument. (#732)
Rename correlation context header from "Correlation-Context" to "otcorrelations" to match the OpenTelemetry specification. 727)

Fixed

Ensure gRPC ClientStream override methods do not panic in grpctrace package. (#755)
Disable parts of BatchSpanProcessor test until a fix is found. (#743)
Fix string case in kv Infer function. (#746)
Fix panic in grpctrace client interceptors. (#740)
Refactor the api/metrics push controller and add CheckpointSet synchronization. (#737)
Rewrite span batch process queue batching logic. (#719)
Remove the push controller named Meter map. (#738)
Fix Histogram aggregator initial state (fix #735). (#736)
Ensure golang alpine image is running golang-1.14 for examples. (#733)
Added test for grpctrace UnaryInterceptorClient. (#695)
Rearrange api/metric code layout. (#724)

v0.5.0
Compare Source
Added

Batch Observer callback support. (#717)
Alias api types to root package of project. (#696)
Create basic othttp.Transport for simple client instrumentation. (#678)
SetAttribute(string, interface{}) to the trace API. (#674)
Jaeger exporter option that allows user to specify custom http client. (#671)
Stringer and Infer methods to keys. (#662)

Changed

Rename NewKey in the kv package to just Key. (#721)
Move core and key to kv package. (#720)
Make the metric API Meter a struct so the abstract MeterImpl can be passed and simplify implementation. (#709)
Rename SDK Batcher to Integrator to match draft OpenTelemetry SDK specification. (#710)
Rename SDK Ungrouped integrator to simple.Integrator to match draft OpenTelemetry SDK specification. (#710)
Rename SDK SDK struct to Accumulator to match draft OpenTelemetry SDK specification. (#710)
Move Number from core to api/metric package. (#706)
Move SpanContext from core to trace package. (#692)
Change traceparent header from Traceparent to traceparent to implement the W3C specification. (#681)

Fixed

Update tooling to run generators in all submodules. (#705)
gRPC interceptor regexp to match methods without a service name. (#683)
Use a const for padding 64-bit B3 trace IDs. (#701)
Update mockZipkin listen address from :0 to <IP_ADDRESS>:0. (#700)
Left-pad 64-bit B3 trace IDs with zero. (#698)
Propagate at least the first W3C tracestate header. (#694)
Remove internal StateLocker implementation. (#688)
Increase instance size CI system uses. (#690)
Add a key benchmark and use reflection in key.Infer(). (#679)
Fix internal global test by using global.Meter with RecordBatch(). (#680)
Reimplement histogram using mutex instead of StateLocker. (#669)
Switch MinMaxSumCount to a mutex lock implementation instead of StateLocker. (#667)
Update documentation to not include any references to WithKeys. (#672)
Correct misspelling. (#668)
Fix clobbering of the span context if extraction fails. (#656)
Bump golangci-lint and work around the corrupting bug. (#666) (#670)

v0.4.0
Compare Source
Added

New API package api/metric/registry that exposes a MeterImpl wrapper for use by SDKs to generate unique instruments. (#580)
Script to verify examples after a new release. (#579)

Removed

The dogstatsd exporter due to lack of support.
This additionally removes support for statsd. (#591)
LabelSet from the metric API.
This is replaced by a []core.KeyValue slice. (#595)
Labels from the metric API's Meter interface. (#595)

Changed

The metric export.Labels became an interface which the SDK implements and the export package provides a simple, immutable implementation of this interface intended for testing purposes. (#574)
Renamed internal/metric.Meter to MeterImpl. (#580)
Renamed api/global/internal.obsImpl to asyncImpl. (#580)

Fixed

Corrected missing return in mock span. (#582)
Update License header for all source files to match CNCF guidelines and include a test to ensure it is present. (#586) (#596)
Update to v0.3.0 of the OTLP in the OTLP exporter. (#588)
Update pre-release script to be compatible between GNU and BSD based systems. (#592)
Add a RecordBatch benchmark. (#594)
Moved span transforms of the OTLP exporter to the internal package. (#593)
Build both go-1.13 and go-1.14 in circleci to test for all supported versions of Go. (#569)
Removed unneeded allocation on empty labels in OLTP exporter. (#597)
Update BatchedSpanProcessor to process the queue until no data but respect max batch size. (#599)
Update project documentation godoc.org links to pkg.go.dev. (#602)

Changes since v0.3.0
f474c34 Script to verify example after new release. (#579)
5d346a4 update godoc.org links to pkg.go.dev (#602)
1e8e72b Process the queue until no data but respect max batch size (#599)
e8546e3 Remove Labelset (#595)
e7a9ba1 Remove unneeded allocation on empty labels (#597)
e458809 Build both go-1.13 and go-1.14 in circleci (#569)
c97b4f7 Update project License headers and checking (#596)
c9dcc1b Move span transforms of the OTLP exporter to internal (#593)
cfe74cf Add a RecordBatch benchmark (#594)
4c69dd3 Remove dogstatsd and statsd support (#591)
06f833e Unique instrument checking (#580)
dff6265 Pre-release script fixes (#592)
d648712 Kick label encoder out of sdk (#574)
6f881b4 update to proto v0.3.0 (#588)
a485d0e Update License header for all source files (#586)
c16f56e Fix missing return in mock span (#582)

Configuration
📅 Schedule: Branch creation - "every weekday" in timezone Europe/Paris, Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about these updates again.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

⚠ Artifact update problem
Renovate failed to update an artifact related to this branch. You probably do not want to merge this PR as-is.
♻ Renovate will retry this branch, including artifacts, only when one of the following happens:

any of the package files in this branch needs updating, or
the branch becomes conflicted, or
you click the rebase/retry checkbox if found above, or
you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:
File name: hello/dagger/go.sum
Command failed: go get -d -t ./...
go: -d flag is deprecated. -d=true is a no-op
go: dagger/hello imports
	dagger/hello/internal/dagger: package dagger/hello/internal/dagger is not in std (/opt/containerbase/tools/golang/1.23.2/src/dagger/hello/internal/dagger)


Optimize: Saga StateHandlerInterceptor and StateRouterInterceptor support SPI

Ⅰ. Describe what this PR did
Optimize: Saga StateHandlerInterceptor and StateRouterInterceptor support SPI
Ⅳ. Describe how to verify it

Add io.seata.saga.engine.pcext.StateHandlerInterceptor and  io.seata.saga.engine.pcext.StateRouterInterceptor file at classpath:/META-INF/services/ directory
File content is your implements of StateHandlerInterceptor and StateRouterInterceptor

Ⅴ. Special notes for reviews
see seata/test/src/test/resources/META-INF/services

Codecov Report

Merging #2584 into develop will decrease coverage by 0.14%.
The diff coverage is 100.00%.

@@              Coverage Diff              @@
##             develop    #2584      +/-   ##
=============================================
- Coverage      51.19%   51.04%   -0.15%
+ Complexity      2806     2804       -2
=============================================
  Files            554      554
  Lines          17774    17774
  Branches        2101     2072      -29
=============================================
- Hits            9099     9073      -26
- Misses          7817     7818       +1
- Partials         858      883      +25

Impacted Files
Coverage Δ
Complexity Δ

...ata/saga/proctrl/handler/DefaultRouterHandler.java
60.00% <100.00%> (ø)
7.00 <0.00> (ø)

...obuf/convertor/BranchRegisterRequestConvertor.java
90.47% <0.00%> (-9.53%)
3.00% <0.00%> (ø%)

...otobuf/convertor/GlobalBeginResponseConvertor.java
92.59% <0.00%> (-7.41%)
3.00% <0.00%> (ø%)

...otobuf/convertor/GlobalCommitRequestConvertor.java
93.75% <0.00%> (-6.25%)
3.00% <0.00%> (ø%)

...otobuf/convertor/GlobalStatusRequestConvertor.java
93.75% <0.00%> (-6.25%)
3.00% <0.00%> (ø%)

...obuf/convertor/GlobalRollbackRequestConvertor.java
93.75% <0.00%> (-6.25%)
3.00% <0.00%> (ø%)

...protobuf/convertor/RegisterTMRequestConvertor.java
94.73% <0.00%> (-5.27%)
3.00% <0.00%> (ø%)

...protobuf/convertor/RegisterRMRequestConvertor.java
90.47% <0.00%> (-4.77%)
3.00% <0.00%> (ø%)

...otobuf/convertor/BranchReportRequestConvertor.java
95.45% <0.00%> (-4.55%)
3.00% <0.00%> (ø%)

...tobuf/convertor/BranchReportResponseConvertor.java
95.45% <0.00%> (-4.55%)
3.00% <0.00%> (ø%)

... and 15 more

Codecov Report

Merging #2584 into develop will increase coverage by 0.73%.
The diff coverage is 100.00%.

@@              Coverage Diff              @@
##             develop    #2584      +/-   ##
=============================================
+ Coverage      50.18%   50.91%   +0.73%
+ Complexity      2919     2815     -104
=============================================
  Files            578      558      -20
  Lines          18724    17936     -788
  Branches        2253     2127     -126
=============================================
- Hits            9396     9132     -264
+ Misses          8396     7934     -462
+ Partials         932      870      -62

Impacted Files
Coverage Δ
Complexity Δ

...ata/saga/proctrl/handler/DefaultRouterHandler.java
60.00% <100.00%> (ø)
7.00 <0.00> (ø)

...ing/annotation/GlobalTransactionalInterceptor.java
8.80% <0.00%> (-15.81%)
2.00% <0.00%> (-5.00%)

...main/java/io/seata/core/rpc/netty/RmRpcClient.java
30.76% <0.00%> (-10.90%)
9.00% <0.00%> (-1.00%)

...main/java/io/seata/core/rpc/netty/TmRpcClient.java
63.04% <0.00%> (-8.15%)
9.00% <0.00%> (-1.00%)

...eata/core/rpc/netty/AbstractRpcRemotingClient.java
18.95% <0.00%> (-3.65%)
6.00% <0.00%> (-2.00%)

...a/io/seata/core/rpc/netty/AbstractRpcRemoting.java
10.55% <0.00%> (-1.95%)
4.00% <0.00%> (-1.00%)

.../main/java/io/seata/rm/datasource/ColumnUtils.java
75.47% <0.00%> (-1.32%)
18.00% <0.00%> (ø%)

...ava/io/seata/common/thread/NamedThreadFactory.java
90.00% <0.00%> (-0.48%)
6.00% <0.00%> (ø%)

server/src/main/java/io/seata/server/Server.java
0.00% <0.00%> (ø)
0.00% <0.00%> (ø%)

...re/src/main/java/io/seata/core/rpc/ClientType.java
0.00% <0.00%> (ø)
0.00% <0.00%> (ø%)

... and 49 more


Add TfLite micro Squeeze reference kernel

Add TfLite micro Squeeze reference kernel and tests (uint8, int8, float32).
Signed-off-by: SiCongLi<EMAIL_ADDRESS>

@njeffrie Sorry for the late reply. As far as we know, mobilenet uses squeeze but it also seems that it's only used in tensorflow not tflite?

@njeffrie @gbaned  Sorry for the late reply. I resolved the comment last week. Could you please review the changes I made? Thanks!

Hi @njeffrie. Could you please review the new patch I submitted when you have time? Thanks :)

@njeffrie Could you please give me an update on the new patch? Thanks!

@sicong-li-arm Did you get a chance to look on njeffrie's  comments? Please let us know on the update. Thanks!

Had a discussion with @njeffrie . Closing this as it's not required by most tflite models.


Removing constraints?

Is there a way to remove or break a constraint? I am currently making a game where the player can shoot a ball which will stick, and then the player will be able to swing off it like a grappling hook. I am using a constraint to allow the player to swing from this point, but would like to break it when the mouse is released. Is there a way to easily remove a constraint? All I can find are disable() and enable(), but the grappling point is being deleted so I would ideally like both to be removed at the same time.
Kind regards,
Matthew

Hi. Did you try world.removeConstraint()? http://schteppe.github.io/cannon.js/docs/classes/World.html#method_removeConstraint
Also see the tear demo: https://github.com/schteppe/cannon.js/blob/master/demos/tear.html

Thank you very much for the quick reply! It worked! I will send you a link to the game when I'm done with this bit! I just think grappling hooks are always fun in games!


Use isAvailableOnline as a checkbox filter [FE]

Definition of Ready
https://github.com/wellcomecollection/content-api/issues/107 is Done
What
Add a checkbox filter in the Events search. We don't have those yet, so it will require the creation of a flexible "checkbox/boolean" filter.
Done when

New boolean filter is created
Checkbox has disabled styles
Query functions well

Started a PR here and it works well https://github.com/wellcomecollection/wellcomecollection.org/pull/10704, I just need to discuss a few things with @j-jaworski in terms of placement - more info in PR. Will move to blocked until I can have that chat.

Now available in prod (see events search behind toggle)


[Hub Generated] Publish private branch 'rahuls-microsoft-quota-Microsoft.Quota-GroupQuota-Update'

This is a PR generated at OpenAPI Hub. You can view your work branch via this link.
ARM (Control Plane) API Specification Update Pull Request

[!TIP]
Overwhelmed by all this guidance? See the Getting help section at the bottom of this PR description.

[!NOTE]
As of January 2024 there is no PR assignee. This is expected. See https://aka.ms/azsdk/pr-arm-review.

PR review workflow diagram
Please understand this diagram before proceeding. It explains how to get your PR approved & merged.

 Click here to see the details of Step 1
Breaking changes review (Diagram Step 1)
If the automation determines you have breaking changes, i.e. Step 1 from the diagram applies to you,
you must follow the breaking changes process.
IMPORTANT This applies even if:

The tool fails while it shouldn't, e.g. due to runtime exception, or incorrect detection of breaking changes.
You believe there is no need for you to request breaking change approval, for any reason.
Such claims must be reviewed, and the process is the same.

 Click here to see the details of Step 2
ARM API changes review (Diagram Step 2)

For help with Step 2 / "ARM review", see https://aka.ms/azsdk/pr-arm-review.

 Click here to see the diagram footnotes
Diagram footnotes
[1] See ARM review queue (for PR merge queues, see [2]).
[2] public repo merge queue, private repo merge queue (for ARM review queue, [1])
The ARM reviewer on-call engineer visits the merge queue twice a day, so the approximate ETA for merges is 12 - 24 hours.

Purpose of this PR
What's the purpose of this PR? Check the specific option that applies. This is mandatory!

[ ] New resource provider.
[ ] New API version for an existing resource provider. (If API spec is not defined in TypeSpec, the PR should have been generated using OpenAPI Hub).
[ ] Update existing version for a new feature. (This is applicable only when you are revising a private preview API version.)
[ ] Update existing version to fix OpenAPI spec quality issues in S360.
[ ] Other, please clarify:

edit this with your clarification

Due diligence checklist
To merge this PR, you must go through the following checklist and confirm you understood
and followed the instructions by checking all the boxes:

[ ] I confirm this PR is modifying Azure Resource Manager (ARM) related specifications, and not data plane related specifications.
[ ] I have reviewed following Resource Provider guidelines, including
ARM resource provider contract and
REST guidelines (estimated time: 4 hours).
I understand this is required before I can proceed to the diagram Step 2, "ARM API changes review", for this PR.

Additional information

 Viewing API changes
For convenient view of the API changes made by this PR, refer to the URLs provided in the table
in the Generated ApiView comment added to this PR. You can use ApiView to show API versions diff.

Suppressing failures
If one or multiple validation error/warning suppression(s) is detected in your PR, please follow the
suppressions guide to get approval.

Getting help

First, please carefully read through this PR description, from top to bottom. Please fill out the Purpose of this PR and Due diligence checklist.
To understand what you must do next to merge this PR, see the Next Steps to Merge comment. It will appear within few minutes of submitting this PR and will continue to be up-to-date with current PR state.
For guidance on fixing this PR CI check failures, see the hyperlinks provided in given failure
and https://aka.ms/ci-fix.
For help with PR workflow diagram Step 2 (ARM review), see https://aka.ms/azsdk/pr-arm-review.
If the PR CI checks appear to be stuck in queued state, please add a comment with contents /azp run.
This should result in a new comment denoting a PR validation pipeline has started and the checks should be updated after few minutes.
If the help provided by the previous points is not enough, post to https://aka.ms/azsdk/support/specreview-channel and link to this PR.

The PR is created based on the updates in the private branch. The updates in the PR has already been reviewed and approved with this PR Azure/azure-rest-api-specs-pr/15893

@msyyc This is the new PR based on the PR branch with the history.
So, all the approval should be visible.
Please let me know, if any further action is needed from my side?
Thanks for your help to merge this PR.

Please address or respond to feedback from the ARM API reviewer. When you are ready to continue the ARM API review, please remove the ARMChangesRequested label. This will notify the reviewer to have another look. If the feedback provided needs further discussion, please use this Teams channel to post your questions - aka.ms/azsdk/support/specreview-channel. Please include [ARM Query] in the title of your question to indicate that it is ARM-related.

The new API version is getting updated. No customer, user onboarded. The API was changed based on the ARM team's suggestion, as ARM routing was not working 3 providers in the URI.
The details are reviewed by ARM multiple ARM team members and signed off.

After ARMSignedOff label marked, SDK review will finish within one day

[ARM Query] Hi ARM Team, the swagger was reviewed by ARM team members, which you can see in the history. Please let me know if there any questions.
Original PR on PR branch was - https://github.com/Azure/azure-rest-api-specs-pr/pull/15893
Snapshot from the PR for reference-

[ARM Query] Hi ARM Team, the swagger was reviewed by ARM team members, which you can see in the history. Please let me know if there any questions. Original PR on PR branch was - Azure/azure-rest-api-specs-pr#15893 Snapshot from the PR for reference-

Adding @TimLovellSmith Who reviewed the API from ARM side on the PR.

/azp run

Please get a breaking changes approval from Azure Breaking Changes Reviewers<EMAIL_ADDRESS>and ARM can review the changes afterwards.
And fix the lint diff error and model validation error.

Please get a breaking changes approval from Azure Breaking Changes Reviewers<EMAIL_ADDRESS>and ARM can review the changes afterwards.
And fix the lint diff error and model validation error.

The changes are for the new GroupQuota APIs. And no customers are onboarded yet. So, there should not be any impact. For Private preview, the GroupQuota API was changed based on ARM team suggestions, as there were 3 providers in the URL, which was breaking ARM routing.
It was already reviewed and signed off.
Do we need to get started again with all the process? We have spent more than a month going through all the reviews!
Please check the previous approvals. So, that we can expedite the process.

Hi ARM Reviewer -

This is the private preview of API, no customer is onboarded, hence won't require BreakingChange review.
This API was approved in the PR branch by ARM reviewers. Please check the notes in original PR on PR branch was - https://github.com/Azure/azure-rest-api-specs-pr/pull/15893
This is a new API version, still getting ready for Private Preview.

Please let me know if there are any questions to expedite the review process.

/azp run

@msyyc Please let me know if any action is needed from my side?
When we can merge the swagger and generate the SDKs, as lots of internal teams are waiting for it to onboard the new GroupQuota APIs.
Thanks for your help and expedited action.

The remaining LintDiff errors are already approved, as -

This API is at MG level, not subscription level.
The filter parameters are added after ARM review discussion, as ARM routing doesn't work with 3 providers in URI.

Please let me know how I can help to expedite the merging.
Thanks.
Rahul.

Hi @msyyc
The remaining LintDiff errors are already approved, as -

This API is at MG level, not subscription level.
The filter parameters are added after ARM review discussion, as ARM routing doesn't work with 3 providers in URI.

Please let me know how I can help to expedite the merging.

Approved for python

Please let me know when we can merge to main and get the SDKs ready for internal customers.
Thanks for your help.!

Based on the flow:

The SDK breaking change, Suppression review was already approved.
Can we proceed?
Please let me know how I can expedite the process and give our internal teams the .Net and other SDKs next week. Teams are waiting, so please help. Thanks.

Please let me know whom I should contact to expedite the process.

@JeffreyRichter Please approve the breaking change as we discussed and got your approval in PR- https://github.com/Azure/azure-rest-api-specs-pr/pull/15893

@konrad-jamrozik
Please approve the breaking change as we discussed and got your approval in PR- https://github.com/Azure/azure-rest-api-specs-pr/pull/15893

@ms-henglu  Please approve the PR as we discussed and got your approval in PR- https://github.com/Azure/azure-rest-api-specs-pr/pull/15893

Why do you have filter query parameters on the path

"/providers/Microsoft.Management/managementGroups/{managementGroupId}/subscriptions/{subscriptionId}/providers/Microsoft.Quota/groupQuotas/{groupQuotaName}/quotaAllocations/{resourceName}": {

Do not have duplicate name of x-ms-example, make sure every x-ms-example name unique. Duplicate x-ms-example: Quotas_UsagesRequest_ForNetworkLocation: Microsoft.Quota/preview/2023-06-01-preview/quota.json#L143

@TimLovellSmith I have updated the APIs we discussed during the meeting.
There are few finer details related to model validations, Examples I will fix it. Please look at the API, request, and response - If any changes are needed there once the API requests and response looks fine, I can update the examples accordingly for the Model validation. Thanks for your help.

@TimLovellSmith I have updated the APIs we discussed during the meeting.
There are few finer details related to model validations, Examples I will fix it. Please look at the API, request, and response - If any changes are needed there once the API requests and response looks fine, I can update the examples accordingly for the Model validation. Thanks for your help .

/azp run

@TimLovellSmith -
We discuss this regarding this API-  "/providers/Microsoft.Management/managementGroups/{managementGroupId}/providers/Microsoft.Quota/groupQuotas/{groupQuotaName}/resourceProviders/{resourceProviderName}/groupQuotaRequests"
The request body supports singles resource, but the get is a list API.
There is another Det API with requestID- "/providers/Microsoft.Management/managementGroups/{managementGroupId}/providers/Microsoft.Quota/groupQuotas/{groupQuotaName}/groupQuotaRequests/{requestId}"
This should be fine, right?

EvenSegmentedPathForPutOperation | API path with PUT operation defined MUST have even number of segments (i.e. end in {resourceType}/{resourceName} segments).Location: Microsoft.Quota/preview/2023-06-01-preview/groupquota.json#L734 | RPC-Put-V1-02
-- | -- | --
❌ PutGetPatchResponseSchema | /providers/Microsoft.Management/managementGroups/{managementGroupId}/providers/Microsoft.Quota/groupQuotas/{groupQuotaName}/resourceProviders/{resourceProviderName}/groupQuotaRequests has different responses for PUT/GET/PATCH operations. The PUT/GET/PATCH operations must have same schema response.Location: Microsoft.Quota/preview/2023-06-01-preview/groupquota.json#L734

[EvenSegmentedPathForPutOperation](https://github.com/Azure/azure-openapi-validator/blob/main/docs/even-segmented-path-for-put-operation.md)	API path with PUT operation defined MUST have even number of segments (i.e. end in {resourceType}/{resourceName} segments).
Location: [Microsoft.Quota/preview/2023-06-01-preview/groupquota.json#L734](https://github.com/Azure/azure-rest-api-specs/blob/75e90f690c048bd0ac5dcd06667737ca9bdbd0ef/specification/quota/resource-manager/Microsoft.Quota/preview/2023-06-01-preview/groupquota.json#L734)	RPC-Put-V1-02
❌ [PutGetPatchResponseSchema](https://github.com/Azure/azure-openapi-validator/blob/main/docs/put-get-patch-response-schema.md)	/providers/Microsoft.Management/managementGroups/{managementGroupId}/providers/Microsoft.Quota/groupQuotas/{groupQuotaName}/resourceProviders/{resourceProviderName}/groupQuotaRequests has different responses for PUT/GET/PATCH operations. The PUT/GET/PATCH operations must have same schema response.
Location: [Microsoft.Quota/preview/2023-06-01-preview/groupquota.json#L734](https://github.com/Azure/azure-rest-api-specs/blob/75e90f690c048bd0ac5dcd06667737ca9bdbd0ef/specification/quota/resource-manager/Microsoft.Quota/preview/2023-06-01-preview/groupquota.json#L734)

For - This error -

❌ ProvisioningStateSpecifiedForLROPut | 200 response schema in long running PUT operation is missing ProvisioningState property. A LRO PUT operations response schema must have ProvisioningState specified for the 200 and 201 status codes.Location: Microsoft.Quota/preview/2023-06-01-preview/groupquota.json#L735
-- | --

The response contains the provisioningState - Why it's complaining?
"SubmittedResourceRequestStatus": {
"type": "object",
"description": "Status of a single GroupQuota request.",
"properties": {
"requestedResource": {
"description": "Requested Resource.",
"$ref": "#/definitions/QuotaAllocationRequestBase"
},
"requestSubmitTime": {
"description": "The request submission time. The date conforms to the following format specified by the ISO 8601 standard: yyyy-MM-ddTHH:mm:ssZ",
"type": "string",
"readOnly": true,
"format": "date-time"
},
"provisioningState": {
"$ref": "#/definitions/RequestState",
"readOnly": true
},
"faultCode": {
"type": "string",
"description": "Details of the failure.",
"readOnly": true
}
}
},❌ ProvisioningStateSpecifiedForLROPut	200 response schema in long running PUT operation is missing ProvisioningState property. A LRO PUT operations response schema must have ProvisioningState specified for the 200 and 201 status codes.
Location: Microsoft.Quota/preview/2023-06-01-preview/groupquota.json#L735

200 response schema in long running PUT operation is missing ProvisioningState property. A LRO PUT operations response schema must have ProvisioningState specified for the 200 and 201 status codes.
Location: Microsoft.Quota/preview/2023-06-01-preview/groupquota.json#L735
The   "provisioningState": "Accepted" is included int 200, 201 responses. At what level it requires this field to be include? Please suggest.

@TimLovellSmith  Please review the PR, as you have context to the PR.
All the changes suggested during the meeting have been included. Thanks.

@TimLovellSmith  - Do we need to define all long running operations status API in swagger? Its
based on -
https://github.com/Azure/azure-resource-manager-rpc/blob/master/v1.0/Addendum.md#202-accepted-and-location-headers.  New guidelines - https://github.com/microsoft/api-guidelines/blob/vNext/Guidelines.md#131-resource-based-long-running-operations-relo
Any changes to schema.  it pops other violations. intermediate response!
So, please suggest what's needed?  Thanks for your help and guidance.

Please get a breaking changes approval from Azure Breaking Changes Reviewers<EMAIL_ADDRESS>and fix following errors. After that, please remove the "ARMChangesRequested" label from the PR to make the PR visible to the ARM reviewers.
https://github.com/Azure/azure-rest-api-specs/pull/27847/checks?check_run_id=22908400343
https://github.com/Azure/azure-rest-api-specs/pull/27847/checks?check_run_id=22908400968

@ms-zhenhua _ Please let's know what changes are required.
We addressed most of the issues.
The filters and moving the put Apis to match semantics was made after discussion with @TimLovellSmith .

We have get some exceptions as - ARM has limitation of only 3 child resources.
The uri cannot have more than 2 providers, else ARM routing breaks.

Please suggest -

What changes you are recommending?
We can setup a meeting with  you, if you want more details.

We need to commit the changes this week, so your help to resolve the open questions/issues is appriciated.

TO address the issues flagged-
AzureRestAPISpecReview added ARMChangesRequested and removed WaitForARMFeedback BreakingChangeReviewRequired labels 14 hours ago

BreakingChangeReviewRequired - This API is in Private preview, no customer onboarded so, breakingChange Review shoudn't be required. If required then I can explain it to the reviewer. Who should I contact? I was already approved on the PR branch.
ARMChangesRequested - Please let's know -
What specific changes or suggestions you have?
Some of the rules or checks doesn't apply or we have get the exception, as explained erlier due to ARM restrictions and limitations.

I would greatly apricate your help to expedite the process and finish it this week.

@rahuls-microsoft Seems that we still have a couple linting errors about filters in point GET. I thought we were going to get rid of all of those.

Query parameter $filter should be removed. Point Get's MUST not have query parameters other than api version.

E.g. paths:
/providers/Microsoft.Management/managementGroups/{managementGroupId}/subscriptions/{subscriptionId}/providers/Microsoft.Quota/groupQuotas/{groupQuotaName}/quotaAllocations/{resourceName}
/providers/Microsoft.Management/managementGroups/{managementGroupId}/providers/Microsoft.Quota/groupQuotas/{groupQuotaName}/resourceProviders/{resourceProviderName}/groupQuotaLimits/{resourceName}

Please add a suppression for the TenantLevelAPIIsNotAllowed error

For the 'location' parameters, would you need to suppress this error, or is there a way you intend to change the API?
Its also potentially going to confuse people having 'name' and 'location' within the GroupQuotaDetails, but also at the top level in any properties you inherit from ProxyResource. Do you need them at both levels? Could the non-top-level properties be renamed, or would doing that rename lead to a different kind of confusion?

Property location must have 'x-ms-mutability':['read', 'create'] extension defined.
Location: Microsoft.Quota/preview/2023-06-01-preview/groupquota.json#L1845

"GroupQuotaDetails": {
"type": "object",
"description": "Group Quota details.",
"properties": {
"location": {
"$ref": "#/definitions/LocationScope"
},

You can ignore the 'Consider using x-ms-client-flatten to provide a better end user experience' warnings.

Making enforcement enabled a boolean makes it hard to extend in the future in case you want to overload the 'on' 'off' option with other meanings.
"enforcementEnabled": {
"type": "boolean",
"description": "Is the GroupQuota Enforcement enabled for the Azure region."
},

Making enforcement enabled a boolean makes it hard to extend in the future in case you want to overload the 'on' 'off' option with other meanings.
"enforcementEnabled": { "type": "boolean", "description": "Is the GroupQuota Enforcement enabled for the Azure region." },

Add a suppression if you're sure you'll never extend it in the future.

Please fix the unique xms example name warnings

Do not have duplicate name of x-ms-example, make sure every x-ms-example name unique. Duplicate x-ms-example: SubscriptionQuotaAllocation_List_Request_ForCompute
Location: Microsoft.Quota/preview/2023-06-01-preview/groupquota.json#L1135

Making enforcement enabled a boolean makes it hard to extend in the future in case you want to overload the 'on' 'off' option with other meanings.
"enforcementEnabled": { "type": "boolean", "description": "Is the GroupQuota Enforcement enabled for the Azure region." },

Will make it enum as suggested for future extension.

For the 'location' parameters, would you need to suppress this error, or is there a way you intend to change the API?
Its also potentially going to confuse people having 'name' and 'location' within the GroupQuotaDetails, but also at the top level in any properties you inherit from ProxyResource. Do you need them at both levels? Could the non-top-level properties be renamed, or would doing that rename lead to a different kind of confusion?

Property location must have 'x-ms-mutability':['read', 'create'] extension defined.
Location: Microsoft.Quota/preview/2023-06-01-preview/groupquota.json#L1845

"GroupQuotaDetails": { "type": "object", "description": "Group Quota details.", "properties": { "location": { "$ref": "#/definitions/LocationScope" },

will rename it to azureRegion, so that the user understands it and doesn't conflicts with location.

Please add a suppression for the TenantLevelAPIIsNotAllowed error

Will add supression.

@rahuls-microsoft Seems that we still have a couple linting errors about filters in point GET. I thought we were going to get rid of all of those.

Query parameter $filter should be removed. Point Get's MUST not have query parameters other than api version.

E.g. paths:
/providers/Microsoft.Management/managementGroups/{managementGroupId}/subscriptions/{subscriptionId}/providers/Microsoft.Quota/groupQuotas/{groupQuotaName}/quotaAllocations/{resourceName}
/providers/Microsoft.Management/managementGroups/{managementGroupId}/providers/Microsoft.Quota/groupQuotas/{groupQuotaName}/resourceProviders/{resourceProviderName}/groupQuotaLimits/{resourceName}

The location/region is required to make this API usable for the end-user. As the end-user is checking for a specific region quota, without that parameter, how will this API work?
The $filter parameter was suggested by the ARM team and resources API use oDatFilter $filter, as ARM team suggested.
Please suggest an API which returns resources Quota for RP/location.

For the 'location' parameters, would you need to suppress this error, or is there a way you intend to change the API?
Its also potentially going to confuse people having 'name' and 'location' within the GroupQuotaDetails, but also at the top level in any properties you inherit from ProxyResource. Do you need them at both levels? Could the non-top-level properties be renamed, or would doing that rename lead to a different kind of confusion?

Property location must have 'x-ms-mutability':['read', 'create'] extension defined.
Location: Microsoft.Quota/preview/2023-06-01-preview/groupquota.json#L1845

"GroupQuotaDetails": { "type": "object", "description": "Group Quota details.", "properties": { "location": { "$ref": "#/definitions/LocationScope" },

will rename it to azureRegion, so that the user understands it and doesn't conflicts with location.

Changed the name to region

@rahuls-microsoft Seems that we still have a couple linting errors about filters in point GET. I thought we were going to get rid of all of those.

Query parameter $filter should be removed. Point Get's MUST not have query parameters other than api version.

E.g. paths:
/providers/Microsoft.Management/managementGroups/{managementGroupId}/subscriptions/{subscriptionId}/providers/Microsoft.Quota/groupQuotas/{groupQuotaName}/quotaAllocations/{resourceName}
/providers/Microsoft.Management/managementGroups/{managementGroupId}/providers/Microsoft.Quota/groupQuotas/{groupQuotaName}/resourceProviders/{resourceProviderName}/groupQuotaLimits/{resourceName}

**The location/region is required to make this API usable for the end-user. As the end-user is checking quota for a specific region, without that parameter, how will this API work? The $filter parameter was suggested by the ARM team and resources API use oDatFilter $filter, as ARM team suggested.
Current Resources API, based on which the aRM team suggested to use $filter to address the limitation of having only 3 child resources, else ideally location should be part of the url.
Example: GET https://management.azure.com/subscriptions/{subscriptionId}/resources?$filter={$filter}&$expand={$expand}&$top={$top}&api-version=2021-04-01**
Please suggest an API which returns resources Quota for RP/location.

@TimLovellSmith  - Please check the comments above. We discussed this limitation during our meeting to discuss the APIs.

 Please get a breaking changes approval from Azure Breaking Changes Reviewers<EMAIL_ADDRESS>and ARM can review the changes afterwards. Once you have the approval, please remove the "ARMChangesRequested" label from the PR to make the PR visible to the ARM reviewers.

 Please get a breaking changes approval from Azure Breaking Changes Reviewers<EMAIL_ADDRESS>and ARM can review the changes afterwards. Once you have the approval, please remove the "ARMChangesRequested" label from the PR to make the PR visible to the ARM reviewers.

Sent the email for Breaking change review and created the template work item with detila-
https://msazure.visualstudio.com/One/_workitems/edit/27312269

/azp run

Hi, Please let's know, if there is any changes needed, as the merge is not completed.

Hi, Please let's know, if there is any changes needed, as the merge is not completed.

I see these 2 errors-

For Avocado error it is complaining about the unreferenced examples file for the stable APIs. So, I think We can ignore that.
https://github.com/Azure/azure-rest-api-specs/runs/23415484873 - For .net2 SDK track, please look into it and let me know, if any changes needed for SDK?
From logs- The error is not clear, please check it and let me know, if any changes needed from myside?
command	pwsh ./eng/scripts/Automation-Sdk-Init.ps1 ../azure-sdk-for-net_tmp/initInput.json ../azure-sdk-for-net_tmp/initOutput.json
command	pwsh ./eng/scripts/Invoke-GenerateAndBuildV2.ps1 ../azure-sdk-for-net_tmp/generateInput.json ../azure-sdk-for-net_tmp/generateOutput.json
cmderr	[Invoke-GenerateAndBuildV2.ps1] GeneratePackage: /mnt/vss/_work/1/s/azure-sdk-for-net/eng/scripts/automation/GenerateAndBuildLib.ps1:714
cmderr	[Invoke-GenerateAndBuildV2.ps1] Line |
cmderr	[Invoke-GenerateAndBuildV2.ps1]  714 |          GeneratePackage -projectFolder $projectFolder -sdkRootPath $s …
cmderr	[Invoke-GenerateAndBuildV2.ps1]      |          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cmderr	[Invoke-GenerateAndBuildV2.ps1]      | Failed to generate sdk. exit code: False
cmderr	[Invoke-GenerateAndBuildV2.ps1] Get-ChildItem: /mnt/vss/_work/1/s/azure-sdk-for-net/eng/scripts/automation/GenerateAndBuildLib.ps1:807
cmderr	[Invoke-GenerateAndBuildV2.ps1] Line |
cmderr	[Invoke-GenerateAndBuildV2.ps1]  807 |  … rtifacts += Get-ChildItem $artifactsPath -Filter *.nupkg -exclude *.s …
cmderr	[Invoke-GenerateAndBuildV2.ps1]      |                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cmderr	[Invoke-GenerateAndBuildV2.ps1]      | Cannot find path
cmderr	[Invoke-GenerateAndBuildV2.ps1]      | '/mnt/vss/_work/1/s/azure-sdk-for-net/artifacts/packages/Debug/' because
cmderr	[Invoke-GenerateAndBuildV2.ps1]      | it does not exist.
cmderr	[Invoke-GenerateAndBuildV2.ps1] GeneratePackage: /mnt/vss/_work/1/s/azure-sdk-for-net/eng/scripts/automation/GenerateAndBuildLib.ps1:714
cmderr	[Invoke-GenerateAndBuildV2.ps1] Line |
cmderr	[Invoke-GenerateAndBuildV2.ps1]  714 |          GeneratePackage -projectFolder $projectFolder -sdkRootPath $s …
cmderr	[Invoke-GenerateAndBuildV2.ps1]      |          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cmderr	[Invoke-GenerateAndBuildV2.ps1]      | Failed to generate sdk artifact

❌Azure.ResourceManager.Quota [View full logs]  [Preview SDK Changes]

info	[Changelog]

/azp run

For Python breaking change. Please let me know if any action is needed from my side.

/azp run

/azp run

[like]  Tejas Manjunath reacted to your message:

From: Rahul Singh @.>
Sent: Friday, April 5, 2024 5:11:32 PM
To: Azure/azure-rest-api-specs @.>
Cc: Tejas Manjunath @.>; Comment @.>
Subject: Re: [Azure/azure-rest-api-specs] [Hub Generated] Publish private branch 'rahuls-microsoft-quota-Microsoft.Quota-GroupQuota-Update' (PR #27847)
/pr RequestMerge
—
Reply to this email directly, view it on GitHubhttps://github.com/Azure/azure-rest-api-specs/pull/27847#issuecomment-2040281859, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BAYULQQM5WNAGSCAVLYEYKTY33LMJAVCNFSM6AAAAABDSKUTQOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBQGI4DCOBVHE.
You are receiving this because you commented.Message ID: @.***>

@ms-henglu @msyyc Requesting to merge the PR.