[openuserjs] Add OpenUserJS service badges

Fixes #5505 (when merged along with #8080 being merged)
Partially resolved - #829
API endpoint - https://openuserjs.org/meta/username/scriptname.meta.json
Documentation - https://openuserjs.org/about/Frequently-Asked-Questions#q-does-openuserjs-org-have-meta-

Messages

:book:
:sparkles: Thanks for your contribution to Shields, @DenverCoder1!

  Generated by :no_entry_sign: dangerJS against 249d2952c792b02459f8c7b62fe41540aaab8d1a

All tests are passing locally

@calebcartwright
Up to this point I see no other issues from our stand-point. I don't fully understand every bit of the code for this but that's all I can analyze for now. Official :+1:  from us. :smile_cat:
OUJS Admin / OUJS Co-Owner

Thanks to all involved, it's nice coming into a PR that's already had thorough discussion and review :smile:
Couple questions before I dive in:

Is there any public documentation for the endpoint? Doesn't need to be anything official, swagger page or even wiki/markdown content in a repo. We integrate with a large number of services, many of which we aren't familiar with ourselves, and it's helpful to know where to go for more info/bug reports/etc.
Are there rate limits applied to this endpoint, and if so what are those current limits?

Is there any public documentation for the endpoint? Doesn't need to be anything official, swagger page or even wiki/markdown content in a repo. We integrate with a large number of services, many of which we aren't familiar with ourselves, and it's helpful to know where to go for more info/bug reports/etc.

The existence of the page is documented at https://openuserjs.org/about/Frequently-Asked-Questions#q-does-openuserjs-org-have-meta- The .meta.json endpoint is being used.

Are there rate limits applied to this endpoint, and if so what are those current limits?

@Martii may have a full answer. From what I've seen, usual requests to .meta.json don't seem to have a very strict ratelimit if any at all. But for 404 pages (eg. scripts that don't exist), it seems to get a 429 after about 3 requests within every few seconds.

Thanks @DenverCoder1. Would be good to get a feel for what those are and to see what our options are. We do have some caching knobs we can tune but want to know what we're working with.
Also as an aside, you don't necessarily have to worry about updating the branch until we get close to being ready to merge. It's more of a final check we have in place to make sure there's no conflicting work and that the changes will be fine atop the trunk branch, but it's not necessary to add merge commits any time an unrelated PR gets merged.

Are there rate limits applied to this endpoint, and if so what are those current limits?

Currently no... see:
https://github.com/OpenUserJS/OpenUserJS.org/blob/a9cbf7d6670d5232bae44f284129a63d758210fb/routes.js#L148-L150
This could change if it is abused but so far knock on things. We're thinking about pruning @icon or "nubbing" it to our basic icons depending on how much bandwidth comes into play as the user base increases... but for now it's minimally managed.

I appreciate you sharing relevant snippets from the codebase but I'm going to ask some follow up questions anyway to avoid incorrect assumptions about the source code, gain a better understanding of potential future plans, to account for anything else in the system architecture that could be at apply above/before the running app, etc.
the meta json endpoint is the only one we'll need

is my understanding correct that this is not currently rate limited, and there's no explicit plans to change that? (understand you reserve the right to change it in the future regardless)
how frequently does the meta.json file get updated? we rely on cache pretty heavily but have a standard set of ttl periods used by default across all badges for a given family (version vs. build status vs. etc.), but we can override the ttl for individual badges too.
admittedly anecdotal, but the rate limiting that gets applied on 404 requests for the meta endpoint appear to get reset quite quickly, and, fortunately for us, doesn't seem to have any impact on a request for a valid/found script. Am I correct in assuming that's the behavior we should be expecting? It's important for us because we wouldn't want a handful of 404-type badge requests we receive to limit/lock out Shields.io and our ability to serve up these badges

is my understanding correct that this is not currently rate limited, and there's no explicit plans to change that? (understand you reserve the right to change it in the future regardless)

Correct and what I've already stated.

how frequently does the meta.json file get updated?

Any time the script gets updated which can be as little as never or as maximum as reposting allows (hence the short period you mentioned next). We do however cache in a browser for a maximum of 7 days for HTTP 1 caching and immediately on eTag for HTTP 1.1 if changed.

Am I correct in assuming that's the behavior we should be expecting?

Same as your first question bullet point answer here.

It's important for us because we wouldn't want a handful of 404-type badge requests we receive to limit/lock out Shields.io and our ability to serve up these badges.

If you have an endpoint similar to GitHub's (for synchronizing a repo here to us... mentioned at https://api.github.com/meta ... possibly much simpler than GH's of course) we'd be more than happy to add Shield's server IP to a special list.
Also note other UserScript sites (including GitHub) has rate limiting so most of these questions probably should be asked/checked as well. :smile_cat:

@Martii

Correct and what I've already stated.

I appreciate you taking the time to participate in the review and dialog here as we consider potentially adding a feature to our platform that would primarily be utilized by users of your platform.
However, please keep in mind that we integrate with and provide badges for hundreds of platforms/services, the overwhelming majority of which, including OpenUserJS, we do not use ourselves and have no familiarity with. You are obviously very familiar with your service, but the discussion here has been heavy on acronyms and tribal knowledge, and relative to the other services we integrate with, there's not a lot of API documentation through which we could edify ourselves.
We're still trying to play catch up, and clarifying questions are being asked because we don't feel we had sufficient clarity. Even if things looked and felt sufficiently clear to you, I'd still kindly ask that you refrain from the "already answered" types of comments and their associated implications.

If you have an endpoint similar to GitHub's (for synchronizing a repo here to us... mentioned at https://api.github.com/meta ... possibly much simpler than GH's of course) we'd be more than happy to add Shield's server IP to a special list.

Understand the inclination but this won't be viable for us. Our runtime is dynamically scaled and ephemeral with dynamic IP addresses. As such when we engage with vendors/maintainers of platforms that have concerns around load, we typically look to adjust cache settings on our end and/or change to a model where the Shields requests are authenticated using an account the vendor/maintainers have granted a higher rate limit.
However, this doesn't sound like something that can/should be solved in the abstract, especially given your confirmation around the not found rate limiting behavior. If the traffic Shields sends to OpenUserJS starts to become a problem down the road, please don't hesitate to reach out and we'll work to find an appropriate solution (we send info in the request headers that could be used to filter our traffic from the rest).

Also note other UserScript sites (including GitHub) has rate limiting so most of these questions probably should be asked/checked as well. smile_cat

Sorry, but I don't understand what you're saying at all. Are saying that we need to ask/investigate the questions I've asked you about OpenUserJS against all the other services we integrate with? If so, thanks, but we're all set. I ask these questions of you because these are the standard set of questions we consider when adding support for a new service/platform, and we're very, very familiar with GitHub's rate limits and how to work with them at mass scale.

@calebcartwright

including OpenUserJS, we do not use ourselves and have no familiarity with

I am quite familiar with that and we've been using Shields for about 10 years and I've personally dealt with this repo before. :smile:

I'd still kindly ask that you refrain from the "already answered" types of comments and their associated implications.

Apologies that your perception was skewed on this. Directness is our goal not beating around the bush.

Our runtime is dynamically scaled and ephemeral with dynamic IP addresses.

So is GitHub but we'll just treat Shields in the same traffic pattern as a Guest then. No big deal. Thought I'd offer an improvement on Shields via our site, if it wasn't already available, since the retrieval on NPM is about 98% instead of the alluded 100%... but is mostly reliable compared to others.

please don't hesitate to reach out and we'll work to find an appropriate solution

That's actually why we are here now to keep the bugs to a minimum for now. :smile_cat:  And of course... there's always the dynamic badges anyhow for Authors to utilize if things change outside of my current Active Maintainer scope.

Are saying that we need to ask/investigate the questions I've asked you about OpenUserJS against all the other services we integrate with?

Recommending being impartial yes as to not be monopolistic in nature.

If so, thanks, but we're all set. I ask these questions of you because these are the standard set of questions we consider when adding support for a new service/platform, and we're very, very familiar with GitHub's rate limits and how to work with them at mass scale.

There's more than just GitHub. We chose GitHub as a comment discussion point as it is familiar to all of use since we are all here for objectivity. You skipped this validation within the last three weeks. Just hoping for some objectivity from Shields instead of what our team has observed and perceived as a dual standard. Again we don't beat around the bush and we do appreciate your service as do others.
Anyhow.... if you feel the need to ask more questions I am available at your leisure but you are reminded that literal answer will be given at all times through my successful communications and lifetime accolades. @DenverCoder1 has plenty of accolades as well and this is the first we have enjoyed dealing with his organization/himself as he keeps his objectivity which is what our community strives for. :+1:

