Feature Request: Automatic git add

lefthook is great library, thanks!
I would like to use like

run a linter and a formatter at pre-commit.
(like--auto-correct by RuboCop, --fix by ESLint)
include the result of changing by auto-fix to staged code.
then, commit.

first, I tried like
pre-commit:
  commands:
    backend-linter:
      glob: "*.rb"
      run: bundle exec rubocop --auto-correct --force-exclusion {staged_files}  && git add {staged_files}

but it does not work like I expected.
should be alright if the staged range is whole file,
but in the case of staged as hunk(like git add -p ...), re-add whole file.
Does any one know a solution?

I used use lint-staged and husky like that.
{
  "lint-staged": {
    "*.rb": [
      "bundle exec rubocop --auto-correct --force-exclusion",
      "git add"
     ]
  }
}

in this case include the result of changing by auto-correct to a commit.

I fixed typo force-exclution = > force-exclusion

Thank you @AquiTCD for question. Have you tried this one?
  run: bundle exec rubocop --auto-correct --force-exclution {staged_files}  && git add

Thank you for the answer.
I tried it, but it said
/Users/aqui/.ghq/github.com/AquiTCD/ruby-sandbox/vendor/bundle/ruby/2.6.0/gems/lefthook-0.6.3/libexec/lefthook-mac run pre-commit
Lefthook v0.6.3
RUNNING HOOKS GROUP: pre-commit

  EXECUTE > backend-linter
Inspecting 1 file
W

Offenses:

src/test.rb:8:11: W: [Corrected] Style/StringLiterals: Prefer double-quoted strings unless you need single quotes to avoid extra backslashes for escaping. (https://github.com/fortissimo1997/ruby-style-guide/blob/japanese/README.ja.md#consistent-string-literals)
    two = 'bbb'
          ^^^^^

1 file inspected, 1 offense detected, 1 offense corrected
Nothing specified, nothing added.
Maybe you wanted to say 'git add .'?

SUMMARY: (done in 1.51 seconds)
✔  backend-linter
/Users/aqui/.ghq/github.com/AquiTCD/ruby-sandbox/vendor/bundle/ruby/2.6.0/gems/lefthook-0.6.3/libexec/lefthook-mac install
SYNCING lefthook.yml
SERVED HOOKS: pre-commit, prepare-commit-msg
/Users/aqui/.ghq/github.com/AquiTCD/ruby-sandbox/vendor/bundle/ruby/2.6.0/gems/lefthook-0.6.3/libexec/lefthook-mac run prepare-commit-msg .git/COMMIT_EDITMSG message
[master 51662ee] test
 1 file changed, 7 insertions(+), 1 deletion(-)

just information, lint-staged struggled this kind of issue before.
https://github.com/okonet/lint-staged/issues/62
IMO
I think the concept of lefthook is not exactly same as lint-saged,
that's why perhaps lefthook should not concern about fixed code by pre-commit.

Thank. The concept of a lefthook is different, and we don’t want to be lint-staged on golang.
But I'll try to figure it out.

For me this is the one feature preventing me from migrating from husky+lint-staged to lefthook. I would love to see official/formal support for git add added as part of the configuration. Maybe something like this:
pre-commit:
  commands:
    eslint:
      add: true
      glob: "*.js"
      run: eslint --fix {staged_files}

Where add:true would add any files modified as part of the command into the commit itself.

Wanted to chime in with this too, I was really surprised when the job formatted the files but didn't add them to the commit, which was something I expected from a tool like this. Right now this makes it fairly useless when you only want to run something that formats/fixes small errors. I hope you'll consider something like this as it'll make this tool perfect. Thanks for lefthook regardless :smile:

Oke, let's give it a try. It would be great if someone will take it. Here's how the task can be achived:

Add new config key to the list
https://github.com/Arkweid/lefthook/blob/master/cmd/run.go#L42
Grab it from config file like this:
https://github.com/Arkweid/lefthook/blob/master/cmd/run.go#L469-L472
Add new behavior at the end of executing command:
https://github.com/Arkweid/lefthook/blob/master/cmd/run.go#L248-L249
Just something simple like that: ExecGitCommand("git add files")
https://github.com/Arkweid/lefthook/blob/master/context/context.go#L24-L25
Double new code for _windows prefix files.

I can try to suggest a quick solution, for your issue:

as a first command you can stash unstaged changes for all files, which have in "staged_files" (via git stash push -k -- [...] syntax), or for the whole project (via git stash -k -u)
after the execution you can do one of two things:
2.1) automatically pop your code from stash (on post-commit, not forget to check if any stashed was created, for example by adding a commit hash to the stash name). But you can get a lot of fails and problems.
2.2) keep the stash, and print a message to user, that you stashed something and it is not resolved now. Not forget to create a command text for the user (useful for users who wants to copy-paste).

AFAIK stashing is used by many git-hooks tools, see for instance lint-staged and pre-commit.
For a step-by-step description se the autokooks instructions for linting plugins and formatting plugins.
Other useful documentaiton:
https://danilodellaquila.com/en/blog/use-git-stash-in-your-pre-commit-hook
https://www.darrenlester.com/blog/git-pre-commit-stash
https://medium.com/@MadsSejersen/git-precommit-hooks-done-right-886cfdf4ffb0
Stashing involves the risk of manual intervention in case the hook fails badly, see for instance the following two pre-commit issues, that have been fixed:
https://github.com/pre-commit/pre-commit/issues/176
https://github.com/pre-commit/pre-commit/issues/397
Maybe precise-commits does something more / different, but I do not have precise information...

To make it clear, I wrote the information above just trying to help on this. As for myself, I run hooks only to check staged files, as I prefer to fix them manually in case the checks do not pass. So personally I would not even be against the decision to disallow automatic fixing, if it could be dangerous.

Is there any updates so far?

Maybe there should be info about this behaviour in this guide https://github.com/evilmartians/lefthook/wiki/Migration-from-husky-with-lint-staged ?
Because I think husky+lint-staged users expect that changed files will be re-added automatically.

If that can help someone, here's how to add a new commit on pre-push with applied rubocop corrections:
pre-push:
  parallel: true
  commands:
    rubocop:
      glob: "*.rb"
      run: bundle exec rubocop --force-exclusion --auto-correct -- {all_files} && git add . && git commit -m "rubocop corrections"

I just did the reverse because of this and one other thing I found missing on lefthook.

The move to husky V8 from lefthook was quite tricky since they put everything in the .husky/ folder as a script (which means I have to ensure proper line endings on Windows) rather than relying on having things configured in package.json.
Since I am on monorepo with different types of components and styles having a lint-staged on a per project basis was something I was looking for.  lefthook.yml seems to only go on the root and does not have a per package version.  The translation to left hook wasn't too bad, but as noted you can only have staged files (which is what I was looking for).

Let's start with stating:

I much prefer Lefthook over any other alternative currently available.

Like many others I switched from Husky + Lint-staged, in my case the reasons were:

primarily because developers had performance issues (3+ minutes waiting in some cases)
reduce dependencies
great dx using lefthook.yml

Even though Lefthook might not have intended to solve the "automatic git add" use case described in this issue,
it seems to be the main reason people are forced away from using it.

Currently my only viable options are:

Accept current limitation > you'd have to commit twice if the pre-commit hook changes files
Return an exit code, forcing user to fix the files themselves >
eg: npx stylelint {staged_files} || (npx stylelint --fix {staged_files} && exit 1)
Revert back to husky+lint-staged
Find another alternative (lot of subpar ones out there that eg need ruby or python to be installed or are very slow)

All of these options result in a suboptimal developer experience.

I think what the majority of people using Lefthook to do pre-commit checks want is:

Fix what can be fixed automatically without disrupting a developers workflow

Proper solution
As @mrexox mentioned here on PR #109 just using git add {staged_files} is dangerous since committing partially staged files would add the whole file.
The fix would have to be similar to how lint-staged fixed this issue in https://github.com/okonet/lint-staged/pull/75.
IMHO the acceptance criteria would be:

add a addChangedDuringCommand property (being over specific here on purpose, could be eg. addChanges)
this property is only applicable to the pre-commit hook
the logic would have to deal with partially staged files

Hey @pvds! With 1.3.0 version I've added handling for partially staged files. Now for pre-commit hook unstaged changes are being hidden, and commands run on staged changes only. Then after the hook processing the unstaged changes are applied again.
This is not super stable although I haven't noticed any issues related to that. My next step is to decide:

Enable auto git add by default as many people might want
Add a configuration option like auto_add (or any other meaningful name) for this

I'm still thinking but I guess that I'm going to implement this feature in 1-2 months (maybe earlier, if there is a request for it).
I'll be glad to know what you think about these options. To sum up, my questions:

Should it be an option auto_add or a default behavior (for pre-commit hook only, of course)?
If it is an option, should it be true or false by default? false will be more backward-compliant.
What naming do you like?

Namings:

auto_add: true
stage_changed: true
restage: true

I think the last is the most intriguing question :)

@mrexox let's start with the most intriguing question!
I'm also struggling but I do know I would like the name to be a bit more descriptive.
From your suggestions I think stage_changed is describing best what happens.
There is possibility someone might be confused and think "but I don't want to stage all my changes" .
My mind started wondering towards including the word hook, for example:

add_hook_changes
include_hook_changes
stage_hook_changes

Then again this would make sense in case it's a property of the pre-commit hook, but may be less intuitive as a property of commands within the pre-commit hook. I guess you intended to implement it as the latter?
The changes are made by the run command so stage_run_changes could also be an option.

For now my answers to your questions would be:

It should be an option; leaving room for cases like using an exit code
The default value should be true, people (including myself) expect this to be default behaviour.
Strictly making it a breaking change
Best names for the option as a property of commands within the pre-commit hook: stage_changed  or
stage_run_changes

NB. Setting the default value to true would require the feature to be super stable.
Could you explain why handling partially staged file is "not super stable"?
Would love to hear your considerations!

Enable auto git add by default as many people might want

I don't recommend changing the default otherwise you may get into the same situation as https://github.com/svg/svgo/issues/1128 and lock this conversation because it may become heated.

Thank you for participating in this discussion. I guess maybe stage_fixed might also be a good name because most linters have a --fix or --autocorrect option and fixed makes more sense than changed. @pvds, what do you think?
An example:
pre-commit:
  commands:
    lint:
      run: npm run lint --fix
      stage_fixed: true

I'd like to leave a room for a default behavior but @trajano you are right, it makes sense to leave defaults untouched and then reach out to lefthook users about whether they want to change the default behavior. Also a major version bumping will make sense in this case.

I don't recommend changing the default otherwise you may get into the same situation as svg/svgo#1128 and lock this conversation because it may become heated.

I agree that we should be careful when changing defaults and take into account the potential impact on the community. However, I also believe it's important to hear different perspectives and ensure that everyone's opinions are valued. While the situation you've referenced is worth considering, it's important to remember that each situation is unique and should be evaluated on its own merits.

