[$500] Web - IOU - App start flashing when any changes as the admin

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Version Number: v1.3.97-2
Reproducible in staging?: Y
Reproducible in production?: N
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause-Internal Team
Slack conversation: @
Action Performed:
Precondition:
Create IOU with the receipt as employee

Log in as the workspace admin
Navigate to the workspace chat with the employee
Navigate to the request conversation and fix the errors as the admin

Expected Result:
The admin is able to edit the missing information. Nothing strange doesn't happen.
Actual Result:
The admin is able to edit the missing information. Nothing strange doesn't happen.
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android: Native
[ ] Android: mWeb Chrome
[ ] iOS: Native
[ ] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[ ] MacOS: Desktop

Screenshots/Videos
Add any screenshot/video evidence
https://github.com/Expensify/App/assets/115492554/d15d429b-9e95-447b-a774-28bc1f9a1ed3

View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~0196a9e3104ad62434
Upwork Job ID:<PHONE_NUMBER>643566592
Last Price Increase: 2023-11-09

:wave: Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open StagingDeployCash deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

Identify the pull request that introduced this issue and revert it.
Find someone who can quickly fix the issue.
Fix the issue yourself.

git bisect weirdly did not help here, trying some other ways

It feels like this might be related? https://github.com/Expensify/App/pull/28793
I coudl replicate this on local for a moment and now I can't anymore so weird stuff is happening