@Martii - I was trying to give you a gentle nudge but allow me to be more direct this time. You may believe you're simply being blunt/literal, but your comments are coming across with an increasingly flippant tone. I need you to stop and ask you to be mindful of this caution should you choose to continue engaging in the conversation.
Your comments give the impression of at least being mildly irked that I posted a summarizing/clarifying comment, and then noted that impression. Perhaps I misunderstood, but that's how they come across, and when it comes to intra-human communications I think the phrase "perception is reality" holds a lot of water. I hope it was just a simple misunderstanding, but I also apologize if I've offended in any way. Again, I understand you feel you've been unequivocally clear in your brief commentary, but please remember that your perception doesn't inherently mean your shorthand is actually clear to everyone else. It wasn't, but we're in a better state now.

Recommending being impartial yes as to not be monopolistic in nature.

There's more than just GitHub. We chose GitHub as a comment discussion point as it is familiar to all of use since we are all here for objectivity. You skipped this validation within the last three weeks. Just hoping for some objectivity from Shields instead of what our team has observed and perceived as a dual standard. Again we don't beat around the bush and we do appreciate your service as do others.
Anyhow.... if you feel the need to ask more questions I am available at your leisure but you are reminded that literal answers will be given at all times through my successful communications and lifetime accolades. @DenverCoder1 has plenty of accolades as well and this is the first we have enjoyed dealing with his organization/himself as he keeps his objectivity which is what our community strives for. +1

This is over the top, and unnecessary. This sounds as if you feel OpenUserJS is being unfairly scrutinized, which is absolutely not the case. I will make the assumption that you are referring to the recent GreasyFork badges and are trying to conflate that instance to paint a broader, and incorrect, set of characterizations. To the best of my knowledge, neither of these two services had public documentation around their respective rate limits, however, rate limits still became a discussion point here because they were directly observed by the contributor and you were present as a maintainer of that service.
There's a pretty standard set of criteria we consider when adding badges for a new service, and when applicable, that includes rate limiting on the upstream service too. Not every one of those considerations is a "blocker" per se, but are things we try to wrap our heads around for each service.

I'm simply trying to ensure we have due diligence on our part to make sure we're operating as a good citizen with your platform and that we can provide a good badge experience to our users, nothing more and nothing less.
Also want to stress there's no hard feelings, and I hope we'll be able to get these badges incorporated. I just wanted to make sure we keep the conversation constructive, respectful, and in accordance with the the type of dialog we strive for here in our community.

I was trying to give you a gentle nudge but allow me to be more direct this time.

See the gentle nudge that one of our developers gave me to pass on gently to your team. So I'll reiterate their concern by re-quoting their concerns as posted by me:

Recommending being impartial yes as to not be monopolistic in nature.

... in which I'm starting to see the point due to your inappropriate escalation of the matter (mountain out of a molehill). I will and have given you appropriate respect and would hope to see that in your responses from now on instead of attacking the messenger in poor taste. :smile:

Perhaps I misunderstood, but that's how they come across

Text is always one of the worst ways to communicate unfortunately. As I mentioned your perception wasn't intended as a consequence and I was politely setting the record straight. If you would like even more direct... you are projecting some inadequacies that may have occurred to you, or this project, in the past. I'm sorry that you feel that way. Please don't project.
On the matter of perception mentioning:

the discussion here has been heavy on acronyms and tribal knowledge

... is confusing to say the least as I've done my personal best to cite just about everything and not use acronyms. One of our repos rules of thumb is not to use them whenver possible (like lgtm or tldr). If it doesn't meet your standards I apologize... I'll attempt to walk you through it even more which is always part of life (learning and teaching). Part of the communication here is not just DenverCoder1, you, and myself but all of the others that follow. So when I actually answer, and spend the time to cover all questions (hopefully all) by using quotations... please do not assume that it is being "irked" which is also unprofessional. I spent the time to answer all bullet points.  A lot of time was spent examining this PR including how Shields currently operates and breaking down your projects code to a point.
If you want even more direct:

This is where I get fuzzy on the Shields side.

... means exactly that I'm not seeing any kind of DoS protection, at least in this PR, that sticks out in the code. This is something Shields should probably make more clear (or at least cite) and where I toss the proverbial ball to you (since you are the current maintainer for this)... instead didn't get much back. You should have examined the headers if I were to assume the role you think I am playing (but definitely was not) even though you said your project does.

neither of these two services had public documentation around their respective rate limits,

They vary according to time and instances of DoS. Ours has been public for many years and mentioned directly by the contributor of this PR and was also mentioned by myself at https://github.com/badges/shields/pull/8081#discussion_r896481892 . Sorry you must have missed that. GF also has rate limiting and it's more discussed in their issues in their repo primarily and https://greasyfork.org/en/discussions/development with https://greasyfork.org/en/discussions/greasyfork . I asked DenverCoder to check something for them as I was unable to get to dev station to confirm myself as I am on GF as well but not actively. There's nothing "covert" about our documentation... it's all there under industry standard terminology for searching (which I'll do when asked and have available time). If you want definitive you have the link again. :smile: I'll probably add the minimally managed to it next cycle if not sooner for your projects clarification.

however, rate limits still became a discussion point here because they were directly observed by the contributor and you were present as a maintainer of that service.

Yes because we do our best to pay attention to all linkage even if it's another project or more. I saw a potential issue with this PR even though wasn't directly summoned here and it  helped my understanding on NatoBorams original request even better than the last time. In addition it gave some insights into the service badges vs dynamic badges.
So teaching is something that should be accepted and not interpreted as a Psychology exam of being "over the top" in which case you have already projected multiple times. I really don't have time to have philosophical debates with your trying to incorrectly analyze the situation. Don't read into things instead listen and be considerate like I have been. If you want "nasty" to justify your position we'll take things elsewhere... it's as simple as that. :smile:
If you have any technical questions I'm still available. Ask away and I'll quote/answer away. Duplication happens a lot and once there is experience under ones belt projection ceases. Apologies for the novel but you escalated beyond the topic of the PR with the projections and I'm cutting it off.

Minimizing the last comment as it's rather adversarial and there's no need to continue that thread which is increasingly off topic.
Thanks for your feedback on the submitted code, technical insight, and willingness to answer questions about your service. We'll be sure to reach out if there are any additional questions you can assist with!

It seems everything should be resolved now (besides waiting for the route name for installs)

@Martii
I was really hoping this matter was settled, but given subsequent discussion https://github.com/OpenUserJS/OpenUserJS.org/issues/1961, and particularly https://github.com/OpenUserJS/OpenUserJS.org/issues/1961#issuecomment-1158064065 onward, I see that it is not.
First and foremost, everyone that decides to participate in our community is inherently agreeing to our Code of Conduct, and that includes being subject to moderation from those of us that lead this community.
As stated in that document, we, the leaders of this community, are responsible for making the determination about what is, and what is not appropriate. Whether or not you like or agree with the rules of our community, or the decisions we make around appropriateness, does not change the fact that we have the final, and only say on this front within our community.
This all started because the way you had been communicating within our community on multiple occasions, particularly when responding to questions from both contributors and maintainers, was not really in accordance with the type of dialog we strive for here. It was still very mild at that point, and I assumed it was unintentional on your part, so I gave you what I believe was an in-kind, very mild moderation check in https://github.com/badges/shields/pull/8081#issuecomment-1175170525 in the hopes you'd have a typical "sorry, wasn't my intent" type of response. In retrospect I probably should have been more explicit about that motivation for that check, so apologies if that wasn't clear.
Unfortunately your reaction to that check, and especially the reaction to the subsequent moderation check, was simply inappropriate. I recognize that you disagree, that you think your behavior is fine, and that you did not appreciate those checks. However, your perception of the appropriateness of your behavior does not particularly matter in this context. You do not dictate the terms here and you do not get to determine what is and what is not appropriate in our community.
This is not up for debate; there is no need for you to defend or rationalize your prior responses, nor is there any utility in critiquing me or the project, so please do not do so again.
I have no intention of responding to the various name calling, misquotes, and insinuations from your previous comments above and in the linked issue in your project, however, I recognize that in some of those same comments you noted some continued technical concerns and I agree with you that we would need to discuss and come to an agreeable resolution before we could consider moving forward with this PR. I am willing to discuss those specifics here, provided you are willing and able to do so in a different manner, one that's in accordance with our community rules and goals, even if it requires agreeing to disagree about the prior discussion. (For what it's worth I'd also happy to answer questions over in your community if you'd prefer that, although it sounds like you preemptively banned me over there)
However, if you have decided that you would instead prefer that Shields not integrate with OpenUserJS, for any reason, we will absolutely abide by that, and abandon this PR. We could also consider an enhancement to our DynamicBadge feature to prevent users from leveraging that to produce OpenUserJS badges. I'm unclear on what if any relationship exists between OpenUserJS and GreasyFork, but the above can apply to GreasyFork as well if that's desirable/necessary.
Please let me know if you'd prefer that we abandon the OpenUserJS badges, or if you'd still like to see if there's a viable path forward, in which case I'll try to respond to some of your commentary around rate limits and dos.