@mrexox @trajano I agree that we should not make this default behaviour without providing a configuration option to change it. Without more community feedback I agree the default value of this option should not be true.
Considering the name @mrexox I think your stage_fixed suggestion is great!
I dismissed it myself while brainstorming because I was thinking that changes made during the pre-commit hook might not always be due to an option called fixed but using stage_fixed actually describes the intent very well!

Just release 1.3.5 version with this feature included. Please, test it and feel free to open a new issue if you face any problem :pray:
New option docs: stage_fixed


ARIA roles in docs and examples

Questionning documentation markup with accessibility in mind, I came across Scott O'Hara's recent post about implicit landmarks which basically says:

main role is not necessary anymore since both NVDA and Jaws fill the gap in IE11;
contentinfo role is useful (albeit not necessary) for macOS VoiceOver with WebKit / Chromium based browsers.

I also added the search role to the search form since it's very useful as a landmark, and obviously updated the vnu-jar.js ignored warning to match what's been done on markup.
There isn't any edge cases as far as I'm aware of, but it's still useful to share the last WebAim Screen-reader users survey (anchored to the browser combos section).
I guess @patrickhlauke should review this?

IE is still supported https://getbootstrap.com/docs/4.4/getting-started/browsers-devices/ so role="main" should probably stay.
identifying the main part of a page is more important for users than identifying the footer - historically, the biggest concern has always been for users to be able to easily find the main section. not so much about users needing to easily find the/a footer. so for role="contentinfo" i'd say it's not that important to patch it...but not a hill i'd die on. belt-and-braces doubling up is not really a problem in my view, and if we feel it does help some people...why not.,

IE is still supported https://getbootstrap.com/docs/4.4/getting-started/browsers-devices/ so role="main" should probably stay.

@patrickhlauke I'm aware of that; I'm refering to Scott O'Hara's recent post "Landmarks exposed" explainging that IE11 & Edge with both NVDA or JAWS now expose main landmark correctly — despite the fact that browsers didn't fix anything, ATs did.
Do you still want to get the explicit role back? It's a single commit to revert, please let me know :)

reliant on latest AT. anyway, you do what you think is best, i just feel that it's such a small inconsequential thing that doesn't do any harm to keep

I understand. You're right in that it doesn't do any harm — the only drawback is that it requires ot ignore a warning in HTML Validator (so I did).
Let's go with this, then.

@patrickhlauke the final call is yours :) I'm not 100% sure it makes sense to support such workarounds, unless we've tried bugging upstream to fix the issues there and there's no response.
Also, we need to make sure our current supported browsers are affected by this. If you read https://www.scottohara.me/blog/2019/04/05/landmarks-exposed.html it says:

Please note that there the following information may no longer be accurate if testing with newer versions of browsers and screen readers than the ones noted in this article. For instance, since Safari 13 was released, VoiceOver will now correctly expose a footer a content information landmark.

@XhmikosR @patrickhlauke  Up on this one: very low importance, however it's the last one coming from my fork (which I'd be proud to delete!).
It basically only adds contentinfo role on <footer>.

https://github.com/twbs/bootstrap/pull/30067#issuecomment-602512092

ok, although i'm really not too fussed about this, my current thinking - take it for what it is...
as we're now ripping other more fundamental stuff out (in various places) that will end up actually breaking IE11, we can probably also do away with role="main".
as for the role="contentinfo", @scottohara rightly pointed out that if our supported browsers includes "Safari >= 10" (per https://github.com/twbs/bootstrap/blob/master/.browserslistrc) then that fix should be there. or we can modify the browser list to go for >= 13 onwards.

I think only supporting Safari 13 would be quite too much, since it's pretty young (released in last september).
However until this PR isn't approved, it's open for discussion :)

I guess we can land it although it's not valid and we'll probably forget to remove it later, but, well.

Validation is about syntax; this won't cause any issue. The main role was implemented this way and ignored from the Validator too.
Do you want me to leave a @todo comment about this? The switch here is already known: as soon as we stop supporting Safari previous to 13, we'll be safe removing this.
I don't know if there's some kind of reminder for things?

not that it's not valid. defining the same role on an element is redundant, but not disallowed. it's the validator not differentiating between hard failures and "shouldn't need to do it"

Let's dump this one, it's a very small improvement for an even smaller part of our users and end users.
I don't think it worths it.


add entei

I changed the mudkip repeated by a entei

I am sorry but entei and mudkip are already there in the website. Please try and add some new unique pokemon.


Tests aren't insulated from the network.

