App Permissions - Manage app access to this tenant

Under the Apps section of the SharePoint Admin Center, there is an App Permissions option. I'm not able to find much documentation around the App Permissions, what should show up here and what shouldn't. I don't know what should show up here, but seems it should be any/all apps that have access across the tenancy as opposed to site level only access. Can we elaborate on this option please, somewhere?
Category

[x] Content fix
[ ] New article
[x] Example checked item (delete this line)

For the above list, an empty checkbox is [ ] as in [SPACE]. A checked checkbox is [x] with no space between the brackets. Use the PREVIEW tab at the top right to preview the rendering before submitting your issue.
(DELETE THIS PARAGRAPH AFTER READING)

Related issues:

fixes #issuenumber
partially #issuenumber
mentioned in #issuenumber

If this fixes (aka: closes) or references an issue, please reference it here. This helps maintaining the issue list as it will (1) link the PR to the issue & (2) automatically close the issue when this PR is merged in.
(DELETE THIS PARAGRAPH AFTER READING)

What's in this Pull Request?

Please describe the changes in this PR. Sample description or details around bugs which are being fixed.
(DELETE THIS PARAGRAPH AFTER READING)

Guidance

Please update this PR information accordingly. We'll use this as part of our release notes in monthly communications.
Please target your PR to 'master' branch. Released documents are in live branch.
(DELETE THIS PARAGRAPH AFTER READING)

Couple things:

unclear what you're saying
we can't accept PRs that have feedback in content... please submit an issue on the doc's page if there's an issues with the content.


dependencies

So in the Gradle build we have:
    compile ("org.hibernate:hibernate-core:${hibernateOrmVersion}") {
        exclude group: 'org.javassist', module: 'javassist'
        exclude group: 'net.bytebuddy', module: 'byte-buddy'
        exclude group: 'org.dom4j', module: 'dom4j'
        exclude group: 'javax.activation', module: 'javax.activation-api'
        exclude group: 'org.glassfish.jaxb', module: 'jaxb-runtime'
        exclude group: 'javax.xml.bind', module: 'jaxb-api'
        exclude group: 'org.hibernate.common', module: 'hibernate-commons-annotations'
        exclude group: 'org.jboss.spec.javax.transaction', module: 'jboss-transaction-api_1.2_spec'
    }
    testCompile ("org.hibernate:hibernate-testing:${hibernateOrmVersion}")
    compile 'io.vertx:vertx-pg-client:3.9.0'
    compile 'io.vertx:vertx-mysql-client:3.9.0'

    runtimeOnly 'org.jboss.spec.javax.transaction:jboss-transaction-api_1.2_spec:1.1.1.Final'

I would like to know what is the reason for all the exclusions here. I would naïvely have expected us to just declare a dependency to hibernate-core, and then programs that use HR would not need to explicitly declare their own dependency to Hibernate. But with all these exclusions, they need to redeclare the dependency in order to pick up stuff like net.bytebuddy.
I suspect that these exclusions might not now be the right thing, since I've eliminated the separate -api module.
Also I'm confused by the exclusion of jboss-transaction-api_1.2_spec and then the re-inclusion as a runtime dependency.
@DavideD could you throw some light on this, I'm sure there was some reason.

I think the idea was to remove all dependencies that we didn't need for a first prototype. @Sanne ^

I can review these.

Also I'm confused by the exclusion of jboss-transaction-api_1.2_spec and then the re-inclusion as a runtime dependency.

On that point: it's only to exclude the JTA API when our own new code is compiled; this helps ensure that we don't expose the blocking JTA API, or use it otherwise unintentionally.
It's then re-introduced as a runtime dependency as I believe ORM can't boot without having it - we might be able to improve on that and make it 100% unnecessary but it doesn't feel like a priority

Well the issue is that right now, by excluding all those things, at least some of which are hard dependencies of Hibernate ORM, we force users to explicitly depend on Hibernate ORM as well as HR.

I think the idea was to remove all dependencies that we didn't need for a first prototype.

We might not need them, but the user's program can't run without them.

Sure I understand. We'll add the ones that the user application needs - the intention is only to exclude dead weight that they won't need.
N.B. the  configuration name in Gradle named "compile" is not meaning what the name suggests :) Hint: there's also a "compileOnly". https://docs.gradle.org/4.10.2/userguide/building_java_projects.html
It's also a very old and deprecated name, I'll change it to use the better named configurations it offers nowadays in Gradle 6+

OK, great, thanks guys.


Added `ydb.{WithTablePathPrefix,WithAutoDeclare,WithPositionalArgs,…

…WithNumericalArgs}` query modifiers options

Supported binding parameters for database/sql driver over connector option ydb.WithAutoBind() and connection string params go_auto_bind={origin,table_path_prefix(path),declare,numeric,positional}
Added testutil.QueryBind test helper

I hereby agree to the terms of the CLA available at: https://yandex.ru/legal/cla/?lang=en

Pull request type

Please check the type of change your PR introduces:

[ ] Bugfix
[x] Feature
[ ] Code style update (formatting, renaming)
[x] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] Documentation content changes
[ ] Other (please describe):

What is the current behavior?

Issue Number: N/A
What is the new behavior?

Other information

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@47416eb). Click here to learn what that means.
Patch coverage: 37.77% of modified lines in pull request are covered.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@            Coverage Diff            @@
##             master     #677   +/-   ##
=========================================
  Coverage          ?   45.80%
=========================================
  Files             ?      154
  Lines             ?    15833
  Branches          ?        0
=========================================
  Hits              ?     7253
  Misses            ?     8252
  Partials          ?      328

Flag
Coverage Δ

1.17.x
45.49% <37.90%> (?)

1.19.x
45.89% <37.77%> (?)

1.20.x
45.87% <37.77%> (?)

macOS
45.79% <37.77%> (?)

ubuntu
45.89% <37.77%> (?)

unit
45.80% <37.77%> (?)

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

 Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


ENH: Make Slerp callable with a scalar argument

What does this implement/fix?
Now we can do
s = Slerp(...)
r = s(0.5)  # Single rotation in r

Very simple change, I also moved Slerp-related code and tests into separate files, which makes sense.
@rgommers @tylerjereddy @pmla please take a look if possible, not much to review here.

I think it's good to be merged, right? Waiting for CI to complete.

Merged, thanks @nmayorov