okay confirmed, removing src/components/FlatList/index.web.js (which was added in #28793) fixes this. The PR mentions that there will be "glitches" until an upstream PR is fixed, I think we might want to revert until that time? Will copy this on the PR.

Yes, I agree. I think we need to revert as these glitches are not minor.

The PR that caused this ended up getting reverted. Removing the deploy blocker label.

Closing, will handle on the updated PR for https://github.com/Expensify/App/issues/23220


Add Uno Platform

https://github.com/MartinZikmund/awesome-uno-platform
The list gathers most useful resources for developers working with Uno Platform.
Reviewed PRs

https://github.com/sindresorhus/awesome/pull/2509#issuecomment-1463688010
https://github.com/sindresorhus/awesome/pull/2482#issuecomment-1463745158

By submitting this pull request I confirm I've read and complied with the below requirements 🖖
Requirements for your pull request

[x] Don't open a Draft / WIP pull request while you work on the guidelines. A pull request should be 100% ready and should adhere to all the guidelines when you open it. Instead use #2242 for incubation visibility.
[x] Don't waste my time. Do a good job, adhere to all the guidelines, and be responsive.
[x] You have read and understood the instructions for creating a list.
[x]  You have to review at least 2 other open pull requests.
Try to prioritize unreviewed PRs, but you can also add more comments to reviewed PRs. Go through the below list when reviewing. This requirement is meant to help make the Awesome project self-sustaining. Comment here which PRs you reviewed. You're expected to put a good effort into this and to be thorough. Look at previous PR reviews for inspiration. Just commenting “looks good” or simply marking the pull request as approved does not count! You have to actually point out mistakes or improvement suggestions. Comments pointing out lint violation are allowed, but does not count as a review.
[x] This pull request has a title in the format Add Name of List. It should not contain the word Awesome.

✅ Add Swift
✅ Add Software Architecture
❌ Update readme.md
❌ Add Awesome Swift
❌ Add swift
❌ add Swift
❌ Adding Swift
❌ Added Swift

[x] Your entry here should include a short description about the project/theme of the list. It should not describe the list itself. The first character should be uppercase and the description should end in a dot. It should be an objective description and not a tagline or marketing blurb.

✅ - [iOS](…) - Mobile operating system for Apple phones and tablets.
✅ - [Framer](…) - Prototyping interactive UI designs.
❌ - [iOS](…) - Resources and tools for iOS development.
❌ - [Framer](…)
❌ - [Framer](…) - prototyping interactive UI designs

[x] Your entry should be added at the bottom of the appropriate category.
[x]  The title of your entry should be title-cased and the URL to your list should end in #readme.

Example: - [Software Architecture](https://github.com/simskij/awesome-software-architecture#readme) - The discipline of designing and building software.

[x] The suggested Awesome list complies with the below requirements.

Requirements for your Awesome list

[x] Has been around for at least 30 days.That means 30 days from either the first real commit or when it was open-sourced. Whatever is most recent.
[x]  Run awesome-lint on your list and fix the reported issues. If there are false-positives or things that cannot/shouldn't be fixed, please report it.
[x]  The default branch should be named main, not master.
[x] Includes a succinct description of the project/theme at the top of the readme. (Example)

✅ Mobile operating system for Apple phones and tablets.
✅ Prototyping interactive UI designs.
❌ Resources and tools for iOS development.
❌ Awesome Framer packages and tools.

[x] It's the result of hard work and the best I could possibly produce.
If you have not put in considerable effort into your list, your pull request will be immediately closed.
[x] The repo name of your list should be in lowercase slug format: awesome-name-of-list.

✅ awesome-swift
✅ awesome-web-typography
❌ awesome-Swift
❌ AwesomeWebTypography

[x]  The heading title of your list should be in title case format: # Awesome Name of List.

✅ # Awesome Swift
✅ # Awesome Web Typography
❌ # awesome-swift
❌ # AwesomeSwift

[x] Non-generated Markdown file in a GitHub repo.
[x] The repo should have awesome-list & awesome as GitHub topics. I encourage you to add more relevant topics.
[x] Not a duplicate. Please search for existing submissions.
[x] Only has awesome items. Awesome lists are curations of the best, not everything.
[x] Does not contain items that are unmaintained, has archived repo, deprecated, or missing docs. If you really need to include such items, they should be in a separate Markdown file.
[x] Includes a project logo/illustration whenever possible.

Either centered, fullwidth, or placed at the top-right of the readme. (Example)
The image should link to the project website or any relevant website.
The image should be high-DPI. Set it to maximum half the width of the original image.

[x] Entries have a description, unless the title is descriptive enough by itself. It rarely is though.
[x] Includes the Awesome badge.

Should be placed on the right side of the readme heading.

Can be placed centered if the list has a centered graphics header.

Should link back to this list.

[x] Has a Table of Contents section.

Should be named Contents, not Table of Contents.
Should be the first section in the list.
Should only have one level of nested lists, preferably none.
Must not feature Contributing or Footnotes sections.

[x] Has an appropriate license.

We strongly recommend the CC0 license, but any Creative Commons license will work.

Tip: You can quickly add it to your repo by going to this URL: https://github.com/<user>/<repo>/community/license/new?branch=main&template=cc0-1.0 (replace <user> and <repo> accordingly).

A code license like MIT, BSD, Apache, GPL, etc, is not acceptable. Neither are WTFPL and Unlicense.
Place a file named license or LICENSE in the repo root with the license text.
Do not add the license name, text, or a Licence section to the readme. GitHub already shows the license name and link to the full text at the top of the repo.

[x] To verify that you've read all the guidelines, please comment on your pull request with just the word unicorn.
[x] Has contribution guidelines.

The file should be named contributing.md. Casing is up to you.
It can optionally be linked from the readme in a dedicated section titled Contributing, positioned at the top or bottom of the main content.
The section should not appear in the Table of Contents.

[x] All non-important but necessary content (like extra copyright notices, hyperlinks to sources, pointers to expansive content, etc) should be grouped in a Footnotes section at the bottom of the readme. The section should not be present in the Table of Contents.
[x] Has consistent formatting and proper spelling/grammar.

The link and description are separated by a dash. Example: - [AVA](…) - JavaScript test runner.
The description starts with an uppercase character and ends with a period.
Consistent and correct naming. For example, Node.js, not NodeJS or node.js.

[x] Does not use hard-wrapping.
[x] Does not include a CI (e.g. GitHub Actions) badge.You can still use a CI for linting, but the badge has no value in the readme.
[x] Does not include an Inspired by awesome-foo or Inspired by the Awesome project kinda link at the top of the readme. The Awesome badge is enough.

Go to the top and read it again.

unicorn

Hey @MartinZikmund 👋
So much like the last PR I reviewed, I love discovering new platforms and excited to explore Uno more after this.
In terms of comments, despite the request for more than just "good job!", I really can't provide any critical feedback - you seem to have met all of the requirements for the PR and then some.
Excited to explore Uno and hope the PR gets merged 👏

Thank you very much @andrewdmaclean!

There is no description for the "Visual Studio for Uno Platform" (Imagine *nix developer, who doesn't know, what is the MSVS).
"Contributing" section is not necessary. contributing.md file is enough.

@artiomn Thank you for the review! Addressed the first point, as for the second I prefer to keep the section there, even though it is optional 👍

It looks bad to have both an image and header text that sayd "Awesome Uno". Pick one. You could for example have "Awesome Uno" in centered text and above it, the coored icon (without text).

Uno Platform in Uno Platform is an open-source UI Platform for building single-codebase should be linkified to its website.

❯ awesome-lint https://github.com/MartinZikmund/awesome-uno-platform
✖ Linting

  readme.md:65:57
  ✖  65:57   List item description must end with proper punctuation  remark-lint:awesome-list-item
  ✖  99:135  List item description must end with proper punctuation  remark-lint:awesome-list-item

  2 errors

@sindresorhus thank you for the review and tips, I have adjusted all of the above, hopefully should all be correct now!

Uno Platform website => Website
Uno Platform documentation => Documentation
Fix cases of incorrect capitalization: Figma File to use with => Figma file to use with

Tweet: https://twitter.com/awesome__re/status/1757522804592042119


Refactor score calculations to handle null values in test cases

Context
Ensure overall scores for PNI constituent scores are null if any of the individual scores are null
NB. This appears to alter the overall PNI risk score.
Changes in this PR
Updated IndividualNeedsScores calculation logic to integrate a new extension function that checks for null values in data class properties. Adjusted parameterized tests accordingly to ensure robustness in scenarios with partial data, improving the validation of score computations.
Release checklist
Release process documentation
As part of our continuous deployment strategy we must ensure that this work is
ready to be released once merged.
Pre-merge

[ ] There are changes required to the Accredited Programmes UI for this change to work...

[ ] ... and they been released to production already

Post-merge

[ ] Manually approve release to preprod
[ ] Manually approve release to prod

Can you add ticket number to your commit message, please.
Possibly squash commits into one, unless there is a need to be in separate commits?


EveOnline Different Scopes

Hi, is there a way to request different scopes using the EveOnline provider?
I think that these are needed for example to get a refresh token and also to be able to get different data from the CREST API.
I can see that the Scopes object in the EveOnlineAuthenticationOptions class has a private setter and the member variable is set to an empty list. This means at present it is not possible to add additional scopes (which may be by design).
In the future I understand that additional scopes will be used to get different data from the CREST API. One example of this is the "publicData" scope.
Please let me know if there is a way at present to do this.
Thanks.
References
http://eveonline-third-party-documentation.readthedocs.org/en/latest/sso/refreshtokens/
http://eveonline-third-party-documentation.readthedocs.org/en/latest/crest/authentication/

Update: I can see that code exists in EveOnlineAuthenticationHandlerto look for a refresh token and add it to the claims but I cannot see a way to request the token at this time. Thanks.

The Scopes property is readonly, but it is a List so you can add items, remove items etc.
Here is an example of how to do it for Facebook:
http://www.oauthforaspnet.com/providers/facebook/
Have a look under the section "Request extra permissions". Like I said, this particular example is for Facebook, but the same principle applies.

Thanks. I had structured my code incorrectly. Following the FB example worked perfectly.

:+1:


Add default styling for tables

Fixes

Fixes #225  by @TimidRobot
Description
Currently, there are no default styling for markdown tables.
This new Lektor plugin uses the required Bootstrap classes - thead-dark and table table-striped.
Screenshots

Checklist

[x] My pull request has a descriptive title (not a vague title like Update index.md).
[x] My pull request targets the master branch of the repository.
[x] My commit messages follow best practices.
[x] My code follows the established code style of the repository.
[ ] I added tests for the changes I made (if applicable).
[ ] I added or updated documentation (if applicable).
[x] I tried running the project locally and verified that there are no
visible errors.

Developer Certificate of Origin

Developer Certificate of Origin
Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.

Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

Thanks for the suggestion @hugosolar
Is manual css an option or a compromise?
Also, if I were to create a plugin, it wouldn't cover just tables. Maybe I could generalize for a tag and the bs4 class required. This basically, looking for a specific tag and adding the class to it, same as the jquery code but the better way as you suggested.

I think the plugin is a good idea and would potentially be useful to others as well.

@TimidRobot I had pushed the plugin here!


ie

For ie it not work right?

As you know, for IE always is a good idea to load polyfills, see some
example here:

https://github.com/jherax/proxy-storage#shimming-polyfills

I will add that section to the README.md
Thanks for your comment !! :)
2017-05-21 15:11 GMT-06:00 Rodrigo Porcionato Alves <
<EMAIL_ADDRESS>
For ie it not work right?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/jherax/array-sort-by/issues/1, or mute the thread
https://github.com/notifications/unsubscribe-auth/AFL_4b6qJQKiQPD3LwBZAaGwKpqczHfjks5r8KiQgaJpZM4Nhud6
.

--
Cordialmente,
David Rivera
Wordpress https://jherax.wordpress.com/ | Linkedin
https://www.linkedin.com/in/jherax | GitHub http://jherax.github.io/

Could you please report the error from the console? Because in this project the only features used by Babel are Array.prototype.sort and Object.defineProperty (from Webpack)

Although this project is transpiled with Babel, some features are missing for IE (e.g. Object.assign).
That's why for IE always is a good idea to load polyfills, see some examples here:
https://github.com/jherax/proxy-storage#shimming-polyfills
I will add that section to the README.md
Thanks for your comment!! :)


Fix not accepting connection hang on mono

SaeaLayer used single SocketAsyncEventArgs for both
accepting new connection and receiving data on the connection.
There is probably a race condition in mono connected to this use case.
Splitting AcceptAsync and ReceiveAsync arguments solves the issue
in my test.

This should solve issue #52

Is there a new NuGet release available to resolve this issue?
The most recent release appears to be from January: https://www.nuget.org/packages/Nowin/0.22.2

Just published 0.23.0. Sorry for taking it so long.

Awesome, thanks


Update migrate-from-hub-spoke-topology.md

Technical corrections, minor updates to spelling, grammar and capitalisation.

@adstuart : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#sign-off


suggestion Request

is it possible to make sidebar re sizable?

can we make the sidebar resizeable?

nope, unfortunately not


Crashes horribly when function names are invalid identifiers

See mciparelli/co-redis#16
Small test case to reproduce:
const thenify = require('thenify')

function testMe () {}

Object.defineProperty(testMe, 'name', { value: 'test-me' })

thenify(testMe)

Also reported here: mciparelli/co-redis#16

it's like they are intentionally trying to break it... :P
what's your solution here?

Reverting back to<EMAIL_ADDRESS>🐎  is the current fix

Hehe, it seems that way 😆
I would actually prefer this being fixed on both ends, we could probably implement a quick check for valid names here, and if the name is invalid we could drop the name...
Another solution would be to utilize the same check that they are using, and in newer engines (e.g. Node.js >4) set the name by using Object.defineProperty instead of using eval. That way this wouldn't have blown up...

a function's .name containing - and other chars is totally valid from a language point of view, so -1 on having to change that in the redis libs.

I'm using eval to build cowrap for keeping the function.length, but what's purpose of this using eval here? keeping the function name?


calories, emotionalized

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 600s
close stale after: 24 hours
[pullrequest]
requests per hour: 20
deps=[c,e]

/trunk merge


Convert Meta to JObject.  Merge API responses into model instances

#76 Convert Meta from Dictionary to JObject to make the Patch object consistent and allow more flexible Meta pathing.

The 84a776b commit fixes #75 if the HasManyIds property is accessed after a create or update.  84a776b also merges the API response into the model instance passed into the Update/Create method, which allows the consumer of the Update method to access updated eTag, timestamp, or relationship information.  This also eliminates possible consumer bugs where the consumer accesses properties on the unmanaged entity after a Create

84a776b might also fix #36


Paper: Special issue of the Data Intelligence Journal on “Canonical Workflow Frameworks for Research”

Working title: The Specimen Data Refinery - A canonical workflow framework and FAIR Digital Object approach to speeding up digital mobilisation of natural science collections
Due date: full paper of maximally 8 pages submitted by 1 August 2021.

Accepted and preprint available here: https://doi.org/10.1162/dint_a_00134

Published


Adding an E2E test that runs a full CAPL cluster test (default, k3s, & rke2) on merging to main

What type of PR is this?
/kind testing

What this PR does / why we need it:
This PR contains the following changes:

New e2e tests for 3 flavors default, k3s, and rke2
New feature to allow selecting specific e2e tests using --selector LABEL flag (check testing docs for more detail)
A complete e2e test (All the e2e test) that runs when a PR is merged into the main branch
Adding some catch blocks for debugging

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
TODOs:

[ ] squashed commits
[ ] includes documentation
[ ] adds unit tests
[ ] adds or updates e2e tests

There's quite a lot of duplication where we have multiple files creating the same resources in different directories. I'll try to refactor this so we have all of them in one place.


[GitHub] Unable to list all issues

Extension
https://www.raycast.com/raycast/github
Description
Despite creating a token with full permissions, only issues created by myself are listed.
I'm not sure if this is related to a private organization repo, but I've created a token with full permission:

Steps To Reproduce
No special steps necessary.
Current Behaviour
You can see in the right hand side, only my avatar shows because these are issues owned and created by me. I'm unable to see other open issues created by my team.
Expected Behaviour
All issues should be seen

Thanks for the feedback. This has been confusing other users as well (like here). Let me check with the team to see what improvements we can make.

After talking with the team, we can see how it's confusing. We'll see how we can change the GitHub commands to make the extension clearer. Stay tuned!

I've seen this is actually a duplicate of issue #4058, so I'll mark it as such.

@thomaslombart This is not the same as #4058   In an organization repo, no matter what, I am only able to see PRs by me. There are no filters and cant see anything from my team.

It is the same issue underlying it. The Search Pull Requests command was built to help you search your PRs without having the PRs from your team or other PRs in mind. However, after discussing with the team, we realized it was confusing and so we'll revamp the way these commands work. Since both issues are based on the fact that you can only see your PRs, we prefer having one to avoid having too many issues in the repository.


Pr/1002

Here is another approach which doesn't touch _normalize and correctly writes vertical-align directions.

Please adjust the PR title and PR description - you may also want to reword the commit message.


Create implementation of IRandomNumberGenerator that is cryptographically secure

Currently FRP is using only Random() which is cryptographically unsecure. It is going to be flagged as major flaw by a lot of static code analyzers (i.e veracode). Adding new interface to handle random number generation in more secure way would be great.
Also there should be a way to exchange currently used random number generator.

Hi,

Also there should be a way to exchange currently used random number generator.

That's already possible.
You can pass it as an argument of the Of() method and the code uses it everywhere.
If someone has written a new RNG (it has to implement the interface IRandomNumberGenerator, you could instantiate it (e.g. var rng = new SecureRandomNumberGenerator()) and pass it (Out.Of(rng)...).
I think, it makes sense to implement a cryptographically secure one (probably based on RNGCryptoServiceProvider because it's already part of .Net) as part of the package, so that the user has the choice and does not have to implement it himself/herself. But I'm not sure about making the cryptographically secure one the default option because of performance reasons.


refactor http parser implementation in http_inspector

Commit Message: refactor http parser implementation in http_inspector
Additional Description:
This update replaces the usage of the legacy http_parser in http_inspector with the LegacyHttpParserImpl as the first step in transitioning to the Balsa parser (part of #36433). The Parser interface is used with LegacyHttpParserImpl to preserve the current behaviour of http_parser.
Risk Level: Low (no behavioural change)
Testing: All the http_inspector tests have passed (bazel test //test/extensions/filters/listener/http_inspector/...)
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]

/wait on CI
@wbpcode please remember to use wait tags if you're not reviewing due to CI failures, to keep this off the stale dashboard

/retest

FWIW we had a permafail on main so this will almost certainly need a main merge now

FWIW we had a permafail on main so this will almost certainly need a main merge now

Thanks for the info, will merge the changes from main now.

Code coverage for source/extensions/filters/listener is lower than limit of 96.6 (96.0)
Code coverage for source/extensions/filters/listener/http_inspector is lower than limit of 96.6 (86.2)

Hi, please check the coverage issue of CI. Thanks. The code LGTM, and thanks for this contribution!
/wait

Code coverage for source/extensions/filters/listener is lower than limit of 96.6 (96.0)
Code coverage for source/extensions/filters/listener/http_inspector is lower than limit of 96.6 (86.2)

Hi, please check the coverage issue of CI. Thanks. The code LGTM, and thanks for this contribution!
/wait

working on adding more tests to increase coverage for http_inspector. will update the PR shortly.

@vamshi177 Thanks for your hard working. But we recently will cut a major release version, we could land the PR after that release. So, take it easy, it have enough time.
/wait


CompileBot fails julia 1.8

See e.g. failing job at https://github.com/JuliaPlots/Plots.jl/runs/6023176404?check_suite_focus=true.
Are there any ways to debug this ?

It seems like an upstream issue. It might be because of https://github.com/aminya/CompileBot.jl/commit/a88f7e3c8539bf8f30948c93cf475e226c2b89b8

I've re-run CI against<EMAIL_ADDRESS>and it still fails.
The scripts hangs at [ Info: Processsing the generated precompile signatures. I think the memory grows endlessly and the process crashes with ProcessSignaled(9) (no more memory available), after ~2h (it should only take ~5min to generate the precompilation statements).
I've ran julia --project -e 'include("deps/SnoopCompile/snoop_bot.jl")' with 1.8.0-beta3 locally, and the process ends without errors.
I seem to be able to reproduce this locally. Investigating this now ...

Clearly going further with the latest run (I've added 10GB swap in CI), but 5h 51m (build cancelled automatically) is a massive regression ...

Try excluding some tests from the test script and see if you can find the faulty test.
https://aminya.github.io/CompileBot.jl/dev/#Create-the-script-that-runs-snoop_bot-1

Might be related to julia being able to precompile more methods?
Ref: https://youtu.be/GnsONc9DYg0


Charts do not show up

As discussed in #170 I'm going to open a new issue for the following problem.
We're using angularjs-nvd3-directives inside of some Tabs. When the Tab, containing the chart is being shown by ng-show, the chart does not get redrawn correctly. The only solution is resizing the browser window/frame.
http://plnkr.co/edit/23UvXij6SiI9Gk4ZCjYu?p=preview
Is it possible to force the chart to redraw itself?

had the same issue, found using ng-if instead of ng-show resolved the issue

I had the same issue here. My solution was something different. I used the following callback in my chart's options:
                callback: function(chart) {                   chart.update();                 },
Apparently it's working well.


Adapt user/integration guide according to new flow with adyen-web-components

#324
Hint for review: Instead of checking the diff first, go all paths from the main readme for this branch, then you could follow diff.
Additional Todos:

[x] Check the main readme and check the part:https://github.com/commercetools/commercetools-adyen-integration#supported-payment-methods

[x] #328

[x] #326

@lojzatran docker badges redirect me into docker hub login page, can you check the link?

@lojzatran docker badges redirect me into docker hub login page, can you check the link?

I guess you need to log in to docker hub to view the images.

@lojzatran docker badges redirect me into docker hub login page, can you check the link?

I guess you need to log in to docker hub to view the images.

No, for example, check this link: https://hub.docker.com/r/commercetools/commercetools-adyen-integration-extension

@lojzatran docker badges redirect me into docker hub login page, can you check the link?

I guess you need to log in to docker hub to view the images.

No, for example, check this link: https://hub.docker.com/r/commercetools/commercetools-adyen-integration-extension

Oh right https://github.com/commercetools/commercetools-adyen-integration/pull/329/commits/ea418414bfc1ae8a663ea36d206b42070e5e0291

@lojzatran docker badges redirect me into docker hub login page, can you check the link?

I guess you need to log in to docker hub to view the images.

No, for example, check this link: https://hub.docker.com/r/commercetools/commercetools-adyen-integration-extension

Oh right ea41841

Cool,  but please check all badges, also there is a badge in the extension readme and integration readme 😉

@lojzatran docker badges redirect me into docker hub login page, can you check the link?

I guess you need to log in to docker hub to view the images.

No, for example, check this link: https://hub.docker.com/r/commercetools/commercetools-adyen-integration-extension

Oh right ea41841

Cool, but please check all badges, also there is a badge in the extension readme and integration readme 😉

Damn, so many badges 😄 Thanks: https://github.com/commercetools/commercetools-adyen-integration/pull/329/commits/b17ea9b66ad845c150b770675393fcb8e4a8ef43


How do I run this

How do I run this? How do I put up a server for single player

i believe you'll need docker to run a server but I'm not 100% sure you should check his instructions tho maybe that will help solve your problem.

use docker


Module shadowing

To add deprecation warnings, several public sub modules were 'shadowed' by moving them to a private file (prefixed with _) and adding a stub public module in their place that issued a deprecation warning then replaced itself with the private module. Here is one example:
https://github.com/asdf-format/asdf/blob/6b4701277bb25c1d4e8583b88bc2b125be9a36d6/asdf/types.py#L1-L26
This example illustrates one issue with this approach where certain objects needed special handling to allow doc references to work.
An alternative approach was used for asdf.tests.helpers.
https://github.com/asdf-format/asdf/blob/6b4701277bb25c1d4e8583b88bc2b125be9a36d6/asdf/tests/helpers.py#L1-L26
That has several benefits including:

easier control over what attributes are exposed
a hook to allow deprecation warnings to be issued for every attribute access and not just during module import (which can sometimes result in retrieval of a cached import and no deprecation warning).

This PR updates asdf.types, asdf.type_index and asdf.resolver module shadowing to align with the approach taken with asdf.tests.helpers.

The new warnings in astropy:
https://github.com/asdf-format/asdf/actions/runs/4265734101/jobs/7425422437#step:9:300
were likely not seen because of the entry point warning filtering for astropy.io.misc hiding the initial types deprecation warning:
https://github.com/asdf-format/asdf/blob/6b4701277bb25c1d4e8583b88bc2b125be9a36d6/asdf/entry_points.py#L68-L71
Because asdf._types replaced asdf.types subsequent use of asdf.types (even with warnings cleared) did not emit a new deprecation warning. With this PR, the use of asdf.types.format_tag causes a new asdf.types deprecation to be issued (the new warning seen here).

The errors in roman_datamodels appear unrelated:
https://github.com/asdf-format/asdf/actions/runs/4265734101/jobs/7425422199#step:9:247
and may be due to:
https://github.com/spacetelescope/roman_datamodels/pull/125
Independent tests are needed.

The weldx errors:
https://github.com/asdf-format/asdf/actions/runs/4265734101/jobs/7425423059#step:9:432
are due to additional issues of the existing deprecation warning. This time the warning is occurring during schema validation which is turned into an error by pytest_asdf:
https://github.com/asdf-format/asdf/blob/6b4701277bb25c1d4e8583b88bc2b125be9a36d6/pytest_asdf/plugin.py#L249-L251

I added a warning filter (treating AsdfDeprecationWarning as default instead of error) during schema validation. This should fix the weldx failures (but not the root cause which is they are using old style validators).

It is unclear to me why the docs fail to properly include asdf.testing.helpers.format_tag (and instead generate a warning and list, but fail to link to the function) with these changes but the modifications in commit https://github.com/asdf-format/asdf/pull/1445/commits/9f28dbb58d80d59bf065294e5c24a8afa3addb92 allow them to build.
The warnings issued (without the changes in the above linked commit) are:
asdf/docs/asdf/developer_api.rst:220: WARNING: autosummary: stub file not found 'asdf.testing.helpers.format_tag'. Check your autosummary_generate setting.
asdf/docs/asdf/developer_api.rst:224:<autosummary>:1: WARNING: py:obj reference target not found: asdf.testing.helpers.format_tag

The weldx errors: https://github.com/asdf-format/asdf/actions/runs/4265734101/jobs/7425423059#step:9:432 are due to additional issues of the existing deprecation warning. This time the warning is occurring during schema validation which is turned into an error by pytest_asdf:
https://github.com/asdf-format/asdf/blob/6b4701277bb25c1d4e8583b88bc2b125be9a36d6/pytest_asdf/plugin.py#L249-L251

thank you for looking into this
once 2.15 is out I plan to build everything on >=2.15 and remove deprecated calls (including the legacy validation extension)

Why is astropy failing in this branch but not with the changes on master?

This comment describes the changes with respect to astropy: https://github.com/asdf-format/asdf/pull/1445#issuecomment-1444386535
In brief, the change in module shadowing creates more warnings with this PR.
For this example:
import warnings

import asdf

with warnings.catch_warnings():
    warnings.simplefilter('ignore')
    import asdf.types

asdf.types.format_tag('a', 'b', 'c', 'd')

run against master produces
AsdfDeprecationWarning: asdf.types.format_tag is deprecated. Please use asdf.testing.helpers.format_tag

with this PR there is an additional warning:
AsdfDeprecationWarning: asdf.types.format_tag is deprecated. Please use asdf.testing.helpers.format_tag
AsdfDeprecationWarning: asdf.types is deprecated Please see the new extension API https://asdf.readthedocs.io/en/stable/asdf/extending/converters.html

In brief, the change in module shadowing creates more warnings with this PR.

Yes, as noted by https://github.com/asdf-format/asdf/pull/1445#issuecomment-1448659885 you changed the warning message for format_tag. While annoying, its easily fixed by astropy/astropy#14474, which covers both versions of the warning.

In brief, the change in module shadowing creates more warnings with this PR.

Yes, as noted by #1445 (comment) you changed the warning message for format_tag. While annoying, its easily fixed by astropy/astropy#14474, which covers both versions of the warning.

I see no change in the format of the warning for format_tag. Can you provide an example?

I see no change in the format of the warning for format_tag. Can you provide an example?

With the master branch of asdf the message for format_tag emitted in astropy is filtered by https://github.com/astropy/astropy/blob/38145e2c2c6a024eeec010e91dd95407fa3d17c4/astropy/io/misc/asdf/tags/tests/helpers.py#L20-L25. That is it has the form:
r"asdf.types.format_tag is deprecated.*",

The origin point of the deprecation message is here: https://github.com/asdf-format/asdf/blob/056c3ffc8639eb864553fbb967abb3d49a09cf17/asdf/_types.py#L21-L24
With the changes in this PR two warning messages get raised for the from asdf.types import format_tag, first the one originating here: https://github.com/braingram/asdf/blob/125915dc78c831cec96eab86c0ee913c6bb1b37e/asdf/types.py#L8-L13 followed by the one being filtered for in astropy. This means you have changed the warnings being issued by format_tag.
It is a bit redundant to issue two warnings for format_tag, especially with the first message being different from the original message being issued.

I see no change in the format of the warning for format_tag. Can you provide an example?

astropy/astropy#14474 was just merged, and it modified the filter to catch both warning messages together so the question is moot.


Security?

Why does caddy run as root, again? Why did you remove the separation with 0.9.3?
https://github.com/abiosoft/caddy-docker/commit/be00e81ea112799ee654243fb6fb3e02307cf898

Permission issues primarily with mounted volumes.

You need to sync the group and group ids of both containers. e.g. on debian based boxes www-data has a gid of 33, on alpine it's 82 https://git.alpinelinux.org/cgit/aports/tree/main/apache2/apache2.pre-install.

I definitely prefer it to run without root. But after having to deal with multiple permission issues, I had to revert.
If you have some time on your hands, do you mind raising a PR ?
Thanks.


typechecker allows class alias to value constructor

This should be disallowed, I believe:
class X {
    shared new instance {}
}
class XInstance() => X.instance();

Fixed. Thanks.


RPED

About the PR
adds the RPED as a science tech. For making all of your machine upgrading woes just a bit better.
the actual place in the science tree (like most things) is a bit arbitrary and should probably be changed.
Closes #3044
Screenshots

Changelog

:cl:

add: Added the Rapid Parts Exchange Device. Just load it up with parts and click on a machine to instantly upgrade it.

Does it require the maintenance panel to be open to replace parts? It didn't look like it did when I looked at the AfterInteract

Does it require the maintenance panel to be open to replace parts? It didn't look like it did when I looked at the AfterInteract

It doesn't. Is that a relevant feature from 13 that matters? I feel like needing a screwdriver is a bit superfluous.

 The idea was the RPED can't actually replace parts if the machine isn't 'open' to get at those parts. If that functionality is not desired it's not really a big deal :woman_shrugging:

It is how it worked in SS13 for the RPED (not the stupid BRPED that should never be added). The idea was the RPED can't actually replace parts if the machine isn't 'open' to get at those parts.

If you use an RPED with the panel CLOSED, it will tell you what parts are inside. With the panel open, it'll try to swap lower components for higher. That's the purpose of the screwdriver, really.

If you use an RPED with the panel CLOSED, it will tell you what parts are inside. With the panel open, it'll try to swap lower components for higher. That's the purpose of the screwdriver, really.

The one thing worth noting is that not all machines have wire panels. Maybe I'll keep that functionality as an alt verb.

If you use an RPED with the panel CLOSED, it will tell you what parts are inside.

I was a fan of the idea that when examining an upgraded machine, the examine tooltip would tell you what upgraded parts are in it and what they were doing to the machine. see https://github.com/space-wizards/space-station-14/issues/11530

If you use an RPED with the panel CLOSED, it will tell you what parts are inside.

I was a fan of the idea that when examining an upgraded machine, the examine tooltip would tell you what upgraded parts are in it and what they were doing to the machine. see #11530

Showing average rating definitely isnt that difficult but showing effects would have to be done on a per-machine basis. I'll look into showing part ratings on examine though.

fixed the thing that was causing test fails on this for like literal weeks that i just somehow didn't notice.


when stepping through a different cell than the one that started debugging, clicking run will deadlock the kernel

set a break point in a function in cell 1
call that function from cell 2
debug cell 2 and wait for it to hit the breakpoint
click run on cell 1
:bug: kernel seems to be stuck

we should disable the run button if already debugging. I thought this was already the case.

Closing this issue, as the cell execution does get queued, and the Run button turns into a stop button, meaning it can be intterrupted/stopped.
Also this means the cell execution has been queued,
Hence disabling might not be right, as we're queueing it,
Also possible user might want to queue instead of having to wait for debug to complete.
Closing this as kernel isn't stuck, but debugger has paused and this is by design.


Fixes drag and drop issues

Submission Checklist
Required

[x] The pull request title clearly contains the name of the sheet I am editing.
[ ] The pull request title clearly states the type of change I am submitting (New Sheet/New Feature/Bugfix/etc.).
[ ] The pull request makes changes to files in only one sub-folder.
[ ] The pull request does not contain changes to any json files in the translations folder (translation.json is permitted)

New Sheet Details

The name of this game is: <   >  (i.e. Dungeons & Dragons 5th Edition, The Dresden Files RPG)

The publisher of this game is: <   > (i.e. Wizards of the Coast, Evil Hat)

The name of this game system/family is: <   > (i.e. Dungeons & Dragons, FATE)

[ ] I have followed the Character Sheets Standards when building this sheet.

[ ] This sheet has been made on behalf of, or by, the game's publisher.
[ ] This game is not a traditionally published game, but a copy of the game rules can be purchased/downloaded/found at: <   >
[ ] This sheet is for an unofficial fan game, modification to an existing game, or a homebrew system.

Changes / Description

Bug Fixes

Dropped NPCs will now show only the sections they should show
Fixed an error that caused dropped repeating items to be dropped twice (e.g. Plans)

Character Sheet Info Roll20 Internal Use only.


ht: fix gcc7 compilation

Motivation for this change
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

Here we go.

@GrahamcOfBorg build ht

Failure on x86_64-darwin (full log)
Partial log (click to expand)
Package ‘ht-2.1.0’ in /Users/graham/nix-borg/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/grahamc-ndnd/pkgs/applications/editors/ht/default.nix:21 is not supported on ‘x86_64-darwin’, refusing to evaluate.

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowBroken = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowBroken = true; }
to ~/.config/nixpkgs/config.nix.

Success on x86_64-linux (full log)
Partial log (click to expand)
make[2]: Leaving directory '/tmp/nix-build-ht-2.1.0.drv-0/ht-2.1.0'
make[1]: Leaving directory '/tmp/nix-build-ht-2.1.0.drv-0/ht-2.1.0'
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/5cbd1dbzc6r8hxgfzlaqsvdi6r4p7yqm-ht-2.1.0
shrinking /nix/store/5cbd1dbzc6r8hxgfzlaqsvdi6r4p7yqm-ht-2.1.0/bin/ht
strip is /nix/store/b0zlxla7dmy1iwc3g459rjznx59797xy-binutils-2.28.1/bin/strip
stripping (with command strip and flags -S) in /nix/store/5cbd1dbzc6r8hxgfzlaqsvdi6r4p7yqm-ht-2.1.0/bin
patching script interpreter paths in /nix/store/5cbd1dbzc6r8hxgfzlaqsvdi6r4p7yqm-ht-2.1.0
checking for references to /tmp/nix-build-ht-2.1.0.drv-0 in /nix/store/5cbd1dbzc6r8hxgfzlaqsvdi6r4p7yqm-ht-2.1.0...
/nix/store/5cbd1dbzc6r8hxgfzlaqsvdi6r4p7yqm-ht-2.1.0

Success on aarch64-linux (full log)
Partial log (click to expand)
make[2]: Leaving directory '/build/ht-2.1.0'
make[1]: Leaving directory '/build/ht-2.1.0'
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/vcns3kp5jn2q9vyh5nphbaydnwc0m425-ht-2.1.0
shrinking /nix/store/vcns3kp5jn2q9vyh5nphbaydnwc0m425-ht-2.1.0/bin/ht
strip is /nix/store/lvx1acn1ig1j2km8jds5x3ggh3f2wa8v-binutils-2.28.1/bin/strip
stripping (with command strip and flags -S) in /nix/store/vcns3kp5jn2q9vyh5nphbaydnwc0m425-ht-2.1.0/bin
patching script interpreter paths in /nix/store/vcns3kp5jn2q9vyh5nphbaydnwc0m425-ht-2.1.0
checking for references to /build in /nix/store/vcns3kp5jn2q9vyh5nphbaydnwc0m425-ht-2.1.0...
/nix/store/vcns3kp5jn2q9vyh5nphbaydnwc0m425-ht-2.1.0

also backported a32fcfd0dad

Success on aarch64-linux (full log)
Partial log (click to expand)
/nix/store/vcns3kp5jn2q9vyh5nphbaydnwc0m425-ht-2.1.0

Failure on x86_64-darwin (full log)
Partial log (click to expand)
Package ‘ht-2.1.0’ in /Users/graham/nix-borg/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/grahamc-ndnd/pkgs/applications/editors/ht/default.nix:21 is not supported on ‘x86_64-darwin’, refusing to evaluate.

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowBroken = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowBroken = true; }
to ~/.config/nixpkgs/config.nix.

Success on x86_64-linux (full log)
Partial log (click to expand)
make[2]: Nothing to be done for 'install-data-am'.
make[2]: Leaving directory '/tmp/nix-build-ht-2.1.0.drv-0/ht-2.1.0'
make[1]: Leaving directory '/tmp/nix-build-ht-2.1.0.drv-0/ht-2.1.0'
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/5cbd1dbzc6r8hxgfzlaqsvdi6r4p7yqm-ht-2.1.0
shrinking /nix/store/5cbd1dbzc6r8hxgfzlaqsvdi6r4p7yqm-ht-2.1.0/bin/ht
strip is /nix/store/b0zlxla7dmy1iwc3g459rjznx59797xy-binutils-2.28.1/bin/strip
stripping (with command strip and flags -S) in /nix/store/5cbd1dbzc6r8hxgfzlaqsvdi6r4p7yqm-ht-2.1.0/bin
patching script interpreter paths in /nix/store/5cbd1dbzc6r8hxgfzlaqsvdi6r4p7yqm-ht-2.1.0
checking for references to /tmp/nix-build-ht-2.1.0.drv-0 in /nix/store/5cbd1dbzc6r8hxgfzlaqsvdi6r4p7yqm-ht-2.1.0...


Overwrite old reports in terminal by default

I thought that this script put a little too much into the terminal. This PR makes it so that only the most recent report is visible, which can be disabled with the new -n argument.

@Aluminite am I reading this correctly, that you used -n as an argument to specify old-style batch-mode continuous scroll printing?
That's not going to work because it conflicts with @Freaky's -n for dataset literals. I'm open to suggestions from the both of you for the best arguments for each improvement that don't conflict; I'm not too picky aside from wanting to default to "as much like system iostat arguments as possible."

This seems unusual behaviour for an iostat command - at the very least it should be opt-in instead of opt-out IMO.
This approach is also a bit too naive and doesn't cope with the number of datasets going down.

I quite like the idea of not having to use GNU watch to get an inplace display, but I don't really have a dog in the fight about whether it should be opt-in or opt-out.

Thanks @Aluminite , good stuff. Would you also add a keypress check, and exit if the user presses "q" while in -o mode, please?


Getting  message No previous version tag found, fallback to version 0.0.0 even though we have tagged everything

I  created a new branch to reset all the tags andmake sure  we tagging all our apps and libraries.
re-ran  the command to generate a changelog for all our apps/libs
Pushed all  changes and also made sure all the tags were pushed.
Merged everything  back into master.
Created  a  new branch from the new master branch.
Made 1  change  to a  core library.  and  ran the nx affected command to tag and add entries to change logs.
all my apps failed with :
🟠 No previous version tag found, fallback to version 0.0.0.
New version will be calculated based on all changes since first commit.
If your project is already versioned, please tag the latest release commit with onboarding-web-component-e2e-x.y.z and run this command again.
✔ tagging release onboarding-web-component-e2e-0.1.0
fatal: tag 'onboarding-web-component-e2e-0.1.0' already exists
Command failed: git tag -a onboarding-web-component-e2e-0.1.0 -m chore(release): 0.1.0
fatal: tag 'onboarding-web-component-e2e-0.1.0' already exists
This is correct as the tags exist. So not sure why the version command isnt picking up  the correct previous version.
any ideas around this?

Hi @BurtV, can you confirm that the last tag and the version defined in package.json are in sync? for example, if you tagged onboarding-web-component-e2e-0.1.0, the version in package.json should be 0.1.0.

Any updates on this? Also running into this issue.

It's hard to tell without replication but I think this can occur for the following reason, the tag was created but not targeting any mainBranch commit checksum. I would investigate more if I can dive into the Git history.

Ok here is a reproduction repo: https://github.com/jafaircl/semver-testing
When running nx run new-lib:version --releaseAs=minor on the attempt-new-minor-version branch, here is the error I get:
🟠 No previous version tag found, fallback to version 0.0.0.
New version will be calculated based on all changes since first commit.
If your project is already versioned, please tag the latest release commit with new-lib-x.y.z and run this command again.
✔ bumping version in /Users/jonathanfaircloth/Projects/semver-testing/packages/new-lib/package.json from 0.1.0 to 0.1.0
✔ outputting changes to /Users/jonathanfaircloth/Projects/semver-testing/packages/new-lib/CHANGELOG.md
✔ committing /Users/jonathanfaircloth/Projects/semver-testing/packages/new-lib/package.json and /Users/jonathanfaircloth/Projects/semver-testing/packages/new-lib/CHANGELOG.md and all staged files
✔ tagging release new-lib-0.1.0
fatal: tag 'new-lib-0.1.0' already exists

Command failed: git tag -a new-lib-0.1.0 -m chore(release): 0.1.0
fatal: tag 'new-lib-0.1.0' already exists

Error: Command failed: git tag -a new-lib-0.1.0 -m chore(release): 0.1.0
fatal: tag 'new-lib-0.1.0' already exists

    at ChildProcess.exithandler (node:child_process:397:12)
    at ChildProcess.emit (node:events:390:28)
    at maybeClose (node:internal/child_process:1062:16)
    at Socket.<anonymous> (node:internal/child_process:448:11)
    at Socket.emit (node:events:390:28)
    at Pipe.<anonymous> (node:net:687:12)

———————————————————————————————————————————————

>  NX   ERROR  Running target "new-lib:version" failed

  Failed tasks:

  - new-lib:version

  Hint: run the command with --verbose for more details.

Is it possible that using "squash and merge" to merge pull requests is causing it?

Is it possible that using "squash and merge" to merge pull requests is causing it? Or should we only be running the release command from the main branch?

Yes, I think this is the problem, the tag is created with a commit reference that disappears when you squash and merge. Tags are not updated on their own. IMO you should always version on the main branch.

Ok. My solution to this was to switch to the main branch, delete the tag for the release with git tag -d my-library-0.1.0 and then run  nx run my-library:version --releaseAs=minor once to create the 0.1.0 release. Now, when I try to create a 0.2.0 release, everything works as expected. Thanks for your help!


xgboost for prediction

when i use xgboost4j for prediction，i find a question:
i use two ways to load test file.
1)DMatrix testMat = new DMatrix(fArray, nrow, ncol);
fArray is the feature value array
2）DMatrix testMat = new DMatrix("data/xgboost/test.train");
the parameter is test file path and the file is libsvm format
after i do predcition operation,i find the prediction score is different.and the second way is the same with the way i use c++/shell interface like in demo package.
what's the difference between the two way of loading test file.especially how shoud i do in the firsrt way to get correct result? thank sincerely

Have you checked that both testMat have the same properties? (by comparing rows for instance)

first thak you for your reply.
i checke the row properties, it is the same in both testMat.
what else properties should i check.
i get the code from following class for the two way of loading test file:
https://github.com/dmlc/xgboost/blob/master/jvm-packages/xgboost4j/src/test/java/ml/dmlc/xgboost4j/java/DMatrixTest.java
i want to use the first way in my project, because the test instance is produced from RAM not from disk file.

i face the same problem. I Use libsvm format to train, when distribution the feature is numpy array, but the prediction is totally wrong.


Custom Prefix causes error

Hello,
I tried to define a custom prefix for hum, as it is described in the documentation:
add_filter('hum_redirect_base_e',
create_function('', 'return "https://ebird.org";'));

Unfortunately, this causes an error as create_function is deprecated.
Is there any other way to define a custom prefix?
Cf.: WordPress Support

As @willnorris mentioned in your other issue, a possible solution is with an anonymous function:
add_filter( 'hum_redirect_base_e', function($url, $path) {
    return "https://ebird.org";
}, 11, 2 );

or the classic way:
function custom_redirect_base_e( $url, $path ) {
    return "https://ebird.org";
}

add_filter( 'hum_redirect_base_e', 'custom_redirect_base_e', 11, 2 );

Thank you @pfefferle,
unfortunately the proposed functions don't seem tot work (contrary to the analogous redefining of the i-prefix for ISBN-search). I have tried these methods:
method 1
add_filter( 'hum_redirect_base_e', function($url, $path) {
    return "https://ebird.org/" . $path;
}, 9, 2 );

method 2
add_filter( 'hum_redirect_base_e', function($url, $path) {
   return "https://ebird.org";
}, 9, 2 );

method 3
function custom_redirect_base_e( $url, $path ) {
    return "https://ebird.org";
}
add_filter( 'hum_redirect_base_e', 'custom_redirect_base_e', 9, 2 );

```None of these methods brings me outside of my blog to the intended extrernal site.

Can you change the priority (9) to something higher, like for example 15 and re-try it?

redirect_types in your snippet above never gets called.  You can make it an anonymous function as well...
add_filter( 'hum_redirect_types', function($types) {
    $types[] = 'e';
    return $types;
});

And it looks like you should be able to use public functions withe code snippets plugin.  At least they show an example of that here.

Thank you very much, @willnorris,
I now have the following code inserted as snippet:
# Define redirect types
add_filter( 'hum_redirect_types', function($types) {
    $types[] = 'e';
    return $types;
}, 15, 2 );

# eBird
add_filter( 'hum_redirect_base_e', function($url, $path) {
    return "https://ebird.org/" . $path;
}, 15, 2 );

I am sorry, but this lines also don't work. I am still getting redirected to my blog, not to the external site.
Unfortunately, I am everything else than a PHP expert. So it seems, that I have to give up at this stage. I have managed to adapt the i custom prefix, which has already been defined in the code of the plugin. But obviously I can't create a new custom prefix. I will wait until the plugin gets updated in the future.

I don't have a working WordPress install anymore, so can't easily test this myself, so maybe Matthias can spot the error above.
One thing to note is that you modified the "hub_redirect_types" filter slightly from what I wrote.... you have it specified as taking two parameters, whereas it only takes one.  I don't recall how much of a problem that causes in WordPress.  The priority 15 shouldn't matter either way.
It's also worth noting that there is nothing to be updated in the plugin in the future (as far as this specific problem is concerned).  All of the hooks are there, it's just get them connected properly.

Thank you again, @willnorris,
I have now corrected the lines according to your original suggestion:
add_filter( 'hum_redirect_types', function($types) {
    $types[] = 'e';
    return $types;
});

This does change nothing, unfortunately. I understand that the plugin won't be updated in the future. But maybe at least the documentation should be corrected concerning the custom prefixes, because there is still an example there using deprecated WordPress functions which are causing an error.

Okay, I figured it out.  I did a clean local install of WordPress with only the hum and code snippets plugin.  The bug is that you're using the hum_redirect_base_e filter rather than hum_redirect_e.  The hum_redirect_base_* is for when you want to redirect all requests for a given base to a specific URL, without including the path at all.  It only takes a single parameter, not two, which is causing a PHP error.  Instead, you want:
add_filter( 'hum_redirect_types', function($types) {
    $types[] = 'e';
    return $types;
});

add_filter( 'hum_redirect_e', function($url, $path) {
    return "https://ebird.org/" . $path;
}, 15, 2);

that now works:
% curl -i http://localhost:8080/wordpress/e/foo
HTTP/1.1 301 Moved Permanently
Content-Type: text/html; charset=UTF-8
Location: https://ebird.org/foo
Server: Caddy
Status: 301 Moved Permanently
X-Powered-By: PHP/8.2.3
X-Redirect-By: WordPress
Date: Tue, 04 Apr 2023 18:57:34 GMT
Content-Length: 0

And I apologize... I didn't mean that the plugin won't ever be updated in the future, just that I didn't think there was an update necessary to resolve this.  But you're right about the code sample using deprecated functions, and I'll fix that.

oh, actually.... you could use hum_redirect_base_e... hum automatically appends the remaining path.  I forgot about that.  So this would also work (and would be equivalent):
add_filter( 'hum_redirect_types', function($types) {
    $types[] = 'e';
    return $types;
});

add_filter( 'hum_redirect_base_e', function() {
    return "https://ebird.org/";
});

@willnorris, thank you very much for all your efforts! Now the code is working and redirects to the external site. This is really great.
Just one last question, hopefully... I am now trying to configure several external redirections with different custom prefixes and have added this code to my snippet:
# eBird
add_filter( 'hum_redirect_types', function($types) {
    $types[] = 'e';
    return $types;
});

add_filter( 'hum_redirect_base_e', function() {
    return "https://ebird.org/";
});

# iNaturalist
add_filter( 'hum_redirect_types', function($types) {
    $types[] = 'n';
    return $types;
});

add_filter( 'hum_redirect_base_n', function() {
    return "https://www.inaturalist.org/";
});

# ISBN
add_filter( 'hum_redirect_i', function($url, $path) {
    return "https://www.worldcat.org/de/search?q=" . $path;
}, 9, 2 );

For the first redirection, eBird, with custom prefix e everything works fine, whereas for the second redirection, iNaturalist, with custom prefix n I am facing the same problem as before: the custom link is redirected to my blog instead of the external site.
Do I have to define all custom prefixes at once in order to get it working?
Thank you so much!

You do not have to add two filters to add support for 'n' and 'e', this should also work:
add_filter( 'hum_redirect_types', function($types) {
    $types[] = 'e';
    $types[] = 'n';
    return $types;
});

add_filter( 'hum_redirect_base_e', function() {
    return "https://ebird.org/";
});

add_filter( 'hum_redirect_base_n', function() {
    return "https://www.inaturalist.org/";
});

# ISBN
add_filter( 'hum_redirect_i', function($url, $path) {
    return "https://www.worldcat.org/de/search?q=" . $path;
}, 9, 2 );

Thank you @willnorris and @pfefferle for your hints and please excuse me for answering so late.
I have now configured these filters for hum, and everything works perfect!
add_filter( 'hum_redirect_types', function($types) {
    $types[] = 'e';
    $types[] = 'u';
    return $types;
});

add_filter( 'hum_redirect_base_e', function() {
    return "https://ebird.org/";
});

add_filter( 'hum_redirect_base_u', function() {
    return "https://www.inaturalist.org/";
});

# ISBN
add_filter( 'hum_redirect_i', function($url, $path) {
    return "https://www.worldcat.org/de/search?q=" . $path;
}, 9, 2 );

I am adding one more question: Is it possible to add sub-prefixes for custom links, as with the built-in .../i/a/-links for isbn-amazon redirections? So I could configure links in the following way: .../e/c/ redirecting to https://ebird.org/checklists
Thank you very much!

You can do that in your code, as we do it with /i:
https://github.com/willnorris/wordpress-hum/blob/master/hum.php#L226


#264 Make BraveServletFilter customizable

first step to allow customization of BraveServletFilter by subclassing it. New implementations of HttpServerRequestAdapter and HttpServerResponseAdapter can be provided by overriding the
corresponding factory methods.
A dedicated ServerAdapterFactory class should be considered and move newServerRequestAdapter(...) and newServerResponseAdapter(...) there.

one moment...

one test in grpc seems to be a bit shacky... (BraveGrpcInterceptorsTest.testBlockingUnaryCall unrelated to this).

yeah that test is flakey.
Since this module is for something with a very stable api (servlet spec), I
think we should do something that doesn't require exposing so many
intermediate types. I'd suggest following the pattern of OkHttp instead.
https://github.com/openzipkin/brave/blob/master/brave-okhttp/src/main/java/com/github/kristofa/brave/okhttp/OkHttpParser.java
Ex. ServletParser with the same sort of disclaimers presented in the OkHttp
one, and the default behavior that matches the existing codebase. This
provides users with a single type to extend, which makes everything else
simpler on our end.
care to give it a shot?

agree that there are quite a number of intermediate types. But to some degree I also like them. The reason is in our case Brave will get integrated into dozens of projects. All of them make use of HTTP. The header processing and creation of binary annotations will be mostly the same. But the technology stack can differ (resteasy, servlet, etc.). For this reason having classes like HttpServerRequest and ServerRequestAdapter are very valuable to us since they allow the customizations to take place in a single ServerRequestAdapter and ServerResponseAdapter. We don't have to worry about which implementation is used as long as our adapter somehow can be integrated into it.

if the idea for this is to do something generically, you'll notice all the other implementations "new up" these classes or are package protected. In other words, it isn't current practice in Brave, so this would become the different one, right?

I guess this small PR opens up all kinds of questions regarding customizability. Yes, others like BraveGrpcServerInterceptor have all those classes class/package protected. But to some degree I think people will already be happy having access to HttpServerRequest/HttpServerResponse to compute further binary annotations. For more advanced use cases, maybe there should be some way to get the underyling orignal/native request/response (HttpServletRequest, ServerCall, etc.). But I guess it is undeseriable to make everything public. May some generic unwrap(...) function would suffice.
Personally, I don't yet really know in which direction Brave is heading (I'm new here). I'm fine with the current request/response/adapter/interceptor api. But also open for simplications. In either case I think some kind of interface for a "request/response => binary" annotation producer and a generic "http request/response interface" hiding internals of jersey/restesay/okhttp would be great.

I think the challenge here is mostly that we try to support compatibility. Every thing that's added as protected or public means a new compatibility liability/lock-in for the project. So, eventhough the lines of this change are small, it does imply a significant surface area change.. changes we couldn't undo later until a major version bump. That's the main driver in trying to figure out what this would look like for all of your integrations (not just servlet), and also what's the least exposure way for the project to facilitate that (4 types and corresponding protected methods likely isn't least)
something to think about. Sometimes the best way to explore these is to implement them in test cases to prove your use-case works.

so far the existing request/response/adapter interfaces do a great job from my perspective. So new types should not be necessary, it rather comes down to this four methods which would be necessary in all of the implementations to gain customizability. To slim things down, I think newServerRequestAdapter(...) and newServerResponseAdapter(...) are sufficient and we could avoid newHttpServerRequest(...) and newHttpServerResponse(...). It should not be necessary to reimplement those by the application. Maybe something like a unwrap(...) could provide access to the native request/response in the future for more advanced use cases.
The remaining two methods might be provided by a Factory so that applications can replace the Factory instead of subclassing Brave. I could update the PR accordingly and add an example to the tests.
Maybe some classes of Brave could also be placed into internal packages to make it clear from start that those should not be touched.

so far the existing request/response/adapter interfaces do a great job
from my perspective. So new types should not be necessary, it rather comes
down to this four methods which would be necessary in all of the
implementations to gain customizability. To slim things down, I think
newServerRequestAdapter(...) and newServerResponseAdapter(...) are
sufficient and we could avoid newHttpServerRequest(...) and
newHttpServerResponse(...). It should not be necessary to reimplement those
by the application. Maybe something like a unwrap(...) could provide access
to the native request/response in the future for more advanced use cases.

least change necessary is important. Practically speaking, if you intend to
use this for different frameworks my question remains as to why you are
only doing this for the servlet filter? would we expect a few more PRs for
each of the other ones?

The remaining two methods might be provided by a Factory so that
applications can replace the Factory instead of subclassing Brave. I could
update the PR accordingly and add an example to the tests.

they wouldn't be subclassing Brave, they'd be subclassing the filter,
right?

Maybe some classes of Brave could also be placed into internal packages to
make it clear from start that those should not be touched.

It isn't about "not being touched" It is that these were designed to
implement instrumentation such as the ServletFilter here. Using effective
java, we don't expose arbitrary extension points willy nilly. It just leads
to tech debt. That's why I'm taking time with you now to try and pare this
down and underpin it with an actual use case. Since you noted this was in
support of one adapter for many http frameworks, I'd really like to see
that in practice as you can't do it with the PR you have here for reasons
mentioned about the other instrumentation not being extendible this way.
Remember, you can always copy/paste this <200 line class while you figure
it out. Incomplete extension ideas tend to haunt projects.

I already copy&pasted. So I'm not in a hurry either and totally agree that this has to be done in a careful manner. At some point, naturally, I would like to get rid of the copy/pasting.
I will update the PR to include other filters next to servlet and make use of a factory. I did not want to create to many changes at first before the direction was not discussed.
with "subclassing brave" I meant in generall all brave classes (including the filters). Not just the main Brave class. Sorry for the confusion. When we already talk about the main brave class, I think there potentially ClientTracer, ServerTrace, ClientRequestInterceptor, ClientResponseInterceptor, ServerRequestInterceptor, ServerResponseInterceptor could become interfaces.

I think there potentially ClientTracer, ServerTrace, ClientRequestInterceptor, ClientResponseInterceptor, ServerRequestInterceptor, ServerResponseInterceptor could become interfaces.
It is very unlikely that we change all of our major types to interfaces. That would be a bit silly

The main reasons for why we don't make all of our public types interfaces have a lot to do with the same reasons I'm hesitant to expose 4 methods to mutate the behavior of ServletFilter. Basically we are in general following effective java which favors less visibility, and final unless needed otherwise. While we do have (and will have) some interface types, it wouldn't be congruent to boiler-plate convert things to interfaces, this in mind. Remember, adding to an interface before java 8 means a breaking change! We not only want to be use-case focused, but also not break our users.
We don't have a HACKING file here, but I've made one in other projects, which helps explains some of the highlights to keep in mind when considering extensibility and change.
https://github.com/OpenFeign/feign/blob/master/HACKING.md
Anyway, let's focus on the actual use cases vs a preference for converting things to interfaces or other arbitrary extension. You're more likely to get support for the change when it is centered on change that has common benefits and is testable to actually work diversely without adding liability to the api.

I committed a next iteration: ClientAdapterInterceptor and ServerAdapterInterceptor introduced to make client and server, request and response adapters customizable.
Most common use case: add further annotations to span
Interceptors makes use of a wrapper approach. The interceptor does not get in touch with the internals of the various filter implementations. Instead, he is enabled to intercept and customize any calls to those implementations. This way the surface area of Brave is kept small.
Two filters (servlet, spring) have been modified to use this approach. Test cases and others to follow once the design is finalized. Naming and everything else up for discussion.

I don't think we want to support a list of interceptors. Someone can delegate/compose to achieve that. Considering the amount of people contributing maintenance to this project, we really need the least surface area possible.

sounds good to me too, Saves a couple of lines.
I also like @llinder proposal of using the builder pattern. Maybe I rather add a method Brave.Builder.setAdapterInterceptor(...). That interceptor is then passed to ServerRequestInterceptor and invoked in ServerRequestInterceptor.handle(...). This way the filters do not have to care about the interceptor anymore.

I also like @llinder https://github.com/llinder proposal of using the
builder pattern. Maybe I rather add a method Brave.Builder.setAdapterInterceptor(...).
That interceptor is then passed to ServerRequestInterceptor and invoked in
ServerRequestInterceptor.handle(...). This way the filters do not have to
care about the interceptor anymore.

Depending on how the interceptor is defined, it might need http classes or
concepts which would make it too specific for brave's core builder. It
might be more appropriate to make an http builder (for http-tier
instrumentation). Ex.
HttpInstrumentation.builder(brave).spanNameProvider(foo).requestTags("http.method",
"http.uri")...

currently there is a ClientAdapterInterceptor  and ServerAdapterInterceptor. Maybe we could also consider using a generic Interceptor and could potentially be applied "anywhere". The Interceptor may have an accept(...) method that decides whether the interceptor is applicable to a given source.
interface Intercept{
boolean accept(Object object);
T intercept(T interceptedObject);
}
In that case one could implement e.g. a Interceptor.

moving the discussion back to the issue so that it isn't limited to only you and me


Skip test unless has optional pillow dependency

Fixes #13076.

[ ] I have added the tests to cover my changes.
[ ] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.

Summary
Skip test test_dag_drawer_checks_filename_correct_format unless pillow dependency is found
Details and comments
None.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>0
Warning: This coverage report may be inaccurate.
This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

For more information on this, see Tracking coverage changes with pull request builds.
To avoid this issue with future PRs, see these Recommended CI Configurations.
For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

0 of 0   changed or added relevant lines in 0 files are covered.
19 unchanged lines in 5 files lost coverage.
Overall coverage decreased (-0.02%) to 89.139%

Files with Coverage Reduction
New Missed Lines
%

crates/accelerate/src/two_qubit_decompose.rs
1
90.84%

qiskit/transpiler/passes/synthesis/unitary_synthesis.py
2
88.43%

crates/qasm2/src/lex.rs
4
93.23%

crates/qasm2/src/parse.rs
6
97.15%

qiskit/synthesis/two_qubit/xx_decompose/decomposer.py
6
90.84%

Totals

Change from base Build<PHONE_NUMBER>0:
-0.02%

Covered Lines:
71822

Relevant Lines:
80573

💛  - Coveralls


The Application 32bit did not work after installation by Wine via box86

I get an error "A debugger has been found running in your system. Please, unload it from memory and restart your program." Leading to cannot launch of the *.exe file.

Debian is not recommended. These packages are built on arm64 Kali. You can try the release of box86 and box64 wine on arm64 Kali on August 12, 2022.

Debian is not recommended. These packages are built on arm64 Kali. You can try the release of box86 and box64 wine on arm64 Kali on August 12, 2022.

I want to run the 32bit software. So, I was install the 'box86_0.2.6_kali_armhf.deb' and 'box86-box64-winehq-7.10-x86_ 64-arm64.deb' according to your release on August 12, 2022.
Before that, I also installed the Kali distro on Termux and setting the environment according to your guidance in 'How to set the environment'
Then I met this error. Please tell me how to fix it, thank you.


Added ZTF crossmatch to PGIR alerts

This PR aims to add ZTF crossmatches (public data only) for all alerts incoming in the PGIR stream. We'd like to set up scanning to include PGIR sources that have ZTF crossmatches.
Added ZTF_alerts to crossmatch list for PGIR in config.defaults.yaml. Also included filter to include only programid =1.

Also, looks like your pre-commit hook is not working -- linting failed on the CI, please check.

Thanks @dmitryduev for the review. I examined the code in alert_broker_pgir.py, and it appears that even the CLU crossmatch is done only once? The external (static) and CLU crossmatches appear to happen inside
if (
alert_worker.mongo.db[alert_worker.collection_alerts_aux].count_documents(
{"_id": object_id}, limit=1
)
== 0
):
which would suggest a one-time crossmatch? Do you suggest adding the ZTF crossmatch outside this if construct?

Do you suggest adding the ZTF crossmatch outside this if construct?

Yes, exactly. And as you can see, it should be performant since you'd be running it on each and every alert.

Hi @dmitryduev, okay I've now added a new function in alert_broker.py to find the most recent ZTF alert (made the function more generic than just for ZTF alerts). Also added adding the ZTF alert to aux in alert_broker_pgir.py

@dmitryduev Merged the base branch and fixed linting for review

your

I also ran a test on K to understand how much time it takes to run these crossmatches. Selecting random 1K PGIR alerts from several nights, I ran the same filter and sort on penquins to confirm that the operations take between 1 - 4 seconds, with a median of ~ 2 seconds for 1 K alerts.
Is this fast enough @dmitryduev ?

Thanks @dmitryduev . Committed the suggestions and tests appear to pass. Ready to merge?

Thanks, @dekishalay. Yes, I think it can go in now. The index I was creating is ready so could you please rerun your query timing test once again in the mean time?

Thanks! I tried the test again, and it appears to be hovering between 1 and 3 seconds now.


Use expeditor to open backport PRs

We want to be able to branch for Chef 15 while still backporting changes to the chef-14 branch. We can do this automatically with expeditor using labels.

At the moment we'll need to figure out how to get a list of all commit shas in a PR so we can use that list to cherry pick. This isn't something expeditor has out of the box.

This probably needs to be tracked as an issue against expeditor not chef/chef

This is mostly writing a script to perform the backport using expeditor.


I have 3 Issues (If you already read my comment on the remote decks add on ankiweb page, skip to the second paragraph)

I LOVE this add on but I seem to have 2 major issues. 1)Sometimes the add on turns a Q&A pair written in the basic note format into a cloze note in Anki. For example, go to https://docs.google.com/document/d/e/2PACX-1vQFvH9SCHfb9a5VwI4LRdRJCGRC0UY7Oh0do0YY2Jg1SvbWhsVSoi4vBhL8Kz_kgHQ4LapwBPPZb5tT/pub & find the "How to find MLO?" Q&A. If you look at this image https://drive.google.com/file/d/1rQ6Q68hqfu-z6XUyekFUaCn42g2OOEf_/view?usp=sharing you can see that the note Anki decided to put the Q&A in is not a basic note but rather a cloze note. Problem no. 2 w/the add on: the cloze note will look perfectly fine but I get the error “No cloze 1 found on card. Please either add a cloze deletion, or use the Empty Cards tool.” For example, in this image
https://drive.google.com/file/d/1lQA_SQEoZ7cIcq_JTJH2n30Ntg329RXZ/view?usp=sharing the cloze note looks perfectly fine but I still get the error when trying to review the card belonging to the note.
I posted about the above 2 issues on the add on's ankiweb page but after doing so I discovered a third issue. The "Method for finding MLO only {{c1::works w/ strict TFL}}" cloze deletion as well as the "Logic behind method for finding MLO?" Q&A pair (you can search for these on the google docs I linked) don't show up in Anki as notes. What is interesting is that all my issues are in the same general area in the google docs. There's a lot of comment lines in that area, which led me to think that maybe the comment lines are messing up the cards around them. What do you think is the problem? Thanks!

Hey,
Thanks for the issue report. I'm hoping to clear a lot of the backlog this weekend! has been a very busy winter!
Conor


little improvement?

Just a little thing which I think could be done:
    When playing through a playlist with say a Music bot, when the bot reaches a deleted/private video, it
    errors with "Error: resource not found" to which, I think could be improved by just gracefully skipping
    it/bypassing it. Instead of chucking an error which disturbs the whole sequence..

you should be able to filter on privacy status based on the new property added in 6ae74d2dcb67d0974bd552875ad00950ab55ff05

if you are on master, you can also filter by thumbanils, which private videos and deleted ones don't have! GOOD LUCK.


consider pinning scip/gurobi deps

It looks like both scip and gurobi recently updated, and now the current ilpy build doesn't work because it was built against different versions of the lib.  I guess that means we should probably be hard pinning the deps in our feedstock?   I do believe conda has the ability to negotiate build versions with other libraries in the environment... but to bring back general compatibility with multiple versions of gurobi/scip, we likely need to do more work

will try to fix today.  but for now, you should be able to downgrade scip and/or gurobi to whatever version they were on about a month ago

fix is building now ... should upload within 30 mins or so if all goes well: https://github.com/funkelab/ilpy-feedstock/actions/runs/7145657428

Thanks a lot, installation is working fine again :)

Thanks!