[Sybase] DDL change transaction mode to manual

When execute a DDL command, the transaction mode change to manual.
The opened transaction block de environment.
When the smart commit mode is enabled, the transaction mode shold be locked to auto-commit?

System information:

Operating system (distribution) and version: windows 10
DBeaver version: Version <IP_ADDRESS>104042040
Additional extensions

Connection specification:

Database name and version: Adaptive Server Enterprise/16.0 SP03 PL05/EBF 28234 SMP/P/sparc/SunOS 5.10/ase160sp03pl05x/3455/64-bit/FBO/Sat Jul 28 04:28:01 2018
Driver name
Do you use tunnels or proxies (SSH, SOCKS, etc)?

Describe the problem you're observing:
Steps to reproduce, if exist:
Include any warning/errors/backtraces from the logs

Seems it is expected behavior. You can learn more about smart commit mode here

How to change this expected behavior? Locks in a production environment can be generated as a result of an improperly opened transaction. For example, when creating a local or global temporary table, a transaction was opened and it was just a question of getting data, it should never have been opened a transaction... Who can I request this change from?

you should switch to auto-commit mode. It is expected behavior for the smart-commit mode


fix cancel the job return the false status

Hi djm:
since you cancel the pending job successfully  ,the response json prevstate should be pending ,and the result should be true .

Coverage remained the same at 100.0% when pulling f8a24417133a5c3d0b6f342f96739c56b74fccdb on BruceDone:master into 665e55bcd790824b5bf80842429a7d044dc2accc on djm:master.

Thanks for bringing this to my attention @BruceDone!
I decided that the cancel_job method was better off simply returning the previous state rather than hiding it and returning a boolean which wasn't very useful.
As it is a breaking change, I've bumped the version to 2.x and just released it to PyPi.
Also I added you up to the Authors file, many thanks again.


Extend the BigQuery scope to support sheets

https://soda-community.slack.com/archives/C01HYL8V64C/p1615918663005600

David Schoel  7:17 PM
Testing soda-sql with BigQuery, via a service account.
Is there a way to include the scope of https://www.googleapis.com/auth/drive to enable testing against Google Sheet External tables?
For reference, see how dbt handles here:
https://github.com/fishtown-analytics/dbt/blob/1060035838650a30e86989cbf2693db7720ff002/plugins/bigquery/dbt/adapters/bigquery/connections.py#L[…]31 (edited)
plugins/bigquery/dbt/adapters/bigquery/connections.py:129-131
SCOPE = ('https://www.googleapis.com/auth/bigquery',
'https://www.googleapis.com/auth/cloud-platform',
'https://www.googleapis.com/auth/drive')
https://github.com/fishtown-analytics/dbt|fishtown-analytics/dbtfishtown-analytics/dbt | Added by GitHub

Duplicate of #184


Future warning in trading_ig\utils.py

Hello,
For all intents and purposes, since the latest library version upgrades, this causes futureWarnings in the conv_resol(resolution) function located in trading_ig\utils.py :
...\trading_ig\utils.py:49: FutureWarning: 'H' is deprecated and will be removed in a future version, please use 'h' instead.
to_offset("1H"): "HOUR",
...\trading_ig\utils.py:50: FutureWarning: 'H' is deprecated and will be removed in a future version, please use 'h' instead.
to_offset("2H"): "HOUR_2",
...\trading_ig\utils.py:51: FutureWarning: 'H' is deprecated and will be removed in a future version, please use 'h' instead.
to_offset("3H"): "HOUR_3",
...\trading_ig\utils.py:52: FutureWarning: 'H' is deprecated and will be removed in a future version, please use 'h' instead.
to_offset("4H"): "HOUR_4",
...\trading_ig\utils.py:55: FutureWarning: 'M' is deprecated and will be removed in a future version, please use 'ME' instead.
to_offset("M"): "MONTH",
Best regards

Thanks for your interest in the project.
Please provide more information: what upgrades? what versions of which libraries are you using? etc
It is all documented here

Thanks so much for your reply and for all the work done so far.
The shared sources have been a great help to me for several years!
You will find below the information that I hope is necessary and sufficient to produce the problem:
Used versions :
Python 3.10
trading-ig 0.0.22
Sources for producing a future warning :
from datetime import datetime, timedelta
from trading_ig import IGService
username = "xxx"
password = "xxx"
api_key = "xxx"
acc_type = "DEMO"
acc_number = "xxx"
ig_service = IGService(username, password, api_key, acc_type)
ig_service.create_session()
epic = 'IX.D.NASDAQ.IFE.IP'
resolution = 'H'
end_date = datetime.today()
start_date = end_date + timedelta(hours=-6)
session = None
response = ig_service.fetch_historical_prices_by_epic_and_date_range(epic, resolution, start_date, end_date, session)
print(response)

Pandas renamed offsets aliases
See https://github.com/pandas-dev/pandas/issues/9586
https://github.com/pandas-dev/pandas/blob/main/doc/source/whatsnew/v2.2.0.rst#deprecate-aliases-m-q-y-etc-in-favour-of-me-qe-ye-etc-for-offsets

@Leotheone thanks for the code snippet - but you missed the most important (crucial) bit of information - your pandas version. The warnings you are seeing are due to your use of Pandas 2.2.0 which was released in January 2024. That's why we ask for dependencies and their versions when creating an issue
@femtotrader thanks for the clarification

From #330:
...\trading_ig\rest.py:1801: FutureWarning: Downcasting object dtype arrays on .fillna, .ffill, .bfill is deprecated and will change in a future version. Call result.infer_objects(copy=False) instead. To opt-in to the future behavior, set pd.set_option('future.no_silent_downcasting', True) data["prices"] = data["prices"].fillna(value=np.nan)
...\trading_ig\rest.py:1823: FutureWarning: Downcasting object dtype arrays on .fillna, .ffill, .bfill is deprecated and will change in a future version. Call result.infer_objects(copy=False) instead. To opt-in to the future behavior, set pd.set_option('future.no_silent_downcasting', True) data["prices"] = data["prices"].fillna(value=np.nan)
...\trading_ig\rest.py:1887: FutureWarning: Downcasting object dtype arrays on .fillna, .ffill, .bfill is deprecated and will change in a future version. Call result.infer_objects(copy=False) instead. To opt-in to the future behavior, set pd.set_option('future.no_silent_downcasting', True) data["prices"] = data["prices"].fillna(value=np.nan)


Manual publish 12/27

Manual publish required due to the hotfix release notes and numerous other important changes.

OPS Build status updates of commit 8c3b1de:
:clock10: Preparing: average preparing time is 57 sec(s)

OPS Build status updates of commit 8c3b1de:
:clock10: Incremental building: average incremental building time is 12 min(s) 21 sec(s)

OPS Build status updates of commit 8c3b1de:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

2018-03-01-hybrid/docs-ref-autogen/ams/asset.yml
:white_check_mark:Succeeded
View (azure-cli-2018-03-01-hybrid)

docs-ref-conceptual/azure-cli-extensions-list.md
:white_check_mark:Succeeded
View (azure-cli-latest) View (azure-cli-2017-03-09-profile) View (azure-cli-2018-03-01-hybrid)

docs-ref-conceptual/create-an-azure-service-principal-azure-cli.md
:white_check_mark:Succeeded
View (azure-cli-latest) View (azure-cli-2017-03-09-profile) View (azure-cli-2018-03-01-hybrid)

docs-ref-conceptual/index.md
:white_check_mark:Succeeded
View (azure-cli-latest) View (azure-cli-2017-03-09-profile) View (azure-cli-2018-03-01-hybrid)

docs-ref-conceptual/install-azure-cli-apt.md
:white_check_mark:Succeeded
View (azure-cli-latest) View (azure-cli-2017-03-09-profile) View (azure-cli-2018-03-01-hybrid)

docs-ref-conceptual/install-azure-cli.md
:white_check_mark:Succeeded
View (azure-cli-latest) View (azure-cli-2017-03-09-profile) View (azure-cli-2018-03-01-hybrid)

docs-ref-conceptual/release-notes-azure-cli.md
:white_check_mark:Succeeded
View (azure-cli-latest) View (azure-cli-2017-03-09-profile) View (azure-cli-2018-03-01-hybrid)

latest/docs-ref-autogen/ams/asset.yml
:white_check_mark:Succeeded
View (azure-cli-latest)

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


Consolidate frontend build tooling  into Webpack

Currently, our local CSS is built and compiled using Webpack, while other design system (DS) assets are handled through a simple Makefile task. The goal of this ticket is to streamline the build process by consolidating all tooling into Webpack.

https://github.com/international-labour-organization/ilo_base_theme/pull/49


RecursionError: maximum recursion depth exceeded

