Refactor java instrumentation

Related to #5211. Followup to #4966.
This PR breaks up and adds coherence to the topics currently discussed in Instrumentation:

Add a new "Record Telemetry with API" page

Standard presentation of all key user facing API components. Each component includes a brief description, links to javadoc, links to relevant concept resoruces, and a code snippet exploring API usage.
This page supersedes and expands on the "Traces" and "Metrics" sections from the "Instrumentation" page.

Rework "Instrumentation" page into "Instrumentation ecosystem"

Discuss the various categories of instrumentation in the OpenTelemetry Java ecosystem, linking out to relevant resources.
Discuss cross-cutting instrumentation topics, including context propagation, semantic conventions, and the special case of logging instrumentation.

The PR for the code snippet additions to opentelemetry-java-examples is available here: https://github.com/open-telemetry/opentelemetry-java-examples/pull/498
There is a lot of content in this PR, but like #4966, the principles are simple and scalable. I recommend reviewing by looking at the rendered website. Links to previews for main pages involved:

Instrumentation ecosystem
Record Telemetry with API

cc @open-telemetry/java-approvers, @open-telemetry/java-instrumentation-approvers

@jack-berg - please rebase and resolve conflicts before we proceed:

I've merged main rather than rebase. I generally avoid rebasing since it overwrites git history and requires force pushing. If this repo prefers rebasing for some reason, I'm happy to do that.

@chalin / @svrnm any idea what's happening with a the deploy to netlify? It almost seems like its in a corrupt state, since this PR currently doesn't touch the submodules yet those seem to be the cause of the issue:

@jack-berg - please rebase and resolve conflicts before we proceed:

I've merged main rather than rebase. I generally avoid rebasing since it overwrites git history and requires force pushing. If this repo prefers rebasing for some reason, I'm happy to do that.

Yes rebase from a freshly updated upstream main. Otherwise, we can get wonky issues arise when the PR rooted too far behind, for example: https://github.com/open-telemetry/opentelemetry.io/pull/5270#pullrequestreview-2340468043

@chalin / @svrnm any idea what's happening with a the deploy to netlify? It almost seems like its in a corrupt state, since this PR currently doesn't touch the submodules yet those seem to be the cause of the issue: ...

This is the kind of wonkiness that can happen. Please rebase from a freshly updated upstream main and we'll reassess after.

This is the kind of wonkiness that can happen. Please rebase from a freshly updated upstream main and we'll reassess after.

That did the trick. Thanks!

@jack-berg can you check with @open-telemetry/java-approvers that at least one of them is also taking a look through the changes?

We have one remaining open conversation here. Discussing here because that thread is buried and hard to find.
I feel like the easiest path forward is to just remove the links from the translated versions of libraries to the now removed java sections, like I had originally done. Probably not a solution to the general case, but in this case, there are no translated versions of the instrumentation page being modified, and the link probably shouldn't have been there in the first place.
WDYT?

We have one remaining open conversation here. Discussing here because that thread is buried and hard to find.
I feel like the easiest path forward is to just remove the links from the translated versions of libraries to the now removed java sections, like I had originally done. Probably not a solution to the general case, but in this case, there are no translated versions of the instrumentation page being modified, and the link probably shouldn't have been there in the first place.
WDYT?

We need a quick solution to merge this PR, and we need a long term solution to ensure that we can run translations while updating the (English) documentation. For the quick solution, I'd like to lean on whatever @chalin suggests to do, to get this PR merged.

We need a quick solution to merge this PR, and we need a long term solution to ensure that we can run translations while updating the (English) documentation. For the quick solution, I'd like to lean on whatever @chalin suggests to do, to get this PR merged.

From the GH checks:
blog/2023/spring-native/index.html
  target does not exist --- blog/2023/spring-native/index.html --> /docs/languages/java/libraries/

This needs to be fixed, FYI. Because all en pages must use canonical paths.
I'll update it.
As for non-en pages, a general strategy (I'm proposing) is it create a temporary link-checker ignore rule for the problematic pages, along with an issue to track its removal. I'll do that too so illustrate how that look for this PR.

Thanks for all your help @chalin!

I love it! ❤

🎉


Add cyan to yellow colormap

What
This PR adds a new colormap: cyan to yellow. The colormap is designed to work well for red-green colorblind people and make it easy to see the sign and magnitude of values in the range -1 to 1. It is dark and dull in the middle and bright and colorful at the ends.

This screenshot is from https://www.shadertoy.com/view/lfByRh.

This screenshot is from the signed distance field example. The normalization of values interferes with the colormap as it shifts the center of the colormap away from zero. It will become easier to use it to its full potential when range controls for colormaps are added. This problem is related to #6106 and #1510.
Checklist

[x] I have read and agree to Contributor Guide and the Code of Conduct
[x] I've included a screenshot or gif (if applicable)
[ ] I have tested the web demo (if applicable):

Using examples from latest main build: rerun.io/viewer
Using full set of examples from nightly build: rerun.io/viewer

[ ] The PR title and labels are set such as to maximize their usefulness for the next release's CHANGELOG
[ ] If applicable, add a new check to the release checklist!
[ ] If have noted any breaking changes to the log API in CHANGELOG.md and the migration guide

PR Build Summary
Recent benchmark results
Wasm size tracking

To run all checks from main, comment on the PR with @rerun-bot full-check.

ci failure is a known issue with contributor ci

I hope this won't awaken https://github.com/rerun-io/rerun/issues/3931 again 😬

That's what Jeremy's test was all about

Centering the colormap around zero is now possible thanks to #7549! ❤


release prep: update conventions

Reviewer checklist

[ ] Ensure relevant issues are linked (description should include text like "Fixes #")
[ ] Ensure correct labels applied
[ ] Ensure any appropriate documentation has been added or amended

Coverage remained the same at 100.0% when pulling a44580fde563ba80632c649622d0d589af915bbd on release_prep into 1447e5784a93c6a1e86e9bd7f9be2d238170be01 on main.


Update observer-cli SHA.

Description
Looks like observer cli rebased/force pushed the repo, changing all of
the SHAs. This breaks the build (and any attempt at replicating past
builds). Update observer-cli.
Signed-off-by: Mark Anderson<EMAIL_ADDRESS>Issues Resolved
Fixes build breakage of master
Check List

[x] New functionality includes tests
[ ] All tests pass
[x] All commits have been signed-off for the Developer Certificate of Origin. See https://github.com/chef/chef/blob/master/CONTRIBUTING.md#developer-certification-of-origin-dco

This fixes the build (https://buildkite.com/chef/chef-chef-server-master-omnibus-adhoc/builds/211)

Administratively merging to fix build


IDPS Private IP ranges - wrong info

Statement in the documentation that IDPS Private IP ranges is in preview.
Based on this publication the IDPS Private IP ranges is in GA since November 2022
https://azure.microsoft.com/en-us/blog/announcing-new-capabilities-for-azure-firewall/
"You can configure your IDPS private IP address ranges using the Private IP ranges preview feature. For more information, see IDPS Private IP ranges."

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

ID: bef38298-89c0-6c77-fb9d-7bf6bd5dc030
Version Independent ID: 335d7b03-3e6f-61b6-fe19-19441c1b6b36
Content: Azure Firewall Premium features
Content Source: articles/firewall/premium-features.md
Service: firewall
GitHub Login: @vhorne
Microsoft Alias: victorh

@joachimloe
Thanks for your feedback! We will investigate and update as appropriate.

Additional info.
The IDPS Private IP Ranges is not listed in the preview feature article.
https://learn.microsoft.com/en-us/azure/firewall/firewall-preview

@joachimloe
fixed
#please-close


Support for custom RPC

I'd love support for the POA chain (https://poa.network/), as well as any other chain that implements ethereum's standard RPC.  It's probably a more expensive lift for you because you probably run a full node in order to get all the data needed, so each custom chain you would need to also run a full node of their network.  Just thought I'd open an issue to start the conversation.
Thoughts?

@anurag-arjun Cool.  Yeah, I was hoping to build something on POA during EthDenver next week and was just looking into different tools to use and this one seems like a really good one. Good thing is I can just build it on any other test network and because it uses standard RPC it should translate just fine whenever ready.

Good thing is I can just build it on any other test network and because it uses standard RPC it should translate just fine whenever ready.
Yes! :+1:


Get data availability results from Pelican

For each count information we can take the value from Pelican. It's stored in Pelican as a number of isSet check for a subfield of a particular structure.
For example here we know that there is 3601 awards because we checked the presence of awards.id 3601x

The information we need is result of isSet check for the specific path which will be mention for each item

List of available data
Parties
Count of parties - result of parties.id isSet check
Planning
Count of planning activities  - result of planning.budget isSet check (plannings does not have ids 🤷♂ )
Tenders
Count of tenders - result of tender.id isSet check
Count of tenderers - result of tenderers.id isSet check
Count of tender items - result of tender.items.id isSet check
Awards
Count of awards - result of awards.id isSet check
Count of award items - result of awards.items.id isSet check
Count of awards suppliers - result of awards.suppliers.id isSet check
Contracts
Count of contracts - result of contracts.id isSet check
Count of contract items - result of contracts.items.id isSet check
Count of contract implementation transactions - result of contracts.implementation.transactions.id isSet check
Documents
Count of documents related to the different stages of the contracting process
Total sum of following counts

planning.documents - result of planning.documents.id isSet check
tender.documents - result of tender.documents.id isSet check
awards.documents - result of awards.documents.id isSet check
contracts.documents - result of contracts.documents.id isSet check
contracts.implementation.documents - result of contracts.implementation.documents.id isSet check

Milestones
Count of milestones related to the different stages of the contracting process
Total sum of following counts

planning.milestones - result of planning.milestones.id isSet check
tender.milestones - result of tender.milestones.id isSet check
contracts.milestones - result of contracts.milestones.id isSet check
contracts.implementation.milestones - result of contracts.implementation.milestones.id isSet check

Amendments
Count of amendments related to the different stages of the contracting process
Total sum of following counts

tender.amendments - result of tender.amendments.id isSet check
awards.amendments - result of awards.amendments.id isSet check
contract.amendments - result of contract.amendments.id isSet check

Looks good :)

done


lidarr: init at <IP_ADDRESS>1

Motivation for this change
Fork of sonarr (as radarr) but for music instead of series and movies.
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option 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)
[X] 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/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[X] Fits CONTRIBUTING.md.