Weird crash in the pcc64le CI run:
Error in `/home/travis/virtualenv/python3.6.7/bin/python': free(): invalid next size (normal): 0x0000010008de7e20

let's keep an eye on that


Update Pytorch and Tensorflow images

Description

How Has This Been Tested?
The feature has been tested as part of PRs : https://github.com/red-hat-data-services/s2i-pytorch-notebook/pull/9, https://github.com/red-hat-data-services/s2i-tensorflow-gpu-notebook/pull/11
Merge criteria:

[x] The commits are squashed in a cohesive manner and have meaningful messages.
[ ] For commits that came from upstream, [UPSTREAM] has been prepended to the commit message.
[x] JIRA link(s): Related issue: https://issues.redhat.com/browse/RHODS-2978
[x] The Jira story is acked.
[ ] Live build image:
[ ] Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
[ ] The developer has manually tested the changes and verified that the changes work.
[ ] QE contact acknowledges that this has been tested and is approved for merge.

@VaishnaviHire is this just pointing to the updated images (pytorch/tensorflow) from the other PRs?

@VaishnaviHire is this just pointing to the updated images (pytorch/tensorflow) from the other PRs?

Yes. Following are the tagged branches
https://github.com/red-hat-data-services/s2i-pytorch-notebook/tree/nb-5
https://github.com/red-hat-data-services/s2i-tensorflow-gpu-notebook/tree/nb-6


Look into magic numbers in styles

There are quite a few places in which we have hardcoded numbers in styles ex Page component. It makes sense to move them into variables to understand why those static numbers came into the styling. This would help with readability and reusability (same heights are used across components. Same change as a result needs to be done in multiple places)

This fits in nicely with the same complaint I had about colors, so I'd like to tackle those both as a single project.


Adding ESLint and EditorConfig

ESLint is a great tool to learn JS-Coding-Conventions on the fly and to already detect errors while writing code. Using Airbnb Style Guide as ESLint-base.

Thank you, David! Very well done.


Move the admin user configuration from env to yaml

coveralls also don't consider the method covered and I'm wondering if this will fix that problem.

Coverage remained the same at 80.152% when pulling 7bfa39d22478a1522192ba88436a670564380960 on admin-netids-test-env into 0432971bf85b61677fb53547cb6b43be3640ae46 on master.


schema object without a type attribute

Use case: does-json-schema-to-ts-work-on-json-file-schemas
Look at: schema-object-without-a-type-attribute-in-swagger-2-0
const Account = {
	properties: {
		balance: {
			type: 'string',
			description: 'balance in unit WEI, presented with hex string',
			example: '0x47ff1f90327aa0f8e',
		},
		energy: {
			type: 'string',
			description: 'energy in uint WEI, presented with hex string',
			example: '0xcf624158d591398',
		},
		hasCode: {
			type: 'boolean',
			description: 'whether the account has code',
			example: false,
		},
	},
} as const;
type Dog = FromSchema<typeof Account>;

// Now: type Dog = unknown
// Expected: type Dog = { balance, ... }

You forgot type: "object" before properties

@NikitaIT sorry I didn't respond earlier. I'm not so sure to want to resolve this issue.
From the spec (and the comment in your linked stack overflow page), type Dog should be a union: { balance, ... } | string | null | boolean | number | unknown[]. Which is not much better than unknown.


Pathfinder-USILS-CommunityPatch.netkan merged, but not showing up

This was merged at the same time as the Pathfinder-RemotetechPatch was merged.
The remotetech one is visible in ckan, but this one is not, even when I filter all

It is visible in at my pc

netkanbot just added it to ckan

Ok, I'm now seeing it myself.
This can be closed.
Thanks for checking
JBB
On 9/30/15 11:35 AM, Arne Peirs wrote:

It is visible in at my pc
—
Reply to this email directly or view it on GitHub
https://github.com/KSP-CKAN/NetKAN/issues/2359#issuecomment-144448668.


Implement fix to show CP icons in casual/comp MM

Added in https://github.com/rbjaxter/budhud/commit/d5c162efb49e5ddba2acab967d3a6581e94fcb1d.


Proposal: optional pause and resume methods on Devices

On pausing and resuming, the RunEngine could call device.pause() and device.resume() on all objects that it knows about. This would give objects like flyers or complicated detectors a way to clean themselves up if needed.
I am proposing that this be an optional part of the bluesky interface, not a required method.
Thoughts?

I think this is probably a good idea and am also in favor of not bloating the interface further by making these optional.


treewide: switch back to alejandra formatting

flake-modules: treefmt is formatter by default
flake-modules: switch fmt to alejandra
treewide: reformat with alejandra
.git-blame-ignore-revs: init

This PR switches back to using Alejandra to format the project, as discussed on matrix.
A git blame ignore-revs-file is included using a filename recognised by GitHub.
To use this locally, you should configure your git config as described in .git-blame-ignore-revs's header comments. Or see this section of the git manual.
In the future, it'd be nice to automatically add that config, e.g. via git-hooks and/or a devshell hook.
I kept the change in flake-modules and the actual treewide re-formatting in separate commits for ease of review, however they can be squashed if preferred.
Note to self: when squashing or rebasing, remember to update the sha in .git-blame-ignore-revs!!

The changes look correct to me. The .git-blame-ignore-revs is a nice addition.

Of course, let's wait for @traxys's confirmation before merging such a change.

This might need a deeper look indeed.
In terms of padding in lists/attrs, I don't really care.
I am not sure whereas the downgrades can be made better (while staying alejandra-conformant).
I know that it is possible to have (not too big) lists displayed on a single line.
Alejandra is probably less strict than nixfmt, so we might have some margin to adapt code here and there. To be confirmed though.

Alejandra is probably less strict than nixfmt, so we might have some margin to adapt code here and there. To be confirmed though.

I'd be surprised if that is the case, but for sure worth investigating: Alejandra was originally marketed as a fully AST-based (and therefore deterministic) formatter.

Alejandra is probably less strict than nixfmt, so we might have some margin to adapt code here and there. To be confirmed though.

I'd be surprised if that is the case, but for sure worth investigating: Alejandra was originally marketed as a fully AST-based (and therefore deterministic) formatter, but that may have changed I guess.

Specifically on lists, I stand corrected. If your input code has the list on a single line, alejandra will avoid splitting it up.
So you could have two identical lists, formatted differently in alejandra.
As an example, this is valid formatted code output by alejandra:
{
  foo = ["default" "tinted" "deuteranopia" "tritanopia"];
  bar = [
    "default"
    "tinted"
    "deuteranopia"
    "tritanopia"
  ];
}

Whether or not this non-determinism is a good or a bad thing, I'm undecided.

As for practical ways we could apply that formatting to 450 files, I'm at a loss.
For files with no changes since 62f32bfc711f0a3c8a52af4c0790345b4b3d2346, we could simply checkout a copy of the file from the parent commit 62f32bf^ using a bash script. This should cover most files.
For other files, we'd either have to review every list on a case-by-case basis or write a small single-purpose custom formatting tool that decides based on list length and/or resulting line-length whether to format a list on one line or not.
If we do that, I think it should be done as part of the treewide reformat commit, so that it can be a single entry in the ignore-revs file.
That said, I'm not 100% convinced it is worth the effort.
This issue in particular is annoying, because it means we can't use RFC145 docstrings.

That's one of the reasons I don't like alejandra much, it leaves a huge user choice in the mix, making it difficukt to enforce a style & having loads of PRs with only style reviews.
I'm not really favourable for it, but I am not against it if you decide otherwise

For me the biggest use of a formatter is to avoid any style comments in PRs (or at least try to have almost none). I feel like with nixfmt we have had much less of those, and I'd like that to continue, so I guess the options I'd like are either we stay on nixfmt, or we go back to alejandra but we mostly don't question how people format their code in accordance to alejandra

That's one of the reasons I don't like alejandra much, it leaves a huge user choice in the mix, making it difficukt to enforce a style & having loads of PRs with only style reviews.
I'm not really favourable for it, but I am not against it if you decide otherwise

I agree on the fact that a "strict" formatter is preferable. However, in this case, the question was worth considering as I find the nixfmt style very less readable than alejandra.
But not having to discuss style in PR reviews is a significant benefit of nixfmt... Not easy...

I've marked this as draft since discussion is ongoing and any decisions would likely involve changes to the PR.
I think we're all agreed that a strict formatter is preferable, however we sometimes find specific nixfmt choices less readable than manual formatting.
Frankly, to some degree this is inevitable; the stricter a formatter is the more edge case you'll run into where it doesn't work well for that specific scenario.
For short non-singleton lists, we may be able to patch nixfmt instead of resorting to an entirely different formatter... This would give us the "best of both worlds".
Are short non-singleton lists the only solid example where you prefer alejandra @GaetanLepage?

I am willing to put my preferences aside considering the importance of strict formatting. This is indeed the most important feature of the formatter.
I am OK to let it go and focus on more important matters.
Thank you anyway for the in-depth exploration of the subject.

I'll close this as I think we're all agreed we don't want to do this. Fingers crossed https://github.com/NixOS/nixfmt/issues/206 is accepted upstream or we are able to maintain our own patch.


Adapt to Leaflet > 1.0.3

The master branch in Leaflet now uses a ES6 module structure, changing a lot of the internal calls to e.g. L.DomEvent.* → DomEvent.*.
Code for the rotate functionality should be adapted/rebased so it can be merged on top of that.

That would be nice

@IvanSanchez I am happy to start adapting the rotate code. How would you suggest we best do it?  Was the change to ES6 structure a single merge commit or was it done over time and multiple commits? Should we first rebase on top of the last "ES5" snapshot and then adapt to ES6?
I believe it will be quite some effort still :D


Confuse on the logic judge isRandomPort and the comment  note | 随机端口判断的逻辑和注释容易混淆

Describe the bug
file-location : sofa-rpc/core/api/src/main/java/com/alipay/sofa/rpc/common/utils/NetUtils.java
function : public static boolean isRandomPort(int port)
logic in isRandomPort()  is conflict with the comment, so which is the correct ？ the logic or the comment ?

### Expected behavior
Actual behavior
Steps to reproduce
Minimal yet complete reproducer code (or GitHub URL to code)
Environment

SOFARPC version:
JVM version (e.g. java -version):
OS version (e.g. uname -a):
Maven version:
IDE version:

@jnan806 A precondition is that the port is between - 1 and 65535. Therefore, the comment that is less than 0 actually refers to - 1 too. Look very carefullyl. If you are interested, you can submit PR to modify this comment.

@jnan806 A precondition is that the port is between - 1 and 65535. Therefore, the comment that is less than 0 actually refers to - 1 too. Look very carefullyl. If you are interested, you can submit PR to modify this comment.

Does 0 is the random port ?

@jnan806 A precondition is that the port is between - 1 and 65535. Therefore, the comment that is less than 0 actually refers to - 1 too. Look very carefullyl. If you are interested, you can submit PR to modify this comment.

glad to contribute it. Please sign it to me ?

@jnan806 Okay, look forward to more participation.

@EvenLjj  PR has been submitted. And need an approval to run the workflow.


Fix property overriding, while calling 'super'

In a case, when we need to call parent class method with the same name as existing property, current autobind-decorator implementation overrides instance method with parent method.

Thanks!


allow to pass custom event on brush start

POC - but this was required to handle some synced drawing across multiple charts

added ability to pass custom event on brush.start
added ability to pass alternative (named desiredTarget) to brush.move
temporary added dist to repo for testing purposes*

Is there a possibility to introduce those functionality with this shape or differently

brush.move allows syncing between charts. See https://observablehq.com/@d3/brushable-scatterplot-matrix#brush for an example.


39 continous integration building

Description
This PR adds a GitHub action which will run the linter on PR's.
Fixes #39
Time invested
~5h
Type of change
Please delete options that are not relevant.

New feature (non-breaking change which adds functionality)

Does this PR introduce a breaking change?
No :)
Most important changes
As described above, this change will run the linters for every PR. This is done by running the same docker containers as the precommit hook.
Additionally, the markdownlint.yml file is now mounted through the default volume to avoid the creation of a empty yml file in the root path.
Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works (might be obsolete with CI later on)
[x] New and existing unit tests pass locally with my changes (might be obsolete with CI later on)

@ll7 could you set the settings as described in the PR, to require the action to accept a PR?

You can add rules to your branches and how your merge request works.
Your repo -> Settings -> branches -> Branch protection rules -> Add rule
There, you will find something called Require status checks to pass before merging. Under this, you should see Status checks found in the last week for this repository. If you find the status you want to be passed before merging, you can enable the same.
Docs: https://help.github.com/en/github/administering-a-repository/defining-the-mergeability-of-pull-requests
(Source)

I think, that this PR does not fix #39, see second requirement for building the agent.

@ll7 as I understood last week, the adapted setup from @nylser already only uses one container and creates a json file with the result. So there shouldn't be a need to build a new container.
Wouldn't it be best to just use the same compose setup we use for developement in an GitHub action?

@ll7 as I understood last week, the adapted setup from @nylser already only uses one container and creates a json file with the result. So there shouldn't be a need to build a new container.
Wouldn't it be best to just use the same compose setup we use for developement in an GitHub action?

Just chiming in, as I was mentioned: #27 will change the structure of the project a bit -- the separate carla-ros-bridge container won't be necessary anymore, as everything will be contained in the agent container.
Regardless, @ll7 is right: One of the requirements of #39 states "creating the agent docker container".
This is inprecise, what I actually meant by it: Building the image of the agent Dockerfile (docker-compose build agent), to already have it ready for testing in the second part - #38.
I updated #39 correspondingly -- but we can discuss this tomorrow of course.

@nylser thank you for summing up the new setup!
I would recommend to move the task "building the image" to #38 since it needs a physical machine in the lab. We have a storage limit of 500mb which the limit would exceed. Since we have to build the images on a physical machine anyway I don't see an advantage in building the image previously, it would just block these changes from being merged if we need to setup a physical machine as runner first.
Furthermore why should we rebuild an image? Can't we just run the stack on the physical machine?
What do you think @nylser? We can also discuss this tomorrow.

My thought process behind building the image: I would like to have a tagged artifact for each build.
This way, we know for sure, that a specific tag of the image always should achieve the same results and run through.
We can use the GitHub container registry ghcr.io to store our images, I think there almost second to none storage restrictions for public projects. Once the initial image base image is created, most of the time, only the python files will be changes, making for much smaller image deltas (Docker uses intelligent caching).
This way, our leaderboard-agent will then be a fixed artifact that can be pulled in #38 and execute it.

As discussed, the building will be addressed in another pull request

@timdreier can you resolve the merge conflict?


Time to switch to switch?

Thanks for this great tool that I use to teach git at Paris-Dauphine University.
This request is related to #750. git 2.23 was released two and half years ago. May I suggest that it’s about time to switch the lessons to talk about git switch (and git restore where appropriate) instead of git checkout? I think that this would ease learning.

That's fair feedback! Anecdotally though, adoption of new git commands (in my opinion) has been a little slow in industry, especially when they only provide a small layer of syntactic sugar over the existing commands. Most engineers I work with still use git checkout even though they know switch exists (for instance)
We have the reference to the git switch command in the branching level. If you want, you could add a custom level for your students via these instructions that focuses on it:
https://github.com/pcottle/learnGitBranching#level-builder
Switching over all of the lesson content seems just like a pretty big jump, and we might need to refresh all the various translations as well

I'm all for cleaner mental models for using git, but I'd point out that the documentation for git switch still says

THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.

So perhaps learnGitBranching should at least wait until the experimental status is removed before considering replacing git checkout with it.

Dropping in some links from the mailing list regarding the experimental status of git-switch/git-restore:

May 2020 on what the 'experimental' status means: Re: Why are experimental commands git restore and git switch suggested in CLI output?
May 2021 discussion on their continued experimental status: Re: git switch/restore, still experimental?.  These are interesting tidbits: one, two, three.

That said, I don't think it's a bad idea for learnGitBrancing to advertise the possible use of git-switch -- even if only to garner the usability feedback that the Git project needs. But maybe that's a bad reason to put something into training materials 😄

Thanks for the great links @vermiculus, I really agree with the following:

Which leaves us with two hard choices regarding switch/restore, none of
them really being comfortable:

we scrap switch/restore because their usability is not really all that
improved relative to git checkout.

we leave switch/restore as-are (because by now, changing the options or
the design would be almost certainly disruptive to users who already
tried to adopt the new commands, I being one of those users).

I think it's too late to improve switch's usability, but it hasn't seen the huge jump in adoption that I expected (maybe due to some of the usability issues in the thread). As long as the majority of industry still uses checkout, I'd rather stick with that (and let folks play around with switch in sandbox mode if they want) rather than be the first to update all the lessons and be out of sync with the wider community.
Put another way -- I'd rather this resource be helpful for new students/interns/beginners that have to use checkout since other references use that, than be on the bleeding edge of git adoption.

I don't understand the argument against changing the behavior of git switch as Ævar suggested in their post, which I totally agree with. I mean, what's the purpose of an experimental marker (which explicitly says, in all caps, "THE BEHAVIOR MAY CHANGE"), if not to allow precisely that kind of improvement?

I mean, what's the purpose of an experimental marker (which explicitly says, in all caps, "THE BEHAVIOR MAY CHANGE"), if not to allow precisely that kind of improvement?

I think despite having this warning, it's hard for humans not to build muscle/mental memory when learning new tools. If someone just changed the behavior of most of the git switch options overnight with a new git release, that'd probably produce a lot of angst/frustration for folks who have been using the command for a while and built up muscle memory. And keep in mind it's not like a web release -- the behavior might vary between machines for a single person depending on the version of git.
So it's an interesting tradeoff -- experimental commands should leave the space for changes down the line but after enough time and adoption, those changes come at a cost. It's just like google products being in "beta" for years -- after you have 100 million users, changing something comes at a cost :P

I understand where you're coming from, but I would say that if the feature has reached that point, then the experimental/beta label should be removed; otherwise, they don't really mean anything.
But that's all beside the point, since it's a decision to be taken by the git project itself — regarding learnGitBranching, I agree that it should remain using checkout until the situation is clarified upstream.

Agreed! Thanks everyone for keeping a pulse on this 🙌🏻
(not the same exact thing but our switch to main from master was a time where I was excited to match the industry movements)

Interesting tidbit I noticed today. The advice for detached HEAD recommends git-switch:
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

If git's advice mechanisms are recommending git-switch, I wonder if that changes the calculus here at all.

Yeah that's interesting 🤔 I wonder how many of the git errors and help pages recommend checkout vs switch.
even looking at git help, there's no mention of checkout at all!
grow, mark and tweak your common history
   branch            List, create, or delete branches
   commit            Record changes to the repository
   merge             Join two or more development histories together
   rebase            Reapply commits on top of another base tip
   reset             Reset current HEAD to the specified state
   switch            Switch branches

I'm surprised by that git help piece -- and that's an even stronger argument to 'switch to switch' here than the advice stuff. One of the goals of any tutorial should be to build trust in and encourage (or at least not discourage) the use of built-in help facilities.

Perhaps we should tell git developers that we are wondering about the status of these commands and somehow (with as much tact as possible) make it understood that the current situation is quite unsatisfactory. It is understandable to want to gather opinions and to not rush decisions so that a good API is built, but it’s now been a very long time. From the discussions referred to here above, it seems that they themselves do not really know which direction to take, but (from a cursory reading) I doubt that waiting more will help. I think they should simply take a decision.
I’ve been wanting to write such an e-mail to their mailing list, but could not find the time yet to phrase things as nicely as can be so as not to hurt anyone.

I already have a disclaimer here:

with the link pointing to here:
https://git-scm.com/docs/git-switch
should I maybe just update that language? I would bet most folks have access to git switch now, but its just a matter of what command they prefer (and what command their teammates use)

I would suggest replacing "....because most people won't have access to switch yet" with "...because the switch command is still experimental and the syntax may change in the future". I think that better reflects the reality of the situation.


costly ng-show

ng-show purposedly is rather costly, as the hidden directives' watch-expressions are still evaluated. We should take a deeper look into that, to what extend it applies to our code-base and whether or not all our directives would still work if we'd switch to ng-if (afaict they should, as they shouldn't have internal state transitions, i.e. should only render the redux-state to the DOM). Also see the "when to switch and when not to switch"-section in the linked article.

too old


Use size_t in Enclave.edl

In the Enclave.edl we use a mix of uint32_t and size_t for length parameters. See here for example
        public sgx_status_t init_direct_invocation_server(
            [in, size=server_addr_size] uint8_t* server_addr, uint32_t server_addr_size
        );

	public sgx_status_t init_light_client(
			[in, size=params_size] uint8_t* params, size_t params_size,
            [out, size=latest_header_size] uint8_t* latest_header, size_t latest_header_size
        );

I think we should always use size_t. In Rust this is apparently mapped to usize which would allow us to remove some casts. Using size_t everywhere would make the code not only more consistent but also more idiomatic for both C and Rust. Also we could support architectures that are not 32-bit. Looking forward to see the enclave running on an 16-bit machine 😄

I wanted to quickly do this, but there are no compiler warnings if the types don't match. So we need to be careful. I still think it makes sense to do it, but it is a bit more involved than I thought.


feat: Authorized parties endpoint in enduser API

Description
This adds a parties endpoint in the enduser-API, proxying requests to access-management and returning a custom DTO for all parties that the user has some sort of access relation to.
Related Issue(s)

#660

Verification

[x] Your code builds clean without any errors or warnings
[x] Manual testing done (required)
[ ] Relevant automated test added (if you find this hard, leave it and we'll help out)

Documentation

[ ] Documentation is updated (either in docs-directory, Altinnpedia or a separate linked PR in altinn-studio-docs., if applicable)

Does frontend expect a GraphQl query here, or will they use this REST endpoint?

Does frontend expect a GraphQl query here, or will they use this REST endpoint?

I've added a GQL query. In order to separate them (in code) from the DialogQueries, I've used partials, and added the auth attribute to a third, common partial. Not sure if this is a good way.


add(starters): Add Next JS Boilerplate

Name
Link

Next JS Boilerplate
https://creativedesignsguru.com/demo/Nextjs-Boilerplate/

Add starter code for Next JS using Tailwind CSS for the styling part.

[x] My item is in the right category
[x] My item is logically grouped below similar items
[x] My item's name and description respects the conventions of the list
[x] My item is awesome
[x] My item is in line with the Tailwind brand usage guidelines
[X] I have read and followed the contribution guidelines

Thanks!


[Event Request] Table 39 Purchase Line - trigger OnDelete - OnDeleteOnAfterCalcShouldModifySalesOrderLine

Please add an Event OnDeleteOnAfterCalcShouldModifySalesOrderLine in trigger OnDelete in Table 39 Purchase Line
[Event Request] Table 39 - Purchase Line - OnDelete
trigger OnDelete()
var
    PurchCommentLine: Record "Purch. Comment Line";
    SalesOrderLine: Record "Sales Line";
    IsHandled: Boolean;
    ShouldModifySalesOrderLine: Boolean;
begin
    IsHandled := false;
    OnDeleteOnBeforeTestStatusOpen(Rec, IsHandled);
    if not IsHandled then
        TestStatusOpen();

    if (Quantity <> 0) and ItemExists("No.") then begin
        PurchLineReserve.DeleteLine(Rec);
        IsHandled := false;
        OnDeleteOnBeforeCheckQtyNotInvoiced(Rec, IsHandled);
        if not IsHandled then begin
            if "Receipt No." = '' then
                TestField("Qty. Rcd. Not Invoiced", 0);
            if "Return Shipment No." = '' then
                TestField("Return Qty. Shipped Not Invd.", 0);
        end;

        IsHandled := false;
        OnDeleteOnBeforePurchaseLineDelete(Rec, IsHandled);
        if not IsHandled then begin
            CalcFields("Reserved Qty. (Base)");
            TestField("Reserved Qty. (Base)", 0);
            WhseValidateSourceLine.PurchaseLineDelete(Rec);
        end;
    end;

    if ("Document Type" = "Document Type"::Order) and (Quantity <> "Quantity Invoiced") then
        TestField("Prepmt. Amt. Inv.", "Prepmt Amt Deducted");

    ShouldModifySalesOrderLine := "Sales Order Line No." <> 0; // <-- NEW VARIABLE
    OnDeleteOnAfterCalcShouldModifySalesOrderLine(Rec, ShouldModifySalesOrderLine); // <-- NEW EVENT
    if ShouldModifySalesOrderLine then begin // <-- NEW CONDITION

        LockTable();
        SalesOrderLine.LockTable();
        SalesOrderLine.Get(SalesOrderLine."Document Type"::Order, "Sales Order No.", "Sales Order Line No.");
        SalesOrderLine."Purchase Order No." := '';
        SalesOrderLine."Purch. Order Line No." := 0;
        SalesOrderLine.Modify();
    end;
    ...

[IntegrationEvent(false,false)]
local procedure OnDeleteOnAfterCalcShouldModifySalesOrderLine(var PurchaseLine: Record "Purchase Line"; var ShouldModifySalesOrderLine: Boolean)
begin
end;

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.
Build ID: 46009.


Add 1/4 of a node option in simple menu

closes #20

Well, I don't speak javascript ... but beside this, it looks ok


OCPBUGS-2200: Add remediationAction at the Policy spec level

Signed-off-by: Tao Liu<EMAIL_ADDRESS>

@tliu2021 thanks so much for the contribution! Could you please address the linting failures?
Also, could you please restructure your commit message to follow our standards?
https://github.com/open-cluster-management-io/community/blob/main/sig-policy/contribution-guidelines.md#commit-messages
You can look at the following commits as examples:
https://github.com/stolostron/policy-generator-plugin/commit/88a386a35a2961edeb1a8cb9120e412745166173
https://github.com/stolostron/policy-generator-plugin/commit/cde84ee52ff69df01d1fbbdc37acaaf5332b5c5a

The commit message has been updated and linting failures are fixed.

/cherry-pick v1.9


Not a issue but Want to publish the Automation Test Results executed in Azure Devops to team members through(Mail or Teams)

I have developed a testing framework for automating the UWP Application using appium.
Created the build pipeline to run the tests in VM in Azure Devops and able to see the Test Results and summary.
But wanted this results to publish to my entire team of 12 members as soon as the Test Automation in the VM completes through Mail or Microsoft Teams
Can anyone help me on this, if anyone feels any blog or reference would be useful for the above issue. I am reachable<EMAIL_ADDRESS>

It is possible to set notifications for pipeline completion that will send out the report over email: https://docs.microsoft.com/en-us/azure/devops/notifications/?view=azure-devops

I Just went through the link, but could not find to send the below summary report through mail

Hi Vishnu,
We don't support notifications on the test task itself, however you can add a email notification task in your pipeline after the test task and configure it. This task will send out email notifications to the members you have added once the results are published from the test task.
Thanks,
Aditi

Thank you Additi for the response, I will try to use the email notification task.

Worth trying report generator -
ref this link Report Generator for SpecFlow
https://marketplace.visualstudio.com/items?itemName=mmajcica.SpecFlowReportGenerator
after the html file generation, you can send an email notification with that attachment. worth trying. I am also in the middle of doing that's


Add formatMessage color option

Closes #108

Thank you for this pull request 🎉 (my pull request https://github.com/bluwy/publint/pull/87 had been closed).

Sorry for rejecting the PR in the past, I can't seem to recall myself doing that but looks like I did 😅 Seems like there's many usecases shown so far that this option is helpful so glad that it's implemented now.


Fix build on ARM, and revert old workaround (not needed anymore)

Please merge the second patch. Build still fails on ARM, and and applying the second patch seems to fix it.


Windows 32/64 bit, folder install NOGUI switch

There is a service version to cover the needed functionality, but it will be a good idea to add a /nogui switch that 'hides' the notification area icon thus preventing accidental shutdown by the client.

If you run the application from another application there will be no GUI.
But we recommend to use ErpNet.FP as a service.
/nogui switch is not planned.

There is no notification area icon anymore. We recommend to use ErpNet.FP as a service. Use Windows Services management console or command line tools to start/stop/restart the service, or use Microsoft Services API to control the Services programatically.


SQL: codegen pipeline

This patch adds a first version of a mirror of the dataflow dialect introduced in #471. Currently, this just mirrors the exact same dialect and does not have any special behavior. However, as soon as we have both PRs merged, we should be able to connect the xdsl and the mlir world within this project.

This PR currently depends on a new release of xdsl (v.0.4.2). I am working on releasing that version asap.

In order to try using the Python bindings, this current contains ingos commits to expose them. Once this is merged, I will rebase to remove them.

This work has been merged mainly. All the other things an be found here: codegen branch


provide bids-app

and include into https://bids-apps.github.io registry.  That would facilitate adoption since it would make it super easy to run on bids datasets
Some examples could be

https://github.com/khanlab/hippunfold
https://github.com/DCAN-Labs/CABINET -- seems to include/use SynthSeg but unlikely could be used alone for the purpose of running on non-babies bids dataset

Could you please provide more detail on how it was completed? Thank you in advance


Unable to parse inline JSX element with MDX expression child

It seems that since 1.0.0-alpha.17 this syntax doesn't work any more:
{1}

You get the following error:
Err(
    Message {
        place: Some(
            Point(
                2:1 (17),
            ),
        ),
        reason: "Expected a closing tag for `<span>` (1:1)",
        rule_id: "end-tag-mismatch",
        source: "markdown-rs",
    },
)

1.0.0-alpha.16 parses it correctly:
Ok(
    Root {
        children: [
            Paragraph {
                children: [
                    MdxJsxTextElement {
                        children: [
                            MdxTextExpression {
                                value: "1",
                                position: Some(
                                    1:7-1:10 (6-9),
                                ),
                                stops: [
                                    (
                                        0,
                                        7,
                                    ),
                                ],
                            },
                        ],
                        position: Some(
                            1:1-1:17 (0-16),
                        ),
                        name: Some(
                            "span",
                        ),
                        attributes: [],
                    },
                ],
                position: Some(
                    1:1-1:17 (0-16),
                ),
            },
        ],
        position: Some(
            1:1-2:1 (0-17),
        ),
    },
)

I used the following config:
    let mut opts = markdown::Options::default();
    let mut parse_opts = markdown::ParseOptions::mdx();
    parse_opts.constructs.gfm_table = true;

    opts.parse = parse_opts;

    // Parse the markdown file into an AST
    let mdast = markdown::to_mdast(&content, &opts.parse);

Perhaps this is the commit that caused it? https://github.com/wooorm/markdown-rs/commit/71361e4ada574d50cd9880422f5cf7ca3a38689c
Happy to take a stab at fixing this. Any pointers about what might be going on and where to start would be appreciated!

Would love to have you help!
The commit you link to could definitely be it.
Weird that your input code doesn’t match? It seems that the comments talk about it, and the tests cover it?
In the commit message, I linked to the commits I tried to port. Perhaps there‘s a difference?

Sounds good! I'll take closer look and familiarize myself with the internals a bit.
I've started by adding a test case to tests/mdx_jsx_text.rs that repro's the issue (ignore incorrect positions atm):
    assert_eq!(
        to_mdast("{1}", &mdx.parse)?,
        Node::Root(Root {
            children: vec![Node::Paragraph(Paragraph {
                children: vec![Node::MdxJsxTextElement(MdxJsxTextElement {
                    name: Some("a".into()),
                    attributes: vec![],
                    children: vec![Node::MdxTextExpression(MdxTextExpression {
                        value: "1".into(),
                        position: Some(Position::new(1, 1, 0, 1, 3, 2)),
                        stops: vec![(0, 2)]
                    }),],
                    position: Some(Position::new(1, 1, 0, 1, 3, 2))
                }),],
                position: Some(Position::new(1, 1, 0, 1, 11, 10))
            })],
            position: Some(Position::new(1, 1, 0, 1, 11, 10))
        }),
        "should support mdx jsx (text) with expression child"
    );

I'll see how far I get!

I think I can see the issue, but I'm struggling to figure out the right fix.
The issue is indeed in src/construct/mdx_expression_flow.rs:
pub fn end(tokenizer: &mut Tokenizer) -> State {
    // ...comments removed for brevity...
    match tokenizer.current {
        None | Some(b'\n') => {
            reset(tokenizer);
            State::Ok
        }
        // -------- Attempting to parse a JSX tag after the expr ---------
        Some(b'<') if tokenizer.parse_state.options.constructs.mdx_jsx_flow => {
            tokenizer.attempt(
                State::Next(StateName::MdxExpressionFlowAfter),
                State::Next(StateName::MdxExpressionFlowNok),
            );
            State::Retry(StateName::MdxJsxStart)
        }
        // ----------------------------------------------------------------
        _ => {
            reset(tokenizer);
            State::Nok
        }
    }
}

If you take out those lines handling the JSX tag case, what seems to happen is that we try to parse the closing tag , and the parser realizes "aha, we're no longer in a block-level JsxFlow, and backtracks to the beginning of the line, parsing everything inside a paragraph.
With this line, what instead happens is we never backtrack, and we get the mismatch error because it seems there's a leftover event after we run compile (to_mdast.rs).
So unless I'm way off here, it seems like we'd like to be able to do the same thing once we've parsed the full line?
e.g. if you change the highlighted code above to this:
        Some(b'<') if tokenizer.parse_state.options.constructs.mdx_jsx_flow => {
            tokenizer.tokenize_state.token_1 = Name::MdxJsxFlowTag;
            tokenizer.attempt(
                State::Next(StateName::MdxJsxFlowAfter),
                State::Next(StateName::MdxJsxFlowNok),
            );
            State::Retry(StateName::MdxJsxStart)
        }

This parses, but we don't get an inline JSX flow, inside a Paragraph, but a block-level JSX tag instead.
Any pointers here would be really appreciated!

I actually just noticed that calling to_mdast with this input: {1}<x/> causes a panic:
thread 'main' panicked at /Users/nik/.asdf/installs/rust/1.75.0/registry/src/index.crates.io-6f17d22bba15001f/markdown-1.0.0-alpha.20/src/to_mdast.rs:1557:30:
expected tag
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

to_html_with_options returns a blank string, and there's a test for this case.
This was the config I used:
    let mut opts = markdown::Options::default();
    let parse_opts = markdown::ParseOptions::mdx();

    opts.parse = parse_opts;

    // Parse the markdown file into an AST
    let mdast = markdown::to_mdast(&content, &opts.parse);

thanks!


Sieve of Eratosthenes

Description
The sieve of Eratosthenes is an ancient algorithm for finding all prime numbers up to any given limit.
/*
COMPLEXITY = O(N log log N)
}
*/
Domain
Algorithm
Type of Contribution
Addition, Documentation
Code of Conduct

[X] I follow Contributing Guidelines & Code of conduct of LearnCPP.

/assign

/assign

I have already started work on this issue..

Had been waiting for the confirmation from admin.

If not then I'm gonna take down the issue

I'm gonna make a new issue and work on it sorry team


WebManagement.exe not found in Windows 11

Hi!
This page most probably works fine for Windows 10, but when I try to use this in Windows 11, I find that when I get to using the "WebManagement.exe" service instructions, the "WebManagement.exe" does not seem to exist in Windows 11. I cannot locate a corresponding service either...
: P
/Errol

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

ID: 68c07ba9-8f4f-c051-c945-16742c7fe409
Version Independent ID: 61c4da19-8278-4764-05a4-000653932b83
Content: Provision Windows Device Portal with a custom SSL certificate - UWP applications
Content Source: windows-apps-src/debug-test-perf/device-portal-ssl.md
Product: uwp
Technology: deployment
GitHub Login: @Karl-Bridge-Microsoft
Microsoft Alias: kbridge

You must run from an elevated command prompt. Run webmanagement.exe /help to get in-context help.
WebManagement.exe is located in a not identifiable folder and is a Windows core system file. The program is not visible.
You can also find the service listed in Task Manager, under the "Services" tab.

Sorry, no go in Windows 11:
: P
/Errol
Från: KB @.>
Skickat: den 25 mars 2022 18:13
Till: MicrosoftDocs/windows-uwp @.>
Kopia: Errol Jacoby @.>; Author @.>
Ämne: Re: [MicrosoftDocs/windows-uwp] WebManagement.exe not found in Windows 11 (Issue #3711)
You must run from an elevated command prompt. Run webmanagement.exe /help to get in-context help.
WebManagement.exe is located in a not identifiable folder and is a Windows core system file. The program is not visible.
You can also find the service listed in Task Manager, under the "Services" tab.
—
Reply to this email directly, view it on GitHub https://github.com/MicrosoftDocs/windows-uwp/issues/3711#issuecomment-1079232480 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ABIU6AE3BUQQYZNTTZ4CJF3VBXXZVANCNFSM5QNBIFDA .
You are receiving this because you authored the thread.  https://github.com/notifications/beacon/ABIU6AFW2YLFWVHJVX67E4LVBXXZVA5CNFSM5QNBIFDKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOIBJ4PYA.gif Message ID: @.*** @.***> >

I just realised now that I had sent an image of trying the command in PowerShell/Terminal, but I get the same result in CMD:
Sorry!
: P
/Errol
Från: KB @.>
Skickat: den 25 mars 2022 18:13
Till: MicrosoftDocs/windows-uwp @.>
Kopia: Errol Jacoby @.>; Author @.>
Ämne: Re: [MicrosoftDocs/windows-uwp] WebManagement.exe not found in Windows 11 (Issue #3711)
You must run from an elevated command prompt. Run webmanagement.exe /help to get in-context help.
WebManagement.exe is located in a not identifiable folder and is a Windows core system file. The program is not visible.
You can also find the service listed in Task Manager, under the "Services" tab.
—
Reply to this email directly, view it on GitHub https://github.com/MicrosoftDocs/windows-uwp/issues/3711#issuecomment-1079232480 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ABIU6AE3BUQQYZNTTZ4CJF3VBXXZVANCNFSM5QNBIFDA .
You are receiving this because you authored the thread.  https://github.com/notifications/beacon/ABIU6AFW2YLFWVHJVX67E4LVBXXZVA5CNFSM5QNBIFDKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOIBJ4PYA.gif Message ID: @.*** @.***> >


Add missing license headers

License headers are missing from all code files. We also need a template for this.
BTW is this really necessary? We already put the license and notice files in the repo root which implies that they apply to all the files. Is this a strict legal requirement? Can we add an action to check the header?

There are github actions already out there responsible for checking the header, and @bingenito did ran similar tool to add headers for crossroads earlier.

I added manually


parse field tag and interface method name

fix https://github.com/mandiant/GoReSym/issues/37
the sample binary source code is
package main

import "fmt"

type interface1 interface {
	Interface1Method()
	interface1Method1(string, int) (string, error)
}

type ExampleStruct struct {
	StructField string `json:"StructFieldTag"`
}

type ExampleStruct1 struct {
	Data struct {
		StructField1 string `json:"StructFieldTag1"`
	} `json:"DataTag"`
}

func (e *ExampleStruct1) Interface1Method() {
	fmt.Println("Interface1Method")
}

func (e *ExampleStruct1) interface1Method1(string, int) (string, error) {
	fmt.Println("interface1Method1")
	return "", nil
}

func main() {
	fmt.Println(ExampleStruct{}, ExampleStruct1{})
	var i interface1
	i = &ExampleStruct1{}
	i.Interface1Method()
}

diff of this branch vs master

Note
-Reconstructed field is not valid golang code in many cases, so i add some hack to make it to valid format in common cases.

It's fine to remove the type prefix

You can re-open this, I am not convinced there is entirely correct. I see an unreference flag local in the 1.20 code path. And I see you are parsing out the 'flag' and comparing it to 3, but the rtype flags are already passed to the 'readRtypeName' function as an argument. And I also see adjustments to the name_len fields as mentioned in review, I don't believe this is correct


Potential clash with two jobs with the same project name

A user reports:
It appears that the Jenkins plugin simply checks the latest analysis.  If there are 2 builds writing to the same hub project, this can cause problems.
For instance, if one of the builds fails or stalls the scan after the 2nd build has succeeded, the 2nd build will fail because the plugin is checking the other builds analysis results.
There should be a tighter linkage between the analysis run for the build and the plugin checking for Jenkins.
Either, this should be discussed in the documentation for the plugin. When starting the analysis, you don't get a token back that would be the obvious solution for this.

Based on feedback, this is solved by adding a note in the documentation to add either a suffix or a prefix to the project name, when there are two or more Jenkins jobs using the same project in COdeSonar.


Fix logic in self.cleanup

https://github.com/AgnostiqHQ/covalent-slurm-plugin/blob/bcf2049b61da4e9ddc1d507ef9b56562569d9d84/covalent_slurm_plugin/slurm.py#L166
In the above line, if cleanup = False is set by the user, the code will ignore it and still pull from the config and set cleanup = True. I fixed the logic.

Closed because I've packed this into #57 to prevent a merge conflict.


feat(forge doc): include @custom natspec

Motivation

Closes #8488
Include @custom natspec tags when rendering docs with forge doc.
Solution

I've chosen to prefix custom tags with // Comment: for visibility reasons, but I'm open to suggestions.
Example with https://github.com/artgobblers/art-gobblers where I introduced some custom tags.
$ git diff src/ArtGobblers.sol
diff --git a/src/ArtGobblers.sol b/src/ArtGobblers.sol
index d322858..71cb8e9 100644
--- a/src/ArtGobblers.sol
+++ b/src/ArtGobblers.sol
@@ -80,6 +80,9 @@ import {Pages} from "./Pages.sol";
 /// @author FrankieIsLost<EMAIL_ADDRESS> /// @author transmissions11<EMAIL_ADDRESS> /// @notice An experimental decentralized art factory by Justin Roiland and Paradigm.
+/// @custom:test-a A first custom tag
+/// @custom:test-b A second custom tag
+/// @custom:test-c A third custom tag
 contract ArtGobblers is GobblersERC721, LogisticVRGDA, Owned, ERC1155TokenReceiver {
     using LibString for uint256;
     using FixedPointMathLib for uint256;
@@ -89,6 +92,7 @@ contract ArtGobblers is GobblersERC721, LogisticVRGDA, Owned, ERC1155TokenReceiv
     //////////////////////////////////////////////////////////////*/

     /// @notice The address of the Goo ERC20 token contract.
+    /// @custom:test-b Another custom tag.
     Goo public immutable goo;

     /// @notice The address of the Pages ERC721 token contract.
@@ -344,6 +348,7 @@ contract ArtGobblers is GobblersERC721, LogisticVRGDA, Owned, ERC1155TokenReceiv
     /// limit is enforced during the creation of the merkle proof, which will be shared publicly.
     /// @param proof Merkle proof to verify the sender is mintlisted.
     /// @return gobblerId The id of the gobbler that was claimed.
+    /// @custom:test-c Yet another simple custom tag.
     function claimGobbler(bytes32[] calldata proof) external returns (uint256 gobblerId) {
         // If minting has not yet begun, revert.
         if (mintStart > block.timestamp) revert MintStartPending();

that's great, thanks! not a strong opinion but I think would be nicer to have bullet point for them (as  Custom key is not relevant for docs) like
Inherits: ....
Authors: ....
An experimental ....
- A first custom tag
- A second custom tag

wdyt?

Thanks!
Supportive of changing the format, my suggestion would be to additionally add a header:
Notes:
- A first custom tag
- A second custom tag
as in a list with a header stating Notes in bold

I also prefer this approach.

okay i just now looked at the output for this one, looks good, but it is missing the label after @custom: making the notes section confusing instead of informative
ex.
this
@custom:some-info Hello
outputs this
Notes:

Hello

instead of
Notes:

some-info : Hello

okay i just now looked at the output for this one, looks good, but it is missing the label after @custom: making the notes section confusing instead of informative
ex.
this
@custom:some-info Hello
outputs this
Notes:

Hello

instead of
Notes:

some-info : Hello

It should be fixed! :)


Add notification for Permission requests

Add notification for Permission requests, such as: fullscreen, geolocation, etc.

Close due to https://github.com/qazbnm456/lulumi-browser/commit/026885a16076180d1b5d5cc5f760214a6d3c1a54.


[Backup] az backup policy create/set: Add support for creating/updating IaaSVM MBPD policy

Description
az backup policy create/set: Added support for creating/updating IaaSVM MBPD policy
Testing Guide

History Notes

[Component Name 1] BREAKING CHANGE: az command a: Make some customer-facing breaking change
[Component Name 2] az command b: Add some customer-facing feature

This checklist is used to make sure that common guidelines for a pull request are followed.

[ ] The PR title and description has followed the guideline in Submitting Pull Requests.

[ ] I adhere to the Command Guidelines.

[ ] I adhere to the Error Handling Guidelines.

Backup

Could you add some tests for the new change?

Could you add some tests for the new change?

It is not a new feature. We added it some while back in this PR https://github.com/Azure/azure-cli/pull/21643 with relevant tests. We are just removing a client-side check in this PR. It will now be handled on the service side.

Yes, I personally think we need to test this new scenario that the server can support schedule_run_frequency == ScheduleRunType.hourly


Attempting fix for #316:

Changing check for any foundResource with condition (mutliple finds had caused this to always return true)

There is an issue in Find-JsonContent that needs to be cleaned up before we can merge this...

Let's add a test case (or two or three) - also we should re-enable the test from #316 to ensure this fix also fixed that test.


how to make request by bot api call sendMediaGroup to send album use python

i have a album to send by bot perfer use bot api call https://api.telegram.org/bot{token}/sendMediaGroup?chat_id={chat_id}, according to issue315  i have write code like this:
`import requests
token = '54321'
url = f'https://api.telegram.org/bot{token}/'
chat_id = 123456
data = {
"media": "[{"type":"photo","media":"https://media.cnn.com/api/v1/images/stellar/prod/230719152236-04-how-to-stop-the-next-cuban-missile-crisis.jpg?c=16x9&q=h_720,w_1280,c_fill/f_webp\"},"
" {"type":"photo","media":"https://media.cnn.com/api/v1/images/stellar/prod/230719152208-03-how-to-stop-the-next-cuban-missile-crisis.jpg?c=16x9&q=h_720,w_1280,c_fill/f_webp\"}]"
}
r = requests.post(url + f'sendMediaGroup?chat_id={chat_id}', data=data)
print(r.text)`
it is works.
but i want send photos load from local disk, i change my code to this:
`import requests
token = '54321'
url = f'https://api.telegram.org/bot{token}/'
chat_id = 123456
data = {
"media": [{"type": "photo", "media": open('test1.jpg', mode='rb')},
{"type": "photo", "media": open('test2.jpg', mode='rb')}]
}
r = requests.post(url + f'sendMediaGroup?chat_id={chat_id}', data=data)
print(r.text)`
i get error response is {"ok":false,"error_code":400,"description":"Bad Request: can't parse media JSON object"}.
according to bot api say: 'A JSON-serialized array describing messages to be sent, must include 2-10 items', i change my code data to
data = json.dumps({     "media": [{"type": "photo", "media": open('20230720_4925588140461486_2.jpg', mode='rb')},               {"type": "photo", "media": open('20230720_4925588140461486_1.jpg', mode='rb')}] })
but get error: TypeError: Object of type BufferedReader is not JSON serializable.
how can i send photos load from local disk. i have no idea.

See https://core.telegram.org/bots/samples#python.

not found any example by make request to https://api.telegram.org/bot{token}/sendMediaGroup to send album,the file should be load from disk.
most example is instance bot,then use bot.sendMediaGroup(),But I don't think this will work because the bot is already running on other projects.

You can check source code of the libraries if you can't use one of them.

sorry, I try read source code, and get the get_input_message_contents method get media_content.
I won't cpp, I can't read the code
can you give me a example, how to make request to https://api.telegram.org/bot{token}/sendMediaGroup to send album, the file should be load from disk.
real thanks

I can't you give an example of the code in Python, but all libraries from https://core.telegram.org/bots/samples#python should have it.


Create client library checklist

Checklist with entries like the following:

Support all handshake message types
Support correlating send-error to sent messages
Support re-sending of messages after a send-error occurred
Nonce is always validated
Separate CSN for each connection
Handover requires ice connection state to be CONNECTED
...

Then we can "rate" client libraries using that checklist and create a support matrix. It's also useful for people that want to write new libraries.

This checklist is probably pretty old by now - we should update it.
Do you think this should make it into the spec or is it just an internal checklist for us?

Hm, I don't think it should be in the spec. It could be a separate document as a post-implementation checklist. But I think the spec now already contains a lot of implementation notes.

I agree, the spec is pretty precise. Agree to close?

Yes.


🐛 [VisionCamera] react-native-worklets-core not found, Frame Processors disabled!

What's happening?
After running pod install Vision camera cannot find react-native-worklets-core. I had installed<EMAIL_ADDRESS>and added ['react-native-worklets-core/plugin'], into babel.config.js
Reproduceable Code
-

Relevant log output
[VisionCamera] node modules found at /Users/aleksandrbogdanov/Desktop/git/alcs/4.Implementation/alcs/java/alcs-react/react-app/node_modules/.pnpm/react-native@0.73.4_@babel+core@7.23.9_@babel+preset-env<EMAIL_ADDRESS>[VisionCamera] react-native-worklets-core not found, Frame Processors disabled!
Auto-linking React Native modules for target `driverapp`: RNBootSplash, RNFileViewer, RNGestureHandler, RNPermissions, RNReanimated, RNSVG, RNScreens, ReactNativeAvoidSoftinput, VisionCamera, VisionCameraOcr, VisionCameraV3BarcodeScanner, react-native-blob-util, react-native-document-picker, react-native-encrypted-storage, react-native-flipper, react-native-geolocation, react-native-im
Framework build type is static library
[Codegen] Generating ./build/generated/ios/React-Codegen.podspec.json
[Codegen] generating an empty RCTThirdPartyFabricComponentsProvider
Analyzing dependencies
[Codegen] Found FBReactNativeSpec
[Codegen] Found rncore
[VisionCamera] node modules found at /Users/aleksandrbogdanov/Desktop/git/alcs/4.Implementation/alcs/java/alcs-react/react-app/node_modules/.pnpm/react-native@0.73.4_@babel+core@7.23.9_@babel+preset-env<EMAIL_ADDRESS>[VisionCamera] react-native-worklets-core not found, Frame Processors disabled!
Downloading dependencies
Generating Pods project
Setting USE_HERMES build settings
Setting REACT_NATIVE build settings
Setting CLANG_CXX_LANGUAGE_STANDARD to c++20 on /Users/aleksandrbogdanov/Desktop/git/alcs/4.Implementation/alcs/java/alcs-react/react-app/apps/driver/ios/driverapp.xcodeproj
Pod install took 30 [s] to run
Integrating client project
Pod installation complete! There are 101 dependencies from the Podfile and 108 total pods installed.```