I am getting maximum recursion depth error after running this following command:
python qlora.py --model_name_or_path decapoda-research/llama-7b-hf
And this is the error I got:
File "/home/atilla/miniconda3/envs/qlora/lib/python3.9/site-packages/transformers/tokenization_utils_fast.py", line 257, in _convert_token_to_id_with_added_voc
    return self.unk_token_id
  File "/home/atilla/miniconda3/envs/qlora/lib/python3.9/site-packages/transformers/tokenization_utils_base.py", line 1142, in unk_token_id
    return self.convert_tokens_to_ids(self.unk_token)
  File "/home/atilla/miniconda3/envs/qlora/lib/python3.9/site-packages/transformers/tokenization_utils_fast.py", line 250, in convert_tokens_to_ids
    return self._convert_token_to_id_with_added_voc(tokens)
  File "/home/atilla/miniconda3/envs/qlora/lib/python3.9/site-packages/transformers/tokenization_utils_fast.py", line 257, in _convert_token_to_id_with_added_voc
    return self.unk_token_id
  File "/home/atilla/miniconda3/envs/qlora/lib/python3.9/site-packages/transformers/tokenization_utils_base.py", line 1142, in unk_token_id
    return self.convert_tokens_to_ids(self.unk_token)
  File "/home/atilla/miniconda3/envs/qlora/lib/python3.9/site-packages/transformers/tokenization_utils_fast.py", line 250, in convert_tokens_to_ids
    return self._convert_token_to_id_with_added_voc(tokens)
  File "/home/atilla/miniconda3/envs/qlora/lib/python3.9/site-packages/transformers/tokenization_utils_fast.py", line 257, in _convert_token_to_id_with_added_voc
    return self.unk_token_id
  File "/home/atilla/miniconda3/envs/qlora/lib/python3.9/site-packages/transformers/tokenization_utils_base.py", line 1142, in unk_token_id
    return self.convert_tokens_to_ids(self.unk_token)
RecursionError: maximum recursion depth exceeded

Normally I was getting OverflowError but I followed this PR and it resolved but now I got this error.

I see the same thing, I changed LlamaTokenizerFast back to LlamaTokenizer.
Now I have another issue it dumps core when it is cleaning up something.

seems to be caused by the included, old tokenizer, see detail here: https://github.com/huggingface/transformers/issues/22762. Was able to resolve the issue by switching to huggyllama/llama-7b, which has newer correct tokenizer.

Forcing the unk_token fixed this for me (v4.30.1):
tokenizer = tokenizer_class.from_pretrained(model_name_or_path, unk_token="<unk>")

use_fast=False, can solve this issue.
tokenizer = AutoTokenizer.from_pretrained(model_name, use_fast=False)

Best regards,
Shuyue
July 6th, 2024


decoder MMHA kernel support INT8 SCALE_Q_INSTEAD_OF_K and SCALE_P_INS…

Following the logic of MMHA_FP8_SCALE_Q_INSTEAD_OF_K and MMHA_FP8_SCALE_P_INSTEAD_OF_V, I implemented the INT8 version.
It is theoretically equivalent to the original compute logic without any numeric accuracy degradation.
I tested the speed on H20, A100, and 4090 GPUs. The results show that the average latency of the MMHA kernel decreased by about 5% to 8%, thanks to fewer FMUL instructions.
Nsight Compute Kernel Summary

Nsight Compute Instruction Statistics

@byshiue @Shixiaowei02 May you pls review and verify this PR~ Thank you very much!

@lishicheng1996 moving forward the INT8 scale is not enabled because we observed the accuracy drop because of that. Have you checked the accuracy after enabling that ? I will give it another try locally.

@lishicheng1996 moving forward the INT8 scale is not enabled because we observed the accuracy drop because of that. Have you checked the accuracy after enabling that ? I will give it another try locally.

Hi, thanks for your triage~
I checked the MMLU accuracy score on Llama3.0-8B, with int8 smooth quant. I didn't see accuracy drop.

@lishicheng1996 moving forward the INT8 scale is not enabled because we observed the accuracy drop because of that. Have you checked the accuracy after enabling that ? I will give it another try locally.

Hi, thanks for your review~ I checked the MMLU accuracy score on Llama3.0-8B, with int8 smooth quant. With moving forward the INT8 scale, I didn't see accuracy drop~

Thanks. I will run more tests for different models locally, and merge that into the internal TRT-LLM, and release it in coming weeks if everything looks good. Thanks again.

@lishicheng1996 moving forward the INT8 scale is not enabled because we observed the accuracy drop because of that. Have you checked the accuracy after enabling that ? I will give it another try locally.

Hi, thanks for your review~ I checked the MMLU accuracy score on Llama3.0-8B, with int8 smooth quant. With moving forward the INT8 scale, I didn't see accuracy drop~

Thanks. I will run more tests for different models locally, and merge that into the internal TRT-LLM, and release it in coming weeks if everything looks good. Thanks again.

Hi, may I ask how's the accuracy in your local test? ^_^


Fix Web BackgroundColor bug

#24  👈
main

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

Join @kanziw and the rest of your teammates on  Graphite

Merge activity

Apr 12, 7:54 AM EDT: @kanziw merged this pull request with Graphite.


Add support for comma separated values

Example, these should all parse to exactly the same matches
$ prog --opt val1 val2 val3
$ prog --opt val1,val2,val3
$ prog --opt=val1,val2,val3
$ prog -oval1,val2,val3

I'm going to start looking at this. I'll ping you back if I have questions!

:+1:

You should be able to look at the App:::add_value_to_arg in src/app/mod.rs to start

Hey! Sorry for the late reply, it's been a little busy for me lately. I had the chance to work on this a little this weekend. I have a few questions!
Would introducing something like this be on the right path (notice take_list) ?
let matches = App::new("MyApp")
        .arg(Arg::with_name("input")
                        .help("the input file to use")
                        .takes_value(true)
                        .short("i")
                        .long("input")
                        .multiple(true)
                        .takes_list(true)
                        .required(true)
                        .conflicts_with("output"))
        .get_matches();

So let's say this implementation works. When we're asking for value_of of input for this example, we're expecting a &str right? I was thinking of returning a vector, but that doesn't seem that it would be going in the right direction. So in fact, we'd expect to get a string instead of a list, and leave the user to deal with said input.

No problem! :+1:
Assuming the user runs MyApp -i val1,vla2,val3 calling value_of("input") would return val1which isn't super useful, but that's how it works with other multiple values so this is fine. callingvalues_of("intput")you'll get aVec<&str>which contains["val1", "val2", "val3"]. This is actually something that needs to be changed (and I'll put the issue in for it in just a minute), it should return a &[&str]`.
For this issue, you shouldn't have to worry about anything in arg_matches.rs, it should only require changes  src/app/mod.rs:add_val_to_argand maybesrc/args/arg_matcher.rswhere you split the value by,`.
But you bring up a very interesting idea, that I like. Changing your takes_list(true) to allow_value_delims(bool) (and defaults to true). This would assume most people would be OK with -i val1,val2,val3 parsing to 3 values, but also give them the option to parse -i val1,val2,val3 as a single value if their application requires such. (i.e. most users would never have to use .allow_value_delims(true) because that's the default, they only need to use .allow_value_delims(false) if they want to turn that feature OFF)
Another setting that would go along very nicely with this is making the delimiter selectable but defaulting to , (comma). This would require something like value_delim(char) and allow things like -i val1;val2;val3 if .value_delim(';') was used.
For the above two features though I will create two issues, instead of trying to solve all three in this one issue.

@psyomn How's it going?

Hey, sorry for disappearing! I haven't had a chance to work on clap these
last weeks because I'm occupied with marking, trying to publish a paper
with a teacher, and on a job hunt as well! I will have time during holidays
if that's cool. If I'm holding people back, then I'll snatch another issue
when I'm not as pressed for time.
Thank you for the extensive writeup by the way. I wanted to express my
thanks, but didn't want to add too much noise to the issue tracker.
Hope everything is well on your end!
On Fri, Dec 18, 2015 at 3:58 AM, Kevin K<EMAIL_ADDRESS>wrote:

@psyomn https://github.com/psyomn How's it going?
—
Reply to this email directly or view it on GitHub
https://github.com/kbknapp/clap-rs/issues/348#issuecomment-165717559.

No worries :) Just wanted to check up. We may go ahead and implement this, but if its still open when your time frees up feel free to keep at it and put in a PR or ask if you have questions :wink:

Closed with #387


Add support for passing Vault namespace

This is useful when working with Vault Enterprise

Do you need to use the registry.KMSClient interface? If not and you only need an AEAD, then you can already do that if you use hcvault.NewAEAD:
like this:
client, err := api.NewClient(cfg)
if err != nil {
...
}
client.SetNamespace(namespace)
client.SetToken(token)
...
a, err := hcvault.NewAEAD("/transit/keys/key-1", client.Logical())
if err != nil {
...
}
This also has the advantage that it doesn't use the "context" request parameter to set the associated data, but uses the "associated_data". If you want to use "context" to be compatible with the previous behavior, then you may need to pass the hcvault.WithLegacyContextParamater() option.