No attempt on aarch64-linux (full log)
The following builds were skipped because they don't evaluate on aarch64-linux: lidarr
Partial log (click to expand)

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)
Attempted: lidarr
Partial log (click to expand)
building
no Makefile, doing nothing
installing
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/pb1gixslgn5ag3i3z6n5aciq2p8fjc5d-lidarr-<IP_ADDRESS>1
strip is /nix/store/h0lbngpv6ln56hjj59i6l77vxq25flbz-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/pb1gixslgn5ag3i3z6n5aciq2p8fjc5d-lidarr-<IP_ADDRESS>1/bin
patching script interpreter paths in /nix/store/pb1gixslgn5ag3i3z6n5aciq2p8fjc5d-lidarr-<IP_ADDRESS>1
checking for references to /build in /nix/store/pb1gixslgn5ag3i3z6n5aciq2p8fjc5d-lidarr-<IP_ADDRESS>1...
/nix/store/pb1gixslgn5ag3i3z6n5aciq2p8fjc5d-lidarr-<IP_ADDRESS>1

No attempt on aarch64-linux (full log)
The following builds were skipped because they don't evaluate on aarch64-linux: lidarr
Partial log (click to expand)

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)
Attempted: lidarr
Partial log (click to expand)
/nix/store/pb1gixslgn5ag3i3z6n5aciq2p8fjc5d-lidarr-<IP_ADDRESS>1

Oops, I deleted the branch. Recreated.

LGTM, rebased and applied in aba95986d2e76b24ad2c45bed2076dda8b1451b3


One button response

Cancel button -> Obligatory
Ok Button -> Optional.
If Ok button it's not setted, then only appear one response button instead nothing

Hi @Georgevik, thanks for the PR 😄
I wrote a comment in #26 explaining why this is not supported, so I'll just close it.
Thanks again for contributing in any case 👍


Adding support for L10s Ultra heat

Is it possible to add support for the L10s Ultra heat? It's not recognize as a device when connecting my dreame account in the initial wizard. (using v2.0.0b12)

The model number is RLL82CE.
Thanks a lot for your support.

I updated to the last beta version and it got recognized, thank you very much


Use custom error handler instead of Symfony

Symfony / Monolog turned out to be too much effort to configure.
Closes #137 #135 #152

Current coverage is 93.93% (diff: 100%)

Merging #162 into master will not change coverage

@@             master       #162   diff @@
==========================================
  Files            31         31
  Lines           528        528
  Methods          69         69
  Messages          0          0
  Branches          0          0
==========================================
  Hits            496        496
  Misses           32         32
  Partials          0          0

Powered by Codecov. Last update 12df6a7...30f29e9


Do not use DC as a base for tests with Edge

CC @aboba
getstats test

Edge is no longer a target.

Are your referring to current Edge or Chromium-based Edge?

I was referring to legacy-edge, not edgium :-)


Refactor http example server to abstract the handler

The HTTP example servers (sync and async) should be refactored so that the handler for requests is supplied as a template argument. This would make it easier for people to re-use the server without having to modify the boilerplate.
If the server is generic enough, we can consider moving it to extras/ as a partly-official API.

There's some work on this here but it has design flaws:
https://github.com/vinniefalco/Beast/commits/server

This is done, part of server-framework.


THRIFT-4848: Add ability to set Content-Type,Accept headers in HTTP c…

…lient
Client: netstd
Patch: Kyle Smith

I added the RequestHeaders property that exposes the DefaultRequestHeaders property on the HTTP client instance which allows a developer to set request headers that are not otherwise available using the existing CustomHeaders method. The problem with using CustomHeaders is that it does not allow you to set certain properties (namely Accept). I also added the ContentType property that for specifying the Content-Type request header before sending a request to the server. Our use case is for us to set these headers so that our server can use the correct protocols depending on the clients request.
Other cleanup items include removal of the ConnectTimeout write-only property as the the underlying _connectTimeout field is only ever use on creation, so setting this property was a no-op. I also implemented the OpenAsync and IsOpen fields to work more inline with the other transports.

[X] Did you create an Apache Jira ticket?  (not required for trivial changes)
[X] Does your pull request title follow the pattern "THRIFT-NNNN: describe my issue"?  (not required for trivial changes)
[X] Did you squash your changes to a single commit?
[X] Did you do your best to avoid breaking changes?  If one was needed, did you label the Jira ticket with "Breaking-Change"

I generally welcome that patch, I had in on my todo as well. But I am against the others unrelated stuff. If you think we need that please file another ticket for it and let's discuss these changes separtely. If you could do that, I will commit it (unless I find something else), but in the current form it is a clear -1 from me.

You're right. Sometimes old habits come back and haunt me. Let me clear out the non-topic specific changes.


terraform resources have too less data

Description
It would be good to include more detailed data in resources.
For example, an application has the following:
$ terraform state show juju_application.kubernetes_worker
# juju_application.kubernetes_worker:
resource "juju_application" "kubernetes_worker" {
    config      = {
        "kubelet-extra-config" = jsonencode({})
    }
    constraints = "arch=amd64"
    id          = "k8s-calico:kubernetes-worker"
    model       = "k8s-calico"
    name        = "kubernetes-worker"
    placement   = "1,2"
    trust       = false
    units       = 2

    charm {
        base     =<EMAIL_ADDRESS>        channel  = "1.28/stable"
        name     = "kubernetes-worker"
        revision = 134
        series   = "focal"
    }
}

juju status command has more outputs including IP address and details of each unit.
Without those information it is unable to do other configuration based on what is created.
Urgency
Annoying bug in our test suite
Terraform Juju Provider version
0.13.0
Terraform version
1.9.5
Juju version
3.5.2
Terraform Configuration(s)
No response
Reproduce / Test
terraform apply

Debug/Panic Output
No response
Notes & References
No response

@shundezhang  Please list your use cases and data required.

Hi @hmlanigan what I was trying to do is to deploy a bunch of applications using juju, then run some script on one of the juju deployed machines. To do that I need to know the IP address of each machine deployed by Juju. Also in the juju status --format=json output, there are information such as IP, OS type, UUID, etc, it would be good to have the same information in juju provider's resources.


Get nothing while cat /proc/self/maps

from pwntools's issue https://github.com/Gallopsled/pwntools/issues/1871

close


This page suggests that you must update the OS before configuring networking. That's not possible.

Just got a board, newest SDK installed as of today, and I have an older version of the OS. But it will NOT update the OS until it is connected to my wifi, which the page clearly states at the top that you need to update the OS before continuing.
I think you need to review the steps to this process. You need to be signed in, claim the device, configure networking, then reset the device for it to update.

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

ID: 5db907e3-85a6-ab65-837b-7e6a5dc12224
Version Independent ID: dfd84d21-060c-1ba2-6341-54ed7248ae23
Content: Configure networking - Azure Sphere
Content Source: AzureSphere/articles/install/configure-wifi.md
Product: azure-sphere
GitHub Login: @pennyo
Microsoft Alias: azurespheredocs

@thecodemonk Thanks for the feedback! I have assigned the issue to the content author to evaluate and update as appropriate.

@thecodemonk if you 'azsphere device recover' from the Azure Sphere Developer Command Prompt with the board connected over USB, your computer will download the latest OS and update it over USB.

@kmstory I think I saw that in another page somewhere, but if one is following all the steps in the order listed, they will probably not see, or do that step. If I remember,  they are told to run that command if it says their device is version is to old. My device specifically said, as an output to a previous step, that I needed to configure networking before it would update.
While most of us are technically savvy enough to get through all this, its probably in the projects best interest to have accurate documentation.

@thecodemonk those instructions are on the "Update the OS" page, 3 pages before this one in the instructions: https://docs.microsoft.com/en-us/azure-sphere/install/install-os
So if someone is following the "Install" section of the docs in order, they'll update their board before they even set up an Azure account.

Then perhaps that's the page with the issue? Step 4:
If the output from the preceding command shows that the device is running an unknown release, a deprecated release, or a TP release, you'll need to run the recovery procedure to update it
When I ran that command the output said it was ready to update but needed to be connected to a network first. It never said I was on a unknown or deprecated release. I wish I would have saved the wording, but the output of azsphere device show-ota-status definitely made me believe that I was fine and just needed to continue without doing a device recover.

I agree that the "Update the OS" page should be modified. I forget what mine said on that step, but I remember that I skipped the recover at first. Then, when I tried to claim mine, it kept giving me errors saying that the device was waiting/trying to update. I think the only reason I ended up fixing it is because the page is named "Update the OS", even though the instructions aren't very clear.
Maybe they should use this example from the "Reference" section to show what will be returned if the device is already up to date: https://docs.microsoft.com/en-us/azure-sphere/reference/azsphere-device#example-13
So the beginning of Step 4 would read something like:

If the output from the preceding command includes "Your device has the expected version of the Azure Sphere OS: <versionNumber>", then the device is up to date and you can move on to the next step (Set up an account). Otherwise, you'll need to run the recovery procedure to update it:

azsphere device recover

I agree with that. It probably would have gone smoother for me as well if it was that clear that if it was not up to date, that I can easily just do that command.

Thank you for your feedback. The Azure Sphere team continues to work on the start-up experience and is committed to improving it.

We've reworked the start-up experience and documentation and believe this issue has been solved.

We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.


[Feature] Add more widget sets [sf#26]

Reported by rangar on 2006-02-24 13:00 UTC
Please add more widget sets, i.e calendars etc.
wx has sooo much more to offer :)

Commented by agriggio on 2006-05-02 07:39 UTC
Logged In: YES
user_id=375945
actually, wxGlade is designed to allow users to add their
own widgets... the problem is that the process is at the
moment undocumented (except for some mailing list
messages...). So, it would be nicer to have some docs on how
to do it, rather than adding more (I think)

Updated by cgrohmann on 2016-04-29 18:55 UTC

status: open --> closed
assigned_to: Carsten Grohmann
Group:  --> Next Release

Commented by cgrohmann on 2016-04-29 18:55 UTC
The widget list is grown and will be continue growing.
The usage of a custom widgets is documented now.


cherry-pick: X509 time: tighten validation per RFC 5280 (1.1.0)

Reject fractional seconds
Reject offsets
Check that the date/time digits are in valid range.
Add documentation for X509_cmp_time

GH issue 2620
cherry-picked from 80770da39ebba0101079477611b7ce2f426653c5
(omitting CHANGES and tests)

Requested by @LarsVoelker in #4915.

If it is desired to have the tests ported, too, I can have a second look at them. Probably the conflicts are related to changes in the test framework by @paulidale in ad887416f1e59c3294a7d8f83a0ca77120523b4a.