Currently there are a large number of tests that test networking-related functionality without mocking it out. This means that tests will fail in surprising ways on different environments.
(One example: GCE detection doesn't mock out the network, so we see the behavior intended in the tests in "most" environments, but on GCE we will accidentally pick up the metadata service, and on AWS, we'll see a different codepath as we can fetch <IP_ADDRESS>, but it won't have the expected Google metadata header.)
This needs to be cleaned up throughout the tests.

:+1:

Thank you for creating this issue, however, this project is deprecatedand we will only be addressing critical security issues. You can read moreabout this deprecation here.
If you need support or help using this library, we recommend that you ask yourquestion on StackOverflow.
If you still think this issue is relevant and should be addressed, pleasecomment and let us know!


Switch to stable API's 'ErrorResponseUpdatedFormat'

The 2021-01-15 release of the CosmosDB Swagger API uses ErrorResponseUpdatedFormat instead of CloudError. To avoid causing a breaking change in the .NET SDK, we're going to use that instead.
MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Changelog
Please ensure to add changelog with this PR by answering the following questions.

What's the purpose of the update?

[ ] new service onboarding
[ ] new API version
[ ] update existing version for new feature
[ ] update existing version to fix swagger quality issue in s360
[ ] Other, please clarify

When you are targeting to deploy new service/feature to public regions? Please provide date, or month to public if date is not available yet.
When you expect to publish swagger? Please provide date, or month to public if date is not available yet.
If it's an update to existing version,  please select SDKs of specific language and CLIs that require refresh after swagger is published.

[ ] SDK of .NET (need service team to ensure code readiness)
[ ] SDK of Python
[ ] SDK of Java
[ ] SDK of Js
[ ] SDK of Go
[ ] PowerShell
[ ] CLI
[ ] Terraform
[ ] No, no need to refresh for updates in this PR

Contribution checklist:

[ ] I commit to follow the Breaking Change Policy of "no breaking changes"
[ ] I have reviewed the documentation for the workflow.
[ ] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

[ ] Ensure to check this box if one of the following scenarios meet updates in the PR, so that label “WaitForARMFeedback” will be added automatically to involve ARM API Review. Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs, all “removals” and “adding a new property” no more require ARM API review.

Adding new API(s)
Adding a new API version
Adding a new service

[ ] Please ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.

[ ] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If there are following updates in the PR, ensure to request an approval from Breaking Change Review Board as defined in the Breaking Change Policy.

[ ] Removing API(s) in stable version
[ ] Removing properties in stable version
[ ] Removing API version(s) in stable version
[ ] Updating API in stable or public preview version with Breaking Change Validation errors
[ ] Updating API(s) in public preview over 1 year (refer to Retirement of Previews)

Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Addition details on the process and office hours are on the Breaking change Wiki.
Please follow the link to find more details on PR review process.

Stable API's would be moved to CloudError in future. Next, can you please review the generated .Net SDK and propose all the swagger changes(if any) in this PR.

I realized we don't need this. Abandoning.

Hi, @frrossms. The PR has be closed for a long time and it's related branch still exist. Please tell me if you still need this branch or i will delete it in 14 days.


Sync asm secrets with db resolver references

Currently, nuking / recreating the db removes all references to asm secrets, which means all secrets need to be set again. Client team has had to do this a few times.
Since we're tagging all asm secrets with "ftl", we can fetch them and add their refs to the db. Perhaps at first load / if we have zero refs?

That's a great idea

Alternative: introduce something like
ftl secret --asm --sync <s1,s2,..>
This allows client teams to bring in specific secret refs from asm more intentionally.

The team does not think there is work to be done here if we incrementally update the db instead of performing wipes.


PLT-5775: plutus-ledger refactoring

So there's no reduction in dependencies at all. I got rid of the direct plutus-script-utils dependency from cardano-node-emulator, but it is still an indirect dependency through plutus-ledger. Maybe if we can get rid of DecoratedTxOut in the future we could remove the dependency completely.

Pre-submit checklist:

Branch

[x] Tests are provided (if possible)
[x] Commit sequence broadly makes sense
[x] Key commits have useful messages
[x] Formatting, PNG optimization, etc. are updated
[x] Important changes are reflected in changelog.d of the affected packages

PR

[x] Self-reviewed the diff
[x] Useful pull request description
[ ] Reference the ADR in the PR and reference the PR in the ADR (if revelant)
[x] Reviewer requested

All the improvements look good to me but we're far from the story goal (that seems impossible to achieve). I think we can merge this one and we'll decide later on what to do with plutus-ledger. @koslambrou does it sound ok for you?

Fine by me

@koslambrou Can you force merge?


Issue from website page Page not found

From URL: https://flutter.io/404.html

I don't get your issue. You only pasted the error url, not the url you wanted to open.
Also, this is the repository for the flutter sdk, not the website including the documentation.

Not enough information to be actionable.


Server failed to authenticate the request. on docker App service with Managed identity after 24 hours

Package Name: @azure/identity & @azure/storage-queue
Package Version: 2.0.4 & 12.9.0
Operating system:
[x] nodejs

version: 16

[x] typescript

version: 4.8.3

Is the bug related to documentation in

[ ] README.md
[ ] source code documentation
[ ] SDK API docs on https://docs.microsoft.com

Describe the bug
We are using @azure/identity & @azure/storage-queue packages within a typescript azure functions application to do custom querying on a queue that we cannot do via a regular binding. This functions app is deployed to an app service as a docker container and configured to use a managed identity which has the correct permissions on the storage account. Our typescript looks like this:
const queueServiceClient = new QueueServiceClient(process.env.AzureStorage__queueServiceUri ?? "", new DefaultAzureCredential());

const httpTrigger: AzureFunction = async function(context: Context, req: HttpRequest): Promise<void> {
    const queueClient = queueServiceClient.getQueueClient(req.params.name);

    if (await queueClient.exists() === false) {
        context.res = {
            status: 404
        };
        return;
    }

    const properties = await queueClient.getProperties();
    context.res = {
        // status: 200, /* Defaults to 200 */
        body: properties.approximateMessagesCount
    };

};

This code is running fine however after approximately 24 hours this code starts failing with the following exception
Exception while executing function: Functions.QueueLength Result: Failure
Exception: Server failed to authenticate the request. Please refer to the information in the www-authenticate header.
RequestId:fe44eaeb-d003-0025-8027-c6da7a000000
Time:2022-09-11T21:39:46.1437207Z
Stack: RestError: Server failed to authenticate the request. Please refer to the information in the www-authenticate header.
RequestId:fe44eaeb-d003-0025-8027-c6da7a000000
Time:2022-09-11T21:39:46.1437207Z
    at handleErrorResponse (/home/site/wwwroot/node_modules/@azure/core-http/src/policies/deserializationPolicy.ts:274:17)
    at /home/site/wwwroot/node_modules/@azure/core-http/src/policies/deserializationPolicy.ts:179:47
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async StorageRetryPolicy.attemptSendRequest (/home/site/wwwroot/node_modules/@azure/storage-queue/src/policies/StorageRetryPolicy.ts:168:18)
    at async StorageClientContext.sendOperationRequest (/home/site/wwwroot/node_modules/@azure/core-http/src/serviceClient.ts:520:23)
    at async QueueClient.getProperties (/home/site/wwwroot/node_modules/@azure/storage-queue/src/QueueClient.ts:821:14)
    at async QueueClient.exists (/home/site/wwwroot/node_modules/@azure/storage-queue/src/QueueClient.ts:780:7)

I'm not sure if this is an issue with app services or an issue with one of the SDKs or an issue with the way we're creating the QueueServiceClient statically outside of the function. I could not find any information in the docs which said what sort of lifetime you should expect from the QueueServiceClient class.

@ksstott ,
The code seems fine.  The issue could be caused by several different reasons. I'll try to run a sample for 24hours to see whether I can repro it. If the issue is reproduced in your side, could you share the exception info (as you have pasted above) for the most recent repro? I'll try to take a look in service side to find out why it returns 403 error.
Thanks
Emma

@ksstott ,
The code seems fine. The issue could be caused by several different reasons. I'll try to run a sample for 24hours to see whether I can repro it. If the issue is reproduced in your side, could you share the exception info (as you have pasted above) for the most recent repro? I'll try to take a look in service side to find out why it returns 403 error.
Thanks Emma

Hi Emma
Thanks for getting back so quickly. The exception pasted above was from yesterday afternoon within the hour before I posted this issue so it is the latest repro (it'll happen again later when it gets to 24 hours again). Is there any particular extra exception info that you need in addition to what I've pasted above?
Thanks
Kelvin

@ksstott ,
The exception was thrown at 2022-09-11T21:39:46.1437207Z, logs the request has been rolled out. Usually, service would keep logs for request for about 3 days.
Could you share a more recent repro?
Thanks
Emma

@EmmaZhu,
Ah, that's App insights bunching together all the similar errors together and me not noticing that I'd selected one that was a few days old. Apologies, here is one that is from yesterday when it last occurred.
Exception while executing function: Functions.QueueLength Result: Failure
Exception: Server failed to authenticate the request. Please refer to the information in the www-authenticate header.
RequestId:f9710919-9003-0065-27f3-cc4a26000000
Time:2022-09-20T13:18:23.2661168Z
Stack: RestError: Server failed to authenticate the request. Please refer to the information in the www-authenticate header.
RequestId:f9710919-9003-0065-27f3-cc4a26000000
Time:2022-09-20T13:18:23.2661168Z
    at handleErrorResponse (/home/site/wwwroot/node_modules/@azure/core-http/src/policies/deserializationPolicy.ts:274:17)
    at /home/site/wwwroot/node_modules/@azure/core-http/src/policies/deserializationPolicy.ts:179:47
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async StorageRetryPolicy.attemptSendRequest (/home/site/wwwroot/node_modules/@azure/storage-queue/src/policies/StorageRetryPolicy.ts:168:18)
    at async StorageClientContext.sendOperationRequest (/home/site/wwwroot/node_modules/@azure/core-http/src/serviceClient.ts:520:23)
    at async QueueClient.getProperties (/home/site/wwwroot/node_modules/@azure/storage-queue/src/QueueClient.ts:821:14)
    at async QueueClient.exists (/home/site/wwwroot/node_modules/@azure/storage-queue/src/QueueClient.ts:780:7)

The failure is because the token has been expired.
@jeremymeng , Could you help to take a look at this issue?
Seems BearerTokenAuthenticationPolicy failed to automatically refresh expired token.  From the code, I think it should be able to auto refresh token?
if (cycler.mustRefresh) return refresh(tokenOptions);

@ksstott for @azure/identity are you using the exact version 2.0.4 or with ~2.0.4 or ^2.0.4? There was an issue affecting app service managed identity credential in v2.0.5.  The fix is now available in the latest v3.0.0 version.  Could you please give it a try?

@ksstott for @azure/identity are you using the exact version 2.0.4 or with ~2.0.4 or ^2.0.4? There was an issue affecting app service managed identity credential in ~v2.0.5~ v2.1.0. The fix is now available in the latest v3.0.0 version. Could you please give it a try?

Yes digging out the lock file from the docker image we have deployed we are indeed using v2.1.0. We're going to trial version 3 over the weekend and see if the issue disappears. Will come back to you next week with our findings
Thanks

Hi
After switching to version 3 and letting it run for a while we've had no issues. Thank you for your responses


(#123) Fixed beam not being able to access global namespace + minor related bug.

The beam pipeline wasn't able to see the global namespace, despite that save_main_session=True was passed to the pipeline options. I'm not sure why save_main_session wasn't having its intended effect, but I worked around it by importing the global symbols that the pipeline wasn't able to see.
I also noticed that the save_main_session argument to run() wasn't actually doing anything, and that argument to the pipeline was always set to True, so I fixed that.

Fixed #123


allow train.py to resume non-lora models

Many models will have been created with the default nanogpt code, which doesn't include lora_rank or lora_alpha parameters.  This change just sets them to zero.  Otherwise train.py crashes with a KeyError (lora_rank not found).

Thanks a lot for the PR! I definitely agree with you that it should be backwards-compatible. I'll quickly review it.


adjusted level scaling

Adjusted level scaling to work with a static grid.
-Changed the way gen increments

Looking forward to getting to playtest this new scaling. Merging.


How to install in Alpine.

Exist any image in dockerhub for install octant? can i install in Alpine linux?

Octant is an application that runs on Windows, macOS, and Linux. We do not distribute via Dockerhub or provide a Docker image for Octant because the methods for running a desktop applicaton inside a docker container vary so much depending on the Docker host.
We recommend you download and execute the binary directly from our releases page on GitHub.
That said, to get Octant running with Docker, currently you'll need an image with a browser and Octant installed, but once we have moved fully to an Electron app you shouldn't need to worry about the browser.
Here are some blog posts that might help:

https://blog.jessfraz.com/post/docker-containers-on-the-desktop/
http://fabiorehm.com/blog/2014/09/11/running-gui-apps-with-docker/


Added '.scss' extension as an alternative to documentation in Sass.

I'm using version 1.3.1 but it still doesn't work. Hologram ignores SCSS files with the comment style @gponsu proposed.


[zh] sync extend-kubernetes/compute-storage-net/device-plugins.md

[zh] sync extend-kubernetes/compute-storage-net/device-plugins.md

Thanks.
/lgtm


Elevation Shadow in Dark Mode

Description of the Bug
While testing other things I noticed some issues that I am going to raise for information. All of them from the latest master code base and kitchen sink
The first is best expressed as follows

It seems to me that when in Dark Mode - the Elevation shadow should be a light color to contrast with the Dark background. The current dark shadow on a dark background does not do anything.

Versions

OS: Macos
Python: 3.9
Kivy: 2.0.0
KivyMD:  Latest Master

The material IO only specify that the shadows remain drawn in both modes, except when the element is disabled. It should remain the same color and hue they already are.
Even so, the elevation class allows developers to change the color of the shadows, it's in its docs.

The material IO only specify that the shadows remain drawn in both modes, except when the element is disabled. It should remain the same color and hue they already are.
Even so, the elevation class allows developers to change the color of the shadows, it's in its docs.

Hmm - done a bit more research. You are right but also Material Design does say that in Dark Mode, the change in elevation should change the "lightness" of the card - see this https://material.io/design/color/dark-theme.html#properties.
Compare that to what we have - where there is no visible change in elevation in the Dark theme
https://user-images.githubusercontent.com/2239795/108377395-e5bc8780-71fb-11eb-9773-c813e0473f0b.mp4
I am not sure what the answer is.
I am, however, very positive that the "you can change it yourself" response is not the right one. The reason for having the Dark and Light themes in MD and in kivyMD is to provide two well-formed configurations that look good without having to go through the App individually changing the colors. This issue is constructive feedback about that theme and not an issue saying that the color cannot be changed. You CAN change color yourself, just as you can create an MD app without kivymd or a Python GUI without kivy etc, etc. It is just a lot more work - which is why we all work with frameworks.

Well, that behavior was outside the spec of the elevation page, it is true that it should change color, but, it would directly affect every widget if it's included inside the behaviors. Since a great part of kivymd is its modularity.
It would be a great addition to MDCard class rather than the elevation behaviors.

I understand completely and I guess it is definitely an enhancement - I am just feeding back as a user that there is a gap here

Any feed back is greatly appreciated

Now, how should we proceed?
Since , I'm pretty sure people will be using cards with static colors, and this enhancement might get in the way their cards work.
Do you have any idea on which would be the best approach?

@podraco Wouldn't it be a good idea to use the shadow_color property in the CommonElevationBehavior class?

I'm not certain if that would be a good idea, since each shadow have a different saturation. Which allows people to set a certain strength to the shadows depending on the alpha value.
maybe we could add a base color thats changed if the background style is set to Auto?
so we could accomplish this.

also, for this, we should take in count this spec.

@podraco Wouldn't it be a good idea to use the shadow_color property in the CommonElevationBehavior class?

Also, remember that the BackgroundColorBehavior class now inherits from the CommonElevationBehavior class, it was an update to allow the event dispatcher work the proper way, and cast the background canvas call after the shadow.

The issue is deprecated due to the new API of the KivyMD library 2.0.0 version


conda install of version 2.2 does not work

I have encountered the following issue when upgrading from version 2.1 to 2.2. It seems the pysal ends up not being recognized by the system. To test this I created a clean environment
conda create --name georasters -c conda-forge python=3.7 pysal geopandas

the command works and installs all that is needed.  Seems the installer is doing something wrong.

If I create the clean environment forcing to use v2.1.0
conda create --name georasters -c conda-forge python=3.7 pysal=2.1.0 geopandas

generates the same issue. This is strange since v2.1.0 is the one I have installed in my other environments and works fine. Not sure what is going on.

The issue is also replicated in automatic builds, e.g. here

I just tried to replicate this and don't hit the same errors?
conda create --name georasters -c conda-forge python=3.7 pysal=2.1.0 geopandas
condo activate georasters
python

>>> from pysal.explore import esda
>>> from pysal.explore.esda import G as pysal_G
>>> pysal.__version__
'2.1.0'

(georasters) ~ » python
Python 3.7.6 | packaged by conda-forge | (default, Mar 23 2020, 23:03:20)
[GCC 7.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pysal
/home/sjsrey/anaconda3/envs/georasters/lib/python3.7/site-packages/pysal/explore/segregation/network/network.py:16: UserWarning: You need pandana and urbanaccess to work with segregation's network module
You can install them with  `pip install urbanaccess pandana` or `conda install -c udst pandana urbanaccess`
  "You need pandana and urbanaccess to work with segregation's network module\n"
/home/sjsrey/anaconda3/envs/georasters/lib/python3.7/site-packages/pysal/model/spvcm/abstracts.py:10: UserWarning: The `dill` module is required to use the sqlite backend fully.
  from .sqlite import head_to_sql, start_sql
>>> pysal.__file__
'/home/sjsrey/anaconda3/envs/georasters/lib/python3.7/site-packages/pysal/__init__.py'
>>>

I wonder if it is the conda version? I have recently updated conda. My current config is
conda info

     active environment : georasters
    active env location : /Users/ozak/anaconda3/envs/georasters
            shell level : 1
       user config file : /Users/ozak/.condarc
 populated config files : /Users/ozak/.condarc
          conda version : 4.8.3
    conda-build version : 3.18.8
         python version : 3.7.3.final.0
       virtual packages : __osx=10.13.6
       base environment : /Users/user/anaconda3  (writable)
           channel URLs : https://conda.anaconda.org/conda-forge/osx-64
                          https://conda.anaconda.org/conda-forge/noarch
                          https://conda.anaconda.org/mro/osx-64
                          https://conda.anaconda.org/mro/noarch
                          https://conda.anaconda.org/r/osx-64
                          https://conda.anaconda.org/r/noarch
                          https://repo.anaconda.com/pkgs/main/osx-64
                          https://repo.anaconda.com/pkgs/main/noarch
                          https://repo.anaconda.com/pkgs/r/osx-64
                          https://repo.anaconda.com/pkgs/r/noarch
          package cache : /Users/ozak/anaconda3/pkgs
                          /Users/ozak/.conda/pkgs
       envs directories : /Users/ozak/anaconda3/envs
                          /Users/ozak/.conda/envs
               platform : osx-64
             user-agent : conda/4.8.3 requests/2.23.0 CPython/3.7.3 Darwin/17.7.0 OSX/10.13.6
                UID:GID : 502:20
             netrc file : None
           offline mode : False

I imagine the CI used by conda-forge must also get the most recent conda.

Ok it seems to depend from where you call it. If I import it in python it works
python
Python 3.7.6 | packaged by conda-forge | (default, Mar 23 2020, 22:45:16)
[Clang 9.0.1 ] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import pysal
/Users/user/anaconda3/envs/georasters/lib/python3.7/site-packages/pysal/explore/segregation/network/network.py:16: UserWarning: You need pandana and urbanaccess to work with segregation's network module
You can install them with  `pip install urbanaccess pandana` or `conda install -c udst pandana urbanaccess`
  "You need pandana and urbanaccess to work with segregation's network module\n"
/Users/user/anaconda3/envs/georasters/lib/python3.7/site-packages/pysal/model/spvcm/abstracts.py:10: UserWarning: The `dill` module is required to use the sqlite backend fully.
  from .sqlite import head_to_sql, start_sql
>>> exit()

But if I try in jupyter,
(georasters)$ jupyter console
Jupyter console 6.1.0

Python 3.7.3 (default, Mar 27 2019, 16:54:48)
Type 'copyright', 'credits' or 'license' for more information
IPython 7.14.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: import pysal
---------------------------------------------------------------------------
ModuleNotFoundError                       Traceback (most recent call last)
<ipython-input-1-a9e22df3d4bc> in <module>
----> 1 import pysal

ModuleNotFoundError: No module named 'pysal'

In [2]:

Same if I try ipython
(georasters) 19-10862:~ ozak$ ipython
/Users/user/anaconda3/lib/python3.7/site-packages/IPython/terminal/ipapp.py:346: UserWarning: 'inline' not available as pylab backend, using 'auto' instead.
  warnings.warn("'inline' not available as pylab backend, "
Python 3.7.3 (default, Mar 27 2019, 16:54:48)
Type 'copyright', 'credits' or 'license' for more information
IPython 7.14.0 -- An enhanced Interactive Python. Type '?' for help.
Using matplotlib backend: MacOSX

In [1]: import pysal
---------------------------------------------------------------------------
ModuleNotFoundError                       Traceback (most recent call last)
<ipython-input-1-a9e22df3d4bc> in <module>
----> 1 import pysal

ModuleNotFoundError: No module named 'pysal'

In [2]:

Not sure why in the CI builds it is failing though. Nor why it fails to be found on ipython.

Could be that jupyter is not in the same environment?

You are right. Installing jupyter within that environment solves the issue partially.
jupyter console
Jupyter console 6.1.0

Python 3.7.6 | packaged by conda-forge | (default, Mar 23 2020, 22:45:16)
Type 'copyright', 'credits' or 'license' for more information
IPython 7.14.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: import pysal

In [2]: from pysal.explore.esda import G as pysal_G
---------------------------------------------------------------------------
ModuleNotFoundError                       Traceback (most recent call last)
<ipython-input-2-bcaa6b125888> in <module>
----> 1 from pysal.explore.esda import G as pysal_G

ModuleNotFoundError: No module named 'pysal.explore.esda'

The second command used to work on pysal=2.1.0, but is failing on pysal-2.2.0. Did the way of calling these change between 2.1 and 2.2? This would explain why it fails in the conda-forge CI environments.

Ok it seems one has to update the imports to
from esda import G as pysal_G

instead of the previous calling form. So this was not kept backwards compatible?

Ok it seems one has to update the imports to
from esda import G as pysal_G

instead of the previous calling form. So this was not kept backwards compatible?

This did break backwards compatibility in 2.2. Using esda directly as you have done will work.
Alternatively, one could do from pysal.explore import esda

I just had only seen the migration instructions and never saw that other change.
Thanks for the help!


std::bad_alloc with no error thrown

Hello Jared,
So i've been doing some polishing on a 3GB genome.
I decided to pack the ~1000 contigs I had into groups of 10, and polish each one, using 2CPUs an 32GB of ram total.
However during the processing I was getting many jobs that were prematurely ending, or not processing one or more of the steps, without any errors being thrown.
So I added in the use of /user/bin/time -v on each execution, and these terminate errors for bad_alloc started popping up, both in some of the index calls, and consensus calls. Note, that I would get say, 1 in the index, and then none in the consensus calls, or 1 in the index, and also 1 or 2 in the consensus calls.
Notice the exit status is 0.
Here is an example of both below.
Any ideas?
for the index call
[readdb] indexing /scratch_local/1703722.145.short.q/fast5/
[readdb] num reads: 170670, num reads with path to fast5: 170670
	Command being timed: "nanopolish index -d /scratch_local/1703722.145.short.q/fast5/ -s /scratch_local/1703722.145.short.q/145_seq_sum.txt /scratch_local/1703722.145.short.q/145.fastq"
	User time (seconds): 396.92
	System time (seconds): 2.94
	Percent of CPU this job got: 99%
	Elapsed (wall clock) time (h:mm:ss or m:ss): 6:41.92
	Average shared text size (kbytes): 0
	Average unshared data size (kbytes): 0
	Average stack size (kbytes): 0
	Average total size (kbytes): 0
	Maximum resident set size (kbytes): 153276
	Average resident set size (kbytes): 0
	Major (requiring I/O) page faults: 10
	Minor (reclaiming a frame) page faults: 43362
	Voluntary context switches: 6297
	Involuntary context switches: 741
	Swaps: 0
	File system inputs: 4946376
	File system outputs: 1260912
	Socket messages sent: 0
	Socket messages received: 0
	Signals delivered: 0
	Page size (bytes): 4096
	Exit status: 0
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
Command terminated by signal 6

For the consensus caller
	Command being timed: "nanopolish variants --fix-homopolymers -t 2 -w tig00003015|arrow|arrow:1-89027 --consensus --reads /scratch_local/1703722.145.short.q/145.fastq --bam /share/ScratchGeneral/jamfer/GermanShep/canu/batches/sam_batch.145.bam --genome /share/ScratchGeneral/jamfer/GermanShep/canu/batches/contig_batch.145.fasta -o /scratch_local/1703722.145.short.q/tig00003015|arrow|arrow-nanop.vcf"
	User time (seconds): 1280.54
	System time (seconds): 10.09
	Percent of CPU this job got: 160%
	Elapsed (wall clock) time (h:mm:ss or m:ss): 13:25.66
	Average shared text size (kbytes): 0
	Average unshared data size (kbytes): 0
	Average stack size (kbytes): 0
	Average total size (kbytes): 0
	Maximum resident set size (kbytes): 540780
	Average resident set size (kbytes): 0
	Major (requiring I/O) page faults: 0
	Minor (reclaiming a frame) page faults: 1480858
	Voluntary context switches: 16538
	Involuntary context switches: 11034
	Swaps: 0
	File system inputs: 33016
	File system outputs: 88
	Socket messages sent: 0
	Socket messages received: 0
	Signals delivered: 0
	Page size (bytes): 4096
	Exit status: 0
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
Command terminated by signal 6

Hi James,
Thanks for the detailed report. This is strange. I wrote a little test program that allocates a too-large array:
#include <stdio.h>

int main()
{
    size_t n = 4e10;
    int* arr = new int[n];
    printf("done allocation\n");
}

when I run this I get the expected bad_alloc error:
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
Aborted

If I check the exit status it is non-zero, as we'd like:
> echo $?
134

If I run this test program under /usr/bin/time though, it reports the exit status as zero like in your case:
> /usr/bin/time -v ./alloc_test
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
Command terminated by signal 6
        Command being timed: "./alloc_test"
        User time (seconds): 0.00
        System time (seconds): 0.00
        Percent of CPU this job got: 0%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.00
        Average shared text size (kbytes): 0
        Average unshared data size (kbytes): 0
        Average stack size (kbytes): 0
        Average total size (kbytes): 0
        Maximum resident set size (kbytes): 2400
        Average resident set size (kbytes): 0
        Major (requiring I/O) page faults: 0
        Minor (reclaiming a frame) page faults: 107
        Voluntary context switches: 6
        Involuntary context switches: 9
        Swaps: 0
        File system inputs: 0
        File system outputs: 0
        Socket messages sent: 0
        Socket messages received: 0
        Signals delivered: 0
        Page size (bytes): 4096
        Exit status: 0

I'm not sure why this is. Can you directly check the exit status (using $?) to see if its non-zero?

After a few more tests it looks like /usr/bin/time always says the exit status is 0 when a process calls abort()

Indeed it does seem to always be 0.
I had a closer look at some of the logs.
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
/opt/gridengine/default/spool/delta-3-4/job_scripts/1693696: line 76: 44690 Aborted                 (core dumped) $CMD

Yes, the exit status with $? does dump the 128+6 exit status for the kill signal 6.
My current work around is a grep on the logs, which relaunches the job with double the memory.
It would be great if there was a way to predict memory allocation requirements before hand. I'm guessing that read length or even coverage have something to do with it. even a ballpark like "32GB" or "64GB" would make a world of difference.
I'll have a look at the Maximum resident set size in the time output, and see if I can match it to some metric to do this prediction.
Thanks for the confirmation around the bad_alloc.


New Maintainer Checklist: add "real" name, meetup suggestion.

We've had problems in the past with Homebrew maintainers being unwilling to disclose their identity or meet other maintainers so here are some very light-touch suggestions to address this in future.
These ideas were run past the PLC and agreed there but I still welcome input from @Homebrew/maintainers.

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[x] Have you written new tests for your changes? Here's an example.

[x] Have you successfully run brew tests with your changes locally?

Thanks for review and comments all!


validation: reject changes to MachinePool platform fields

The MCO does not support updating existing machines when platform details are changed in a machineset. Consequently, Hive should not support making such changes.
https://issues.redhat.com/browse/CO-798

/lgtm


chore: Add script to generate pypi mfa qr

PyPi is now requiring MFA. I set up the necessary MFA configuration in PyPi and have stored relevant credentials in our secret store.
For convenience I'm providing this script to generate an MFA QR code for team PyPi maintainers.
e.g. (not a real QR code)

/azp run

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (7771c96) 86.26% compared to head (687a12a) 1.19%.

Additional details and impacted files
@@            Coverage Diff             @@
##           master   #2150       +/-   ##
==========================================
- Coverage   86.26%   1.19%   -85.08%
==========================================
  Files         312     312
  Lines       16486   16486
  Branches     1456    1456
==========================================
- Hits        14222     197    -14025
- Misses       2264   16289    +14025

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

/azp run

/azp run

/azp run


[Bug]: FileNotFoundError: Can't identify the notebook path.

Is there an existing issue for this?

[x] I have searched for similar issues and discussions

Bug Description
I get a notebook not found error when trying to create a view using:
view = dp.View.from_notebook()

System Information
- Datapane version: 0.16.4
- Python version: Python 3.9.2
- Operating System: Debian 11
- Using Jupyter: Yes
- Pip or Conda: Pip

Anything else?
---------------------------------------------------------------------------
FileNotFoundError                         Traceback (most recent call last)
File ~/.local/lib/python3.9/site-packages/datapane/ipython/environment.py:160, in JupyterEnvironment._get_notebook_path(self)
    159 try:
--> 160     return super()._get_notebook_path()
    161 except FileNotFoundError as e:

File ~/.local/lib/python3.9/site-packages/datapane/ipython/environment.py:135, in IPythonZMQEnvironment._get_notebook_path(self)
    133     return Path(path)
--> 135 return super()._get_notebook_path()

File ~/.local/lib/python3.9/site-packages/datapane/ipython/environment.py:109, in PythonEnvironment._get_notebook_path(self)
    108 """Get the path to the current notebook"""
--> 109 raise FileNotFoundError("Could not discover notebook path")

FileNotFoundError: Could not discover notebook path

During handling of the above exception, another exception occurred:

FileNotFoundError                         Traceback (most recent call last)
File ~/.local/lib/python3.9/site-packages/datapane/ipython/environment.py:98, in PythonEnvironment.get_notebook_json(self)
     97 try:
---> 98     path = self._get_notebook_path()
     99     with open(path, encoding="utf-8") as f:

File ~/.local/lib/python3.9/site-packages/datapane/ipython/environment.py:165, in JupyterEnvironment._get_notebook_path(self)
    164 try:
--> 165     return ipynbname.path()
    166 except IndexError:

File ~/.local/lib/python3.9/site-packages/ipynbname/__init__.py:93, in path()
     92     return root_dir / path
---> 93 raise FileNotFoundError(FILE_ERROR.format('path'))

FileNotFoundError: Can't identify the notebook path.

During handling of the above exception, another exception occurred:

DPClientError                             Traceback (most recent call last)
Cell In [14], line 2
      1 import datapane as dp
----> 2 view = dp.View.from_notebook()

File ~/.local/lib/python3.9/site-packages/datapane/view/view_blocks.py:49, in Blocks.from_notebook(cls, opt_out, show_code, show_markdown, template)
     46 from datapane.ipython import templates as ip_t
     47 from datapane.ipython.utils import cells_to_blocks
---> 49 blocks = cells_to_blocks(opt_out=opt_out, show_code=show_code, show_markdown=show_markdown)
     50 app_template_cls = ip_t._registry.get(template) or ip_t.guess_template(blocks)
     51 app_template = app_template_cls(blocks)

File ~/.local/lib/python3.9/site-packages/datapane/client/analytics.py:138, in capture_event.<locals>._decorator.<locals>._wrapper(*args, **kwargs)
    135 @wraps(func)
    136 def _wrapper(*args, **kwargs):
    137     try:
--> 138         return func(*args, **kwargs)
    139     finally:
    140         capture(name)

File ~/.local/lib/python3.9/site-packages/datapane/ipython/utils.py:97, in cells_to_blocks(opt_out, show_code, show_markdown)
     94 ipython_output_cache = user_ns["_oh"]
     95 ipython_input_cache = user_ns["_ih"]
---> 97 notebook_json = environment.get_notebook_json()
     98 # TODO: debug message for Colab, remove after testing
    100 notebook_is_dirty, dirty_cells = check_notebook_cache_parity(notebook_json, ipython_input_cache)

File ~/.local/lib/python3.9/site-packages/datapane/ipython/environment.py:102, in PythonEnvironment.get_notebook_json(self)
    100         notebook_json = json.load(f)
    101 except FileNotFoundError:
--> 102     raise DPClientError(
    103         "Notebook not found. This command must be executed from within a Jupyter notebook environment."
    104     )
    105 return notebook_json

DPClientError: Notebook not found. This command must be executed from within a Jupyter notebook environment.
Please run with `dp.enable_logging()`, restart your Jupyter kernel/Python instance, and/or visit https://www.github.com/datapane/datapane to raise issue / discuss if error repeats

Closing as archiving project


Spectrum channel mode normalization not working

(running the latest v.19.8)
When in the Spectrum Analyzer channel mode, pressing FN2 makes no effect. As per the F/W version .19.7 description text, it should "flatten spectrum by bringing up all of the RSSI readings to the peak value, plus resolve the 'valley problem' with channels hiding behind other channels of higher noise floor".
Also, to confirm its activation a "N(0x)" symbol should appear at the bottom of the screen - which doesn't occur.
Thanks in advance and congratulations once more for the outstanding job you're doing!
P.s.: channel attenuation and blacklisting functions are working normally.

I suggest you read the release notes again.
sob., 20 sty 2024, 20:36 użytkownik KerseyPaul @.***>
napisał:

(running the latest v.19.8)
When in the Spectrum Analyzer channel mode, pressing FN2 makes no effect.
As per the F/W version description text, it should "flatten spectrum by
bringing up all of the RSSI readings to the peak value, plus resolve the
'valley problem' with channels hiding behind other channels of higher noise
floor".
Also, to confirm its activation a "N(0x)" symbol should appear at the
bottom of the screen - which doesn't occur.
Thanks in advance and congratulations once more for the outstanding job
you're doing!
—
Reply to this email directly, view it on GitHub
https://github.com/kamilsss655/uv-k5-firmware-custom/issues/88, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ACDOWUJLSW6GGLC7LIF4EZ3YPQMFTAVCNFSM6AAAAABCDM2KOOVHI2DSMVQWIX3LMV43ASLTON2WKOZSGA4TEMRRGU3DSNI
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>


Update travis config for QuTiP 4.1.

With the release of QuTiP 4.1 and its use of C++ features, we need to add g++ as a build dependency on Travis to make sure we can compile the qutip package correctly. This should fix build errors seen in #125  and #126. Starting the PR to trigger builds and test whether it works.

Coverage increased (+0.02%) to 71.78% when pulling d32fd37a7dec224583b49b1f0a9c8d6b8a206a35 on fix-qutip-build into 8118ab7adaf0bd82ea39577a08f2ad3b71bca1ae on master.


Fixing Hive Avro scripts for Hive 0.13 & an issue with cross-sources suite

Rahul, can you please take a look? Had a successful run on my system. I'll schedule a test run on the common cluster and will let you know if i see issues.

Looks good. Merge it once you get a successfull run

@rchallapalli, I also made a change to fix the issue with the cross-sources suite. Can you take a look? I've scheduled another run with this commit.

Got a clean run. Merging.


stack issue

Running deploy shell script via hakyll deploy command fails with this bug: https://github.com/commercialhaskell/stack/issues/5000.
To reproduce, run in nixos19.09,

stack exec thoughts deploy

A possible solution is here
https://github.com/cdepillabout/termonad/pull/131/files

Note that https://github.com/commercialhaskell/stack/issues/5000 was fixed in stack master.


Create thapar.txt

Official Institute homepage:
http://www.thapar.edu
Computer Science course info:
http://www.thapar.edu/programmes/pages/computer-engineering

@ygoyalthapar Pull request merged. Thank you!


build<EMAIL_ADDRESS>

Publish version 4.1.5-beta.0.
Expected to be released this 9.23 or 9.24.
node: The last commit must be build: publish@{version}.

Coverage remained the same at 100.0% when pulling ca88048f3d6ab39576551b386c09a9d00f897824 on dev into 27a1ca945d3bea4dc3abc50e827085a16693d633 on main.

Ping @noname0310 to review.
Please aprove and merge https://github.com/js-sdsl/js-sdsl/pull/46 first.

This time we modified the build method of the entire package, so we should publish a beta version to have a test.


[C++] Add support for building on Android

Describe the enhancement requested
vcpkg has a small patch for Android: https://github.com/microsoft/vcpkg/blob/master/ports/arrow/android.patch
Let's upstream this and remove the patch from vcpkg.
Component(s)
C++

We need to add a CI for Android as the first step. But how...? Can we use Android on hosted GitHub Actions runner?


Place utils contracts in remapped directories when appropriate

This PR:

Place utils contracts under node_modules when package remapping is present (Fixes #160)
Add support for function lists in using for directives (added in solc 0.8.13)

Given that we have user complaints about #160 I would rather handle the remaining issues with 0.8.13 as a separate PR. I would even be down to do a patch release after we merge this and then fix the remaining 0.8.13 issues in the next patch. Would you be ok with this idea?


Hover Text on form fields

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Hover over form fields, see that there is some text that shows up.
Expected behavior
This should not show up when a user hovers over form fields.
Screenshots

Additional context
BAHFA's main concern here is that this would be read aloud by a screenreader. We verified that this is not the case, but we should see if we can remove this weird hover state in general.

QA Notes
We will have to pull in latest UIC in Doorway before we can QA. Ensure we aren't getting tooltips on hover anymore.

This is now QA-able as soon as it deploys to staging!

I believe this looks good! I don't see the tooltip hovering over the notification any more.


Implement asynchronous search

Codecov Report

Merging #51 (985fbe7) into main (86c933d) will decrease coverage by 0.44%.
The diff coverage is 72.46%.

@@            Coverage Diff             @@
##             main      #51      +/-   ##
==========================================
- Coverage   93.78%   93.33%   -0.45%
==========================================
  Files          32       34       +2
  Lines        5371     5505     +134
==========================================
+ Hits         5037     5138     +101
- Misses        334      367      +33

Impacted Files
Coverage Δ

search/benches/bench_search.rs
0.00% <0.00%> (ø)

search/src/alpha_beta.rs
68.75% <70.37%> (+4.30%)
:arrow_up:

search/tests/search.rs
83.72% <80.85%> (-0.83%)
:arrow_down:

search/src/negamax.rs
93.39% <86.11%> (-2.01%)
:arrow_down:

search/src/searcher.rs
87.23% <87.23%> (ø)

search/src/search.rs
35.29% <100.00%> (+11.76%)
:arrow_up:

Continue to review full report at Codecov.

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


Propagate wikidata description change on undo/revert action

We need to add 'undo' to the regex for detecting Wikidata description
edits so that this type of change event also gets propagated.

LGTM, waiting for tests and deploying. Thank for providing a special test for it, honestly I'd be too lazy to write a tests here :)

Coverage remained the same at 86.076% when pulling d6b8caefe699a5a642aa14bfc08d25edec8cfb58 on mdholloway:master into a954c43cf222d8acd1a470c63dd626196d41326a on wikimedia:master.

Coverage remained the same at 86.076% when pulling d6b8caefe699a5a642aa14bfc08d25edec8cfb58 on mdholloway:master into a954c43cf222d8acd1a470c63dd626196d41326a on wikimedia:master.

Created a corresponding commit in the deploy repo: https://gerrit.wikimedia.org/r/335294


Error on new cluster boot: secret "moco-mycluster-grpc" not found

Describe the bug
I am trying to start a new Moco cluster. However, the pod does not start successfully, and I see the following error event on the pod:
MountVolume.SetUp failed for volume "grpc-cert" : secret "moco-mycluster-grpc" not found

My cluster config is as follows:
apiVersion: moco.cybozu.com/v1beta2
kind: MySQLCluster
metadata:
  name: mycluster
  namespace: default
spec:
  backupPolicyName: daily
  podTemplate:
    metadata: {}
    spec:
      containers:
      - image: quay.io/cybozu/mysql:8.0.28
        name: mysqld
        resources:
          limits:
            cpu: "1"
            memory: 1Gi
          requests:
            cpu: 100m
            memory: 128Mi
  replicas: 1
  volumeClaimTemplates:
  - metadata:
      name: mysql-data
    spec:
      accessModes:
      - ReadWriteOnce
      resources:
        requests:
          storage: 1Gi

Environments

Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.14", GitCommit:"0f77da5bd4809927e15d1658fb4aa8f13ad890a5", GitTreeState:"clean", BuildDate:"2022-06-15T14:11:36Z", GoVersion:"go1.16.15", Compiler:"gc", Platform:"linux/amd64"}
OS: Linux (DigitalOcean Managed Kubernetes Cluster)

To Reproduce
Steps to reproduce the behavior:

Start a managed Kubernetes cluster on DigitalOcean
Install Cert-Manager using Helm release 1.8.2
Install Moco using Helm release 0.2.3
Create the cluster from the YAML above

Expected behavior
The cluster creates without error.
Please let me know if you need any additional info to help debug this.

The secret should be created before the StatefulSet.
Please run the following command and tell me if you have the Secret.
kubectl get secret moco-mycluster-grpc

Could you provide moco-controller's logs of when you created the cluster?

Yes, this seems to be an issue: the secret isn't created when the StatefulSet comes online:
$ kubectl get secret moco-mycluster-grpc
Error from server (NotFound): secrets "moco-mycluster-grpc" not found

In the logs, I notice that there are three operations occurring which relate to secrets:

created controller Secret (mysql-default.mycluster)
reconciled user Secret (moco-mycluster)
reconciled my.cnf Secret (moco-my-cnf-mycluster)

Here are the full logs from after I create the fresh cluster:
{"level":"info","ts":1657925552.3789482,"logger":"controller.mysqlcluster","msg":"created controller Secret","reconciler group":"moco.cybozu.com","reconciler kind":"MySQLCluster","name":"mycluster","namespace":"default","secretName":"mysql-default.mycluster"}
{"level":"info","ts":1657925552.392066,"logger":"controller.mysqlcluster","msg":"reconciled user Secret","reconciler group":"moco.cybozu.com","reconciler kind":"MySQLCluster","name":"mycluster","namespace":"default","secretName":"moco-mycluster"}
{"level":"info","ts":1657925552.406889,"logger":"controller.mysqlcluster","msg":"reconciled my.cnf Secret","reconciler group":"moco.cybozu.com","reconciler kind":"MySQLCluster","name":"mycluster","namespace":"default","secretName":"moco-my-cnf-mycluster"}
{"level":"info","ts":1657925552.5299957,"logger":"controller.mysqlcluster","msg":"reconciled my.cnf ConfigMap","reconciler group":"moco.cybozu.com","reconciler kind":"MySQLCluster","name":"mycluster","namespace":"default","configMapName":"moco-mycluster.953412cc"}
{"level":"info","ts":1657925552.5386188,"logger":"controller.mysqlcluster","msg":"reconciled ConfigMap for slow logs","reconciler group":"moco.cybozu.com","reconciler kind":"MySQLCluster","name":"mycluster","namespace":"default","configMapName":"moco-slow-log-agent-config-mycluster"}
{"level":"info","ts":1657925552.5647366,"logger":"controller.mysqlcluster","msg":"reconciled ServiceAccount","reconciler group":"moco.cybozu.com","reconciler kind":"MySQLCluster","name":"mycluster","namespace":"default","serviceAccountName":"moco-mycluster"}
{"level":"info","ts":1657925552.5794935,"logger":"controller.mysqlcluster","msg":"reconciled Service","reconciler group":"moco.cybozu.com","reconciler kind":"MySQLCluster","name":"mycluster","namespace":"default","serviceName":"moco-mycluster"}
{"level":"info","ts":1657925552.60589,"logger":"controller.mysqlcluster","msg":"reconciled Service","reconciler group":"moco.cybozu.com","reconciler kind":"MySQLCluster","name":"mycluster","namespace":"default","serviceName":"moco-mycluster-primary"}
{"level":"info","ts":1657925552.6343389,"logger":"controller.mysqlcluster","msg":"reconciled Service","reconciler group":"moco.cybozu.com","reconciler kind":"MySQLCluster","name":"mycluster","namespace":"default","serviceName":"moco-mycluster-replica"}
{"level":"info","ts":1657925552.658057,"logger":"controller.mysqlcluster","msg":"reconciled StatefulSet","reconciler group":"moco.cybozu.com","reconciler kind":"MySQLCluster","name":"mycluster","namespace":"default","statefulSetName":"moco-mycluster"}
{"level":"info","ts":1657925552.6797945,"logger":"controller.mysqlcluster","msg":"reconciled CronJob for backup","reconciler group":"moco.cybozu.com","reconciler kind":"MySQLCluster","name":"mycluster","namespace":"default","cronJobName":"moco-backup-mycluster"}
{"level":"info","ts":1657925552.764195,"logger":"controller.mysqlcluster","msg":"reconciled Role for backup","reconciler group":"moco.cybozu.com","reconciler kind":"MySQLCluster","name":"mycluster","namespace":"default","roleName":"moco-backup-mycluster"}
{"level":"info","ts":1657925552.7883966,"logger":"controller.mysqlcluster","msg":"reconciled RoleBinding for backup","reconciler group":"moco.cybozu.com","reconciler kind":"MySQLCluster","name":"mycluster","namespace":"default","roleBindingName":"moco-backup-mycluster"}
{"level":"info","ts":1657925552.8288941,"logger":"controller.mysqlcluster","msg":"reconciled Service","reconciler group":"moco.cybozu.com","reconciler kind":"MySQLCluster","name":"mycluster","namespace":"default","serviceName":"moco-mycluster"}
{"level":"info","ts":1657925552.833296,"logger":"cluster-manager.default/mycluster","msg":"update the status information"}
{"level":"info","ts":1657925552.8453188,"logger":"controller.mysqlcluster","msg":"reconciled Service","reconciler group":"moco.cybozu.com","reconciler kind":"MySQLCluster","name":"mycluster","namespace":"default","serviceName":"moco-mycluster-primary"}
{"level":"info","ts":1657925552.8542955,"logger":"controller.mysqlcluster","msg":"reconciled Service","reconciler group":"moco.cybozu.com","reconciler kind":"MySQLCluster","name":"mycluster","namespace":"default","serviceName":"moco-mycluster-replica"}
{"level":"info","ts":1657925552.862228,"logger":"cluster-manager.default/mycluster","msg":"cluster state is Lost"}
{"level":"info","ts":1657925552.8741777,"logger":"controller.mysqlcluster","msg":"reconciled CronJob for backup","reconciler group":"moco.cybozu.com","reconciler kind":"MySQLCluster","name":"mycluster","namespace":"default","cronJobName":"moco-backup-mycluster"}
{"level":"info","ts":1657925552.893208,"logger":"controller.mysqlcluster","msg":"reconciled Service","reconciler group":"moco.cybozu.com","reconciler kind":"MySQLCluster","name":"mycluster","namespace":"default","serviceName":"moco-mycluster"}
{"level":"info","ts":1657925552.8963215,"logger":"cluster-manager.default/mycluster","msg":"cluster state is Lost"}
{"level":"info","ts":1657925552.9022868,"logger":"controller.mysqlcluster","msg":"reconciled Service","reconciler group":"moco.cybozu.com","reconciler kind":"MySQLCluster","name":"mycluster","namespace":"default","serviceName":"moco-mycluster-primary"}
{"level":"info","ts":1657925552.941502,"logger":"controller.mysqlcluster","msg":"reconciled Service","reconciler group":"moco.cybozu.com","reconciler kind":"MySQLCluster","name":"mycluster","namespace":"default","serviceName":"moco-mycluster-replica"}
{"level":"info","ts":1657925552.979733,"logger":"controller.mysqlcluster","msg":"reconciled CronJob for backup","reconciler group":"moco.cybozu.com","reconciler kind":"MySQLCluster","name":"mycluster","namespace":"default","cronJobName":"moco-backup-mycluster"}
{"level":"info","ts":1657925553.0171769,"logger":"cluster-manager.default/mycluster","msg":"cluster state is Lost"}
{"level":"info","ts":1657925553.2946203,"logger":"controller.mysqlcluster","msg":"reconciled Service","reconciler group":"moco.cybozu.com","reconciler kind":"MySQLCluster","name":"mycluster","namespace":"default","serviceName":"moco-mycluster"}
{"level":"info","ts":1657925553.3090465,"logger":"controller.mysqlcluster","msg":"reconciled Service","reconciler group":"moco.cybozu.com","reconciler kind":"MySQLCluster","name":"mycluster","namespace":"default","serviceName":"moco-mycluster-primary"}
{"level":"info","ts":1657925553.3295047,"logger":"controller.mysqlcluster","msg":"reconciled Service","reconciler group":"moco.cybozu.com","reconciler kind":"MySQLCluster","name":"mycluster","namespace":"default","serviceName":"moco-mycluster-replica"}
{"level":"info","ts":1657925553.3560166,"logger":"controller.mysqlcluster","msg":"reconciled CronJob for backup","reconciler group":"moco.cybozu.com","reconciler kind":"MySQLCluster","name":"mycluster","namespace":"default","cronJobName":"moco-backup-mycluster"}
{"level":"info","ts":1657925553.4154,"logger":"cluster-manager.default/mycluster","msg":"cluster state is Lost"}
{"level":"info","ts":1657925553.4170942,"logger":"controller.mysqlcluster","msg":"reconciled Service","reconciler group":"moco.cybozu.com","reconciler kind":"MySQLCluster","name":"mycluster","namespace":"default","serviceName":"moco-mycluster"}
{"level":"info","ts":1657925553.490396,"logger":"controller.mysqlcluster","msg":"reconciled Service","reconciler group":"moco.cybozu.com","reconciler kind":"MySQLCluster","name":"mycluster","namespace":"default","serviceName":"moco-mycluster-primary"}
{"level":"info","ts":1657925553.5258667,"logger":"controller.mysqlcluster","msg":"reconciled Service","reconciler group":"moco.cybozu.com","reconciler kind":"MySQLCluster","name":"mycluster","namespace":"default","serviceName":"moco-mycluster-replica"}
{"level":"info","ts":1657925553.54645,"logger":"controller.mysqlcluster","msg":"reconciled CronJob for backup","reconciler group":"moco.cybozu.com","reconciler kind":"MySQLCluster","name":"mycluster","namespace":"default","cronJobName":"moco-backup-mycluster"}
{"level":"info","ts":1657925553.564164,"logger":"cluster-manager.default/mycluster","msg":"cluster state is Lost"}

Not sure if this helps or muddies the waters, but I did not see this specific issue when I booted a test cluster in my local kind cluster.

Just confirming that I am using Moco Helm chart version 0.2.3 from ghcr.io/cybozu-go/moco.
Reviewing the reconciler, it seems clear to me that I should see logs in this order:

created controller Secret
reconciled user Secret
reconciled my.cnf Secret
reconciled gRPC secret
reconciled my.cnf ConfigMap

I wonder if the creation of this secret is falling through silently in the client.IgnoreNotFound case handler?

Thanks for your information.
"moco-mycluster-grpc" is generated by cert-manager.
Could you please check the status of the certificate as follows?
kubectl describe certificate moco-agent-default.mycluster

I see, thanks for clarifying.
Here is the result of kubectl describe certificate moco-agent-default.mycluster:
Name:         moco-agent-default.mycluster
Namespace:    default
Labels:       app.kubernetes.io/created-by=moco
              app.kubernetes.io/instance=mycluster
              app.kubernetes.io/instance-namespace=default
              app.kubernetes.io/name=mysql
Annotations:  <none>
API Version:  cert-manager.io/v1
Kind:         Certificate

...snip...

Status:
  Conditions:
    Last Transition Time:        2022-07-15T23:32:45Z
    Message:                     Issuing certificate as Secret does not exist
    Observed Generation:         1
    Reason:                      DoesNotExist
    Status:                      False
    Type:                        Ready
    Last Transition Time:        2022-07-15T23:32:45Z
    Message:                     Issuing certificate as Secret does not exist
    Observed Generation:         1
    Reason:                      DoesNotExist
    Status:                      True
    Type:                        Issuing
  Next Private Key Secret Name:  moco-agent-default.mycluster-wrvbx
Events:                          <none>

Investigating deeper with moco-agent-default.mycluster-6g87q:
...snip...

Status:
  Conditions:
    Last Transition Time:  2022-07-15T23:32:46Z
    Message:               Certificate request has been approved by cert-manager.io
    Reason:                cert-manager.io
    Status:                True
    Type:                  Approved
    Last Transition Time:  2022-07-15T23:32:46Z
    Message:               Referenced "Issuer" not found: issuer.cert-manager.io "moco-grpc-issuer" not found
    Reason:                Pending
    Status:                False
    Type:                  Ready

I do not see the Issuer moco-grpc-issuer, but here's what I have for kubectl describe issuer moco-8a698ec5-grpc-issuer:
Name:         moco-8a698ec5-grpc-issuer
Namespace:    default
Labels:       app.kubernetes.io/managed-by=Helm
              app.kubernetes.io/name=moco
              app.kubernetes.io/version=0.12.1
              helm.sh/chart=moco-0.2.3
Annotations:  meta.helm.sh/release-name: moco-8a698ec5
              meta.helm.sh/release-namespace: default
API Version:  cert-manager.io/v1
Kind:         Issuer

...snip...

Spec:
  Ca:
    Secret Name:  moco-grpc-ca
Status:
  Conditions:
    Last Transition Time:  2022-07-14T20:31:19Z
    Message:               Signing CA verified
    Observed Generation:   1
    Reason:                KeyPairVerified
    Status:                True
    Type:                  Ready

I notice that certificate.yaml and issuer.yaml use name: {{ template "moco.fullname" . }}-grpc-issuer, but certificate_tmpl.yaml uses moco-grpc-issuer.
I wonder if this bug is exposed by moco.fullname being set to moco-8a698ec5 and not moco in my Helm release?

Looks like a bug in the helm chart.

@mplewis
Thanks!
I fixed it: #432


KinematicBody2D's move_and_slide delayed on moving platforms

Godot version:
3.0 Stable
OS/device including version:
All
Issue description:
(Both) KinematicBody2D (and RigidBody2D) (still) cannot handle moving platforms well.
On a moving platform (moved over AnimationPlayer or script) you still feel like you are playing an egg in an oiled pan.
The character slides left and right too much, depending on the direction where the platform moves.
The problem gets worse with faster platforms.
Increasing the friction does not help to reduce this effect.
Expected result:
I expected a physics body to move exactly the same way as the platform does.
This makes 2D Physics in Godot unusable for platforming games that require high precision.
Steps to reproduce:

install Godot3
get the template "2D Platformer Demo (Kinematicbody)"

optional: edit moving_platform.gd to speed up the movement of the platform to get a more extrem result

run the projekt
jump on a moving platofrm
see the character sliding

Minimal reproduction project:

2D Platformer Demo (Kinematicbody)

There is also problem if "moving platform" moves up and down - KinematicBody2D is jumping, lagging one frame.
There is so much more problems that you will face if you except to make oldschool platformer with KinematicBody2D (especially proper arcade slope physics).
Spare yourself the trouble of making arcade physics with KinematicBody2D, it is not funcional for that purpouse. Make your own cutom tilebased arcade physics.

Yes I guess you are right. I wanted to use the build in physics "just" to see the limitations.
(and to have cleaner code)
It's still good for some "Castle Vania" - like games, but I would probably not use it for something like "Super Meat Boy" or even "Mario".
Guess I need to learn about Tile-based arcade physics now. Thanks for that information.

 I am struggling to make my own. Cheers

This is fixed, see this article.
Closing


Service Fabric for Long running jobs

Hi
Whether service fabric considered for long running jobs?
Thanks
Vino
[Enter feedback here]

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

ID: 50a65e47-b024-0c7c-0ee9-21ff095abafd
Version Independent ID: a764689a-168d-dcef-a297-c47f84ea2d12
Content: Background jobs guidance
Content Source: docs/best-practices/background-jobs.md
Service: guidance
GitHub Login: @dragon119
Microsoft Alias: pnp

This help document is not updated for sometime. Can you updated with other azure options for long running jobs.

@vinomanoharan  Thank you for your comment. Technically speaking, we can use anything for long running jobs but we're focusing on most popular options among our customers here.

Totally agree with @vinomanoharan , guide requires some actualization to address latest trends in Microsoft Azure. For example AKS instead of ACS. https://github.com/mspnp/architecture-center/issues/885
Otherwise it looks like - either guides are too conservative, or simple out-of-date.


Add Differential IK controller

As in https://github.com/isaac-sim/IsaacLab/blob/main/source/extensions/omni.isaac.lab/omni/isaac/lab/controllers/differential_ik.py it should allow fast computation of IK control instead of Lula.

Completed in #858


All Day Events are not determined correctly

I've encountered an issue with the All Day functionality of calendar dates.
When working with the event_list block for example, there is the method Concrete\Core\Entity\Calendar\CalendarEventOccurrence::isAllDay().
I've found this method to constantly return false on events that are set to AllDay.
The reason for this seems to be that this method determines if it is a AllDay Event based on the assumption that All day Events have the same start and end time.
However in Concrete\Core\Permission\Duration::createFromRequest() where the Event Occurrences are saved, the start and end dates are set to defferent values. (00:00:00 and 23:59:59).
I guess this can be easily be fixed by correcting the expected $diff for allDay Events to 86399:
https://github.com/concrete5/concrete5/pull/7620

Merged #7620


Fix missing link

First of all, kudos for this project.
It's the only project I found that properly supports modern models like llama-3.1 out of the box. Also the speed, and other factors, seem better.
Fixing in this PR a small bug - the previous link led to a missing page.

Thanks! LGTM


In "Beta" Channel the update "13.0.0 RC 1" is show for 12.0.4.

I have Nextcloud 12.0.4 installed and I am in "beta "Channel
The updater show me the "13.0.0 RC 1" update, but it should be "12.0.5 RC 1"
The lines 285 ff in "config.php" are wrong:
		'12' => [
			'100' => [
				'latest' => '13.0.0 RC 1',

Greetings
TanarRi

Works as it should -> closing


Federation users shouldn't be required to have go compiler toolchain/libraries installed

 Issue by madhusudancs
Tuesday Jul 12, 2016 at 02:29 GMT
Originally opened as https://github.com/kubernetes/kubernetes/issues/28812

It is unfortunate that our federation turn up scripts run the manifests through a go program which isn't shipped as a binary in our release, but instead as a source.  We should fix this.
It is also quite amusing that e2es did not catch this. Do we have go toolchain installed on the Jenkins machine that deploys the test clusters?
cc @colhom @ixdy @kubernetes/sig-cluster-federation

 Comment by colhom
Tuesday Jul 12, 2016 at 03:52 GMT

@madhusudancs the go toolchain has always been a hard dependency for kubernetes-e2e Jenkins jobs since prior to the existence of federation. There is e2e-runner and a dockerized-e2e-runner, both of which are bash scripts with do bring-up, e2e test themselves, reporting, and tear-down. This is all actuated via  go run ./hack/e2e.go, and as you'd expect both require a working golang installation be available to the context interacting the the kubernetes/ folder.
If we want to fix this anti-pattern of treating golang source files as scripts (the existence of go run command suggests that it's not an anti-pattern...but I digress) , we should take any of the go utilities that aren't codegen related (e2e.go, template.go, ... there are probably more), stuff them all in a package and add them to the release target.
\cc @quinton-hoole

 Comment by quinton-hoole
Tuesday Jul 12, 2016 at 04:13 GMT

@colhom , @madhusudancs I think that you both have good points.  Here's my take:

The e2e status quo relies on the go toolchain, and we should leave it as such (or fix it holistically, and independently of federation).
We should also support a pre-built binary release of federation, which can be installed with minimum external dependencies (including the go toolchain).  This would be consistent with the Kubernetes binary installation e.g. http://kubernetes.io/docs/getting-started-guides/gce/

 Comment by madhusudancs
Tuesday Jul 12, 2016 at 06:17 GMT

@quinton-hoole @colhom agreed on all your points (@colhom except the point on the existence of go run indicating a pattern. I will be happy to discuss about that outside this issue).
My intention, and this issue, is not about fixing e2e's dependency on go toolchain. In some sense it really doesn't matter whether e2e's have go toolchain dependency or not. I was amused that there was a dependency because I was hoping that the jenkins jobs were directly calling the shell scripts, not the go wrappers. But anyway, don't want to get sidetracked.
We should, however, definitely not expect our users to have the go toolchain installed.

 Comment by quinton-hoole
Monday Aug 29, 2016 at 15:34 GMT

@madhusudancs Just confirming that we can get this in by tomorrow as previously discussed. It's pretty critical for usability.

 Comment by madhusudancs
Monday Aug 29, 2016 at 17:04 GMT

@quinton-hoole I think so, yes. PR #30744 is the only blocking PR as far as I remember.

 Comment by nikhiljindal
Wednesday Aug 31, 2016 at 22:42 GMT

@madhusudancs https://github.com/kubernetes/kubernetes/pull/30744 is now merged.
Next step I think is to write a doc explaining the new flow and put it on k8s.io?

 Comment by madhusudancs
Thursday Sep 01, 2016 at 01:30 GMT

@nikhiljindal yes!

 Comment by ixdy
Thursday Sep 01, 2016 at 21:26 GMT

I was OOO when this issue was first discussed.
I think @fejta is working on getting rid of the go requirement for hack/e2e.go. That said, we only expect devs to be using hack/e2e.go, so requiring the go toolchain to be installed seems reasonable.

 Comment by madhusudancs
Thursday Sep 01, 2016 at 21:44 GMT

@ixdy this issue isn't about devs. Current federation scripts that we ship in the release distribution require users (end users) to have go toolchain installed to install federation. That's not reasonable.

 Comment by ixdy
Thursday Sep 01, 2016 at 21:47 GMT

@madhusudancs agree 100%. I saw you mention hack/e2e.go, but I see now that that was mostly to explain why we have the go toolchain available in CI.

 Comment by pwittrock
Thursday Sep 08, 2016 at 01:19 GMT

@quinton-hoole @madhusudancs @ixdy
I am leaving this in the 1.4 release as a blocking issue.  Please provide daily status updates to this issue or move it out of the release and into v1.4-nonblocking where it will no longer be tracked as a release blocking issue in the burndown meetings.

 Comment by madhusudancs
Thursday Sep 08, 2016 at 01:44 GMT

@pwittrock The relevant code is merged. There is only documentation work left and I am keeping this open as a reminder. How would you like us to track this?

 Comment by pwittrock
Thursday Sep 08, 2016 at 04:13 GMT

move it out of the release and into v1.4-nonblocking where it will no longer be tracked as a release blocking issue in the burndown meetings.

 Comment by madhusudancs
Thursday Sep 08, 2016 at 04:24 GMT

@pwittrock Ok, thanks!

cc @madhusudancs

We no longer require go toolchain to run federation e2e. Documentation updates shall be tracked in separate issue.
/close


gorse error in Docker container

goroutine 1 [running]:
xr/svd-cooker/vendor/github.com/zhenghaoz/gorse/core.init.0()
	/go/src/xr/svd-cooker/vendor/github.com/zhenghaoz/gorse/core/built_in.go:75 +0x2a
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x48 pc=0x75be6a]

https://github.com/zhenghaoz/gorse/blob/master/core/built_in.go
func init() {
	usr, _ := user.Current()
	gorseDir := usr.HomeDir + "/.gorse"
	downloadDir = gorseDir + "/download"
	dataSetDir = gorseDir + "/datasets"
	TempDir = gorseDir + "/temp"
}

Need return err in user.Current()
Need create path without being tied to the user

Thanks for your feedback ^_^. Actually, I haven't considered the situation in Docker and I have limited knowledge about Docker. I'll try to fix it later.

With ENV USER root work
FROM scratch

ENV USER root

ADD test ./test
VOLUME ["/logs", "/models"]

CMD ["./test", "-log_dir", "logs"]

Thanks for your feedback ^_^. Actually, I haven't considered the situation in Docker and I have limited knowledge about Docker. I'll try to fix it later.

It is enough to display an error. Then it's clear what's the matter.


dynatrace-sli-service: Ensure compatibility with new metrics v2 api (/api/v2/metrics/query)

The sli service queries /api/v2/metrics/series when it should start talking to /api/v2/metrics/query
See query: https://github.com/keptn-contrib/dynatrace-sli-service/blob/d76e0ebff648f53a18ef97da1cd4a0f0e9632dc5/pkg/lib/dynatrace/dynatrace.go#L143
Execute, for example, curl -X GET "/api/v2/metrics/series/builtin:service.requestCount.total:merge(0):count?scope=tag(hotday-tag-rule:hotday-tag-rule:carts-carts-test)"
Then you get a warning: Any usage of /metrics/series should be updated to use /metrics/query
see: {"totalCount":0,"nextPageKey":null,"metrics":{"builtin:service.requestCount.total:merge(0):count":{"series":[]}},"warnings":["/metrics/series is outdated and has been superseded by /metrics/query. Any usage of /metrics/series should be updated to use /metrics/query. The payload has been modernized and scope has been replaced by the new entitySelector, with a slightly different syntax that requires a mandatory type predicate. Note that the new end point no longer supports metrics with different primary entity types being queried together. See the Swagger Documentation for more details on the modern endpoint."]}

Sorry about the delay -
Have updated the Readme and integration document - alongwith static metric definitions in the following PR
https://github.com/keptn-contrib/dynatrace-sli-service/pull/28
If I have missed something, please let me know!
:bowing_woman:


initialize / find callbacks do not work

As described here: https://github.com/neo4jrb/neo4j/wiki/Neo4j%3A%3AActiveNode#callbacks
i expect to have callbacks working, though those do not work:
tried different variations:
after_initialize
initialize
before_initialize
before_find
find
after_find

Some of callbacks work, for example those:

before_validation / after_validation
before_create / after_create
before_save / after_save

Checked by this code:
class Te
    include Neo4j::ActiveNode
    property :name

    before_validation do
      print 'before_validation callback'
    end

    after_validation do
      print 'after_validation callback'
    end

  before_initialize do
    print 'before_initialize callback'
  end

  after_initialize do
    print 'after_initialize callback'
  end

end

    n = Te.create(name: '999')
    n.name = 'xxxx'
    n.save
    n.update name: 'yyyyy'
    Te.find_by name: 'xxxx'

Moreover, when you try to catch after_find / before_find callbacks -
other callbacks which worked in class before - also stop working.
E.g. here - validation not working anymore:
class Te

    include Neo4j::ActiveNode
    property :name

    after_find do
      print 'after_find callback'
    end

    before_find do
      print 'before_find callback'
    end

    before_validation do
      print 'before_validation callback'
    end

    after_validation do
      print 'after_validation callback'
    end

end

The last behavior confuses a lot

So the act of including the find callbacks cause the validation callbacks to stop working?

Yes, if they are included before validation callbacks.
But the most sad thing, is that initialize/find callbacks do not work at all

Maybe it simply was never implemented...

Don't know how it should work, but looks like that
Need at least fix documentation then

I imagine we'd need a run_callbacks(:find) in there? I didn't implement any of those so I'm not entirely sure how all the callbacks are implemented. We should add a failing test and work from there.

Someone else reported that after_initialize callbacks were not firing and I seem to have confirmed. It looks like only some of those callback methods were ever expected to work:
define_model_callbacks :initialize, :find, only: :after
define_model_callbacks :save, :create, :update, :destroy

But the act of actually triggering any callbacks seems to be a side-effect of other methods implemented in the gem, as you pointed out in that screenshot. If we follow the pattern in use, the solution is to define the methods that expect to trigger callbacks and run them manually. I'm going to write some failing tests for this and see if I can correct it.

This was fixed a few months back so I'm closing. Thanks for reporting!


Is it possible to use it on npm packages without polluting the global?

I'm intend to use tachyons to solve the ever complex css on one of my npm packages, but it will apparently pollute the global css for anyone who use it, is there a way around it?

You can try compiling tachyons with a custom namespace. The tachyons-cli tool might be useful but its interface does not reflect the plugins parameter update from tachyons-build-css (what tachyons-cli use under the hood).
So you can use the tachyons-build-css tool with postcss-prefix-selector to compile tachyons with a custom namespace.

@cristianofromagio Thank you. I import another component library in my package, so postcss-prefix-selector seems to be doing to much, I tried exclude but still not making a smooth solution. Currently I think I'll use sass or less and just copy the stylesheet of tachyons and making it a sass file, so I can easily wrap a class at the top.


Breakpoints and Source maps appear broken

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

VS Code Version:  1.74 (Latest)
OS Version: Windows 11

Steps to Reproduce:

Set breakpoint in typescript file and start debugging with extension host.
Breakpoint does not hit.

I initially thought I was doing something wrong (which is still possible), but I made no relevant code changes (launch.json, tsconfig.json, webpack config, package.json, etc.).  The breakpoints also DO hit in vs code (not insiders).  The problem also started this morning.

/jsDebugLogs

https://microsoft-my.sharepoint.com/:u:/p/robreed/EVfLdfk6UT9CqUGKHA68IWMBvp5uVchsiT0AWfVMzKESeA?e=X2zyh8
The code also not does not allow closing with stop button.

I also get a lot of these entries in debug log

It's certainly possible that I'm doing something incorrectly, but it's odd that...

I made no changes to the config files before the issue started occurring.
The issue does not show up in VS Code.
The issue started randomly one morning after Insiders updated.

Thank you

Thanks for the update! I believe this may be the same issue seen in https://github.com/microsoft/vscode-js-debug/issues/1469. You can either swap to the new nightly js-debug now, or wait for the next Insiders build to come out later today which will also have the fix. Please let me know if that works for you.

This should be a pretty urgent problem. It has halted extension development, dead in it's tracks on Linux. It has become utterly impossible to continue development, in my case on a debug adapter.

Closing since I have not heard from the author.

This should be a pretty urgent problem.

That's why the linked bug is marked as a candidate 🙂