Yes, I need the registry.KMSClient interface

I've added the function hcvault.NewClientWithAEADOptions here:
https://github.com/tink-crypto/tink-go-hcvault/commit/57c4fd3df405fd496d63e97f4c27afecf9dba5a0
I think that should cover your use-case, is that correct?

I'll close this now because it is not needed anymore.


feat: add ability to post identity key via admin API

High Level Overview of Change
Asana task: https://app.asana.com/0/1182225689526777/1186929984905884
Context of Change
Part of a series of PRs adding user supplied identity keys & signatures to addresses to unlock non custodial wallet partners
Type of Change

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Refactor (non-breaking change that only restructures code)
[x] Tests (You added tests for code that already exists, or your new feature included in this PR)
[ ] Documentation Updates
[ ] Release

Before / After
Extending the insertUser function to an accept an optional identityKey param
Test Plan
I added a unit test confirming it works + doesn't break our old ones b/c it's an optional param
Future Tasks
The subtasks outlined in this Asana task: https://app.asana.com/0/1182225689526777/1186312611097763

Don't review yet, I broke my local spacing config and it's making my PRs ugly. Lemme fix before you waste your time

Don't review yet, I broke my local spacing config and it's making my PRs ugly. Lemme fix before you waste your time

@hbergren I knew you were somehow going to see this minutes after I pushed it, glad I left that comment lol

I would add another test, for a Admin API GET (if that is implemented yet).
We could add a seeded value for a PayID with an identity key, and make sure that we can retrieve it.

Good point, will do that now.

I would add another test, for a Admin API GET (if that is implemented yet).
We could add a seeded value for a PayID with an identity key, and make sure that we can retrieve it.

Good point, will do that now.

Oh actually, we were planning to implement that in another PR through this task: https://app.asana.com/0/1182225689526777/1186929984905890
I can take that on next if we want to make sure any issues that might be caused by this PR are addresses as soon as possible.


Possibility to order infinite configurable products (product_ordered_inventories and / or order_items not correctly updated at order)

Bug Report

Issue Description
Currently it is possible to order an infinite amount of configurable products as the product_ordered_inventories table / order_items table are not filled correctly on order
Bagisto Version
master branch and online demo using v1.3.3
Steps To Reproduce
In demo admin

create configurable product with differenze sizes (s,m,l...)
set quantity of all to 1
set individually visible of configurable product to true and to false for the simple variants

In demo shop

go to configurable product and add 1 of size s to cart
order cart
size s should not be available anymore
go to configurable product

Actual Result

it is still possible to add 1 of size s, even though the available amount should be 0

Expected Result

it should not be possible to add 1 of size s

Possible Explanation
Above happens using master branch as well.

Locally on master branch we observe that after order the order_items table seems incorrect. For the scenario described above we have two items in there:

The configurable product with qty_ordered 1
Its simple variant which was ordered with qty_ordered 0

Then https://github.com/bagisto/bagisto/blob/65e70b6c6dbbfc987a2b28d4fc8def7c60c63249/packages/Webkul/Sales/src/Repositories/OrderItemRepository.php#L102 copies the quantity of the simple variant (0) to product_ordered_inventories
So the net totalQuantity for the simple product does not change

it seems this is already problematic in the cart_items table. There, also the quantity for the respective configurable product is 1, but the quantity for the simple variant which is actually in the cart is 0. If there are two different variants for the same configurable products in the cart, then there are two copies of the configurable product (actually with the counts in the cart as quantity) and for each copy there is a simple product (the variant) with count 0

Hi @derMart,
Thanks for reporting this. I will check and fix this.

Hi @derMart,
I just added quantity to the child one. Let me know are you still facing issue,
https://github.com/bagisto/bagisto/pull/5454

@devansh-webkul
Thanks, now this issue is fixed. Please find the screen recording Here.

@devansh-webkul Thanks alot! Works when adding items to cart. Issue remaining is updating the cart. In https://github.com/bagisto/bagisto/blob/837f78fa287fa078d46edb057e3cd45c43b0cdc8/packages/Webkul/Checkout/src/Cart.php#L293 only quantity of configurable is updated, not that of the child.

another bug, now if I order e.g. 3 times the variant of size s, product_ordered_inventories has quantity 9 instead of 3

also returnQtyToProductInventory probably has to be updated, I do see code like ($orderItem->qty_ordered / $orderItem->parent->qty_ordered) * $shipmentItem->qty in there which could be problematic if not parent and child have same quantity (?)

Another issue: If I order e.g. 3 times the variant of size s, product_ordered_inventories has quantity 9 instead of 3 EDIT: the simple variant in order_items also has quantity 9, in that scenario EDIT2: See
https://github.com/bagisto/bagisto/blob/837f78fa287fa078d46edb057e3cd45c43b0cdc8/packages/Webkul/Checkout/src/Cart.php#L751
@devansh-webkul Have you thought about (unit) tests for these kind of things? This should eliminate alot of problems and would improve finding regressions in the future for all those cases found already and detects side effects of changes

We tested this with multiple quantities also and everythings seems fine even we checked with cart, order and invoices also. Not facing this.
Becuase i have changed in the configurable portion not everywhere.
If possible can you provide us PR what you trying to say so that i can verify.

Okay got the point. Seems like its getting doubled.

I will check all possible cases and if you find anything then let me know. Thanks for reporting this.

Reverted previous PR.
And by putting this,
$child['quantity'] = $child['quantity'] ? $child['quantity'] * $data['quantity'] : $data['quantity'];

Instead of this,
$child['quantity'] = $child['quantity'] ? $child['quantity'] * $data['quantity'] : $child['quantity'];

Solving most of the problems. But still i will check all the possible cases for the parent one.
I will take some time on this and will prepare the unit and functional also for this.

@derMart,
Sorry for the delay but currently I am busy with some other task, but I have kept in mind this also. That's why I am simplifying test cases for this also.
I will provide you with the fix in the next release. If you want to contribute you can provide us with the pull request. We will consider it if everything is fine.

I will provide you with the fix in the next release. If you want to contribute you can provide us with the pull request. We will consider it if everything is fine.

I am sorry, in this case I do not have the time resources to do that.

No worry I will check. Low priority I added for my understanding I will start working on them once I get free.

Hi @derMart,
The mentioned issue has been fixed.
And for unit tests, configurable products and bundle products both support need to be added. Will provide it later.
And let me know, if still any inventory impacted.

Hi @derMart,
Are you still facing any issues?

@devansh-webkul well not yet directly related to order quantities as in this bug report, but a related bug is here: https://github.com/bagisto/bagisto/issues/6290
What is the status of the unit tests? Please I see that unit tests for this core functionality have low priority and are not yet done in two months. This is really concerning. Please take this seriously. Unit tests are very important and should have high priority!


test: E2E tests for SQL support in CDK construct

Description of changes
Test 1 for SQL support in the CDK construct. This tests the basic case of specifying connection params for a pre-existing SQL database, and letting the transformer provision Lambda, VPC endpoint, and IAM resources via CDK.
Other changes:

Add a new env variable to allow local invocations to skip the 0-3 minute delay when setting up a new project folder
Add a create-env.sh script to write an .env file based on AWS environment variables in the current shell session

Checklist

[x] PR description included
[X] yarn test passes
[X] Tests are changed or added

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Test stacks aren't being deleted after the test. Investigating.

Changes since last approval:

735094b39 - Rebased against feature/rds-support-preview2 & addressed merge conflicts
033626c94 - Fixed error destroying CDK project
4a1c64a92 - Added construct test reports to .prettierignore


fix plugin arg conversion when using multiple profiles with same plugin

If you have multiple profiles and reuse the plugin, the values stump over each other because we were reusing the same PluginArgInstance.
closes #1142

/cc @ingvagabund @knelasevero

/label tide/merge-method-squash

/lgtm

/approve


Added blank line to build constraint examples

As specified in https://golang.org/pkg/go/build/#hdr-Build_Constraints:
"To distinguish build constraints from package documentation, a series of build constraints must be followed by a blank line."

Pull Request Test Coverage Report for Build 97

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 89.686%

Totals

Change from base Build 95:
0.0%

Covered Lines:
400

Relevant Lines:
446

💛  - Coveralls

LGTM, thanks!