Sorry @paulidale, wrong alarm. Your commit was later.

It's now a full fledged backport with tests and CHANGES. Taking it out of WIP.

nice backport of the test :)

Thanks, Rich! I even was crazy enough to backport the test to 1.0.2. Thought it might be a good exercise to learn about the differences in the test frameworks. Well, I'm still struggling with it. Maybe you can have a look at #6162 and give me a hint what I am doing wrong?

Editorial note: I will replace

Cherry-picked from 80770da

by

Backported from 80770da

in the commit message when merging, because that's more appropriate.

Sorry, it's #6182, not #6162.

Merged, thanks!


CMS, PKCS7, and CRMF: simplify use of EVP_PKEY_decrypt() by helper function

Part of this has originally been carved out from #15283.

Factor out common decryption pattern involving two calls of EVP_PKEY_decrypt() within libcrypto, where further improvements such as those as discussed in #17319 can done there, at just one place for all these uses.
ssl/statem/statem_srvr.c: clean up handling of EVP_PKEY_decrypt() outlen
OSSL_CRMF_ENCRYPTEDVALUE_get1_encCert(): remove needless constant_time_*  and ERR_clear_error() calls, as discussed in https://github.com/openssl/openssl/pull/15283#pullrequestreview-836288625
cmp_http.c: Remove obsolete comment w.r.t. ERR_clear_error()

This pull request is ready to merge

Merged - thanks @t8m and @beldmit for the swift approvals.


Add support to gather indices stats for unloaded segments

This is related to https://github.com/elastic/elasticsearch/pull/39512 - we should add an option to the IndexStats telemetry device to also gather information about unloaded segments so we can measure how much memory a frozen index would use if were unfrozen (this will only work from Elasticsearch 7.1.0 onwards though).
Marking as "blocked" as this feature is not yet available in Elasticsearch.

The feature is now merged and available on the master and 7.x branch in Elasticsearch.

Frozen indices are deprecated as of Elasticsearch 7.14 thus closing this issue.


Add sample Code Scanning YAML as a copyable file

Currently, the user journey when configuring Code Scanning is to go through this step page by page.
When getting to the "Code Scanning" portion, if they want to configure a YAML file they have to enter all the values themselves because the sample workflow is shared as an image.
I think keeping an image makes sense, but it would be useful to have a boilerplate template (could even be identical to the one in the image) that has sample YAML code a user could just copy.

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

ID: 121e4848-4927-4353-8283-b3e413fc8f42
Version Independent ID: 121e4848-4927-4353-8283-b3e413fc8f42
Content: Dependency Scanning for GitHub Advanced Security for Azure DevOps - Azure Repos
Content Source: docs/repos/security/github-advanced-security-dependency-scanning.md
Service: azure-devops
Sub-service: azure-devops-integration
GitHub Login: @juliakm
Microsoft Alias: jukullam

Change merged


Display duration since start of the log file

The duration since the start of the log file should be displayed for every log entry.
If there is no parseable timestamp, then nothing should be displayed.
To start with, the duration should be displayed in milli seconds (maybe this should be configurable, too in a future version)

Prototype:


Unable to log in

Hi.
Downloaded the concept, started it up inserted all the info needed which is my email username and password to log in but it just keeps telling me that the password is wrong or username is wrong. I've already gotten 3600sec protection timers when trying to login to path of exile forums, reset my password and still same issue.
What have i done wrong?

Have you tried logging in with session ID?

Dunno what this was about, i messed aroound the whole day with it,
restarted the pc and moved the folder around and whatever no success, it
made me reset my poe password 2 times because it just gave me massive
timers for protection. Next day login in the morning, boom, works.
Thanks for help!
2015-07-28 22:20 GMT+03:00 Stickymaddness<EMAIL_ADDRESS>
Have you tried logging in with session ID?
—
Reply to this email directly or view it on GitHub
https://github.com/Stickymaddness/Procurement/issues/136#issuecomment-125725657
.

Haha alright, glad it's sorted!


handle app killed scenario of stop tracking state and follow the same state of the app after the app restart

in this sample app sticky notification clicking state scenario  not working properly on when app killed from recent apps
Steps to reproduce:
1)run the sample
2)start the tracking
3)press back or home button and kill the app
4>then click on the sticky notification it should open the app with 'Stop Tracking' instead of 'start tracking' since already a previous start tracking process is running there
it is the important thing since apps might kill at any time and restart for the delivery boy android mobile scenario, please provide this fix in the flutter sample itself

@LOG-TAG FYI ^^^

thanks for the quick fix, any plans for hypertrack/views-android clone for flutter ?

@LOG-TAG Nobody requested it before. You can create a feature request here


Fix refresh token auth bug

Fixes https://github.com/workos/authkit-remix/issues/7
When re-authenticating via refresh token, the new session plus refresh token wasn't being saved correctly. This meant that if you re-authed via refresh token, then refreshed the page you'd get a stale token error and have your session wiped.

@PaulAsjes does this mean we need to pass the headers returned from the withAuth function to the json response in every loader/action we have?

@BenjaVR we've had some internal discussions and are going to be changing the API surface a bit so you don't have to do that.

For what it's worth, Clerk does an amazing job with their Remix SDK, might be worth it to take a look at how they tackle this?
At first glance it seems weird to actually return the withAuth result.

Noting inconsistent use of ports. Some changed to 2884. Is that intentional?

It's just in the readme. "2884" spells "auth" and I thought it was cute.

@BenjaVR Looking at Clerk's docs I think they landed on a similar pattern: https://clerk.com/docs/quickstarts/remix#configure-root-auth-loader

@BenjaVR Looking at Clerk's docs I think they landed on a similar pattern: https://clerk.com/docs/quickstarts/remix#configure-root-auth-loader

@PaulAsjes Clerk only requires you to wrap your loader in root.tsx, but not on every route you want to get the user authenticated.
I don't know the specifics about their implementation though, I've just used it in some projects.


eth_callMany doesn't accept 'pending' blockTag