### Camera Device

```json
-

Device

VisionCamera Version
3.9.0
Can you reproduce this issue in the VisionCamera Example app?
No, I cannot reproduce the issue in the Example app
Additional information

[ ] I am using Expo
[X] I have enabled Frame Processors (react-native-worklets-core)
[X] I have read the Troubleshooting Guide
[X] I agree to follow this project's Code of Conduct
[X] I searched for similar issues in this repository and found none.

You created a bug report, not a build error. This is the wrong template, I'm closing this issue - please create a new one with the correct template.
The first line in your logs is:[VisionCamera] node modules found at /Users/aleksandrbogdanov/Desktop/git/alcs/4.Implementation/alcs/java/alcs-react/react-app/node_modules/.pnpm/react-native@0.73.4_@babel+core@7.23.9_@babel+preset-env<EMAIL_ADDRESS>
apparently something went (terribly) wrong when trying to find your node_modules path, where is your project located?


Add Faq section

Add FAQ section and some initial question/answer

Feel free to re-open it on Software Factory.


refactor: adjust only plugins logic to reuse utils helper

This PR includes small changes to types of the CLI onlyPlugins internal functionality.
It replaces parts of the existing logic with helpers form utils and adds tests.
Changes included:

introduce types for the plugin middleware
use helper
add tests

Why was this merged with requested changes? There are still issues with this PR.

A newly added test for "filling undefined categories with empty array" has nothing to do with the middleware functionality. It is an unwanted side-effect of incorrectly handled optional categories. So creating a test for it is not desired.
The test descriptions are still vague. "should filter categories for slug "p1"' says nothing to someone who didn't previously implement this option. Filter how? What should happen to categories that have both plugins that are mentioned in onlyPlugins and plugins that are not? This should be the place for someone to learn about the functionality and its use cases.
Some test descriptions look like they have not even been proof-read ("should filter plugins plugins for slug "p1"")
I requested adding coverage to cover the following cases: Some plugins are filtered out, all (to check it returns empty array) and none (to check it returns identical array). Currently, only one out of three cases is covered for both plugins and categories.

A newly added test for "filling undefined categories with empty array" has nothing to do with the middleware functionality. It is an unwanted side-effect of incorrectly handled optional categories. So creating a test for it is not desired.

I created this for discussion.'''

The test descriptions are still vague. "should filter categories for slug "p1"' says nothing to someone who didn't previously implement this option. Filter how? What should happen to categories that have both plugins that are mentioned in onlyPlugins and plugins that are not? This should be the place for someone to learn about the functionality and its use cases.

Getting better in testing is an incremental process, at least when it comes to non trackable things.
If you could write some suggestions that will speed up the situation currently and allows a faster & motivating learning.

I requested adding coverage to cover the following cases: Some plugins are filtered out, all (to check it returns empty array) and none (to check it returns identical array). Currently, only one out of three cases is covered for both plugins and categories.

Please list me the 3 describe blocks and i will add them to this issue here https://github.com/code-pushup/cli/issues/568


How to spawn a Actor with spawn(start=<CoroutineFunction>)

On pulsar 1.x, it works with:

async def some_fn(*args, *kwargs):
       foo

monitor.spawn(start=some_fn)

And on 2.0:
It will warning coroutine was never waited.

yes, events cannot be coroutines, the event dispatching mechanism was very slow and it has been changed so that no waiting for asynchronous events is supported.
In your case, you need to warp the coroutine in a task with the ensure_future function.
async def some_fn(*args, *kwargs):
       foo

monitor.spawn(start=lambda: ensure_future(some_fn()))

Do you have a use case for this?

Thanks, ensure_future is exactly what I need, I'm just switching to pulsar 2.0.  🥂

closing


Added support for JSON comments

Fixes #43. /cc @tannernelson
Funny thing, the easiest way to do it was to treat comments as a new type of token that we're trying to parse. This means I actually pull all those comments out before throwing them away. Means that if we found a nice API to emit found comments, that would be very easy to do. (But I don't think that's really useful, just a fun fact)

Nice :)


Annoucement: php-webdriver repository organization name change

Despite the name, facebook/php-webdriver is no longer developed by Facebook. All current active maintainers are volunteers not associated with Facebook.
However because of historic reasons the repository is still under facebook organization on Github. This cause several limitations, for example:

There is no easy way for us to add members to the organization and add contributor rights to more people
We cannot customize the contributor process, for example set multiple issue templates, enable GitHub Actions (they are disabled organization-wide), also signing of the CLA is required, which creates more barriers for newcomers
Main branch is community (because master branch is reserved for archived version of the repository from times it was actively used by FB itself), which is quite confusing
The namespace/organization itself is misleading, as is creates false impression that the project is associated and maintained by FB developers
etc.

Facebook (via @gfosco) agreed to transfer the repository out of facebook organization. This will also allow us to build more sustainable team of maintainers and better manage our community efforts.
👉 The new repository name will probably be php-webdriver/php-webdriver 👈.
We also discussed with  @christian-bromann possibility of sharing organization webdriver and call it webdriver/php-webdriver, however this in my opinion does not have many advantages, maybe a bit shorter name :-). Standalone organization will however provide more freedom for our needs.
The renaming should not have impact on URLs, git etc. - GitHub provides redirections after repository is renamed, so everything should still work.
Also following the change, we will also rename the packagist repository from facebook/webdriver probably to php-webdriver/webdriver. However this is not simple process (packagist packages cannot be simply renamed, they must be submitted under new name and the old one need to be marked as abandoned). So I'm thinking about postponing this change to 2.x - but we will see, it may happen sooner.
:speech_balloon: Any ideas, questions, recommendations? I'd like to hear opinions from other contributors and the community as well!

rename the packagist repository from facebook/webdriver probably to php-webdriver/webdriver

Would it maybe make sense to name the package webdriver/webdriver?

@christian-bromann I just want to say that if you do so you will limit future languages in the namespace

I just want to say that if you do so you will limit future languages in the namespace

What do you mean?

webdriver/php-webdriver seems more future proof and search friendly

I agree! Happy to give any kind of access to it.

What do you mean?

I agree that I was unclear, webdriver/php-webdriver vs webdriver/webdriver was my point

Yeah, I didn't know that packagist is using GitHub namespaces. So webdriver/php-webdriver or webdriver/php would make sense to me.

webdriver/php IMO looks more official and sexy

I don't think it really matters too much whether it's php-webdriver/php-webdriver, or webdriver/php-webdriver, or webdriver/php. It really is just a name, and as long as there are a variety of people from different organisations who can keep the project moving, on-track, and ensure it's longevity, I don't think that it matters particularly.
Personally my vote would be for php-webdriver/php-webdriver.
There are some benefits to having it under the webdriver organisation, as long as it is possible to have the required level of control over the repository:

it ensures that even if all of the repository Owners go AWOL, there is still the webdriver organisation who can resurrect (though this is hopefully not going to happen and is a last resort);
improved discoverability - only marginally, and this doesn't have any real weight to me
shorter name - again this is just semantics and doesn't offer any real benefit IMHO

Equally, there are benefits to a new Organisation for the project:

Greater level of control
Ability to host related projects -- for example a Mink driver making use of it could be placed at php-webdriver/mink-driver.

In terms of time I don't think it matters whether we move at 1.8.0 or 2.0.0. Whilst it technically is an incompatible API change (and assuming the versioning follows semver) which would normally require a major version bump, the version bump is moot because it would still affect old versions anyway. In fact, I'd say it's better to go for a bump at 1.8.0 because it allows for any patch releases to be made while we're working on dev for 2.0.0.
So my 2c:

1.8.0 is probably a better time to make the move;
php-webdriver/php-webdriver has benefits when it comes to the ability to 'host' related projects; and
Having more official contributors who can triage, merge approved changes, etc. would be extremely beneficial so either naming is a major benefit anyway.

2. php-webdriver/php-webdriver has benefits when it comes to the ability to 'host' related projects; and

Makes totally sense given that the raw bindings for WebDriver in JS land is also in the WebdriverIO project.

GitHub repostiory organization/name is not related to Packagist namespace/name. Even now it is github facebook/php-webdriver and on packagist facebook/webdriver. On each of these places are being used different conventions and we can/should solve them separately & maybe differently.
Having different package name on GitHub and on Packagist is relatively common - they don't need and often are not the same - for example common rule is not to include "php" in package name on Packagist, if the reason why it is used on GitHub is to differentiate if from clients for other languages, as GitHub hosts project in different languages. You don't need to do this on Packagist, because, well, Packagist contains only PHP packages :-).
On the other hand, organization on GitHub is usually the same as namespace on Packagist.
So I agree with @andrewnicols about naming github repository php-webdriver/php-webdriver.
And for reasons above I preffer php-webdriver/webdriver as Packagist name ( = same organization as namespace, but package name does not contain redundant "php").
Both of these names also provide benefits mentioned by @andrewnicols (possibility to host related PHP projects in the future under php-webdriver org/namespace).
What do others think?

@OndraM What do you think about the timing?

@OndraM What do you think about the timing?

About moving the repo itself I think we should do it as soon as we have an agreement :).
About creating new Packagist package and abandoning the previous one: we can do it soon after package is moved and 1.8.0 sounds reasonable if we can manage it in time - the thing is I need to coordinate this with Facebook, as they are maintainers of the current Packagist package and only they can mark it as abandoned.

The repository was transferred to https://github.com/php-webdriver/php-webdriver .
I've just created #733 but few other changes must follow - please allow me few days to sort everything it out.


Bower.json Main Isn't Set for Distribution by Wiredep in Version 0.2.6

Pulling in ngOnload and then having bower postinstall hook run a gulp-wiredep task doesn't inject ngOnload.  Looks like you've got main set to "lib/ng-onload.js" and it should be "release/ng-onload.min.js", seems like it is correct in your repo in master and version 0.2.2, but not for version 0.2.6, which is being pulled down by bower since it is the latest.  Currently I'm using mikaturunen/ng-onload#master to get the correct bower main value if anyone else needs a quick work around.

Yup, I managed to majorly f up the latest release which I'm pushing a fix for. :) Sorry for the trouble folks.

There, fixes should be in place in 0.3.0 now 👍

Updated the bower json to point to 0.3.0, published new tag to point to the same point and fixed the reference to the distributed file. Thanks for letting me know!

If there's more to this issue, reopen it and we'll rock it from there :) Thanks!