Syntax bug fixes (#68, #77, #84, Range Operator)

Why is the build failing? On the commits above, it looks like it's failing on the last commit (2f400dd), but it did the same thing the last pull request I tried (#91), and this is the same thing minus that pull's last commit. The changes are fairly simple. Did I miss something, or is there something wrong with the test?

It looks like this is failing because of the issue from #96. The build fails on support.function.powershell.

I merged #96. It may be related. We already have a bunch of similar problem https://github.com/SublimeText/PowerShell/blob/master/tests/pester/SyntaxHelper.psm1#L139
Ideally, case should not affect kind of scope. Last release, I didn't have time to fix all problems and just workaround them.

Please, include samples of syntax that used to be incorrect and now correct to tests\samples\test-file.ps1. It's both human and machine readable and including samples will reduce regressions in future.

@bcrotty I probably should write-up how to run tests locally.

@bcrotty I probably should write-up how to run tests locally.

@vors Yes, please! :-) I took a (very) quick look at your testing code, but couldn't figure out how to run the new syntax tests locally.

(Or whether some previous step is needed at all; I thought so.)

#102

@vors Sorry about the test-file. Should be sorted out now.

no problem. I added instruction about run tests locally https://github.com/SublimeText/PowerShell/blob/dev/CONTRIBUTING.md#run-tests-locally

For now, you can unblock yourself with adding failed scopes to https://github.com/SublimeText/PowerShell/blob/dev/tests/pester/SyntaxHelper.psm1#L139

Or create a separate if above. This code require some time to dive in... Let me if you are stuck with it.

@vors I might need some help. I added exclusions for support.function.powershell and interpolated.simple.source.powershell, but it doesn't work still. When it's doing its tests, is it using my branch or SublimeText:dev?

Sorry, I mislead you a little bit.
The current usage of $bugsExclude is to provide a common substrings (in form of regex) to consider different tokens the same, i.e. constant.numeric.scientific.powershell and support.constant.powershell. In your case, there is no common substring which can be used. You can ever add a separate if for your case or try to understand why that happens (you are way better in understanding sublime plist rules then me). It have to be fixed eventually.

Ok, I'll work on that. Also, @vors I can't run the tests locally. I get the below error. From the source code, it looks like ${env:SUBLIME_TEXT_VERSION} doesn't correctly resolve to anything. Is that not a universal environment variable?

This code leaves in https://github.com/randy3k/UnitTesting/blob/master/sbin/appveyor.ps1
Please, workaround it with $env:SUBLIME_TEXT_VERSION = "3"
I will update instruction to run tests locally, once you will succeed :)

I finally got it working, but none of the ${env:____} worked for me. Also, start-filedownload and 7z.exe could not be found. I have 7zip installed, but I guess it's not in my PATH or something. I downloaded and extracted the build manually.
I finally was able to run the test using the command:
& "C:\st\Data\Packages\UnitTesting\sbin\run.ps1" "PowerShell"
It looks like it copied PowerShell from the current directory that my PowerShell console was pointed to, which happened to be correct, but if I had wanted it to run on a different copy of the PowerShell code, I'm not sure how I would have done that.

You are absolutely right.
I actually should not point to appveyor.ps1, because it's heavily depends on build agent environment:

start-filedownload is a cmdlet provided by AppVeyor on build VMs.
AppVeyor has 7z.exe in $env:PATH

I think the right way would be contribute to https://github.com/randy3k/UnitTesting/blob/master/sbin and provide two scripts: for local run (?) and for appvoyer run.

Oh we need to merge this. Can you, resolve merge conflicts?

I think that's why this never got merged in the first place. I'm pretty sure the commits themselves are good, but we need to add an exclusion to the test, and I could use some help with that.

Current tests framework is super complicated, involves cloning UnitTests repo, installing sublime texts, run python in-proc tests, serialize sublime scopes. I believe it can be replaced with scopes generation out-of-proc (maybe github library for that). It would greatly simplify troubleshooting.

Just a heads up that a new syntax def using the new format .sublime-syntax is under work:
https://github.com/SublimeText/PowerShell/pull/127
The .sublime-syntax also includes the ability to test syntax defs. We need to integrate that with the tests in the PS package, though.
I think fixing bugs in the .tmLanguage is ok (as it will help GH hilite PS files better too), but I'm not so sure we should spend too much time improving tests, etc. around the old format?


plutus ledger events tool

I have added a new tool to the cardano-client-demo package. It uses foldBlocks to gather Plutus debugging information about scripts in the chain history. It was helpful recently while tracking down a ledger bug which caused a script in the chain history to fail, since it let us inspect the context when it ran successfully.
This is the second tool that I have added to cardano-client-demo. I think that we should consider making a new repository for foldBlock tools.

The help command describes tool like this:
$ cabal run plutus-events -- --help
Up to date
Usage: plutus-events (-c|--conf FILEPATH) (-s|--socket FILEPATH)
                     [--slot NATURAL] [--hash SCRIPTHASH]

  This is a tool which provides debugging information for any Plutus script
  included in the chain history. The debugging information includes the script,
  the execution units, the script context, and the cost model. This tool
  requires a running node. The cardano-ledger repository provides a function
  'debugPlutus' in thecardano-ledger-alonzo package which will replay the script
  and provide the Plutus logs. The debugging information is first CBOR encoded
  and then base 64 encoded, but note that 'debugPlutus' expects the input to be
  base 64 encoded.

Available options:
  -c,--conf FILEPATH       node configuration file
  -s,--socket FILEPATH     node socket
  --slot NATURAL           Restrict to the given slot numbers. If not used, no
                           slot restrictions are imposed. This field can be
                           supplied multiple times.
  --hash SCRIPTHASH        Restrict to the given script hashes. If not used, no
                           script hash restrictions are imposed. This field can
                           be supplied multiple times.
  -h,--help                Show this help text

Are these tools distributed with cardano-node & cardano-cli?  Or are they mostly for demo purposes?

This PR is stale because it has been open 45 days with no activity.

That's fair, github-action-bot, but I still think it's a good tool. Perhaps I'll rebase it soon here...


Move assignment logic to PBlib

Move the assignment logic from PBassign to PBlib. This makes possible to import PBlib and call the assignment function.
This is a first step toward the proposal #25.

OK. Thanks for the nice work.


https://youtu.be/ZdSrOnuIxkU

Does this issue occur when all extensions are disabled?: Yes/No

VS Code Version:
OS Version:

Steps to Reproduce:

https://youtu.be/ZdSrOnuIxkU
https://youtu.be/ZdSrOnuIxkU

### Tasks
- [ ] https://github.com/microsoft/vscode/issues/187885
- [ ] connor4312/cli-service-windows-fixhttps://youtu.be/ZdSrOnuIxkU
- [ ] https://github.com/microsoft/vscode/issues/187875
- [ ] sev
- [ ] https://github.com/microsoft/vscode/pull/187884
- [ ] https://github.com/microsoft/vscode/issues/180419
- [ ] https://github.com/microsoft/vscode/pull/187749
- [ ] https://github.com/microsoft/vscode/issues/187747
- [ ] https://github.com/microsoft/vscode/pull/187787
- [ ] https://github.com/microsoft/vscode/issues/187016
- [ ] https://github.com/microsoft/vscode/pull/187883
- [ ] https://github.com/microsoft/vscode/pull/187743
- [ ] https://github.com/microsoft/vscode/issues/175262
- [ ] https://github.com/microsoft/vscode/issues/183081
- [ ] https://github.com/microsoft/vscode/issues/183686
- [ ] https://github.com/microsoft/vscode/issues/178403
- [ ] https://github.com/microsoft/vscode/issues/183703
- [ ] https://github.com/microsoft/vscode/issues/178567
- [ ] https://github.com/microsoft/vscode/issues/182742
- [ ] https://github.com/microsoft/vscode/issues/183737
- [ ] https://github.com/microsoft/vscode/issues/183729

https://youtu.be/ZdSrOnuIxkU

connor4312/cli-service-windows-fixhttps://github.com/nodejs/help.wiki.gitCODE_OF_CONDUCT.md

Simjo77
https://youtu.be/ZdSrOnuIxkU

https://youtu.be/ZdSrOnuIxkU
CODE_OF_CONDUCT.md

https://youtu.be/ZdSrOnuIxkU

<EMAIL_ADDRESS>


Fixing entry_stop selection

... once and for all 😅
See https://github.com/XENONnT/fuse/pull/166.
Thanks to @mhliu0001 and sorry for overlooking this.

We should also perform a check whether entry_stop is larger than entry_start.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 1 (0.0%)  changed or added relevant line in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 66.592%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

fuse/plugins/micro_physics/input.py
0
1
0.0%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1782

Relevant Lines:
2676

💛  - Coveralls

Another major problem is the definition of entry_start and entry_stop. Should they act on the RAW root file or after filtering out edep=0 (interactions)? Now, it is the former case, which will cause some confusion for the users.

I also added a test for this entry_start and entry_stop problem, hope that this can solve the problem once and for all.

Another major problem is the definition of entry_start and entry_stop. Should they act on the RAW root file or after filtering out edep=0 (interactions)? Now, it is the former case, which will cause some confusion for the users.

Hey @mhliu0001, I think this is the intended behavior. We want the user to be able to track the events processed with an index correspondance with the original ROOT file. So first we process index, later we apply the edep cut.


PocketSVG Error: No d attribute found in SVG file