Describe the bug
sending a request to eth_callMany should allow the usage of the 'pending' blockTag, but when a request is sent using this it throws an 'invalid block' error.
git diff to resolve is here: (created by replicating the code from the debug_traceCallMany handler, which accepts the 'pending' tag as expected.
diff --git a/crates/rpc/rpc/src/eth/api/call.rs b/crates/rpc/rpc/src/eth/api/call.rs
index 675ef3aa5..e077b36cb 100644
--- a/crates/rpc/rpc/src/eth/api/call.rs
+++ b/crates/rpc/rpc/src/eth/api/call.rs
@@ -99,13 +99,14 @@ where
         let transaction_index = transaction_index.unwrap_or_default();

         let target_block = block_number.unwrap_or(BlockId::Number(BlockNumberOrTag::Latest));
-
+
         let ((cfg, block_env, _), block) = futures::try_join!(
             self.evm_env_at(target_block),
             self.block_with_senders(target_block)
         )?;

-        let Some(block) = block else { return Err(EthApiError::UnknownBlockNumber) };
+        let block = block.ok_or_else(|| EthApiError::UnknownBlockNumber)?;
+
         let gas_limit = self.inner.gas_cap;

         // we're essentially replaying the transactions in the block here, hence we need the state
@@ -115,7 +116,7 @@ where

         // but if all transactions are to be replayed, we can use the state at the block itself
         let num_txs = transaction_index.index().unwrap_or(block.body.len());
-        if num_txs == block.body.len() {
+        if !target_block.is_pending() && num_txs == block.body.len() {
             at = block.hash();
             replay_block_txs = false;
         }```

### Steps to reproduce

eth_callMany rpc call with, for example:
`[{"transactions":[{"data":"0x70a08231000000000000000000000000000000dbc80bf780c6dc0ca16ed071b1f00cc000","to":"0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2"}],"blockOverride":{"timestamp":1711546233}},{"blockNumber":"pending"},{}]`

### Node logs

_No response_

### Platform(s)

Linux (x86)

### What version/commit are you on?

4d798c7b6 build from main

### What database version are you on?

Current database version: 2
Local database version: 2

### What type of node are you running?

Archive (default)

### What prune config do you use, if any?

_No response_

### If you've built Reth from source, provide the full command you used

cargo build --release

### Code of Conduct

- [X] I agree to follow the Code of Conduct

do you know if other clients that support eth_callMany support a blocktag?
not mentioned here, so I'm not sure where we should put that? at last position?
https://www.chainnodes.org/docs/ethereum/eth_callMany

hmm,
this should be possible via the second argument, the statecontext which supports blockNumber: BlockId

oh I think json parsing might be wrong for Statecontext, checking

hmm,
this should be possible via the second argument, the statecontext which supports blockNumber: BlockId

Yes, agreed. The payload object i provided was ``[{"transactions":[{"data":"0x70a08231000000000000000000000000000000dbc80bf780c6dc0ca16ed071b1f00cc000","to":"0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2"}],"blockOverride":{"timestamp":1711546233}},{"blockNumber":"pending"},{}]  which included that stateContext override for blockNumber


[Request-for-external] page 343 "Check Credit Limit" - SalesLineShowWarning

Can you please remove [Scope('OnPrem')] from procedure SalesLineShowWarning in page "Check Credit Limit" (343).

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


Guide: links errors

If you look in the source of the left menu of the guide (http://www.yiiframework.com/doc-2.0/guide-README.html), you will find several links pointing to "./guide-README.html".
For example, Special Topics > Advanced Project Template
Whereas if you look at the same link in the main page, you find a useful link.
Could you correct it?
Yii seems to be missing a good navigation core system.

Duplicate of #9922


Allow list collaborators for users with Read access to repo

Fix for issue #9956.

@sd1998 Do you have possibility to install gitea build tools (https://docs.gitea.io/en-us/hacking-on-gitea/) and run make fmt? Continuous integration is picky about style and it can be hard to get it right manually.

@sd1998 just update branch and CI just restart ...

@6543 done.

@lunny your review is required.

@sd1998 can you "update" :)

@lunny need your review

ping LG-TM


React 18 with MUI is working fine

Duplicates

[X] I have searched the existing issues

Latest version

[X] I have tested the latest version

Current behavior 😯
Currently Material UI is not supposed to work with React v18 as we can see support for React v18 is being worked on: https://github.com/mui/material-ui/milestone/45
But I just installed newest React v18 with Material UI and started my project and it runs without warnings and errors?
So is support for React 18 already added or should I better downgrade and wait until the milestone is complete?
My dependencies that I use and do not cause errors.
 "dependencies": {
    "@emotion/react": "^11.10.0",
    "@emotion/styled": "^11.10.0",
    "@mui/icons-material": "^5.8.4",
    "@mui/material": "^5.9.3",
    "@mui/types": "^7.1.5",
    "@testing-library/jest-dom": "^5.16.4",
    "@testing-library/react": "^13.3.0",
    "@testing-library/user-event": "^14.4.0",
    "@types/jest": "^28.1.6",
    "@types/material-ui": "^0.21.12",
    "@types/mui-image": "^1.0.0",
    "@types/node": "^18.6.3",
    "@types/react": "^18.0.15",
    "@types/react-dom": "^18.0.6",
    "@types/react-redux": "^7.1.24",
    "mui-image": "^1.0.7",
    "react": "18.2.0",
    "react-dom": "18.2.0",
    "react-scripts": "5.0.1",
    "styled-components": "^5.3.5",
    "typescript": "^4.7.4",
    "web-vitals": "^2.1.4"
  },
"devDependencies": {
    "@types/styled-components": "^5.1.25"
  }

Expected behavior 🤔
No response
Steps to reproduce 🕹
Steps:

Context 🔦
No response
Your environment 🌎

npx @mui/envinfo
  Don't forget to mention which browser you used.
  Output from `npx @mui/envinfo` goes here.

So, we should update the description of this milestone https://github.com/mui/material-ui/milestone/45 to be clearer. It's not exploring how to take advantage of React 18.

Ok this makes sense, thank you for the clarification! I assumed it is not compatible because of the description in the milestone:

If it is supported, can we update peer dependencies in package.json's to allow install in v18 environment?

Hi!
I think we can update peerDependencies with "react": ^17.0.2 || ^18.0.0, or this change are included on milestone?
If this is correct I can open a PR for that.
https://github.com/mui/material-ui/blob/db6c358d0e83da10968ec81b1a95e11a8e3bb3d0/packages/mui-styles/package.json#L42

@BearCooder I have updated the title and description of the GitHub milestone to be clearer https://github.com/mui/material-ui/milestone/45.

@grzegorzjudas @AntonyF-Andreani @mui/styles would be a different discussion, see https://github.com/mui/material-ui/issues/32142


Portal Footer broken layout & positioning mobile devices only

Please note that issues that do not follow this template will automatically be rejected.
Use the following form to submit ask a question related to this repo. If you have an issue related to the SharePoint Framework or its documentation, please submit the issue at https://github.com/SharePoint/sp-dev-docs/issues/new. This will help us respond to your issue faster.

Thank you for asking a question. We appreciate your feedback - to help the team to understand your needs, please complete the below template to ensure we have the necessary details to assist you.
(DELETE THIS PARAGRAPH AFTER READING)

Category
Portal Footer - Position and Layout suddenly broken

[x] Question
Does anyone have a solution for the portal footer layout and positioning breaking in mobile browsers only, appears fine in all other browsers?

The portal footer appears at the bottom of the page but stays fixed in front of the webparts and does not scroll properly.
Question

Thank you for reporting this. We'll take  look as a bug and add it to the backlog!

Here is the workaround I used for this issue:
.sp-placeholder-bottom{
position: fixed!important;
left:0px;
bottom: 0;
width: 100%;
}

HI @JamesHForsytheIV
My I ask ...where/how did you implement this workarround?

Here is the workaround I used for this issue:
.sp-placeholder-bottom{
position: fixed!important;
left:0px;
bottom: 0;
width: 100%;
}

First I updated the PNP Footer to V2...
Next I modified our CSS file that is injected by PNP inject web extension with the following css:
.sp-placeholder-bottom {
position: fixed!important;
left: 0px;
bottom: 0;
width: 100%;
z-index: 100;
}
The placeholder previously worked this way in mobile OOB, the placeholder must have changed or there is some react core library missing on tenant...

@JamesHForsytheIV thank you for sharing the fix. I am glad the fix is working for you, though since you are providing new styling over elements that Microsoft does not support direct customization to, we cannot inject this directly into this project. MS could change that class name at any time, without warning, and we want this project to follow the practice of never touching aspects of the DOM that our custom components did not inject themselves.
Your fix is good, just be aware it may break at some point with no warning.
Overall though, when I went to test the collab / portal footer in iOS, it properly fixed to the bottom of the screen. Possibly MS fixed their footer placeholder container?
Im going to close this issue for now as the issue appears fixed.

I’ll test what you mention but I doubt it’s fixed, there is also issue with
OOB navigation on our tenant and not on another so I question what really
works tenant to tenant.
On Fri, Jul 31, 2020 at 6:09 PM Eric Overfield<EMAIL_ADDRESS>wrote:

@JamesHForsytheIV https://github.com/JamesHForsytheIV thank you for
sharing the fix. I am glad the fix is working for you, though since you are
providing new styling over elements that Microsoft does not support direct
customization to, we cannot inject this directly into this project. MS
could change that class name at any time, without warning, and we want this
project to follow the practice of never touching aspects of the DOM that
our custom components did not inject themselves.
Your fix is good, just be aware it may break at some point with no warning.
Overall though, when I went to test the collab / portal footer in iOS, it
properly fixed to the bottom of the screen. Possibly MS fixed their footer
placeholder container?
Im going to close this issue for now as the issue appears fixed.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/pnp/sp-starter-kit/issues/408#issuecomment-667407043,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQALJULTMU5ZAFFISVDXUO3R6M6H5ANCNFSM4OCYA47Q
.

@eoverfield Hi Eric,
I am having the same problem as James on two different Tenants.
Just tested this with the Shareoint app on a IPad.
The footer is still not sticking at the bottom.
Why are you closing this issue while at least two users still have this problem on different Tenants.
To me the issue is not fixed.


renames psrBatchLogger to psrLogger

The Bootstrap function can be used to hook into error reporting w/o requiring batch processing. This PR renames the logger's property to make this clear.

Bot!! I signed it years ago!!


Update about-self-hosted-runners.md

Don't advise allowing access to *.blob.core.windows.net as it allows access to all azure blobs in the world, for any action.  Better to allow access to only specific blob stores.

Why:
Relates to: https://github.com/actions/actions-runner-controller/issues/3406
Previously, the docs said to only allow specific azure blob stores, but now they say to allow *.blob.core.windows.net which is much less secure. Any-bucket controlled by anyone, for any operation in the whole of Azure, worldwide, isn't exactly controlled. Surely it's enterprises paying for github enterprise that want selfhosted runners, and don't want to give unfettered access to build agents that this exists for?
What's being changed (if available, include any code snippets, screenshots, or gifs):
Just a list of hostnames
Check off the following:

[ ] I have reviewed my changes in staging, available via the View deployment link in this PR's timeline (this link will be available after opening the PR).

For content changes, you will also see an automatically generated comment with links directly to pages you've modified. The comment won't appear if your PR only edits files in the data directory.

[x] For content changes, I have completed the self-review checklist.

@diroussel Thank you again for submitting this PR 💛 Our engineering team provided the following response upon review -

We today already publish a list of URLs specifically as part of the https://api.github.com/meta if [the customer] wishes to allow specific access and that list is updated dynamically over time as we add more storage accounts to the system. This is on the customer though to be sure to evaluate their own firewall rules and what they do and don't want to allow for their own needs.

For this reason, we won't be accepting this contribution, but greatly appreciate the time you've taken on this PR! If you're looking for another issue to pick up, take a look at our help wanted section to find open issues you can work on ✨


Enable go to definition for markdown links

Feature request
Enable triggering go to definition on a markdown reference link to jump to  the link definition
[text][link] // trigger on link here

[link]: https://example.com

Go to def should jump to the definition at the end of the file

Related #146277

Created a PR https://github.com/microsoft/vscode/pull/148017 fixing this


Fuzzing

Add fuzzing tests to each of the data structures:
https://rust-fuzz.github.io/book/cargo-fuzz.html

#10


pupistry diff is too noisy

pupistry diff is too noisy when doing branches, since any change visible in multiple branches gets diffed multiple times. Additionally, creating a new branch creates an initial mega-diff of what has changed.
The diff function needs to be a lot smarter in order to scale beyond small users. This ticket is a reminder to self to fix, or an invitation for a pull request from you, the wonderful reader of this issue whom would like to fix it for all. :-)

Opened in the wrong project, sigh


Skip merge accessors before combine nodes/meshes

Running merge accessors before nodes/meshes when multiple accessors can
be independent but have the same data causes one of the accessors to be
deleted and both meshes to use the same accessor. When this happens,
combineNodes can no longer merge the meshes.
Skipping merge accessors allows the nodes to be merged first and the
accessors can be merged during the second call to
mergeDuplicateProperties.

Good fix for now. This sort of issue will be fixed in the cleanup branch.

I'm not sure you actually want to do this.
The reason that combineNodes doesn't merge meshes that share attribute data is because we flatten out transforms into the data, so if two meshes use the same data and the transforms are different, we can't apply different transforms to the same data.
If you skip this step, a duplicated accessor may get its data transformed by combineNodes and then they won't be combined later because the data has changed, bloating the model unnecessarily.
I think what you really want here is to add a smarter check to combineNodes for the case where two meshes contain primitives with shared attribute accessors, but the transform that would be applied is the same, so there is no conflict.

Hit merge right as you left your comment... we can fix/revert if needed.

Haha sorry guess I need to learn to type faster


machine translation

Is there any way for machine translation to work for a language other than English? PTBR for example

Not currently, it's up to the PTBR team if they want that.


make restart handle the terminal properly

new restart function is great but it detaches from the parent terminal but it should stay attached to it, is this even doable since the detach seems to be hidden in runtime. For now though it does not necessarily appear to as soon as you hit a key and get a prompt appearing in the logging. Oh, even that connection stops so this needs a little research

"github.com/kardianos/osext" contains a function to get the current executable, then syscall.Exec handles restarting it and current process exits. Works perfectly exactly as intended.


Spam Video ID Submission

Duplicate Links

[X] Yes, I checked that the ID is not currently in the list
[X] I read the wiki explaining each different categories and examples before submitting

(Required) Spam Comment Direct Link
https://www.youtube.com/watch?v=ESW3gXUo1QM
(Optional) Screenshot of comments using the link

(Required) List of the spam video IDs / Links
WDNel-fXk3w

Added


fix: generate alias files for nextjs import mapping

https://github.com/lucide-icons/lucide/issues/1482#issuecomment-1667976412

This is a good idea, this way we don't have to update those aliases files. I will test this with my NextJS PR

Hmm rollup is removing the aliases modules during build 😞 , I searching for a solution to preserve those modules


Flexible multiple clips

Fix for #420.
This builds on the example created in PR #418, so I'm going to leave as a draft PR until #418 is merged.

I forgot about this back in Feb...
#418 is now merged, and the changes on top of that look good to me.
@vincentfretin - would appreciate if you could cast an eye over this before I merge it.


Enhancement 2: add missing versions

Various offsets are listed https://github.com/bongtrop/hbctool/issues/17

In case commit gets closed copying the comment as is from aancw
I've listed commit tree url for every hermes bytecode version. So it can be easy to search for building the opcodes:
78 https://github.com/facebook/hermes/blob/c57fde25efaef83cec7e80b27e064d31d7bb166e/include/hermes/BCGen/HBC/
79 https://github.com/facebook/hermes/tree/05b29726e766594ae0a9be7947dd1378303d9a42/include/hermes/BCGen/HBC
80 https://github.com/facebook/hermes/tree/e70045d8430e7913e2f74695402d9fb12214e4f4/include/hermes/BCGen/HBC
81 https://github.com/facebook/hermes/blob/40aa0f7aa907aefcfc85c00c76fb425454ed30fd/include/hermes/BCGen/HBC/
82 https://github.com/facebook/hermes/tree/65de349ab1bde8062b54346c2d861cbde71d5841/include/hermes/BCGen/HBC
83 https://github.com/facebook/hermes/tree/87fc45298fb62dd9d85d76405c8f4782647be561/include/hermes/BCGen/HBC
85 https://github.com/facebook/hermes/tree/b74eb2d5bff8ffbfa6914746261c4efd2c4223c5/include/hermes/BCGen/HBC
More to be added. On progress.

Currently implemented versions.
HBC89, HBC85, HBC84, HBC83, HBC76, HBC74, HBC62, HBC59
I dont see a specific need to implement other versions. only versions missing from this lot are.
78,79,80,81,82
However a lot of these versions are not used in react native versions and right now react native has enabled hermes by default with version 89 so better to spend time on those.
This issue can be reopened to work on the new.
83: https://github.com/cyfinoid/hbctool/commit/c19803f8acc5674c8907a48f5a92344a5b09909f


I'm failed to configure the Mako's tree shaking

As the title says

So how to configure the tree shaking in the official way? @petercat-assistant


custom-repos: FIXES - route module.

Type of change
What is it?

[X] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Documentation update
[ ] Tests update
[X] Refactor

Checklist:

[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works
[X] New and existing unit tests pass locally with my changes
[X] I run go fmt ./... to check that my code is properly formatted
[X] I run go vet ./... to check that my code is free of common Go style mistakes

Codecov Report

Merging #1053 (17480e7) into main (344968b) will increase coverage by 0.31%.
The diff coverage is 15.25%.

@@            Coverage Diff             @@
##             main    #1053      +/-   ##
==========================================
+ Coverage   31.26%   31.57%   +0.31%
==========================================
  Files          46       46
  Lines        5662     5600      -62
==========================================
- Hits         1770     1768       -2
+ Misses       3638     3584      -54
+ Partials      254      248       -6

Impacted Files
Coverage Δ

pkg/services/errors.go
36.66% <0.00%> (ø)

pkg/routes/thirdpartyrepo.go
22.03% <15.51%> (+4.04%)
:arrow_up:

pkg/services/devices.go
59.48% <0.00%> (+0.39%)
: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 344968b...17480e7. Read the comment docs.

Test results are available in Ibutsu. The test run IDs are:
83e5313a-5d59-4701-857a-5d301b811bc6
dce9f42d-fbb5-4b1c-956a-13f30ad0e2d5

/retest

Test results are available in Ibutsu. The test run IDs are:
3bc212ff-7152-4121-9f45-fcaf9b7b0b4d
f0530c2d-fa5f-418c-846f-6150db908877

Test results are available in Ibutsu. The test run IDs are:
7a275526-9923-442f-a603-4898d101ddb6
c9144e26-750a-4ff8-a8bf-7fc2defcf1fd

@mergifyio refresh

@mergify unqueue

@mergifyio requeue

@mergifyio refresh

Test results are available in Ibutsu. The test run IDs are:
085e7fbd-3e22-4c6e-a28d-3589902dcdd0
6ccb11b5-4f9a-45ec-b746-74f432ec34e6

Test results are available in Ibutsu. The test run IDs are:
3d35b47f-e4ea-4b30-874a-de127f6e032e
5b2df22a-6266-427d-af7a-4f7f46380182


tdf: unstable-2024-10-09 -> 0.2.0

This PR:

Adds me as a maintainer for tdf
Adds MacOS to tdf's platform list
Bumps tdf to the newly released 0.2.0 version of tdf

I tested with ghostty on aarch64-darwin and x86_64-linux. Seems to work.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[x] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

@ofborg build tdf tdf.passthru.tests


Block: Add story selector for embedding single story

Context
We want to make the Single Story embed block more similar to the image block, allowing to choose between selecting an existing story or inserting from URL:
Mock:

The URL option would show the URL input field in a popup/tooltip like in the Image block.
The "Select Story" button would open the story selector we already have today, but only allow selecting 1 story (and not show a reorder option, obviously).
Summary
Make the Single Story embed block more similar to the image block.
Relevant Technical Choices

Updated PHP logic, new story is created, the id of the story is embedded. This means in future, we have this data stored. It also means that user can edit the story block.
Update E2E and Unit tests.
Moved all the story picker and related files into share components from there current location in selected stories block type.
Rename Story url to story embed.
Make StoryPicker much generic, so it can be used in both places.

To-do

User-facing changes
New interface for selecting stories.
https://user-images.githubusercontent.com/237508/134694059-27e991dc-e2c5-4747-a6e1-0b18c3a73d1d.mov
New interface for embedding via URL.
https://user-images.githubusercontent.com/237508/134694097-7e5eb37c-b015-4e54-9005-fdb2c1ef62db.mov
Testing Instructions

[ ] This is a non-user-facing change and requires no QA

This PR can be tested by following these steps:
Embed story via selector.

Create a story.
Create a new post.
Insert a web story block.
Click Story embed.
Click Select Story.
Select a story.
See embedded story.
Edit block, see Replace story button
Select another story.
See embedded story.

Embed story via URL.

Create a story.
Create a new post.
Insert a web story block.
Click Story embed.
Click insert from url.
Enter a url for a story. Example - https://stories-qa-wordpress-amp.pantheonsite.io/?web-story=test-story
See embedded story.
Edit block, see Replace url button
Enter a url for a story.
See embedded story.

Reviews
Does this PR have a security-related impact?

Does this PR change what data or activity we track or use?

Does this PR have a legal-related impact?

Checklist

[x] This PR addresses an existing issue and I have linked this PR to it in ZenHub
[x] I have tested this code to the best of my abilities
[x] I have verified accessibility to the best of my abilities ([docs](https://github.com/google/web-stories-wpx
[x] /blob/main/docs/accessibility-testing.md))
[x] I have verified i18n and l10n (translation, right-to-left layout) to the best of my abilities
[x] This code is covered by automated tests (unit, integration, and/or e2e) to verify it works as intended (docs)
[x] I have added documentation where necessary
[x] I have added a matching Type: XYZ label to the PR

Fixes #8845

There are some e2e test failures due to React warnings and probably some bugs

There are some e2e test failures due to React warnings and probably some bugs

E2E tests are now passing. Super simple fix!


Merge branch 'combine-main' into master for better ease of development

As discussed, let's merge combine-main into master to make ongoing development easier.
@lorenzofiamingo, @ziadtamim, and @mortenbekditlevsen FYI. Your working branched should update automatically once we close the combine-main branch.
Next steps:

Migrate tests to SwiftPM (@paulb777)

Removing CocoaPods support
Make sure we're able to run the tests from SwiftPM

Need to verify we have test coverage across APIs
API review of existing public APIs + proposal to keep adding APIs under "community support" with @ryanwilson reviewing the new additions.

LGTM, pending two open questions for @ryanwilson

BTW, I suggest doing the master merge from the command line to avoid squashing the branch history.


Distinguish between "levels" of data release

Is your feature request related to a problem?
At the moment, in addition to versions of a data file, there can be several functional levels of data depending on the stages in the processing.
This could include:

"raw" data with no calibration applied (NRT?)
partially finalised data but not fully signed off (or would this be closer to NRT?)
public access data from e.g. CEDA repository (QA/QC?)

This data will need to be distinguished and sometimes compared.
c.f. ICOS data level
Describe the solution you'd like
Some way to distinguish between these different "data levels" using the metadata e.g. add data_level key or otherwise to observation metadata.
Features needed:

This will need to be decided in some way in advance (e.g. 2 = public facing data, 1 = local processing)
Could allow for flexibility (e.g. 1.1, 1.2, 1.3 etc. or could this be covered by existing versioning?)
Can be related to where the data originates OR an input e.g. 2 = from external resource / matches to data level on that platform.
Can tie into ranking where data level could be used as a distinguisher to specify a preference between "degenerate" data

Describe alternatives you've considered
No response
Additional context
No response

I like the idea of flexibility. It probably makes sense to keep the "L1" and "L2" definitions the same as ICOS. So having the ability to specify sublevels (e.g. L1.1, L1.2) could help with this? Then all L2 data could match a publicly-accessible data repository (and specify the source in the metadata?).

@joe-pitt I suppose the main benefit of the "sub-levels" would be to allow easy comparison between pre-finalised versions of the data? Is that the use case you would have in mind for this?

Yes - to allow comparison, and also to allow the NRT data to be L1, the final archived data to be L2, and the partially-finalised data to have some level in between. From a pure openghg perspective, it generally seems useful to allow for this flexibility in level naming (i.e. level numbers don't have to be integers). Then in the "acrg implementation" of openghg (i.e. the object store that we maintain on BP1) we can decide exactly how we want to define each sub-level (but in principle another group could maintain a local object store and define different sub-levels).

Great, that makes sense. We could either do this (A) as proposed above with non-integer levels in some way or (B) have an additional label (e.g. data_sub_level). Either way this could be an extra way to distinguish which can be set by the data owners.
Another question around this is if we would want a search for "L1" to return ALL data labelled with L1 (even if this has a sub-level) OR only the data labelled as "L1" with no sub-level.

Yeah good point - an additional data_sub_level label works just as well. It could potentially help to clarify things too - especially if there was a comment associated with each data_sub_level explaining what it refers to. I guess in that case it would make sense for a search of level=L1 to return all the sublevels? But I don't have a strong view on this - people with more end-user experience are probably better able to see the different pros/cons

For OpenGHG

Can add new options: "data level", "data sub level" - check alignment with ICOS Carbon Portal

also "data sub level comment" - or something less cumbersome - Joe: something to help describe what is in the sub level
sub level can also be highly flexible as needed (could be numeric or otherwise)
level should be more strict - has to be an integer, >=0

Need to consider how this ties into ranking for both us and for the general product (ADVANCED)

Do we want this to be completely empty or could this be shipped with a few basic rules? Could allow these rules to be set up by choice?

Using command line interface could be good. E.g. $ openghg --setup-ranking

Could present each basic rule and ask if user wants this to be included?

Use highest height when there is choice?

Use highest level when there is a choice?
Would need to include "highest" keyword and set up in some way.

From Architecture planning meeting on 07/09/2023. Still add data_level but rather than adding a data_sublevel keyword could use the versioning for this, moving to the following.
Planning

Initial Step: Add ‘data_level’ as a general key for all objects
Next phase: Change how versioning is detailed

Include details of versions within the metastore

Full UUID becomes uuid/version e.g. 4d5-63u-rr3/v1
Could split this out to be within a version column (just numerical)
[Longer term could de-normalise – linking to an entry per datasource containing all the versions]

Need to add layer within searching to group together details linked to the same Datasource and return the latest version

Group on everything except specific version and version related details.
Allow search for specific versions.
“version” becomes special essentially

Can also include version specific metadata

“label” / “comment” as a free form text input for each added piece of data – this can be different per version and added by the user
“date” / “timestamp” for when the data was added to the object store. This would be automatically generated.

Consider how to make sure this is not a breaking change – need to ensure backwards compatability e.g. don’t worry about entries in the metastore with no version entry for instance and check there’s only one entry.

Can I check I've understood - now the version number will replace the data_sublevel? One of my use cases is the AGAGE data, where we have L1 data (NRT), L2 data (from the archive), and also some data that is halfway between. This data has been checked by station operators and has been through the European data review process, but has not yet been signed off for release by the wider AGAGE group. It is this data that Alistair uses in his annual report/NIR inversions. I had in mind that I would call this something like: data_level=1, data_sublevel=Euro_QC. Now should I use: data_level=1, version=Euro_QC?

I think the idea is that if data at level X is updated, it is a new version, but it is still level X. If you want to add data at level X+1, it is a new "datasource", starting at version 0, and the data at level X is unaffected.
So maybe we need L0 (NRT), L1 (some checks, not signed off), and L2 (signed off for release). (Or L1, L1.5, L2 if NRT must be L1.)
For versions, I think the plan was, for each level, start the version numbers at 0 and just use the next whole number when a version is added. This made sense to us for cases when a new version was just a minor correction to the data. It sounds like NRT and Euro_QC should be different levels. (So if you decide to update the data after it has had some checks, but it is still not ready to be L2, then it would be a new version of the Euro_QC level.)
I think with Rachel's versioning updates, you can decide if a new version will replace the old version, or if both versions will be kept. Although for observations, it might be worth it to just keep most copies, since the data is small. (Then if the data is updated after someone has used it for an inversion, we would know exactly what data they used.)
We also discussed adding an option to include a message when data is updated. So you could have L1 include NRT and Euro_QC, and mention in the comment that the new version added is Euro_QC. I don't think we planned to make the comments searchable, but the default behaviour would be to return the latest version, so once NRT is updated to Euro QC as a new version, the Euro QC would be returned by default.
Does that make sense/seem like it would work for you?

Can I check I've understood - now the version number will replace the data_sublevel? One of my use cases is the AGAGE data, where we have L1 data (NRT), L2 data (from the archive), and also some data that is halfway between. This data has been checked by station operators and has been through the European data review process, but has not yet been signed off for release by the wider AGAGE group. It is this data that Alistair uses in his annual report/NIR inversions. I had in mind that I would call this something like: data_level=1, data_sublevel=Euro_QC. Now should I use: data_level=1, version=Euro_QC?

Happy to set up a chat about this so we can make sure this doesn't move too far away from what you were thinking (or just stick with the previously discussed plan)? The idea of folding this into the versioning was so this didn't create additional work for you when adding new data (i.e. you always have to label if) but if it isn't mapping to what would work practically then we can re-tool it.

Ok cool - yeah essentially what I want is the freedom to set arbitrary levels. When we discussed this before, I think the following thoughts came up:

It would be nice to stick to the ICOS convention for data levels (NRT=1, final archive=2)
Having non-integer data levels might be confusing
Therefore to accommodate arbitrary levels (like my Euro_QC) we would have a data_sublevel

I'm not too concerned about non-integer data levels - it might have been @mrghg who made this suggestion? Either allowing flexibility in the data levels or having a sublevel would be fine by me.

Comment on the current "icos_data_level" key, is that we need to consider how this relates to the more generic data_level key.
Suggestion for this would be:

retire icos_data_level and just use data_level instead. When pulling from ICOS what was icos_data_level would be used for data_level instead but could also be set in other circumstances as well.

Would there be any reason not to do this?
We need to consider and ensure this still works well enough with a current object store which already used icos_data_level.

Retiring icos_data_level sounds fine to me

Comment on the current "icos_data_level" key is that we need to consider how this relates to the more generic data_level key.
Suggestion for this would be:
* retire `icos_data_level` and just use `data_level` instead. When pulling from ICOS what was `icos_data_level` would be used for `data_level` instead but could also be set in other circumstances as well.

Would there be any reason not to do this?
We need to consider and ensure this still works well enough with a current object store which already used icos_data_level.

New issue created for this - #1067

Keys have now been added.


Cannot compile inner classes in voc

I cannot compile a python script with inner classes. For example, in my voc_test.py file:
class Thing(object):
    class InnerThing(object):
        pass

I invoke voc voc_test.py and get this error:
Traceback (most recent call last):
  File "/Users/tre11/anaconda2/envs/python3.5/lib/python3.5/site-packages/voc/python/ast.py", line 160, in visit
    super().visit(node)
  File "/Users/tre11/anaconda2/envs/python3.5/lib/python3.5/ast.py", line 245, in visit
    return visitor(node)
  File "/Users/tre11/anaconda2/envs/python3.5/lib/python3.5/site-packages/voc/python/ast.py", line 49, in dec
    fn(self, node, *args, **kwargs)
  File "/Users/tre11/anaconda2/envs/python3.5/lib/python3.5/site-packages/voc/python/ast.py", line 284, in visit_ClassDef
    klass = self.context.add_class(class_name, extends, implements)
AttributeError: 'Class' object has no attribute 'add_class'

Problem occurred in voc_test.py
Node: ClassDef(name='InnerThing', bases=[
    Name(id='object', ctx=Load(), lineno=2, col_offset=21),
  ], keywords=[], body=[
    Pass(lineno=3, col_offset=8),
  ], decorator_list=[], lineno=2, col_offset=4)

I am using python 3.5 and the latest master version of voc

For context, I'm trying to compile dateutil.parser

Thanks for reporting!
The solution to this is to add an add_class method to Class class in the klass.py file similar to the one in module.py.
Which is also quite similar to the one in methods.py, it might be interesting to refactor the common parts.


Interate with a CI system and generate downloadable executables.

Consider using the cross crate to create executables for Linux/x86 and Windows.

Requires:

[ ] On merge: build and run tests.
[ ] On successful merge: tag repository, ideally using version in toml file, and only if a tag does not exist.
[ ] After tagging, create release.
[ ] After release is created attach assets as individual files or as an archive.

Is this one work multiples?


1.13.2 Materials not working

I cant use Yellow_concrete because you aren't using api-version 1.13 in your plugin.yml. Therefore, spigot causes issues and doesn't thing it's a material.

We now release specific versions of the bukkit plugin for post 1.13 - download the latest version from your Tebex control panel


$Diff appears to recreate original type instead of diffing

Flow version: 0.190.0
Given type Pick:
type Test = {
    a: number,
    b: string,
}

type Pick<T, K> = {
    [K]: T[K];
};

I can do the following:
type TestAOnly = Pick<Test, "a">;
// THIS WORKS; try changing a's value to a string or adding values
const x: TestAOnly = {
    a: 4,
    //b: "string",
    //c: 4,
};

I can then also do this (you can try it without this step too, this was me experimenting on getting this working, which I couldn't):
type TestAAsAny = $ObjMapConst<TestAOnly, any>;
// THIS WORKS; try adding b, too
const y: TestAAsAny = {
    a: "test",
};

Since these two steps work, it follows that this should also work, but instead of giving the difference between the two types (i.e. a type with only b), it gives back a type equivalent to the original Test type.
type TestNoA = $Exact<$Diff<Test, TestAAsAny>>;
// or type TestNoA = $Exact<$Diff<Test, TestAOnly>>;
// THIS SHOULD BE AN ERROR
// Instead, this type seems to work exactly like the original type Test
const w: TestNoA = {
    a: 5,
};

Expected behavior
It should give the difference of the two types.
Actual behavior
You can see the actual behavior on Try Flow below.

Link to Try-Flow or Github repo: Link to Try-Flow

Well, nevermind. I got things working.
See here
My original pick type was not correct (it was causing a union of the value types). Fixing that, seems to have corrected things in my example.
Still, I am confused by what happened above - even with the unioning of types, I would expect it to work in the final stage because this is about omitting the keys.

Closing since we now have Pick


"A fatal error occurred" when opening the website

Http response at 400 or 500 level
The above error occurred in task st
created by takeEvery(network/selectNetwork, st)
created by lt
Tasks cancelled due to error:
takeEvery(network/selectNetwork, st)
undefined
the above error occurred when simply trying to open web page "https://testnet.oasis-wallet.com/"

Hi @mohammed-najib,
Please be careful. Our official Oasis Wallet -  Web can be found at https://wallet.oasisprotocol.org/. Then you can switch between mainnet and testnet.

https://testnet.oasis-wallet.com/ -> now redirects to https://wallet.oasisprotocol.org/

https://testnet.oasis-wallet.com/ now redirects to https://wallet.oasisprotocol.org/

did oasis take control of the domain? or is that only an observation of what an external domain is doing right now?

did oasis take control of the domain? or is that only an observation of what an external domain is doing right now?

Thanks for the remark. The oasis-wallet.com domain has been transferred to the Oasis Foundation and we set up the redirect. So, indeed, Oasis Foundation controls the domain.


Replace Unicorn with Puma

Heroku now recommends using the Puma webserver. The previously
recommended webserver, Unicorn, is susceptible to slow client attacks.

https://devcenter.heroku.com/changelog-items/594

:+1:

Okay before merging I'm going to try actually running an app with this server and these config.

And leave this at least a day.

Definitely want to hear reports of people using this config in production before we merge this in.
Otherwise, makes sense and thanks for the PR. Good to squash and merge at your discretion.

@croaky @schneems updated with most feedback addressed.

This is great. I've been thinking we should be switching to Puma for a while, and I've always been uncomfortable with the slow client problem.
I think Upcase is a good mid-traffic app to try this on. I can hopefully try it out this week, but if you're looking for a test project, feel free to open a pull request there.

Thanks, Joe.

Since we now never specify the port in either puma.rb or the Procfile, will Puma still work with Foreman?

Foreman uses port 5000 by default. Also even if you start using rails s rails sees puma is in the gemfile and uses it by default, but won't use your config/puma.rb setup.

So, this will work with Foreman even if I use a custom port like foreman start -p 7001?

@gabebw - Yes. It will. Working for me here, currently.

Great!

(y)

I am swamped with other stuff right now - if anyone would like to take this over you have my blessing.

I'd happy to help out with this.

@calebthompson what's left to do in here? Rebase, squash and test? @pedrosmmoreira may do it, and I could help this Friday too.

It would be better to generate an app and throw it up on heroku with some crud scaffold to test the full stack. Suspenders tests aren't very comprehensive and this could break a lot.
Sent from my iPhone

On Feb 17, 2015, at 5:48 PM, Tute Costa<EMAIL_ADDRESS>wrote:
@calebthompson what's left to do in here? Rebase, squash and test? @pedrosmmoreira may do it, and I could help this Friday too.
—
Reply to this email directly or view it on GitHub.

@tute We should get a few thoughtbot projects using this config in the real-world before codifying it into Suspenders. Upcase, Hound, FormKeep, thoughtbot.com, Maitre-d are all good candidates. If they run well for a few days or a week, then we can feel good about swapping out a major component (web server) as the new default.

The other thing you can do is add a .foreman file that specifies some stuff, maybe?

We've run into issues using ember-cli-rails and a forking server (i.e. unicorn).
https://github.com/rwz/ember-cli-rails/issues/94
My understanding is that puma can be configured to have a single, non-forking worker in development, which would smooth over the difficulties with ember-cli-rails.
I'm willing to try out puma on my next ember-cli-rails project (heroku or otherwise).

I've used Puma a few times in the last month or so, for example on a production app serving an API for an active iPhone app. This change in general seems well-vetted now in prod.
@seandoyle I think you can set WEB_CONCURRENCY and MAX_THREADS to 1 each in development? Maybe we add that to .sample.env?
https://devcenter.heroku.com/articles/deploying-rails-applications-with-the-puma-web-server#config

@drapergeek and I tried setting UNICORN_WORKERS=1 to no avail.
I'll try out puma with WEB_CONCURRENCY=1 and MAX_THREADS=1.

@seanpdoyle How has Puma been running for FormKeep? Any settings in this PR that you recommend as different defaults?

@calebthompson Possible to push this over the finish line? Seems like we're ready. @halogenandtoast had one piece of feedback above.

:+1:

@calebthompsen I think you're available tomorrow? Possible to do a final review, merge this, and release a new version?
Seen a couple of brand-new apps recently getting slow client errors with Unicorn, Heroku, two dynos, almost no traffic.
Might be something worth grabbing from https://github.com/thoughtbot/hound/pull/846/files

Ready for final review.

I'm content with this. If it's a :+1: please go ahead and merge this.

Looks good to me.

:tada:


added more words to cspell file

added more words to the spell file .. i imagine you can setup a CI using this file config in the future

@ILiedAboutCake i dont understand why this pr is closed .. i only added words that was breaking the cspell check.


feat: repositories_client - Support gpgkey for Ubuntu

Support gpgkey/gpgcheck options for Ubuntu in repositories_client role.
Given the input:
repositories:
  - name: repo-no-gpg
  - name: repo-with-gpg
    gpgcheck: 1
    gpgkey: /usr/share/keyrings/gpgkey-12345678-keyring.gpg
    distribution: jammy main

The following output is produced at /etc/apt/sources.list.d
deb [trusted=yes] http://<IP_ADDRESS>/repositories//ubuntu/20.04/x86_64/repo-no-gpg ./

deb [signed-by=/usr/share/keyrings/gpgkey-12345678-keyring.gpg] http://<IP_ADDRESS>/repositories//ubuntu/20.04/x86_64/repo-with-gpg jammy main

Note: apt update command requires the key in signed-by option to be present, otherwise the command will fail.

Dear @ginomcevoy
My apologies for the delay. I was off few weeks.
Your changes make sens and are ok. However, repositories_client role is in the process of being migrated into collections.
I will push collections into master, so you can PR on it. Give me few days.

Ok, role has been updated. I will move it to collection just after your PR.
Are you able to solve merge conflicts ? Apologies for that.

I also need to apologize, I got busy with other stuff and forgot about this one. I will resolve conflicts in the next few days.

Hello @oxedions, I have updated the PR for "BB 2.0". Took a bit of time to test it with some inputs for bb_repositories.


exiftool: 12.80 -> 12.82

https://github.com/exiftool/exiftool/compare/12.80...12.82
Description of changes

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[x] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Upgraded exiftool to 12.82


Bump boto3 to version v1.28.42

Bump boto3 to version v1.28.42
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

/hold

only merge after #381

/test all

/unhold

/lgtm


Tests

Add tests for index.js and bin/index.js
closes #2

Coverage remained the same at 100.0% when pulling d833bfd08377e580b993c8dd71cf75dbc4af8925 on tests into 8037ac54da45f015ff5109661fdd6808e1f0ef48 on master.


add(docs): add llm input debug log

Close #906

:rocket:
This description was created by Ellipsis for commit f68392c19ad1708dd85203131d5b1d0726629cc8

Summary:
Added debug logging for input arguments in retry_sync and retry_async functions in instructor/retry.py.
Key points:

Added debug logging for input arguments in instructor/retry.py.
Updated retry_sync to log args and kwargs before function execution.
Updated retry_async to log args and kwargs before function execution.
Helps in tracing inputs passed to the LLM during retries.

Generated with :heart: by ellipsis.dev

Hmm have you tried using logfire or langfuse? I find that the logging is pretty good there and should work out of the box since we're using the base clients itself.

Hmm have you tried using logfire or langfuse? I find that the logging is pretty good there and should work out of the box since we're using the base clients itself.

Well, thanks for your timely reply and I haven't test these observability tools with instructor. IMHO, it will be very convenient if the instrctor library itself could provide some basic log. For example, in some simple project, the basic build-in logging library is enough. So I think these logs should be helpful in the situations where we don't(or can't) use some  observability tools.

openai has debug logs that call log everything.
that said i dont want instructor to be logging everything to debug, not all input data should be logged so I'll have to think harder about this


Add python3.8-dev to Travis jobs

Add py38 to tox
Add py38-dev job to Travis

FTR: Appveyor doesn't support python 3.8 yet.
Changelog-friendly one-liner: Add python3.8-dev to Travis jobs
Contributor checklist

[X] Provided the tests for the changes.
[X] Requested a review from another contributor.
[X] Gave a clear one-line description in the PR (that the maintainers can add to CHANGELOG.md on release).
[x] Assign the PR to an existing or new milestone for the target version (following Semantic Versioning).

Hello, @blueyed.
I don't mind, actually. Which pip version would you suggest? Maybe the piplatest?

Yeah, sounds good to me.

@blueyed
Thank you for the feedback! I've fixed the .travis.yml 👍


Document using / extending the Astro JSX definitions

This is very advanced usage, nonetheless we see some people do it. Notably, our official image integration use them to provide img props completions and type checking in the components
Using them is done through a triple slash directive, this works both in Astro files and in TypeScript files
---
/// <reference types="astro/astro-jsx" />

// Access them directly:
export type Props = astroHTML.JSX.ImgHTMLAttributes;
---

<img ...>

Extending them is done through a .d.ts file redeclaring the namespace:
declare namespace astroHTML.JSX {
  interface HTMLAttributes {
    mycustomattribute?: any;
  }
}

People tend to extend them whenever they want non-standard attributes while still having typechecking. Another case is when we made a mistake and some attributes isn't included in our definitions 😅

Maybe we can add this to our Typescript page? Are there other use cases for triple-slash directives augmenting ambient types we would want to mention?

Maybe we can add this to our Typescript page? Are there other use cases for triple-slash directives augmenting ambient types we would want to mention and does it matter where .d.ts are?

I do not think there's other use cases specific to Astro and it shouldn't matter where the .d.ts is in this case, though I have heard of issues when using a folder called "types" in the past


Move TestSpectrumSolver.h5 to proper folder

:pencil: Description
Type: :beetle: bugfix :vertical_traffic_light: testing
tardis-sn/tardis@2706faa (#2808) turns the spectrum tests into a module which corrects the path of the HDF file.
:pushpin: Resources
Examples, notebooks, and links to useful references.
:vertical_traffic_light: Testing
How did you test these changes?

[X] Testing pipeline
[ ] Other method (describe)
[ ] My changes can't be tested (explain why)

:ballot_box_with_check: Checklist

[ ] I requested two reviewers for this pull request
[ ] I updated the documentation according to my changes
[ ] I built the documentation by applying the build_docs label

Note: If you are not allowed to perform any of these actions, ping (@) a contributor.

No problem!
On Mon, 26 Aug 2024 at 8:02 PM, Andrew @.***> wrote:

@.**** approved this pull request.
Oops, my bad :)
—
Reply to this email directly, view it on GitHub
https://github.com/tardis-sn/tardis-regression-data/pull/22#pullrequestreview-2260848864,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ANKOCXDAYVZ4HRRBBTOWJITZTM36JAVCNFSM6AAAAABND4ZK3GVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDENRQHA2DQOBWGQ
.
You are receiving this because you authored the thread.Message ID:
@.***>


Returning object from field condition causes it to be run infinitely

Link to reproduction
No response
Describe the Bug
{
      type: 'text',
      name: 'textField',
      admin: {
        condition: (props) => {
          return {
            someObject: true
          }
        },
      },
 },

Having a field like this causes the condition function to endlessly run over and over again.
To Reproduce

Payload Version
2.5.0
Adapters and Plugins
No response

@patricsgamma I've created a new issue for #4410 if you're interested in following it


add helm test step to gh-actions

Also, remove local helm testing in favor of ct in PRs.
Example successful run can be checked here (from my fork to my fork): https://github.com/knelasevero/descheduler/pull/2/checks
Example fail: https://github.com/knelasevero/descheduler/runs/7564334471?check_suite_focus=true
We already get events, describe, and logs of the deployed chart pod in the CI directly.
I am already removing the scripts and references to previous helm testing approach.
So /hold this one until I normalize and merge https://github.com/kubernetes/test-infra/pull/26630

@cpanato you mentioned some improvements that could be done to this. If you prefer we can review in this PR, or I can merge this and wait for a follow up PR from you. Your call :heart:

/ok-to-test

https://github.com/kubernetes-sigs/descheduler/pull/895/files#diff-3be36a9541f01c2e8a31c46ccbbb49265f35f3dc8bb57d01160d4f925961a87cR25-R28
also can be bumped to use helm 3.9.2

Will do!

/hold after reviews are done I will remove https://github.com/kubernetes-sigs/descheduler/pull/895#discussion_r934597809
and also need to wait for https://github.com/kubernetes/test-infra/pull/26630

and also need to wait for https://github.com/kubernetes/test-infra/pull/26630

I'd prefer first to introduce a new test, merge this PR, merge https://github.com/kubernetes/test-infra/pull/26630 and then change the make test-helm to run locally.

and also need to wait for kubernetes/test-infra#26630

I'd prefer first to introduce a new test, merge this PR, merge kubernetes/test-infra#26630 and then change the make test-helm to run locally.

New test? 🤔 You mean this PR itself as the replacement, or something else?

Merge this PR

If we merge this PR first, all new PRs will fail because of inexistent scripts being called on test-infra steps.

make test-helm

I've introduced make ct-helm in this PR, and it runs locally against kind

In overall, this is quite awesome improvement :)

🙌🙌

I would like to see the changes in the following order:

updating this PR so only a new Helm / lint-and-test (pull_request) test is introduced while still keeping pull-descheduler-helm-test and make test-helm unchanged (merged through https://github.com/kubernetes-sigs/descheduler/pull/895)
making sure the new Helm / lint-and-test (pull_request) test is required and a PR does not merge without the new test going green (this is paramount and needs to be verified)
removing pull-descheduler-helm-test test (https://github.com/kubernetes/test-infra/pull/26630 gets merged)
updating the make test-helm to run the new Helm / lint-and-test (pull_request) test locally (new PR)

I would like to see the changes in the following order:

updating this PR so only a new Helm / lint-and-test (pull_request) test is introduced while still keeping pull-descheduler-helm-test and make test-helm unchanged (merged through add helm test step to gh-actions #895)
making sure the new Helm / lint-and-test (pull_request) test is required and a PR does not merge without the new test going green (this is paramount and needs to be verified)
removing pull-descheduler-helm-test test (descheduler: remove helm tests from prow kubernetes/test-infra#26630 gets merged)
updating the make test-helm to run the new Helm / lint-and-test (pull_request) test locally (new PR)

You are right, that makes sense. I will convert this PR in a draft/wip to keep it as reference, and open new PRs step by step then. Then we can actually just test if prow ignores or considers gh-actions workflows before merging right after the first merge :)


Configure modern eslint

A/C:

When I write something bogus, the test suite rejects it and tells me what I did wrong.

Notes:

Probably go with the Airbnb standard just out of general popularity. It's not perfect, but: it's good enough not to need a lot of complicated revising; it's well supported by eslint; it's easy to install; and it's a standard, which is a lot better than none.

This is not the simplest thing that might work.


Volto 17.0.alpha14,  cookiecutter-plone-starter: Error: Unable to find 'razzle-plugin-scss' or scss/razzle-plugin'

Created a new volto project with
When I use cookiecutter-plone-starter to set u a new Plone 6 project with the latest Volto 17.apha14, make install-frontend succeeds, but starting the frontend gives the traceback below. Running
yarn add razzle-plugin-scss --dev  solves the problem.
Maybe I'm using the wrong volto_generator_version, it defaults to 6.3.1 and I cannot find any newer version for the alpha's. @sneridagh  Am I indeed using a volto 16 generator version for the 17 alphas?
 ERROR  Unexpected error

Error: Unable to find 'razzle-plugin-scss' or scss/razzle-plugin'
    at loadPlugin (/Users/fred/demo/volto-demo/frontend/node_modules/razzle/config/loadPlugins.js:61:11)
    at loadPlugin (/Users/fred/demo/volto-demo/frontend/node_modules/razzle/config/loadPlugins.js:8:12)
    at /Users/fred/demo/volto-demo/frontend/node_modules/razzle/config/loadPlugins.js:69:12
    at Array.map (<anonymous>)
    at loadPlugins (/Users/fred/demo/volto-demo/frontend/node_modules/razzle/config/loadPlugins.js:68:18)
    at /Users/fred/demo/volto-demo/frontend/node_modules/razzle/config/loadRazzleConfig.js:47:9
    at new Promise (<anonymous>)
    at module.exports (/Users/fred/demo/volto-demo/frontend/node_modules/razzle/config/loadRazzleConfig.js:12:10)
    at /Users/fred/demo/volto-demo/frontend/node_modules/razzle/scripts/start.js:53:5
    at new Promise (<anonymous>)
    at main (/Users/fred/demo/volto-demo/frontend/node_modules/razzle/scripts/start.js:52:10)
    at Object.<anonymous> (/Users/fred/demo/volto-demo/frontend/node_modules/razzle/scripts/start.js:246:1)
    at Module._compile (node:internal/modules/cjs/loader:1256:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1310:10)
    at Module.load (node:internal/modules/cjs/loader:1119:32)
    at Module._load (node:internal/modules/cjs/loader:960:12)
make[1]: *** [start] Error 1
make: *** [start-frontend] Error 2

Hmm, I got the same error earlier today while trying volto 17 on a project that was previously using volto 16 -- but I was able to resolve it by updating razzle to 4.2.18 like it says in the upgrade guide.
Probably needs a close look to see what is going wrong with the generator. Does yarn why razzle reveal multiple versions of razzle used in different places, by any chance?

@fredvd @sneridagh says an alpha of the generator is needed. Make sure you're setting the environment variable that was added here: https://github.com/collective/cookiecutter-plone-starter/pull/87
(Maybe we can make the cookiecutter do that automatically based on the selected version, instead of needing an env var?)

I started the project with Volto 17, but the cookiecutter / stable 3.6.x volto generator creates a package.json with razzle 4.2.17.  I bumped that version to 4.2.18 manuall and reran yarn, but that didn't help, so maybe that's also what happens when upgrading Volto from 16 to 17.
Would be nice indeed if cookiecutter could switch the Volto generator listed based on the Volto version.  I didn't do that because I was almost at the end of the wizard and didn't want to restart the thing again for setting an env variable.  :-)

I tested once more, merged the PR and tested it right away after that. The volto generator version now correctly selects an alpha version as well if you pass in an alpha Volto version.  If you stick with a 16.20 volto version the generator is using the released 6.3.1.
Thank you @davisagli & reviewers !!
> cookiecutter https://github.com/collective/cookiecutter-plone-starter
You've downloaded /Users/fred/.cookiecutters/cookiecutter-plone-starter before. Is it okay to delete and re-download it? [yes]: yes
project_title [Project Title]: testsite2
project_slug [testsite2]:
description [A new project using Plone 6.]:
author [Plone Foundation]:
email<EMAIL_ADDRESS>python_package_name [testsite2]:
Select python_test_framework:
1 - pytest
2 - unittest
Choose from 1, 2 [1]: 1
plone_version [6.0.6]:
volto_version [16.21.2]: 17.0.0-alpha.15
volto_generator_version [7.0.0-alpha.4]:


Fixing the express error handling for async functions

The try/catch block does not handle errors of async functions and they cannot be forwarded (next) to the proper error middleware, as done with sync functions. Instead, if an exception is thrown from an async function, this exception will be returned as a  Promise, that must be handled on a Promise.catch() method.
We cannot simply await async functions to handle it synchronous in this section of code to only enable try/catch block to handle async exceptions, it would not make sense.

You will want to check out http://expressjs.com/en/guide/migrating-5.html whixh alreay has this change 👍

Any reason why this is not merged into the 4x code? I just wrote pretty much the same patch for myself, I don't see any drawbacks having that available in the 4x branch.

It broke various middleware and real world apps who are using arrow functions and other constructs that are returning promises and works fine since Express 4.x ignores the return value of middlewares and handlers.

Understood, thank you for the quick reply.
I've switched to the 5x branch and it works like a charm.


Time backward mode

Time backward mode (#12) should now be working with this PR

This looks really great now. Apart from the small API change and the test suite comment I'm happy for this to land.
@erikvansebille Do you mind if I squash a few commits before merging this to keep the history clean?

I had another thought on this regarding the API changes: Why are we still passing a positive dt in pset.execute(..., dt=dt) in the moving eddies test? Wouldn't setting dt=-dt be the most intuitive way to trigger time-backward mode?
That said, if the dt value passed into a kernel is negative, do we still need to invert U and V sampling? Or should we instead just make sure that we have more intuitive time-stepping parameters in ParticleSet.execute() and let negative dt values propagate to the kernel. Something like execute(starttime=start, endtime=end, dt=dt and equivalently execute(starttime=end, endtime=start, dt=-dt)?

This idea of execute(starttime=end, endtime=start, dt=-dt) is an interesting idea yes. Perhaps we could even infer that dt < 0 if starttime > endtime.
And you may be right that if dt < 0, we don't need to negate the velocity fields.
I'll have a look at it over the next few days

I've been reworking the whole PR today, and have revamped the way time is handled by .execute. Rather than the old time and timesteps variables, .execute now requires starttime and endtime, which hopefully are more intuitive. If the sign of dt is not equal to the sign of endtime - starttime, PARCELS will now negate dt.
Something more to do is to change output_steps to the more intuitive output_freq (every how many seconds should output be saved, rather than every how many dt)

@erikvansebille Ok, so I found out what was causing this bug and added a patch that fixes it for this particular case. However, the problem is really a deeper one that highlights that numpy arrays are really the wrong container type for our JIT approach once you add particle removal, since np.delete invalidates the Python memory views for our JITParticles.  Anyway, it works for now and I also added an xfailing test that highlights the case where it doesn't (see b703af9).
I also rebased the branch to get a clean history for the time backward changes and I believe it is now ready to be merged. Please have another look first though.