Hi 你好
I have a svg file
<svg xmlns="http://www.w3.org/2000/svg" width="138" height="138"><rect x="0" y="0" width="100%" height="100%" fill="rgb(131, 201, 59)"  /> ... </svg>

my swift code
           let patch = PocketSVG.pathFromSVGFileNamed("test").takeUnretainedValue()
           let myShapeLayer = CAShapeLayer()
           myShapeLayer.path = patch
           self.view.layer.addSublayer(myShapeLayer)

then
 PocketSVG Error: No d attribute found in SVG file.
PocketSVG Error: Path string is empty of tokens

Hello!
For now, only SVG paths are supported, not shapes. Sorry!

PocketSVG has been updated to v2.0.0! Multiple paths are supported now. Happy coding!


generateGeoQueryDocumentSnapshotI() returns ...Data instead of ...Snapshot

Currently the method generateGeoQueryDocumentSnapshot() returns a QueryDocumentSnapshot.
This only exposes a few methods or properties compared to a Firebase QueryDocumentSnapshot.
This means that what one can expect from either a generic Query or a GeoQuery is very different,
making passing results to generic functions a bit non unified (talking about geofirestore-js here).
With version v2.2.3 of geofirestore-js I had patched (but not PR'ed) theQueryDocumentSnapshot.
So it would expose QueryDocumentSnapshot methods, making it a drop-in replacement/addition.
As a sketch/conversation starter I did the same thing for the 5.0.0 version of geofirestore-core
This means that the implementing geofirestore-js would start to return the missing methods.
Now I say as a sketch, because I struggle with TypeScipt ( hence :any ),
and there are probably some semantics or reasons to take into account.
The commit does a few things.
Types

It renames the type GeoFirestoreTypes.QueryDocumentSnapshot to GeoFirestoreTypes.QueryDocumentSnapshotData, as the type was more ...Data than ...Snapshot

for the method decodeGeoQueryDocumentSnapshotData(), type QueryDocumentSnapshotData is still semantically valid and used

The previous, type GeoFirestoreTypes.QueryDocumentSnapshot is updated to extend the Firebase.QueryDocumentSnapshot type, (exposing all methods) and adding distance : number

Methods

generateGeoQueryDocumentSnapshot() now returns the original snapshot methods, and properties, but overwriting data() with decoded.data() and adding {distance : decoded.distance}

I wonder if this would be a good addition or if there are reasons why (not) to return the original snapshots.

Ok holdup...somehow it seems is not really achieving much and is not a fix.
The manifestation of the problem is that
GFS.GeoQuery.get() returns  <Core.GeoQuerySnapshot>  that has a method GeoQuerySnapshot.forEach
That foreach passes the QueryDocumentSnapshot that says
The document is guaranteed to exist and its data can be extracted with .data() or .get() to get a specific field.
A QueryDocumentSnapshot offers the same API surface as a DocumentSnapshot.
..and this is not true, as for example .get(<field>) is not exposed.

I added the missing method(s)/property to utils.ts:generateGeoQueryDocumentSnapshot() of the geofirestore-core. I did notice that these missing methods were present in the src/GeoDocumentSnapshot.ts:class GeoDocumentSnapshot{} of geofirestore-js, but in my experience this did not expose them (at least within a cloud functions implementation) with a one time query near(..).where(..).get().
I think I do understand what the envisioned design/abstraction would be, but I was unsuccessful in implementing this in such a way that the  geofirestore-core would stay untouched. As said earlier this could be a shortcoming of my understanding/ability with TS.
If indeed the geofirestore-core should be patched, then I'll try to tidy up the commit and create a PR, but it is for the creator @MichaelSolati to have a opinion about.


OSError: [WinError 193] %1

Describe the bug
When I try to command "python demo.py -f examples/inputs/emma.jpg --onnx"
this error message will pop up
Error message
Traceback (most recent call last):
File "demo.py", line 13, in
from utils.render_ctypes import render  # faster
File "C:\Users\Yuan\3DDFA_V2-master\utils\render_ctypes.py", line 64, in
render_app = TrianglesMeshRender(clibs=make_abs_path('asset/render.so'))
File "C:\Users\Yuan\3DDFA_V2-master\utils\render_ctypes.py", line 39, in init
self.clibs = ctypes.CDLL(clibs)
File "C:\Users\Yuan\anaconda3\envs\Test\lib\ctypes_init.py", line 348, in init
self._handle = _dlopen(self._name, mode)
OSError: [WinError 193] %1 不是有效的 Win32 应用程序。
Platform:
Window

Try not to use utils/render_ctypes.py by comment out the last three lines of build.sh, and comment this line. utils/render_ctypes.py may not be friendly to Windows.
cd FaceBoxes
sh ./build_cpu_nms.sh
cd ..

cd Sim3DR
sh ./build_sim3dr.sh
cd ..

#cd utils/asset
#gcc -shared -Wall -O3 render.c -o render.so -fPIC
#cd ../..

Try not to use utils/render_ctypes.py by comment out the last three lines of build.sh, and comment this line. utils/render_ctypes.py may not be friendly to Windows.
cd FaceBoxes
sh ./build_cpu_nms.sh
cd ..

cd Sim3DR
sh ./build_sim3dr.sh
cd ..

#cd utils/asset
#gcc -shared -Wall -O3 render.c -o render.so -fPIC
#cd ../..

Try not to use utils/render_ctypes.py by comment out the last three lines of build.sh, and comment this line. utils/render_ctypes.py may not be friendly to Windows.
cd FaceBoxes
sh ./build_cpu_nms.sh
cd ..

cd Sim3DR
sh ./build_sim3dr.sh
cd ..

#cd utils/asset
#gcc -shared -Wall -O3 render.c -o render.so -fPIC
#cd ../..

thank you, it work for me

Try not to use utils/render_ctypes.py by comment out the last three lines of build.sh, and comment this line. utils/render_ctypes.py may not be friendly to Windows.
cd FaceBoxes
sh ./build_cpu_nms.sh
cd ..

cd Sim3DR
sh ./build_sim3dr.sh
cd ..

#cd utils/asset
#gcc -shared -Wall -O3 render.c -o render.so -fPIC
#cd ../..

thank you, it work for me


Add support for equalization via alsaeq

Adds software-based equalisation using alsaeq, based on the guide published over at HifiBerry as well as this one.
Requires that the alsaeq modules be installed first using sudo apt-get install -y libasound2-plugin-equal, so will have to be incorporated in a future distribution of MusicBox.
I wasn't able to test the fallback to USB in the first part of the if statement, so if someone with a USB DAC could run a quick check before merging that would be great.
Implements the enhancement requested at https://github.com/woutervanwijk/Pi-MusicBox/issues/306

The latest commit contains the following changes:

equalizer defaults to 'off' which reverts to the old Musicbox functionality
setting the qualifier to 'default' will delete the control file on every reboot and revert to default system settings
I've scaled all of the presets down to 50%-65% to avoid likelihood of sound distortion occurring.

...pushed 7c1efadeb3958e12806a29d04700e2a582c61c8a to make use of an obvious opportunity to simplify the script logic, which I missed the first time round.
@kingosticks, not sure if you would prefer that we move the .alsaequal.bin file location at this stage?

Having fiddled around with the sound curve settings for a while, the following sequence has yielded the most pleasing results for me on a set of small speakers:
65 65 65 62 58 52 54 56 62 54

Update: resynchronised with main development branch.

Just FYI - your sound curve numbers are in the wrong order.
Left-most numbers increase bass, right-most numbers increase treble.
Test this by using
 treble) curve="65 65 65 62 58 54 51 51 51 50" ;;
then contrast that with
bass) curve="50 50 50 52 56 60 63 65 65 65" ;;
Your "treble" setting increases bass

Yes that didn't make sense to me either. The curves are based on an example that I found here: http://www.pclinuxos.com/forum/index.php/topic,110087.msg944835.html#msg944835.
Not sure if just the bass and treble ones are switched around or if the same is true of the other presets - your thoughts?
In the end I decided to just leave them as-is in the hope that the community will improve on it if the PR ever gets merged - but switching treble and bass makes sense as a first step.

For future reference: instructions for setting up a 15-band equalizer is available at: https://discuss.mopidy.com/t/equalizer-alsaequal-on-pimusicbox-with-dac/1189/8?u=jcass77

Can we expect to see this anytime? I really need it


[HUDI-2015] Fix flink operator uid to allow multiple pipelines in one…

… job
Tips

Thank you very much for contributing to Apache Hudi.
Please review https://hudi.apache.org/contributing.html before opening a pull request.

What is the purpose of the pull request
(For example: This pull request adds quick-start document.)
Brief change log
(for example:)

Modify AnnotationLocation checkstyle rule in checkstyle.xml

Verify this pull request
(Please pick either of the following options)
This pull request is a trivial rework / code cleanup without any test coverage.
(or)
This pull request is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:
(example:)

Added integration tests for end-to-end.
Added HoodieClientWriteTest to verify the change.
Manually verified the change by running a job locally.

Committer checklist

[ ] Has a corresponding JIRA in PR title & commit

[ ] Commit message is descriptive of the change

[ ] CI is green

[ ] Necessary doc changes done or have another open PR

[ ] For large changes, please consider breaking it into sub-tasks under an umbrella JIRA.

Codecov Report

Merging #3091 (c65b5b8) into master (61efc6a) will decrease coverage by 42.57%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master   #3091       +/-   ##
============================================
- Coverage     45.75%   3.18%   -42.58%
+ Complexity     5262      82     -5180
============================================
  Files           909     272      -637
  Lines         39356   10500    -28856
  Branches       4239    1070     -3169
============================================
- Hits          18008     334    -17674
+ Misses        19504   10140     -9364
+ Partials       1844      26     -1818

Flag
Coverage Δ

hudicli
?

hudiclient
0.00% <ø> (-30.40%)
:arrow_down:

hudicommon
?

hudiflink
?

hudihadoopmr
?

hudisparkdatasource
?

hudisync
6.79% <ø> (-44.66%)
:arrow_down:

huditimelineservice
?

hudiutilities
10.00% <ø> (-46.64%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

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


Server usage examples

I found this package very useful, however there are no examples on how to use things like nintendo.nex.matchmaking. MatchMakingServer. Are there any examples (other than the SMB35 repo) for those server classes?

This repo has an example server found in the examples folder
https://github.com/kinnay/NintendoClients/blob/master/examples/custom/server.py
You would use the other protocol classes the same way. As for the actual logic behind them, that's an implementation detail and really up to you how you implement it. Also some NEX versions have slightly different requirements especially with matchmaking, so your implementation would also vary by game
We've had instances like this several times over at Pretendo, where one game may expect a matchmaking notification and another may not (as an example)

@jonbarrow is right. No other examples unfortunately. If you have a specific question about the match making protocol, feel free to ask and we can try to help.

This repo has an example server found in the examples folder
https://github.com/kinnay/NintendoClients/blob/master/examples/custom/server.py
You would use the other protocol classes the same way. As for the actual logic behind them, that's an implementation detail and really up to you how you implement it. Also some NEX versions have slightly different requirements especially with matchmaking, so your implementation would also vary by game
We've had instances like this several times over at Pretendo, where one game may expect a matchmaking notification and another may not (as an example)

This is very useful, thanks! I was looking at the matchmaking_mk8d code to try serve it, since it has the full server code and as far as I understand I need to run the servers mk8d uses

@jonbarrow is right. No other examples unfortunately. If you have a specific question about the match making protocol, feel free to ask and we can try to help.

This example is good enough and it tells what parts are coded specifically for SMB35 and which ones are the base code needed

This is very useful, thanks! I was looking at the matchmaking_mk8d code to try serve it, since it has the full server code and as far as I understand I need to run the servers mk8d uses

It has the skeleton of the protocol but you'll still need to implement all the actual functionality by hand. You'll also probably need to run your own account server, unless there's some other way to force the game to connect? I haven't looked much into the Switch's architecture myself yet, to be honest. I assume it gets the NEX servers location from the account server much like the WiiU/3DS do

This is very useful, thanks! I was looking at the matchmaking_mk8d code to try serve it, since it has the full server code and as far as I understand I need to run the servers mk8d uses

It has the skeleton of the protocol but you'll still need to implement all the actual functionality by hand. You'll also probably need to run your own account server, unless there's some other way to force the game to connect? I haven't looked much into the Switch's architecture myself yet, to be honest. I assume it gets the NEX servers location from the account server much like the WiiU/3DS do

Oh, that makes a lot of sense, thanks!

You'll also probably need to run your own account server, unless there's some other way to force the game to connect? I haven't looked much into the Switch's architecture myself yet, to be honest. I assume it gets the NEX servers location from the account server much like the WiiU/3DS do

No, the Switch finds the game servers by DNS lookup. The easiest way to connect with a custom server is to write an IPS patch that replaces the game server URL. This is what I did with SMB35 as well.

No, the Switch finds the game servers by DNS lookup. The easiest way to connect with a custom server is to write an IPS patch that replaces the game server URL. This is what I did with SMB35 as well.

That's right, my bad. I remember that from your wiki now, ignore me

You'll also probably need to run your own account server, unless there's some other way to force the game to connect? I haven't looked much into the Switch's architecture myself yet, to be honest. I assume it gets the NEX servers location from the account server much like the WiiU/3DS do

No, the Switch finds the game servers by DNS lookup. The easiest way to connect with a custom server is to write an IPS patch that replaces the game server URL. This is what I did with SMB35 as well.

And what about the dauth/nso check switch does on connection, how to bypass that? I presume a patch too?

Yes. It depends on the game, but you probably want to look for the following functions:

nn::account::EnsureNetworkServiceAccountAvailable
nn::account::EnsureNetworkServiceAccountIdTokenCacheAsync
nn::account::GetNetworkServiceAccountId
nn::account::LoadNetworkServiceAccountIdTokenCache

Yes it does, I just checked and updated the wiki. Its version string is 2.5.5, so the protocol is probably the same as in SMB 35 and Pac-Man 99.

Yes it does, I just checked and updated the wiki. Its version string is 2.5.5, so the protocol is probably the same as in SMB 35 and Pac-Man 99.

Great to know, thanks!

You'll also probably need to run your own account server, unless there's some other way to force the game to connect? I haven't looked much into the Switch's architecture myself yet, to be honest. I assume it gets the NEX servers location from the account server much like the WiiU/3DS do

No, the Switch finds the game servers by DNS lookup. The easiest way to connect with a custom server is to write an IPS patch that replaces the game server URL. This is what I did with SMB35 as well.

And what about the dauth/nso check switch does on connection, how to bypass that? I presume a patch too?

I have a question on this. Instead of the patch for the game server url, couldn't you disable certificate check and custom DNS to point into your game/authentication server?.
Same logic could go on dauth/nso checks?, I could run my own dauth/nso servers with certificate check and custom DNS, correct?

Correct. Here's a repo that disables certificate checks: https://github.com/misson20000/exefs_patches.

Kinnay, would you appreciate implementations for the dauth/nso servers in the repo?

Not here, but I have a server implementation elsewhere: https://github.com/nintendo-playground/.
It currently implements dauth and aauth up to system version 14.1.2.


Fix an issue in OpenSSL build when cross compiling

The commit 44c681e1a551e0599a8ca170cb0cfcc19c4a5d54 seems to have
broken cross compiling builds, as openssl ./config seems to require
both the CC and MACHINE variables to be set, otherwise it seems to
default to build host compiler and machine variables.  Someone appears
to have already seen this issue when cross compiling for android, and
fixed it in commit bb657ff41c874ca3bba1ca394ff1ea09ee8049b3.  This
patch moves the MACHINE argument and adds it to ALL build types, not
just android.
I'm unclear on the architecture of the PACKAGE_INTERNAL_DEPS_ID, but I saw it being incremented for other similar changes, so I assume this will require an update as well.  If I'm wrong, let me know and I will update the PR.

I'm unclear on the architecture of the PACKAGE_INTERNAL_DEPS_ID

I've added some details here:

https://docs.hunter.sh/en/latest/reference/user-modules/hunter_download.html

The commit 44c681e seems to have broken cross compiling builds

So what platforms do we fix by this change?

Testing:

https://ci.appveyor.com/project/ingenue/hunter/build/1.0.1165
https://travis-ci.org/ingenue/hunter/builds/175285201

This fixes cross compiling from Linux x86_64 to Armv6 32 bit.  My CMAKE_TOOLCHAIN_FILE looks like the following
SET(CMAKE_SYSTEM_NAME Linux)
SET(CMAKE_SYSTEM_VERSION 1)
set(CMAKE_SYSTEM_PROCESSOR armv6)

# specify the cross compiler
SET(CMAKE_C_COMPILER   arm-linux-gnueabi-gcc)
SET(CMAKE_CXX_COMPILER arm-linux-gnueabi-g++)

# where is the target environment
SET(CMAKE_FIND_ROOT_PATH  /usr/arm-linux-gnueabi)

# search for programs in the build host directories
SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
# for libraries and headers in the target directories
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

This is on an Ubuntu 16.04 machine with a 5.4 gcc toolchain standard, although it's not clear if that matters.

it's not clear if that matters

I will merge it because it doesn't break old behavior and seems to fix the issue for you. However I can't guarantee that there will be no problem with your toolchain in future. If you want to be sure you have to extend testing.

Uploading:

https://ci.appveyor.com/project/ingenue/hunter/build/1.0.1171
https://travis-ci.org/ingenue/hunter/builds/175429374

Released: https://github.com/ruslo/hunter/releases/tag/v0.16.27