NetNewsWire attempts to access urls when opened in default browser

More of a question of behavior than a bug. When I have links set to open in the default browser Little Snitch still shows an access prompt for the url from NNW. I would think that clicking a link would skip access by NNW. Is it just the nature of how links are sent to the browser that Little Snitch would see NNW accessing the domain?

I installed Little Snitch Version 5.6 (6281) to try to reproduce this with NetNewsWire Version 6.1.2 (6114), and I couldn't get the issue to appear. Auditing the code a bit it seems like there might be a bit of a different code path depending on the default browser and whether it's running at the time. Can you share some more details about your setup for instance what browser are you using? I tested with Safari.

Actually I misread the bug originally. I thought you meant you were using the "Open In Browser" item for the feed itself. I reproduced the warning you described when clicking a link within the content of a post as rendered in NetNewsWire's web view. I suspect because this is going through WebKit that might explain the difference in behavior. I'll take a closer look.

So, some interesting tidbits about this: the process that is making the request that actually triggers Little Snitch is not NetNewsWire per se, but the WebKit networking process that runs on NNW's behalf. The detailed info in Little Snitch confirms this:

I did some poking around in the networking process around the time a link is clicked and I suspect what is going on here is something inside WebKit called "preconnect" is causing it to fetch information about the clicked link, maybe as an optimization in case it is opened in the same web view, or maybe in order to ensure any redirects are managed before informing the WKWebView delegate about the resource that is going to be loaded?
There might not be much we can do about this, but maybe somebody will be able to dig deeper and find out whether it's possible to disable the WebKit "preconnect" behavior or otherwise try to prevent it accessing the URL directly before passing it on to the delegate.

This line of code in WebKit's href clicking handler suggests there's a linkPreconnectEnabled setting on the document. If that could be disabled for NetNewsWire it seems like it would be ideal since the preconnects are not likely to be an efficient use of networking for NNW, where most links will be loaded in the browser or another web view.

I was able to reproduce the same issue in MarsEdit, so I suspect this is a widespread default behavior for apps that use WKWebView.

@danielpunkass Thanks so much for the thorough investigation. It's really not blocking any kind of functionality or causing harm, just something I've noticed for a while and caused some head scratching. Happy to close this as 'working as Apple intends' or leave it open to see if maybe a tweak to linkPreconnectEnabled  would be useful.

@greggb I appreciate you reporting it because it does seem like a situation where WebKit's default (I think) behavior is probably causing lots of false alarms for Little Snitch users. It might be something to try to work around from the app side, or maybe something to ask the Little Snitch developers about. Maybe they could finesse the behavior to at least explain that it's WebKit doing the loading on the app's behalf.


Need docs: add section about validation rules to the prompts doc

We should add a section dedicated to using the validation rules functionality of prompts.
In particular, we need to document that the value to be validated is present in the special property, this.value

The doc is updated and in-review. The content will go live soon.
Closing this issue. Thanks again for the feedback. 👍


C27 6.298774193548391 paracetamol dexamethasone methylprednisolone aspirin antimicrobials orally corticosteroid chloroquine hypoxemia antiretroviral procalcitonin mmr therapeutic diphtheria chemoprophylaxis aspartate infusions contraindications dmem antiviral glaxosmithkline penicillin steroids corticosteroids fbs

Probably some of the above as additional keywords to the current "medicine" node?

C28 6.198982142857141 reporters reporter journalist analysts correspondents journalists musicians operatives pressers delegates bloggers media writer newsethiopia tribune acting deputy publisher servant consultancy correspondent programming leaders headlines scouts insight worker news singer investigative editor administrators spokesman reporting analyst broadcasts heroes defenders supervisors communications broadcasting artists officers

Additional keywords for "person_or_group"?

C34 6.037520000000006 budgets spending grants funding funds budgeting contributions backing funders funder budget programs financing fund spent contracts financial invest revenues block billion requirements efforts schemes powers spends resources subsidies policies philanthropic assistance generosity costed finance appropriations donations thereof towards budgetary

Should some of these be additional keywords under the current "budget" node?

C35 6.036638888888891 electrical grid generator electric electrification electricity fuelwood lighting powered solarization piped backup generation complements charging connected power charge traction utility analog motor solar hydroelectric renewable smoke

Should some of these be additional keywords under the current "electrical_infrastructure" node?

tag @BeckySharp @MihaiSurdeanu

thanks @chanys  !
I vote yes to all except for the budget suggestions, I think only a subset of these should go under budget, and perhaps we need a spend event?

Closed by #115


Fix typo in consent options

Fixed a typo in the host for the consent options.

Hi @user1336, I'm your friendly neighborhood .NET Foundation Pull Request Bot (You can call me DNFBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!
The agreement was validated by .NET Foundation and real humans are currently evaluating your PR.
TTYL, DNFBOT;

thanks!


custom calls: cleanup and improve a few elements

This PR contains a few fixes and clean-up items related to the tail calls for custom programs. Please refer to the individual commits for details.
(Some of those commits were initially included in #15475, which will be updated to focus only on the new metrics.)

test-me-please

test-me-please

Naming the object file after the .h file completely breaks test/bpf/verifier-test.sh, where the logics relies on the conversion .c -> .o reusing the same base name :/.
I will exclude the byte-counter from verifier-test.sh. It's not as if I expected a complexity issue to show up in that program any time soon, and I plan to package it externally anyway.

test-me-please

test-1.19-4.19

test-1.20-4.9

https://github.com/cilium/cilium/issues/15456 and https://github.com/cilium/cilium/issues/14959 again.


Till now it was successful but today it throw an error. Process completed with exit code 1. Did something changed?

Hi. Im using github actions and so far everything was working great but today Im getting an error. Did something changed?

And here is my workflow
jobs:
  deploy_dev_supabase:
    runs-on: ubuntu-latest
    env:
      SUPABASE_ACCESS_TOKEN: ${{ secrets.SUPABASE_ACCESS_TOKEN }}
      SUPABASE_DB_PASSWORD: ${{ secrets.SUPABASE_DB_PASSWORD_DEV }}
      SUPABASE_PROJECT_ID: ${{ secrets.SUPABASE_PROJECT_ID_DEV }}
    steps:
      - name: Get code
        uses: actions/checkout@v4
      - uses: supabase/setup-cli@v1
        with:
          version: latest

      - run: supabase link --project-ref $SUPABASE_PROJECT_ID
      - run: supabase db dump -f supabase/seed.sql --data-only
      - run: yes | supabase db reset --linked

Probably a duplicate of https://github.com/supabase/cli/issues/2341#issuecomment-2137757934
Is it random or always reproducible?

@sweatybridge  Thank you for your answer Im gonna test it and let you know if that was a solution

@sweatybridge It looks like it solved my problem. Thank you :)


fix(cmd): set description for inspect

For some reason I thought this was fixed in an earlier PR that I merged yesterday. :-(


Any way to run this on x86 apks?

Trying to restore some IL on an old APK I have that uses x86 ELF.
Any way I can do this?

Woah, I wasn't aware there were any x86 APKs. It should be doable... Can you send me the apk (or at least the name and version) so I can test it and add support myself?

Of course :)
https://drive.google.com/file/d/1uke5b0EfF9b7mGAWPSwtMD-Y4H6--Uiw/view?usp=sharing

Sorry, I meant to comment this at the time but it slipped my mind - the link was dead mere minutes after you sent it due to a violation of google's TOS.

Download All Apk mods for free from our site and enjoy games and streaming apps.
https://apkzoon.com/


script addresses

#74

[x] introduce ScriptError
[x] move empty list responsibility from Parser to validator
[x] extend validate errors in order to better suggest user of the error
[x] move key length checking responsibility from Parser to validator
[x] add error of duplicate verification keys in a given level
[x] allow using various formats during script construction
[x] introduce PaymentCredential and StakeCredential
[ ] allow construct script as payment OR stake credential

I have two failures of test at this moment :
cardano-addresses-cli>     fails if a script is malformed FAILED [1]
cardano-addresses-cli>     fails if a script is malformed FAILED [2]

which I do not understand. ScriptParser spews ErrorCall when this kind of stuff is in input of it. I hoped that this https://github.com/input-output-hk/cardano-addresses/pull/79/files#diff-9af2a1e1b20742c8d9e1738978cd4ff4R32 would be returned. but it is not. it seems https://github.com/input-output-hk/cardano-addresses/pull/79/files#diff-92cbf0077f38a73ecc103bea0b00efcbR64 is triggered :
cardano-addresses-cli> , fails if a script is malformed
cardano-addresses-cli>        "user error (The hash of verification key is expected to have 28 bytes.)\n" does not contain "Parsing of the script failed. The script should be composed of nested lists, and  the verification keys should be either base16 or base58 or bech32 encoded."

so it seems ScriptParser ejects some bytes and then they are tried and not validated as they do not satisfy 28-byte length

I fixed the test and moved scriptFromString into the parser module.
describeCmd makes it difficult to see what the actual test failures are.

It looks like the stylish-haskell step of the "Coding standards" build fails because it is not using the .stylish-haskell.yaml config file in this repo.


Use LogicalPosition for calculating selection range instead VisualPosition

Fixes: https://github.com/sourcegraph/jetbrains/issues/69
Additional changes: Remove unused EditorContext Java code.
Test plan:

Run IDE.
Open any code that contains some imports and methods.
Collapse methods visually using Ctrl + Shift + Minus.
View logs with tail -f build/sourcegraph/cody-agent-trace.json.
Verify that we are sending the correct selection on textDocument/didChange call.

NOTE: line position is counted from 0, not from 1.

I know. It's WIP, but...

fixes like this are the best 😅

I know. It's WIP, but...  fixes like this are the best 😅

Yeah, I was looking for where we send those caret positions and I stumbled upon some old Java code. Boy Scouting Rule. :smile: :broom:

A caret's Visual Position differs from Logical Position in that it takes into account editor presentation settings such as Code Folding and Soft Line Wrap. In doing so, VisualPosition counts - zero-based - the lines of a Document that can be displayed in an Editor. Consequently, Visual Positions can't be uniquely mapped to Logical Positions or corresponding lines in the underlying Document.

Interesting! Do you know what constructs specifically were causing the offsets in the original bug reports? :slightly_smiling_face:

A caret's Visual Position differs from Logical Position in that it takes into account editor presentation settings such as Code Folding and Soft Line Wrap. In doing so, VisualPosition counts - zero-based - the lines of a Document that can be displayed in an Editor. Consequently, Visual Positions can't be uniquely mapped to Logical Positions or corresponding lines in the underlying Document.

Interesting! Do you know what constructs specifically were causing the offsets in the original bug reports? 🙂

Import statements :sweat_smile:, which are collapsed by default, but it was hard to notice the error because it's usually just a few lines.


Where is IReadonlyTheme, ThemeChangedEventArgs, ThemeProvider.serviceKey ?..

Hi,
I think some information is missing (It's late and I'm a little tired ^^)
Where is IReadonlyTheme, ThemeChangedEventArgs, ThemeProvider.serviceKey ?..
it's a new lib to import ?
Thanks,
Richard

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

ID: d5fe832e-68cc-0f3a-acc1-c9116a5c981d
Version Independent ID: 4b6961ad-45a6-aef9-f197-c31b1cb4a5f8
Content: Supporting section backgrounds
Content Source: docs/spfx/web-parts/guidance/supporting-section-backgrounds.md
Product: sharepoint
GitHub Login: @spdevdocs
Microsoft Alias: spdevdocs

They should be in sp-component-base.

Thanks, it's work fine ;)

Unfortunately, some information is missing in the tutorial. Would be nice to provide step-by-step tutorials that are complete and that work on a green field ;) - at least, in the beginner's section. Took me some time to figure it out.

you need to "npm install @microsoft/sp-component-base"
import { ThemeProvider, ThemeChangedEventArgs, IReadonlyTheme } from '@microsoft/sp-component-base';
declare variables "private _themeProvider: ThemeProvider;" and "private _themeVariant: IReadonlyTheme;"


Query params keep appending

I came across this project from https://libraries.io/clojars/xtreak%2Fclj-http-ssrf/usage. I checked out your Heroku instance. It seems you are appending the query param when I check 'add to current plot'. When I type 'fg' the url becomes 'https://gowherene.herokuapp.com/?q=fg' and 'gh' becomes 'https://gowherene.herokuapp.com/?q=fg&q=gh' and 'bn' becomes 'https://gowherene.herokuapp.com/?q=fg&q=gh&q=bn' . I can see from the code you are using it to track the back button behavior but when the person submits multiple values to same query param will result in an array and might behave differently for different web servers AFAIK.
Feel free to close this if it's the intended behavior.
All the best for your project 👍

Oh you mean to say that other web servers might collapse fg, gh and bn and give me different behaviour? Like overriding or something?

I think I came across this in PHP where multiple values where overridden and in Django we had multiple values accepted and retrieved using getlist. I don't know how it works in Clojure and was just curious if you have the intended behavior in the code.
Seems there is no definitive standard : https://stackoverflow.com/a/24728298/2610955


CXF-7453 check subCodes only in case of SOAP 1.2

Restricts handling SOAPFaultException subCodes  and reasonLocales only for SOAP 1.2 and skipping those in case of SOAP 1.1.
https://issues.apache.org/jira/browse/CXF-7453

Note:  in the future, please submit pull requests based on master instead of some other branch.


Changes ACF to native composer install

NOTE: terminus secret ACF_PRO_KEY should be removed only after all environments have been updated with this change. It will cause no harm to keep it there, but it will not actually do anything once these changes land and should be removed.
Why are these changes being introduced:

ACF now allows direct install and the shim we used is being retired

Relevant ticket(s):

https://mitlibraries.atlassian.net/browse/LM-236

How does this address that need:

Removes acf-composer-bridge repository
Adds acf native repository

Document any side effects to this change:
COMPOSER_AUTH env is required in local .env as well as being set via terminus secret plugin.
Developer
Secrets

[x] All new secrets have been added to Pantheon tiers
[ ] Relevant secrets have been updated in Github Actions
[x] All new secrets documented in README

Documentation

[ ] Project documentation has been updated
[ ] No documentation changes are needed

Accessibility

[ ] ANDI or Wave has been run in accordance to
our guide and
all issues introduced by these changes have been resolved or opened as new
issues (link to those issues in the Pull Request details above)

Stakeholder approval

[ ] Stakeholder approval has been confirmed
[x] Stakeholder approval is not needed

Dependencies
YES dependencies are updated (updated to new version of ACF during this process to address security concern)
Code Reviewer

[ ] The commit message is clear and follows our guidelines
(not just this pull request message)
[ ] The changes have been verified
[ ] The documentation has been updated or is unnecessary
[ ] New dependencies are appropriate or there were no changes

@matt-bernhardt I was holding off on looking at Actions until we confirmed we were okay with this approach as fixing it in this branch will break every other branch but I will make sure what you are seeing is resolved along with the change in the variable syntax. I will work on fixing Actions now for this branch now that we have both seen success in Pantheon and locally. I won't merge until I tag you again for review, but this is the point at which every other branch will fail CI until we merge this branch (I mean, we can always change the ENV back to the old way if this takes too long and we need some other code to land but... yeah).
As for LastPass... yeah, we're still in transition between the old and new LastPass folder structure. I'm not entirely sure why that is being held up at the DLS level but I suspect everyone (like us) just hasn't had time to complete our transition to the new structure.


Provide more pre-contact information

We should have some sort of jump before putting the sdk-support email address on the front page. We've now received enough emails that should have been covered by a look through our documentation, such as how to install things, or wondering what is supported by what SDKs, or how things work.
Just like the best ticket is the one that isn't written, the same can be said for a lot of these emails. Putting together a last second roundup of information in front of the email address could cut down on some of that, and it would additionally give us a chance to help people form better questions by requesting a few pieces of information in their email.
Ideally we link to pages like /sdks, /docs, community, and anything else that might contain the info people are likely asking.
For when it does come down to needing an email, we should suggest they provide info such as operating system, programming language they're working with, SDK if they're working with one, the steps to reproduce the issue they're experiencing, and if possible, code samples that we can run ourselves to help in debugging. We may also want to link them to something like https://gist.github.com/ to drop their code sample.

For as bad as a lot of utility provider websites are, such as cable/internet or electric companies, they typically provide a few last ditch efforts to get information in your hands before resorting to a phone call. I think we have a lot of great info and will be creating more of it, and we should really try to put that in front of people instead of allowing the immediate bypass which is email.

:+1:


cdk-drag-drop connected sorting example stackblitz is broken

Bug, feature request, or proposal:
Bug
What is the expected behavior?
should be functionally equivalent to the material.angular.io docs
What is the current behavior?
currently throws template parse errors in the stackblitz example
What are the steps to reproduce?
Providing a StackBlitz reproduction is the best way to share your issue.
StackBlitz starter: https://goo.gl/wwnhMV
https://stackblitz.com/angular/lpkobqdlppp
What is the use-case or motivation for changing an existing behavior?
Which versions of Angular, Material, OS, TypeScript, browsers are affected?
Is there anything else we should know?

Looks like the DragDropModule isn't imported. @DevVersion should this be fixed once https://github.com/angular/material.angular.io/commit/360393fc19b96cf76e0d88855492a61428816eb8 is released?

@crisbeto Yeah should be fixed once the fix is published with a new docs version.


tree2: Batched tree encoding

Description
In ops and summaries, batch the encoding of tree chunks to avoid duplicating schema/shape information.
Breaking Changes
This breaks all existing documents.
Reviewer Guidance
The review process is outlined on this wiki page.

@Abe27342, @CraigMacomber - I have reviewed the following changes:
src\feature-libraries\default-schema\defaultChangeFamily.ts
src\feature-libraries\modular-schema*
src\test\feature-libraries\default-field-kinds\defaultChangeFamily.spec.ts
src\test\feature-libraries\modular-schema\modularChangeFamily.spec.ts
src\test\feature-libraries\sequence-field\populatedMarks.ts


Add a means of rendering equations nicely

See this thread for some options.


Implement simulation pausing (for non-parallel algorithms)

Part II of the pause + resume feature for rustcoalescence.

[x] Implement basic pause time config parsing
[x] Implement internal early-stopping for non-parallel algorithms
[ ] Print adjusted reporter message when finalising on a pause
[ ] Implement config file writing
[ ] Implement config file output on pause for non-parallel algorithms
[ ] Implement lineage store + sampler sorted lineage output
[ ] Implement resume config file lineage dump output

Codecov Report

Merging #67 (f4141ee) into main (cb200e4) will decrease coverage by 0.10%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##             main      #67      +/-   ##
==========================================
- Coverage   53.64%   53.53%   -0.11%
==========================================
  Files          70       70
  Lines        4431     4440       +9
==========================================
  Hits         2377     2377
- Misses       2054     2063       +9

Impacted Files
Coverage Δ

rustcoalescence/algorithms/cuda/src/lib.rs
1.21% <0.00%> (-0.05%)
:arrow_down:

rustcoalescence/algorithms/independent/src/lib.rs
0.45% <0.00%> (-0.02%)
:arrow_down:

rustcoalescence/algorithms/src/lib.rs
100.00% <ø> (ø)

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 cb200e4...f4141ee. Read the comment docs.


talk: refurb multi-DM chat info

Doesn't touch #1178, but brings the multi-DM "Chat Info" dialog up to spec:

Adds the contents of MultiDmHero without the member list
Breaks the members and pending lists out into their own components
Adds the ability to DM each member directly from this modal
Switches the modal to "edit mode" on button click
Gets you out of "edit mode" by clicking Cancel

With pending members:

With no pending members and image + name set:

Spec: https://www.figma.com/file/sCFYLlAGjehlYXUkT2rarg/Product-Handoffs-(Locked)?node-id=1206%3A42842

Other than hunter's comment, this looks great + easy to understand!


Request timeout while running CST

While running the consensus state transfer protocol, received client requests might time out and start broadcasting false STOP messages

Disabling timeouts while running the CST protocol should fix this.


#5354: Added separate function for resnet-50.

Can we add also skip option for resnet18. The error is when run locally
Statically allocated circular buffers in program 73 clash with L1 buffers on core range [(x=0,y=0) - (x=11,y=1)]. L1 buffer allocated at 831264 and static circular buffer region ends at 1040420

And this passes locally?

yes

Can we also add skip option for resnet18. The error is when run locally
Statically allocated circular buffers in program 73 clash with L1 buffers on core range [(x=0,y=0) - (x=11,y=1)]. L1 buffer allocated at 831264 and static circular buffer region ends at 1040420

That error should be fixed by now after @tt-rkim 's. checkin
.

@arakhmati and @eyonland Can you guys take a look. I need one code owner's review to merge this.


CA1812: Avoid uninstantiated internal classes

Rule summary

Value

Title
CA1812: Avoid uninstantiated internal classes

CheckId
CA1812

Category
Performance

Link
https://docs.microsoft.com/en-us/dotnet/fundamentals/code-analysis/quality-rules/ca1812

What is the problem
This rule flags classes that are not instantiated in a library and are internal as not being used. In the docs for the rule, it says it is safe to suppress the rule if the classes is instantiated through other means, e.g. an IOC container.
One example is when we have an public interface (IMyEndpoint) and an internal implementation (MyEndpoint) that is registered in an IServiceCollection through an extension method. In this case, the rule still gives a warning, even though the class is actually used.
Suggestion
ROOT: NONE.

Decision: ROOT: NONE.


Port mirroring

Port mirroring is a feature where packets going to one port is copied and sent to additional port(s) [one or many].  This feature is useful where packet information is used for network/lawful monitoring, logging and analytics for starters.

Done in 1.0.


XML file

Shouldn't PlayerCompanion.xml also be in the FOR DEVELOPERS folder?

Nope, as that will be used for automatic menu settings generation during runtime in the future. This requires the xml file to be placed in the same folder.

Ill leave this issue around just in case.

Nope, as that will be used for automatic menu settings generation during runtime in the future. This requires the xml file to be placed in the same folder.

cool cool

Ill leave this issue around just in case.

copy that, thanks


Documentation fix: Correct port range for cap_net_bind_service

Correct port range for cap_net_bind_service.

Codecov Report

Merging #9306 into master will decrease coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #9306      +/-   ##
==========================================
- Coverage   41.19%   41.18%   -0.01%
==========================================
  Files         559      559
  Lines       73073    73073
==========================================
- Hits        30100    30098       -2
- Misses      39199    39202       +3
+ Partials     3774     3773       -1

Impacted Files
Coverage Δ

models/unit.go
62.16% <0%> (-5.41%)
:arrow_down:

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 7f0d7c0...f0a5e0c. Read the comment docs.


The "clean" doesn't help if file name capitalization has changed

Hello everyone!
An issue for the record.
Let's consider we create the "test_unit.c" file containing some tests in it. It looks as follows:
#include <unity.h>

void setUp(void)
{
    ;
}

void tearDown(void)
{
    ;
}

void test_success(void)
{
    TEST_PASS();
}

Next we run it and obtain the following output:
F:\sandbox>ceedling test:all

Test 'test_unit.c'
------------------
Generating runner for test_unit.c...
Compiling test_unit_runner.c...
Compiling test_unit.c...
Compiling unity.c...
Compiling cmock.c...
Linking test_unit.out...
Running test_unit.out...

--------------------
OVERALL TEST SUMMARY
--------------------
TESTED:  1
PASSED:  1
FAILED:  0
IGNORED: 0

Perfectly fine. Then, for some reason, we decide to rename the "test_unit.c" to the "test_Unit.c". To run it again, we first execute the "ceedling clean" command to clean the leftovers if any,  then run "ceedling test:all" again. And it fails:
F:\sandbox>ceedling clean

Cleaning build artifacts...
(For large projects, this task may take a long time to complete)

F:\sandbox>ceedling test:all

Test 'test_Unit.c'
------------------
ERROR: Found no file 'test_Unit_runner.c' in search paths. However, a filename having different capitalization was found: 'build/test/runners/test_unit_runner.c'.
#<Thread:0x0000021dadda47e8 C:/WorkSoft/PC/Ruby/lib/ruby/gems/3.0.0/gems/ceedling-0.31.1/lib/ceedling/par_map.rb:7 run> terminated with exception (report_on_exception is true):
C:/WorkSoft/PC/Ruby/lib/ruby/gems/3.0.0/gems/ceedling-0.31.1/lib/ceedling/file_finder_helper.rb:45:in `blow_up': unhandled exception
        from C:/WorkSoft/PC/Ruby/lib/ruby/gems/3.0.0/gems/ceedling-0.31.1/lib/ceedling/file_finder_helper.rb:22:in `block in find_file_in_collection'
        from C:/WorkSoft/PC/Ruby/lib/ruby/gems/3.0.0/gems/ceedling-0.31.1/lib/ceedling/file_finder_helper.rb:12:in `each'
        from C:/WorkSoft/PC/Ruby/lib/ruby/gems/3.0.0/gems/ceedling-0.31.1/lib/ceedling/file_finder_helper.rb:12:in `find_file_in_collection'
        from C:/WorkSoft/PC/Ruby/lib/ruby/gems/3.0.0/gems/ceedling-0.31.1/lib/ceedling/file_finder.rb:102:in `block in find_compilation_input_file'
        from C:/WorkSoft/PC/Ruby/lib/ruby/gems/3.0.0/gems/ceedling-0.31.1/lib/ceedling/file_finder.rb:98:in `synchronize'
        from C:/WorkSoft/PC/Ruby/lib/ruby/gems/3.0.0/gems/ceedling-0.31.1/lib/ceedling/file_finder.rb:98:in `find_compilation_input_file'
        from C:/WorkSoft/PC/Ruby/lib/ruby/gems/3.0.0/gems/ceedling-0.31.1/lib/ceedling/rules_tests.rake:13:in `block in <top (required)>'
        from C:/WorkSoft/PC/Ruby/lib/ruby/gems/3.0.0/gems/rake-13.0.3/lib/rake/task_manager.rb:307:in `block in make_sources'
        from C:/WorkSoft/PC/Ruby/lib/ruby/gems/3.0.0/gems/rake-13.0.3/lib/rake/task_manager.rb:294:in `map'
        from C:/WorkSoft/PC/Ruby/lib/ruby/gems/3.0.0/gems/rake-13.0.3/lib/rake/task_manager.rb:294:in `make_sources'
        from C:/WorkSoft/PC/Ruby/lib/ruby/gems/3.0.0/gems/rake-13.0.3/lib/rake/task_manager.rb:272:in `attempt_rule'
        from C:/WorkSoft/PC/Ruby/lib/ruby/gems/3.0.0/gems/rake-13.0.3/lib/rake/task_manager.rb:156:in `block in enhance_with_matching_rule'
        from C:/WorkSoft/PC/Ruby/lib/ruby/gems/3.0.0/gems/rake-13.0.3/lib/rake/task_manager.rb:154:in `each'
        from C:/WorkSoft/PC/Ruby/lib/ruby/gems/3.0.0/gems/rake-13.0.3/lib/rake/task_manager.rb:154:in `enhance_with_matching_rule'
        from C:/WorkSoft/PC/Ruby/lib/ruby/gems/3.0.0/gems/rake-13.0.3/lib/rake/task_manager.rb:57:in `[]'
        from C:/WorkSoft/PC/Ruby/lib/ruby/gems/3.0.0/gems/rake-13.0.3/lib/rake/task.rb:405:in `[]'
        from C:/WorkSoft/PC/Ruby/lib/ruby/gems/3.0.0/gems/ceedling-0.31.1/lib/ceedling/rake_wrapper.rb:18:in `[]'
        from C:/WorkSoft/PC/Ruby/lib/ruby/gems/3.0.0/gems/ceedling-0.31.1/lib/ceedling/task_invoker.rb:97:in `block in invoke_test_objects'
        from C:/WorkSoft/PC/Ruby/lib/ruby/gems/3.0.0/gems/ceedling-0.31.1/lib/ceedling/par_map.rb:10:in `block (2 levels) in par_map'
rake aborted!

Tasks: TOP => test:all
(See full trace by running task with --trace)

--------------------
OVERALL TEST SUMMARY
--------------------

No tests executed.

To make it work, we must either completely clean the "build" directory or remove the respective runner from the "build\runners" directory. In the particular case, it is the "test_unit_runner.c":
F:\sandbox>ceedling test:all

Test 'test_Unit.c'
------------------
Generating runner for test_Unit.c...
Compiling test_Unit_runner.c...
Compiling test_Unit.c...
Compiling unity.c...
Compiling cmock.c...
Linking test_Unit.out...
Running test_Unit.out...

--------------------
OVERALL TEST SUMMARY
--------------------
TESTED:  1
PASSED:  1
FAILED:  0
IGNORED: 0

Environment:

Windows 10;
MinGW;
ruby 3.0.3p157 (2021-11-24 revision 3fb7d2cadc) [x64-mingw32];
project configuration is default one generated by the "ceedling new";
Ceedling:: 0.31.1;
Unity:: 2.5.4;
CMock:: 2.5.4;
CException:: 1.3.3;

Thanks for your time and good luck.

what about ceedling clobber

@GlebPlekhotko Strictly speaking, this is not a Ceedling issue. It's an OS / file system issue. The behavior depends on how your file system handles capitalization in filenames. For instance, on the Unix variant I'm using, if a file already exists with one capitalization but calls write data to the same filename with a different capitalization, the original case of the filename is preserved while the content of the file changes. This is what is biting you. Unfortunately, this is a wildly complicated topic to handle in a platform agnostic way. A @kafkaaaa suggests, clobber is the best option, albeit a brute force option, for handling capitalization changes in filenames.


ProjectFunctionCpu Not Working

Did ProjectFunctionCpu become deprecated? Out of nowhere it begun returning the following error:
[unexpected error: not_found - Not Found](error: Error updating project Function CPU: Could not update function CPU, unexpected error: not_found - Not Found).

see deprecation notice
https://github.com/vercel/terraform-provider-vercel/blob/71a655f75a51b204e511a76b2f7419fca99e2789/docs/data-sources/project_function_cpu.md#vercel_project_function_cpu-data-source


Add further documentation links to the README

I added these links as it took me a bit to get the project properly configured, likely because of only a superficial knowledge of Doctrine and its various components. My hope is that by adding further links in the documentation, that it will be easier and quicker for others to configure in the future.

Great, thank you

You're most welcome. Thanks for merging it, and so quickly.


allow optional programmer discretion on chain length/function arguments per line

When lines hit max_width (or its derivatives), rustfmt will break chains and function calls with one call or argument per line.  We have found this to result in code that is less clear, and no more consistent with Rust's style than the code that it replaces.  We would like to see an option whereby these chains and function calls would be left to programmer discretion as long as they observe the constraints of indentation and max_width.
To make this more concrete, we have experienced this most recently in the embedded Rust world, where hardware-abstracting crates make extensive use of types to constrain context (viz.  svd2rust's API).
The upshot of this is that we end up with long chains that are asymmetric in that different positions in the chain actually denote different states.  Often, the programmer will use the line break to help clarify what's going on; some (real) examples:
fn func() {
    p.RCC.pllcfgr.modify(|_, w| {
        w.pll1vcosel().wide_vco()
            .pll1rge().range8()
            .divp1en().enabled()
            .divq1en().enabled()
            .divr1en().enabled()
    });

    p.RCC.d1cfgr.write(|w| {
        w.d1cpre().div1()
            .d1ppre().div1()
            .hpre().div1()
    });
}

In this case, the programmer has clearly grouped the chain to indicate the type states -- and to the reader, both uses are clear.  rustfmt, however, doesn't like either of these expressions; they get reformatted as:
fn func() {
    p.RCC.pllcfgr.modify(|_, w| {
        w.pll1vcosel()
            .wide_vco()
            .pll1rge()
            .range8()
            .divp1en()
            .enabled()
            .divq1en()
            .enabled()
            .divr1en()
            .enabled()
    });

    p.RCC
        .d1cfgr
        .write(|w| w.d1cpre().div1().d1ppre().div1().hpre().div1());
}

In both cases, meaning has been lost -- even though the code as written is consistent with Rust's style.  We can of course wrap these constructs in #[rustfmt skip] -- but they come up often enough that we would very much rather fix it in rustfmt.  And to be clear, we don't want these to be compressed either (as raised in #4146 and #2010); we seek to have them be optionally left to the programmer's discretion, within the bounds of the configured style.
Thank you in advance for your consideration and your work on this essential (if underappreciated!) part of the Rust ecosystem!
cc: @cbiffle @steveklabnik @davepacheco @ahl

So, rustfmt doesn't really have the concept of "programmer discretion"; it's mostly intended to produce the same output given the same parse tree, regardless of whitespace. There are exceptions to that; for instance, rustfmt has the concept of "paragraph breaks", where a blank line between blocks of code will be preserved, on the assumption that it was intended to break up code into logical chunks.
I can see how this would be similar. On the other hand, what happens if one of those .x().y().z() blocks becomes longer than the configured line width? Would you expect that one to get split into one-call-per-line, with the others remaining untouched? What happens if the arguments to a function are long?
I do think rustfmt could do a much better job with chains, in a variety of ways. For example, I'd love to see rustfmt consider putting simple calls on the same line of the ) or }) from a complex call:
foo.bar(
    big_arg1,
    big_arg2,
})?.build()?;

foo.bar(BigStruct {
    ...
}).await?

And for the case you're describing, it looks like there is a common pattern as well, and I'm wondering if it could be easily expressed in a way rustfmt could learn to handle:
...
#[rustfmt::chain(start_line)]
fn pll1rge(...)

#[rustfmt::chain(end_line)]
fn range8(...)

#[rustfmt::chain(start_line)]
fn divp1en(...)

#[rustfmt::chain(end_line)]
fn enabled(...)

Suppose that you put something like those attributes on the methods, and then rustfmt automatically implemented the paired-calls pattern you're using? rustfmt::chain(start_line) would mean "if there's more than one of these in the chain, always break this onto a new line even if there's enough room", and rustfmt::chain(end_line) would mean "it's OK to put this on the end of a line that already has a call in it".
That would probably be easier to implement in rustfmt than attempting to preserve semantics implied by line breaks in the original code.  Thoughts?

+1, to me this is the most desired change pending for rustfmt
@joshtriplett

I can see how this would be similar. On the other hand, what happens if one of those .x().y().z() blocks becomes longer than the configured line width? Would you expect that one to get split into one-call-per-line, with the others remaining untouched? What happens if the arguments to a function are long?

I was about to ask this, if max_width gets exceeded again in the lines below, there are two options:

Wrap exceeding method to the line below in the same way that rustfmt's normalize_comments = true works.
Break the line that's exceeding max_width into N new lines, where N is the number of method calls.

In my opinion, the second option is less chaotic when line splitting is needed, it's easier to regroup things in a semantic way.

@joshtriplett FWIW I'll just throw in my 2c that annotations like you describe can really grow to encumber code bases with more "noise" than code. Once a formatter (or tool) starts to go down this path, it's a slippery slope.
If it's possible to avoid adding annotations, by adding smarts that works as-desired 9 times out of 10 (leave the blocks as specified by the programmer, split into one-call-per-line if necessary?) then personally I'd rather live with that 1 time out of 10 or 20 being annoying, instead of always having to deal with manual annotations.

@ericsampson I realize that it would add complexity to the formatter. But having ways to automatically format codebases to match a more nuanced formatting style would help greatly, especially if such annotations can occur in crates that provide such libraries. Consider clap, for instance, the configuration of which often involves a massive nested set of chained calls. It'd be nice to improve the formatting of that, without people having to hand-tweak it.

@joshtriplett Thanks for the thoughtful response, and more generally for everything you've done for Rust!
I think one of my more general frustrations is that the Rust coding style itself actually defers quite a bit to programmer discretion (frequently using language like "prefer" rather than "must"), but -- as you point out -- that discretion is not as reflected in rustfmt itself.  I would really like to see rustfmt embrace some of the deliberate deference to judgement in Rust's coding style, and optionally allow for these "prefers" and "shoulds" to be interpreted as written in the style rather than as rigid absolutes.  I understand that this isn't really rustfmt's model -- which wants to take the AST and re-render it -- but I would argue that that model is far more rigid that the style that it purports to enforce.
We should also remember that, ultimately, the programmer does have discretion: when and where rustfmt insists on being overly autocratic or inflexible (or, as in this case, results in decidedly less readable/maintainable code), the programmer will elect to turn it off via #[rustfmt::skip] -- an outcome that all can agree is undesirable for myriad reasons!

@joshtriplett of course it's the maintainer's choice 110% so do whatever you think speaks best, I just wanted to give a little food for thought re the annotations path based on some experience from other languages. Cheers!!

I can see how this would be similar. On the other hand, what happens if one of those .x().y().z() blocks becomes longer than the configured line width? Would you expect that one to get split into one-call-per-line, with the others remaining untouched? What happens if the arguments to a function are long?

Given how it's accomplished in some other languages/formatters, the simplest solution would probably be to bless a rustfmt configuration or annotation which results in this format remaining stable unless a line is too long. (In which case, only that line would get broken up.)
fn func() {
    p.RCC.pllcfgr.modify(|_, w| {
        w.pll1vcosel().wide_vco() //
            .pll1rge().range8() //
            .divp1en().enabled() //
            .divq1en().enabled() //
            .divr1en().enabled() //
    });

    p.RCC.d1cfgr.write(|w| {
        w.d1cpre().div1() //
            .d1ppre().div1() //
            .hpre().div1()
    });
}

@bcantrill -
Sorry, have been meaning to comment on this one for a while.
Though implicitly indicated previously by the inclusion of this issue in a milestone, I want to state explicitly that we're going to try to support this; just a matter of figuring how best to do so.

I understand that this isn't really rustfmt's model -- which wants to take the AST and re-render it

This is spot on, and I want to emphasize it to provide context since I suspect this thread is likely to see some increased traffic due to the reference from your post (which was a very enjoyable read by the way!)
rustfmt is indeed the AST-driven/pretty-printer type of code reformatter. This means that rustfmt has to process and write something for each and every AST node from the parsed program, and there has to be something that defines how rustfmt rewrites each node. The Style Guide is what provides those definitions, and those definitions are what rustfmt uses by default when reformatting. Yes, the Style Guide has language that varies between "must", "should", etc., but rustfmt by design uses and applies all the Style Guide prescriptions regardless of the strength of wording so that it has a consistent target formatting to work with.
I think this is a powerful and useful feature, as it allows users to easily ensure their code is fully compliant with all of the Style Guide prescriptions (regardless of "should" vs "must"), with zero configuration. I don't think we'd want to remove that feature, just as similarly there are places where the style guide uses "must", but rustfmt also has configuration options that will let users do the exact opposite, and I wouldn't want to remove those either (e.g. derives guidelines and merge_derives config).
I've personally come to prefer these types of code formatters. While I don't absolutely love every aspect of the emitted formatting either, I do love being able to defer to an automated tool that provides predictable and deterministic styling and eliminates back and forth debates on subjective topics that in my experience typically prove to be rather unproductive. There's definitely still occasions where I'll give rustfmt's output a cross look, but overall the benefits of automated reformatting, and doing so according the Style Guide, outweigh the instances of formatting that I dislike. I think there's a lot of users and contexts where that value holds true as well.
However, I know those tradeoffs don't weigh out the same for everyone, and I 100% agree there's cases where the emitted formatting is so painful that users are forced to consider polluting their code with myriad skip attributes or not using rustfmt altogether. The snippets in the description are good examples of this in my opinion.
While I do think reformatting according to the Style Guide should continue to be rustfmt's default modus operandi, I also think we should strive to provide options that at a minimum allow users to avoid these types of specific cases that a sizeable portion of the community indeed finds particularly painful.
Close observers of recent rustfmt releases may have noticed early hints of this, such as configuration options that have a Preserve variant, where rustfmt will take the existing formatting into account as part of the heuristics in reformatting. There are of course other tradeoffs with this tact, but it seems to be something users want, and something we want to be able to support.
The challenge is that it's not always easy to incorporate this within rustfmt. We just don't know at this point whether we could support this via some new config options (e.g. fn_call_layout = Preserve), or whether we would need to add an entirely new formatting mode to rustfmt. The former, at least in incremental pieces, could likely be delivered more quickly, but it will also require figuring out answers to the accompanying "what if" questions (several of which were noted above in this thread).
Prettier is also an AST/pretty-printer type of formatter, and it is able to support preserving existing formatting in some cases, so I have to think we've got opportunities to do so as well.
At some point in the near future I'm going to be doing some refactoring of the chain handling code to address an unrelated long-standing issue. While I'm in there, I'll also be thinking through if/how we could do this and what questions we'd need to get answered before attempting to implement some type of Preserve option.

Suppose that you put something like those attributes on the methods, and then rustfmt automatically implemented the paired-calls pattern you're using? rustfmt::chain(start_line) would mean "if there's more than one of these in the chain, always break this onto a new line even if there's enough room", and rustfmt::chain(end_line) would mean "it's OK to put this on the end of a line that already has a call in it".
That would probably be easier to implement in rustfmt than attempting to preserve semantics implied by line breaks in the original code.  Thoughts?

I'm not keen on this, primarily for two reasons. First, I feel like the ask was for something non-attribute based (at least implicitly if not explicitly). Users can already toss #[rustfmt::skip] in there but I think that's proving too ineffective especially in these types of cases. I know these attributes would be more powerful, but my sense is that folks would still prefer something that took current formatting into account.
Secondly, and somewhat selfishly :smile:, I fear this could snowball pretty quickly and we'll end up with dozens and dozens of attributes. I worry this would add a lot of burden and complexity within the rustfmt codebase, but I also think it could make code noisy and messy for end users.

On Mon, Oct 12, 2020 at 07:43:00PM -0700, Caleb Cartwright wrote:

I'm not keen on this, primarily for two reasons. First, I feel like the ask was for something non-attribute based (at least implicitly if not explicitly). Users can already toss #[rustfmt::skip] in there but I think that's proving too ineffective especially in these types of cases.
...
Secondly, and somewhat selfishly :smile:, I fear this could snowball pretty quickly and we'll end up with dozens and dozens of attributes. I worry this would add a lot of burden and complexity within the rustfmt codebase, but I also think it could make code noisy and messy for end users.

The difference is that these attributes would appear on method
definitions, and would then improve formatting for all users of those
methods. One method definition, many many callers. That seems worth a
few annotations for cases where rustfmt will never be able to
understand otherwise.

The difference is that these attributes would appear on method definitions, and would then improve formatting for all users of those methods. One method definition, many many callers. That seems worth a few annotations for cases where rustfmt will never be able to understand otherwise.

Would would mean decisions about the formatting of a codebase could be deferred to a dependency's author, rather than in the control of the developers of the actual code in question? That doesn't seem like a good shift in responsibility.

@calebcartwright Thank you for writing up a great summary.

The difference is that these attributes would appear on method
definitions, and would then improve formatting for all users of those
methods. One method definition, many many callers. That seems worth a
few annotations for cases where rustfmt will never be able to
understand otherwise.

This means rustfmt needs to be able to resolve names, which is currently (and will be, sadly) outside the scope of rustfmt.

I sometimes think one formating rule or the other would better be different, but what i really love about rustfmt, is that the same code always looks the same. If you allow programmer discretion in formating every third programmer would do much worse.
So i would much rather have bad but standardized formater than programmer discretion, thank you very much!
And the i don't think rustfmt is bad at all.

If you allow programmer discretion in formating every third programmer would do much worse. So i would much rather have bad but standardized formater than programmer discretion

While I agree on this point as a general trend, I have to admit that it does fail in the aforementioned examples. In those cases, strickly sticking to it is valuating standardization over readability, which I think is a bad idea as well. I think in this very cases, human flexibility is better than blind procedural formatting.
I also think that examples like the ones given above are both rare enough that special-casing them is the right solution, and frequent enough that falling back on #[rustfmt::skip] is undesirable. Thus my full support :)

While I agree on this point as a general trend, I have to admit that it does fail in the aforementioned examples. In those cases, strickly sticking to it is valuating standardization over readability, which I think is a bad idea as well. I think in this very cases, human flexibility is better than blind procedural formatting.

Fully agreed! rustfmt overall does a great job, but there are some cases where some programmers like to put more nuance into their formatting to convey additional information or to increase readability by symmetry, and then rustfmt can sometimes remove that information and likewise remove the symmetry.
This issue is an example of this; my own pet peeve here is rustfmt's handling of match, which suffers from similar issues (https://github.com/rust-lang/rustfmt/issues/3995, https://github.com/rust-lang/rustfmt/issues/4004, https://github.com/rust-lang/rustfmt/issues/4005). It might make sense to consider this more broadly instead of focusing on each separate case (or maybe they truly do need individual treatment, not sure).

On the extreme other end, you might be able to solve the original example with language:
trait W {
  fn pll1rge_range8(self) -> Self;
  fn divp1en_enabled(self) -> Self;
  ...
}

impl W for SomeW {
  fn pll1rge_range8(self) -> Self { self.pll1rge().range8() }
  ...
}

fn func() {
    p.RCC.pllcfgr.modify(|_, w| {
        w.pll1vcosel_wide_vco()
            .pll1rge_range8()
            .divp1en_enabled()
            .divq1en_enabled()
            .divr1en_enabled()
    });
}

I'll admit this is probably overkill (and may be impossible in some cases), but there may be situations where this might be useful for cases beyond simply formatting, and an format would just be a bonus.

Thinking about a solution that works 9 out of 10 cases, can't there be some setting that when splitting, would allow chains to be not 1 per line, but some other specified number?
I expect the typical code would be quite symmetric, but in other parts of the code regular 1 per line call makes more sense.
@joshtriplett I think the chain start/end annotations, even if nice for rustfmt, are going to be a "crate service" provided to the users which might not happen or work nice in practice. And when the chain formatting doesn't happen for the user, the source is going to be very obscure. Also, will these chain attributes take precedence over the defaults? Won't that mean that depending on the crates you draw from, different parts of the code would look different?
I've hit this problem in a code doing parsing with pest and have a similar problem to @bcantrill, but in my case the end of chain is a local choice that makes sense from the perspective of the operations I'm doing.
In the test code I have these:
parse.unwrap()
    .next().unwrap().into_inner() // inside typedef
    .next().unwrap().into_inner() // inside rhs_typedef_complex
    .next().unwrap().into_inner() // inside complex_type_def
    .next().unwrap().into_inner() // inside rhs_typedef_simple

But in main.rs, depending on the context it might make more sense to have the break after unwrap():
pair
    .into_inner().next().unwrap()
    .into_inner().next().unwrap()

Apologies everyone for the lengthy radio silence. Chains have a lot of moving parts and unfortunately until very recently I haven't had the bandwidth to dig back into this. I do, however, have some updates that I suspect (or at least hope) most will perceive as good news.
In short, I've got a working enhancement to rustfmt locally that will deliver the core ask of this issue for a (non-default) option that will honor the developer-authored relative association of chain items.
I've still got some cleanup left to do and a few more scenarios to think through, but I wanted to go ahead and provide this update as well as request feedback from the community on a few specifics (which I'll detail in separate comments in order to collect direct feedback).
To provide some context and level-set on expectations:

Plan is to introduce a new config option which controls chain formatting, and this new option will include a variant that will provide the requested feature/control/style
The default will, unequivocally, continue to be the same as the current state as prescribed by the Style Guide
Other variants may be considered down the road, but will be subject to the standard considerations for new options/variants
This is only relevant to chain handling. The standard/existing rules around indentation and the formatting of specific chain items still exist, and I plan to treat those as orthogonal topics for the purposes of this particular issue. I realize there was an additional ask in the description and other comments for something similar for other types of AST constructs (e.g. calls). However, I want to avoid the futility of attempting to boil an ocean and instead want to keep things in more manageable, practical chunks. We can certainly investigate providing a similar pattern/solution for other AST constructs down the road (provided this one pans out for chains), but those should be discussed at a future date in a dedicated issue.
We (rustfmt team) are not going to attempt to implement any "preserve what the developer wrote except/unless..." types of models. That's a proven recipe for idempotency bugs, and as evident by the above discussion, has far to many edge cases and "what about" questions with too many divergent opinions. If you opt to use the new config option variants which preserve the way you associated the chain items and that exceeds the max_width boundary, then rustfmt will treat it the same way as any other chain it can't fit: it will bail on formatting the chain, and it will be up to the developer to adjust/refactor accordingly (and we'd encourage such users take advantage of other config options, e.g. error_on_line_overflow, so rustfmt will tell you when you've got a chain that's too long)

As mentioned in my prior comment I'd like to share what we're (nearly) ready to support via the new option in order to gather feedback. I also have one remaining question on how users would like the new option to work when the indent_style has been set to Visual.
Given the interest in this issue and likely number subscribed for notifications I want to ask that everyone be mindful of posting new comments. This sequence of comments from me requesting feedback will already be rather noisy (apologies but it's the best way for me to get input from the community), so I'd like to try to minimize additional noise and reading.
I'm asking for those willing and interested to provide their feedback via the reactions on the below comments/questions, primarily in the form of the thumbsup reaction to indicate support. I'd also ask that you only use the thumbsdown reaction if you strongly feel the respective option shouldn't even exist; don't just down vote it because you don't plan on using it yourself.
Feel free to comment with clarifying questions or explain why you think an option shouldn't exist. However, please do not ask for other features/variants, off topic questions, etc. What's described below is what's feasible for us to deliver, and assuming the behavior described below will be of interest,  I'll open a separate issue later to facilitate the bikeshedding around the names of the option and variants.
@bcantrill - as the original author of the issue, would be great to get your input on whether either of the two new variants described below will help meet your need (or at least reduce friction compared to current state)

New variant to preserve association of chain items (rustfmt won't join chain items you had separated, nor split items you had connected)
Taking some slightly exaggerated versions of the inputs provided in this thread, with this variant the following:
fn func() {p.RCC.pllcfgr.modify(|_, w| {
                    w.pll1vcosel().wide_vco()
.pll1rge()   .range8()
.divp1en()    .enabled()
.divq1en()         .enabled()
.divr1en()         .enabled()
    });

    p  .      RCC.d1cfgr.write(|w| {
                w.d1cpre().div1()
            .d1ppre()   .div1()
                .hpre()    .div1()
});

        foo.bar(
    big_arg1,
    big_arg2,
    "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
)?.build()?;

foo.bar(BigStruct {
    aaaaa: "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
bbbb: "bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb",
cccc: "ccccccccccccccccccccccccccccccccccccccccc",
}).await?
}

#[tokio::main]
async fn main() -> reqwest::Result<()> {
reqwest::Client::new()
        		.get("http://example.org")
	.send().await?
        .text().await?;
    Ok(())
}

Would produce the below formatting. Note that this could also be used for those wanting to keep awaits on the same line, those wanting keep subsequent items on the same line of preceeding multiline item, if you choose, and more; it just puts a bit more onus on you and the developer to write the code with the associations you want.
fn func() {
    p.RCC.pllcfgr.modify(|_, w| {
        w.pll1vcosel().wide_vco()
            .pll1rge().range8()
            .divp1en().enabled()
            .divq1en().enabled()
            .divr1en().enabled()
    });

    p.RCC.d1cfgr.write(|w| {
        w.d1cpre().div1()
            .d1ppre().div1()
            .hpre().div1()
    });

    foo.bar(
        big_arg1,
        big_arg2,
        "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
    )?.build()?;

    foo.bar(BigStruct {
        aaaaa: "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
        bbbb: "bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb",
        cccc: "ccccccccccccccccccccccccccccccccccccccccc",
    }).await?
}

#[tokio::main]
async fn main() -> reqwest::Result<()> {
    reqwest::Client::new()
        .get("http://example.org")
        .send().await?
        .text().await?;
    Ok(())
}

Note that as mentioned above, the individual formatting rules for the specific items in the chain still apply. So with an input like the following that's (unnecessarily) multilined the bar call:
fn f() {
    foo.bar(
        "a",
    ).baz();

foo.bar(
        "a",
    	)
.baz();
}

this new variant doesn't control the function call rules, so the bar call will still be unwrapped/flattened, resulting in the following:
fn f() {
    foo.bar("a").baz();

    foo.bar("a")
        .baz();
}

Again specifics of function calls, closures, etc. are separate and can be discussed at a later date. This variant is just about the chains and giving you the ability to control how chain items are associated to each other.

New variant that's almost entirely hands off your chains. In this case rustfmt will only perform some minor adjustments to chains:including:

indentation correction on the start of the chain (unavoidable)
trimming any trailing spaces off the end of every line
when a chain appears in a RHS position (e.g. an assignment) rustfmt will select the RHS option for the start of the chain (e.g. same line as LHS/assignment operator or next line) that minimizes max_width excess

Otherwise rustfmt will leave the entire contents within the chain unformatted, and you the developer will be responsible for the formatting of contents within the chain.
This would be roughly analogous to an implicit, light version of the skip attribute being applied to all your chains, without you having to explicitly attribute each as such.
E.g. with this variant, the following:
fn f() {
// trailing space input chain line, removed in output
foo.bar.baz()
    }

would be formatted as:
fn f() {
    // trailing space input chain line, removed in output
    foo.bar.baz()
}

However, this would also mean that any odd/undesirable/etc. formatting within the chain will be left untouched, e.g. the following:
fn f    (
) {
foo    .      bar   .       baz   (  )
    }

would produce this result, with the internal chain content not formatted
fn f() {
    foo    .      bar   .       baz   (  )
}

This does of course give developers the most flexibility, but it's not one I'd use personally because I think it would be too easy to have large chunks of code left unformatted (e.g. a chained call that includes a closure with a large body) which the developers may not even realize/notice.

For the first variant discussed above in https://github.com/rust-lang/rustfmt/issues/4306#issuecomment-992054276, I'd like to get a sense of how those that would leverage it in conjunction with indent_style=Visual would expect subsequent chain items to be indented with a multiline chain where the developer had 3 or more chain items on the first line.
E.g.
fn f() {
  looooooooooooooooooonnnnggg.foooo.baaarr()
 .bazzzzzzzzz()
 .quxxxxxxxx()
}

Should the visual indent be based between the first and second item, or the last and second to last item? (separate comments added below for respective voting/feedback). I'd probably suggest using the first and second to try to minimize the rightward drift and risk of hitting the max_width boundary, but I'm not a user of the visual indent style myself so open to whatever works best for those folks.
For reference, here's how the existing default behavior works (which wraps the baaarr call to the next line)
fn f() {
    looooooooooooooooooonnnnggg.foooo
                               .baaarr()
                               .bazzzzzzzzz()
                               .quxxxxxxxx()
}

Visual Indent based on first and second item of first line (as described above in https://github.com/rust-lang/rustfmt/issues/4306#issuecomment-992055178)
fn f() {
    looooooooooooooooooonnnnggg.foooo.baaarr()
                               .bazzzzzzzzz()
                               .quxxxxxxxx()
}

Visual Indent based on last and second to last item of first line (as described above in https://github.com/rust-lang/rustfmt/issues/4306#issuecomment-992055178)
fn f() {
    looooooooooooooooooonnnnggg.foooo.baaarr()
                                     .bazzzzzzzzz()
                                     .quxxxxxxxx()
}

Any updates on this feature or anything I can do to help get it over the line?

I share many of the sentiments discussed so far. What's the status of this?

I share many of the sentiments discussed so far. What's the status of this?

Any updates on this feature or anything I can do to help get it over the line?

The last comments from me on this thread posed questions to @bcantrill as the original author as well as the community at large, both of which have largely gone unanswered. Unfortunately, as has typically been the case historically, we receive a lot of complaints about chain handling but comparatively little feedback when it comes to the specifics of the actionable, concrete elements we can support.
There's no updates from the rustfmt team on this, and while I appreciate the offers to help, what we really need is more responses/feedback on the questions already posed above.

I share many of the sentiments discussed so far. What's the status of this?

Any updates on this feature or anything I can do to help get it over the line?

The last comments from me on this thread posed questions to @bcantrill as the original author as well as the community at large, both of which have largely gone unanswered. Unfortunately, as has typically been the case historically, we receive a lot of complaints about chain handling but comparatively little feedback when it comes to the specifics of the actionable, concrete elements we can support.
There's no updates from the rustfmt team on this, and while I appreciate the offers to help, what we really need is more responses/feedback on the questions already posed above.

My apologies; I didn't realize that this was blocked on me! I would say that this variant looks great:
https://github.com/rust-lang/rustfmt/issues/4306#issuecomment-992054276
One follow up question: would this apply to function arguments as well?  (We have much the same challenge with, e.g.,
bail! and other macros that operate on format strings.)
Thank you again for your work on this important piece of the Rust ecosystem, and my apologies again for not realizing that further work had become blocked on my feedback!

I would like to provide another perspective on this issue: Due to disability I am coding on a very specific setup; an ancient thinkpad with a small screen and a large font size. Effectively this gives me a 26 row/105 column setup to work with. I often use split screen.
I very actively decides which code should go onto my main view and which does not. I tend to avoid lines with just a closing parenthesis. Sometimes I deliberately split arguments into multiple lines to have them all on the screen, sometimes I deliberately use very long lines just because the precise content of an error message is not that important most of the time.
Right now, rustfmt style makes effective coding very hard for me sometimes. I just deactivated it as part of the CI setup for a project because my loss in productivity is just not worth it. This feature will help a lot in that regard!

Re indent_style=Visual this option makes the most sense to me but I don't feel strongly about it.

any odd/undesirable/etc. formatting within the chain will be left untouched

Thats understandable, I suppose it is up to the dev to keep things tidy.

Could rustfmt avoid "rechaining"  lines with a trailing comment.
Indentation and inter-function/arg spacing could still be corrected, but which functions are chained on that line should be left as-is.
Reasoning:

The comment is a comment FOR THE LINE and most probably applies to several chained calls on that line. ie the meaning is changed by placing the comment on a different line from some of the calls.
eg in the code below the comments apply to ALL calls on that line of code.

  acount.set_owner("name")
      .debit(cash).credit(cash)   // ensure debits and credits match
      .set_transaction date(today)
      .set_id(id)
      .begin_tran().write_entries().commit_tran()?;  // write within a transation

3. A trailing comment means the line width might be exceeded anyway by the comment, regardless of wrapping chained function calls
4. This solves some of the desired "manual override" requests above, as developers could just add a terminating comment // if they want to keep pairs of chained calls together

A trailing comment means the line width might be exceeded anyway by the comment, regardless of wrapping chained function calls

This solves some of the desired "manual override" requests above, as developers could just add a terminating comment // if they want to keep pairs of chained calls together

It doesn't solve the desire for manual control over groups in the chain.  A comment is not always warranted or desired.  A single "leave this alone" attribute at the start of the expression feels better than a magic or load bearing comment.  Even if a comment is warranted it may well be long, and requiring line width excursions to get the behaviour is also not ideal.

I agree. It doesn't really solve the desire for manual control, and there are better ways to help achieve that objective, as you state. But I still feel that the presence of  line comments is relevant to chaining of functions, and somehow needs to be incorprated and work alongside any explicit control.
One more item. I think the rule "dont unchain/chain lines with an end of line comment" applies to other structures too. And reformatting code without paying attention to line comments effectively "breaks" the comment or renders it meaningless.
Rust supports "//" style line comments as a language feature. And they are tied to lines, and thus the line breaks around them become meaningful. Its probably one of the few cases where whitespace like this carries meaning in the language syntax. So rustfmt should not ignore this aspect of the language.
For example arrays.

let tokens : [&str: 9] = [ "-",  // hyphenation
  "a", "e", "i, "o", "u", // vowels
  ",", ".", "?" // punctuation
];

and also to conditional booleans in an if-then expression (obviously this example can be written more idiomatically)
if balance > 0 &&
   name.len() > 0 && name[0].is_digit()  // check length before accessing by index
   &&
'''

@calebcartwright are you thinking about moving one of your proposals forward, need help, ?

@calebcartwright if you're still looking for feedback, especially to help get these changes across the line, then I'd say that your "variant" proposal looks pretty good to me, and would be much better than the status quo, which is far more destructive.
Could you introduce your variant behind a config switch, and then we (the end users) can start using it and give you better feedback? Right now, I wouldn't know how to try your variant mentioned here - it looks good, but does an implementation exist so I can try it with my own day-to-day code?

FWIW, I recall having had thoughts about how distinguishing "line length" (number of chars) from "line weight" (number of items) could help in automating arguments/chains/arrays/etc. wrapping. Maybe some of this can be of relevance here?
https://github.com/psf/black/issues/1281#issuecomment-630309674

Sorry for the excessive delay in providing an update/response, and thanks to all for the discussion and feedback.
In short, we're going to introduce a new config option that will support controlling the line break behavior between chain elements that will, more or less, look like what I outlined in prior comments above.
There's a few reasons why we're going to do this, with the primary two being:

rustfmt needs to be able to apply different chain formatting paradigms to be prepared to support a hypothetical scenario where the Style Team decides to change the default chain formatting rules in a future Style Edition. Adding this config option will be the best way to do so.
I'm sufficiently persuaded by the original argument of this issue that Rust is used in contexts where the addition/removal of line breaks between chain elements borders on being semantically significant.

I can't and won't attempt to provide an estimate for when this new option might land on nightly. It's likely going to have to be accompanied by some other internal chain-related refactoring, and we've got various other priorities as well. However, portions of the changes needed to achieve this have actually already been implemented and merged (as they were independently beneficial), and I anticipate we'll be able to spend some bandwidth on this before the end of the year.
Finally, while I certainly appreciate the offers to help, I don't think the development of this new option is something that others can readily assist with; it's a complex part of the codebase that has a number of outstanding code-level design questions which also need to be considered alongside other needed changes. As such I don't think it would be practical for us to delegate nor mentor the work.
The best way users could assist would be helping with rustfmt more generally (please PM me on Zulip if interested), and/or testing the new config option once available.

@bcantrill
My apologies, I did not intend to imply this was blocked on you, I just wanted to know if the proposal seemed reasonable to you given that you'd taken the time to make the case for this feature in the OP of this issue.
We'd made some good progress on this, but then hit a wall trying to determine how it should behave with other options. It subsequently fell off our radar due to other priorities popping up and a lack of community feedback (at the time).

One follow up question: would this apply to function arguments as well?

Not now, as we'll need to focus on chains first. However, if we're able to find success with chains then I think we'd be able to look at call site args next.

@koraa re: https://github.com/rust-lang/rustfmt/issues/4306#issuecomment-1406391850
Thanks for sharing , I'm glad to hear you think this will likely be beneficial for you.
Though not necessarily related to the specific feature request in this issue, I'd suggest reviewing the Rust Style Guide (which defines the style rustfmt has to provide by default), and if there are other cases where you feel those prescriptions could be better given those constraints you're working within, then consider sharing with the Style Team in https://github.com/rust-lang/style-team/ (similarly with us on the Rustfmt Team here in this repo if you think a new config option could be helpful to provide some non-default behavior)

@tgross35 re: https://github.com/rust-lang/rustfmt/issues/4306#issuecomment-1493836986
Thanks for the feedback

but would add that I'd expect it to still split at line length - just pick the . closest to the line limit and insert a new line.

Understand why users would like that, but this was (somewhat) discussed previously and that's not going to be in scope for what we'll do from the rustfmt side. It's a bit too much of "having one's cake, and eating it too", with too many edge cases and competing user preferences for me to justify the rustfmt team spending cycles on it.
Others will be able to take a crack at implementing additional variants for the new option once it lands if they'd really like this type of conditional preservation.

I would assume that the AST tree contains name information and we would be more than happy with having something like: chain.always_inline.
I feel like most of us would be happy with such a solution. I personally do not have any issues with every element being placed on a new line. However, in the case of unwrap() or await it gets a little bit annoying. I would personally just run with something similar to always_inline = ["await", "unwrap", "iter", "to_*", "into"].
Ideally it would be great if there was an option to not reformat chains at all as it currently lacks the feature due to the fact that it rebuilds code instead of changing it from the AST.
While these stop-gap measures might not be the ideal solution long-term it would still be quite useful for the ability to create simple configurations without dipping into the documentation on creating more complex patterns as most of the time.
Just my 2 cents as this is still far better than whatever jetbrains gives you for formatting especially around (some) macros.

Thanks again for all the input, but at this point I'm going to lock this issue as resolved (n.b. this is not a reaction to any particular comment, I'd meant to do this when I made my prior comment)
This issue was a request for a specific enhancement to be made available in two specific positional contexts, which we've already responded to and announced our plan of action.


Different values for arbitrum CRV rewards on frontend vs. this app

        await curve.init('JsonRpc', { url: ARCHIVENODE_ARB }, { gasPrice: 0, maxFeePerGas: 0, maxPriorityFeePerGas: 0, chainId: 42161 });
        const _2pool = curve.getPool('2pool');
        const Rewards = await _2pool.stats.tokenApy();
        console.log(Rewards);

Returns:
[ '2.1049', '5.2624' ]
ie. CRV rewards of ~2.1%
CRV rewards at https://arbitrum.curve.fi:

ie. CRV rewards of 1.37%

curve-js gives correct values (obtained from https://api.curve.fi/api/getPools/arbitrum/main). Old UI didn't update this part. Don't rely on it.


1.20.4 Update

Amazing mod !

Hello, thanks for the feedback! It is greatly appreciated. 😁
The mod has been updated to version 1.3.7 (Minecraft 1.20.4). You can find download links in the modrinth page or in the releases page.


In Jump Bank message, make page: 0 a default

Also make navigator mode generate Jump Bank messages with page defaulted, if appropriate

Fixed in 0.1.2


Can you use Terraform Extension for Azure DevOps WITHOUT a service connection?

We are trying to utilize Terraform Extension for Azure DevOps to create AWS resources. We are using self-hosted agents running as EC2 in the account we want Terraform to act in. Is there a way to get Terraform to use the EC2 Instance Metadata of the host EC2 instead of a service connection?
Note: this authentication method is similar to the one provided with AWS Toolkit for Azure DevOps

It looks like backendServiceAWS is required and is utilized to set some of the backend config.

It looks like if we store the statefile somewhere else it might work.

For the AWS Toolkit for Azure DevOps we support this use case by making the authentication optional. It would make sense to make provider optional/add a noop "Environment" option, so if the machine already has credentials, they can be used.

@N-Usha to look into this enhancement request.

@clcpolevaulter, Thanks for making this feature ask. While we acknowledge that this may be a feasible option for AWS deployments, we need to ensure optimal user experience for rest of the scenarios. We will surely consider this for future investments to enhance the extension. However we do not have any timelines to commit at this time given that we prioritize our investments by impact and severity for a broad set of customers; the impact of this problem is limited relative to other existing problems that we are currently investigating.
Thanks again and please continue to give us your valuable feedback.

@AmrutaKawade @N-Usha @arjgupta @chshrikh
On a similar note, the Terraform Extension for Azure DevOps uses the service connection: "AWS for Terraform" for authentication:

Is it possible for the extension to consume the service connection provided by AWS Toolkit for Azure DevOps
or
In the service connection "AWS for Terraform", add an optional field for RoleToAssume & ExternalID , to make the service connection more usable and secure
or
Just like @clcpolevaulter mentioned, make the service connection option for the extension optional, so we can consume the metadata permissions from the agent its running on, or fetch credentials from environment variables

@AmrutaKawade @N-Usha @arjgupta @chshrikh
On a similar note, the Terraform Extension for Azure DevOps uses the service connection: "AWS for Terraform" for authentication:

Is it possible for the extension to consume the service connection provided by AWS Toolkit for Azure DevOps
or
In the service connection "AWS for Terraform", add an optional field for RoleToAssume & ExternalID , to make the service connection more usable and secure
or
Just like @clcpolevaulter mentioned, make the service connection option for the extension optional, so we can consume the metadata permissions from the agent its running on, or fetch credentials from environment variables


Brighten things up with emojis before name.

Also makes it possible to vote using emojis, by just writing
+:carrot: in the chat!

Completely useless, I love it!


Nested sort

Hi,
Is there a way to sort on nested documents?
    'sort' => [
            'nested_field.attribute' => [
                'order' => 'asc',
                'nested' => [
                    'path' => 'nested_field'
                ]
            ]
        ]

Possibly, I never tried it 😅

@Jeroen-G I added support for it in a fork: https://github.com/joelatgrayv/Explorer however, I'm getting
 1 covered mutants were not detected. I'm not sure how to resolve it...

If all test pass after infection changes something then you are either missing a test, or a test is doing not enough.
In this case I think there is no test where build() is called while $result is empty.

Thanks for looking. How could that ever happen?
$field can't be null
$order asserts that it's asc or desc
$result is initialized with those values.

Looking at it again, if you write a test for this function both with the if outcome true and false and you assert the result in both tests then you should be covered.

Let me know when you need more help!

I have all lines covered. Here is the coverage:

Here are the tests from SortOrderTests
    public function test_it_builds_sorting(): void
    {
        $sort = Sorting::for(
            new Sort(':fld:', SortOrder::DESCENDING),
        );

        self::assertSame([ 'sort' => [ [ ':fld:' => ['order' => 'desc'] ]]],$sort->build());
    }

    public function test_it_builds_sorting_with_nested(): void
    {
        $sort = Sorting::for(
            new Sort('foreign_model.name', SortOrder::DESCENDING, 'foreign_model'),
        );

        $expected = [ 'sort' => [ [ 'foreign_model.name' => ['order' => 'desc', 'nested_path' => 'foreign_model'] ]]];
        $result = $sort->build();
        self::assertSame($expected,$result);
    }

And another from FinderTest:
public function test_it_accepts_a_sortable_query_with_nested_sort(): void
    {
        $client = Mockery::mock(Client::class);
        $client->expects('search')
            ->with([
                'index' => self::TEST_INDEX,
                'body' => [
                    'query' => [
                        'bool' => [
                            'must' => [],
                            'should' => [],
                            'filter' => [],
                        ],
                    ],
                    'sort' => [
                        ['foreign_model.name' => [
                            'order' => 'desc',
                            'nested_path' => 'foreign_model',
                        ]],
                    ],
                ],
            ])
            ->andReturn([
                'hits' => [
                    'total' => ['value' => 1],
                    'hits' => [$this->hit()],
                ],
            ]);

        $query = Query::with(new BoolQuery());
        $builder = new SearchCommand(self::TEST_INDEX, $query);
        $query->setSort([new Sort('foreign_model.name', SortOrder::DESCENDING, 'foreign_model')]);

        $subject = new Finder($client, $builder);
        $results = $subject->find();

        self::assertCount(1, $results);
    }


Postgres flexible server does or does not automatically fail over to another AZ during scale compute?

This article says that if a flexible server is configured in high availability mode, triggering a scale operation will failover to the standby database while the primary is being scaled.
https://docs.microsoft.com/en-us/azure/postgresql/flexible-server/how-to-scale-compute-storage-portal
But this article says that that is not currently the case, that scaling a flexible server in high availability mode triggers downtime of the primary instance without failover. ￼￼
https://docs.microsoft.com/en-us/azure/postgresql/flexible-server/concepts-high-availability
 Currently, the service is not failed over to the standby and hence while the scale operation is carried out on the primary server, applications will encounter a short downtime.

@khalil-omer Thanks for reaching out. We will investigate and update the thread accordingly.

@khalil-omer I noticed the conflict between the documents. This is being assigned to the content author to evaluate and update as appropriate.

This is address now and below information is accurate.
Currently, the service is not failed over to the standby and hence while the scale operation is carried out on the primary server, applications will encounter a short downtime.

#please-close


cannot run Cannot find module './uws_linux_x64_88.node'

Hey, sorry for this bug report but cannot find any infos  to solve this
on the main page i found version node 15 is supported
but on start i get

/home/arpu/Work/tcu/pshareSignal/node_modules/uWebSockets.js/uws.js:29
		throw new Error('This version of µWS is not compatible with your Node.js build:\n\n' + e.toString());
		      ^

Error: This version of µWS is not compatible with your Node.js build:

Error: Cannot find module './uws_linux_x64_88.node'
Require stack:
- /home/arpu/Work/tcu/pshareSignal/node_modules/uWebSockets.js/uws.js
    at /home/arpu/Work/tcu/pshareSignal/node_modules/uWebSockets.js/uws.js:29:9
    at Object.<anonymous> (/home/arpu/Work/tcu/pshareSignal/node_modules/uWebSockets.js/uws.js:31:3)
    at Module._compile (node:internal/modules/cjs/loader:1108:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1137:10)
    at Module.load (node:internal/modules/cjs/loader:973:32)
    at Function.Module._load (node:internal/modules/cjs/loader:813:14)
    at ModuleWrap.<anonymous> (node:internal/modules/esm/translators:199:29)
    at ModuleJob.run (node:internal/modules/esm/module_job:152:23)
    at async Loader.import (node:internal/modules/esm/loader:166:24)
    at async Object.loadESM (node:internal/process/esm_loader:68:5)
 arpu@hokuspokus  ~/Work/tcu/pshareSignal   master ● ?  node --version                                                                                 1 ↵  10051  22:44:21
v15.4.0

looks like i had to uninstall uws firast and reinstall


OIDC connect with Google - Debug a 400's

Hola! 👋
I'm trying to setup Google's OIDC auth for Headscale, my headscale config.yml has the following configuration for oidc:
oidc:
  issuer: "https://accounts.google.com"
  client_id: "31928xxx-d09xxxxxxxxxx.apps.googleusercontent.com"
  client_secret: "GOxxxxxx"

[x] I have an (external reachable) domain, with SSL configured.
[x] I have added the callback URL https://tailscale.domain.com/oidc/callback to Google's OAuth authorized redirect URIs.
[x] I have setup a consent page with "Internal" user type (as it's for my organization).

No errors seen on Headscale's logs:
2022-02-18T23:23:46Z DBG There has been updates since the last successful update to tailscale-prd handler=PollNetMapStream last_state_change=164522662
4 last_successful_update=1645226616 machine=tailscale-prd
2022-02-18T23:23:48Z DBG Redirecting to https://accounts.google.com/o/oauth2/v2/auth?client_id=31928xxxxx-d09xxxxxxxxxx.apps.googleusercontent.com&redirect_uri=https%3A%2F%2Ftailscale.domain.com%3A8080%2Foidc%2Fcallback&response_type=code&scope=openid+profile+email&state=c63ed2
bcf4b5f58569ee7bbfea427b73 for authentication
[GIN] 2022/02/18 - 23:23:48 | 302 |     157.585µs | 190.191.xxx.xxx | GET      "/oidc/register/mkey:xxxxxxxxxxxxxx"
2022-02-18T23:23:56Z DBG Sending update request func=scheduledPollWorker machine=tailscale-prd
2022-02-18T23:23:56Z DBG There has been updates since the last successful update to tailscale-prd handler=PollNetMapStream last_state_change=1645226634 last_successful_update=1645226626 machine=tailscale-prd
2022-02-18T23:24:06Z DBG Sending update request func=scheduledPollWorker machine=tailscale-prd
2022-02-18T23:24:06Z DBG There has been updates since the last successful update to tailscale-prd handler=PollNetMapStream last_state_change=1645226644 last_successful_update=1645226636 machine=tailscale-prd

When I open the Login URL from my laptop I got redirected to Google's account selection, I pick my organization's account and then I just receive a 400 error:
400. That’s an error.

The server cannot process the request because it is malformed. It should not be retried. That’s all we know.

and the response from the server is:
)]}'

[[["er",null,null,null,null,400,null,null,null,3],["e",2,null,null,78]]]

Environment:

EC2 Ubuntu instance
Headscale v0.13.0
Tailscale client 1.20.4 @ mac osx

Is there any way to debug this kind of error?
Thanks!

I think I found a race condition. I've noticed that the Google authentication request page was in Spanish, manually switching the language to English did the trick and the authentication was successful.

Encountered the exact same behavior with v0.15.0
Switching from "English (UK)" to "English (US)" helped.

This one is a bit weird, not sure why that should matter. This part should be handled by the upstream library I believe.
Can any of you by any chance provide an example payload that brakes it so we can compare?

Will do
I also noticed that "English (UK)" breaks almost every Google OIDC integration I used for the past couple of months. Not sure why, but it seems that the problem may be elsewhere. Anyways, will get back to you with example payloads.

Okay, so I can't figure out which payload fields are sensitive and which are not, but I noticed one interesting thing.
Here is the request path that fails for me when I try to log in from my browser:
https://accounts.google.com/_/signin/oauth?authuser=2&hl=en-GB&_reqid=<redacted>&rt=j
The interesting thing is that this doesn't reproduce when using other languages. It also works with English (UK) chosen when doing a fresh log-in to a google account (I tried incognito mode and another browser). So I compared payloads and noticed that the failing request lacks hl=en-GB in form data. Every successful request I inspected included that field. Haven't figured out why it's being omitted, though.


Rewrite EventBus

Current EventBus realisation very ugly. Needed rewrite

good first issue 😄

should be fixed by #12


copy: limit the number of go routines

@f0rmiga were you thinking similar?
I don't think it's worth getting too complicated, at least for now.
I assume by the time the number of concurrent copies reaches this number the OS/IO operations will far outweigh the go routines, so I don't think limiting the go routines will do any harm?

See https://github.com/aspect-build/bazel-lib/pull/351


Support building without containers (docker)

Is your feature request related to a problem? Please describe.
I'm a packager of OpenSearch in Arch Linux and would like to be able to build without docker since in our chroot environment we can't start docker.
Describe the solution you'd like
I'd like to have the ability to skip any docker steps which are not required for building the project even if it means skipping some tests
Describe alternatives you've considered
I tried using podman but it's not supported - I believe this is in discussion / progress. Even if podman is available as alternative the ability to build the project without containers would be beneficial and unblock me, then I can work on maybe enabling podman when it comes available.
Additional context
Add any other context or screenshots about the feature request here.

I believe we use to skip Docker dependent steps in build but not for distribution targets:
Docker (checked [/usr/bin/docker, /usr/local/bin/docker]) is required to run the following tasks:
:distribution:docker:buildArm64DockerImage
:distribution:docker:buildDockerImage
:distribution:docker:buildPpc64leDockerImage
:distribution:docker:buildS390xDockerImage
you can address this by attending to the reported issue, or removing the offending tasks from being executed.

Should not be too difficult to fix that. Also, for podman support, please check https://github.com/opensearch-project/OpenSearch/issues/6877

@inglor can you try what @reta mentioned above and submit the PR for the fix ? Thanks

@minalsha what's the suggestion exactly? To skip the tasks. I don't think that's a real solution.

@minalsha what's the suggestion exactly? To skip the tasks. I don't think that's a real solution.

@inglor what do you think is the solution?

@minalsha what's the suggestion exactly? To skip the tasks. I don't think that's a real solution.

@inglor what do you think is the solution?

The current state is that the below sub-projects require docker to build due to tests:
    repository-azure
    repository-gcs
    repository-hdfs
    repository-s3

The ideal solution would be to split tests to ones which require docker and the ones which don't, so when downstream projects building those are able to only execute tests which don't require docker with a command line flag (until podman is solved).

I am going to say something controversial, but I think integration tests (that require docker) should not be required to produce the distribution build. IMO that is backwards in OpenSearch, I'd want to make sure all code compiles/builds/assembles, then I want to run integration tests with the output.
Another far-fetched idea: we could go as far as removing these plugins from core repo 🤔 they bring a significant amount of annoying dependencies (e.g. AWS SDK for repository-s3).

I am going to say something controversial, but I think integration tests (that require docker) should not be required to produce the distribution build.

Agree

Another far-fetched idea: we could go as far as removing these plugins from core repo thinking they bring a significant amount of annoying dependencies (e.g. AWS SDK for repository-s3).

We POCed that :-) https://github.com/opensearch-project/OpenSearch/issues/1754

Would this compile/builds/assembles includes unitTesting? As a downstream consumer we get a bit more confidence when we execute tests (even unit testing) instead of just building and packaging it.

AFAIK  compile/assembles - no, build - yes


Shortcut key remapping

Please give up the option to configure the shortcut keys. Amongst other things, these ones conflict with Timeline plugin (KK, by Joan).
Thank you

I will consider this going forward.

Help this


move MC gyro subscription + corrections to BlockGyroCorrected

Controllib seemed like an okay place to put this, but I'm certainly open to suggestions.

Later we can cleanup the structure so that only that rate controllers can run faster than attitude.
@priseborough FYI

Great stuff! <3

@mhkabir this should be good to go after a quick MC and FW (or tailsitter) verification.

This is a case where parameter scope gets a little weird. The sensors module still "owns" the board rotation, but it's only actually used in controllib.

I have a different idea for handling this that I'll explore once https://github.com/PX4/Firmware/issues/8814 is in place.


Quality: PowerShell Summit - GroupPolicy module  #3322

PR Summary
This is an formatting work for the entire GroupPolicy module.
This contained 27 updated files

- Fixes #3322

PR Checklist

[ x] Descriptive Title: This PR's title is a synopsis of the changes it proposes.
[ x] Summary: This PR's summary describes the scope and intent of the change.
[x ] Contributor's Guide: I have read the contributors guide.
[x ] Style: This PR adheres to the style guide.

@microsoft-github-policy-service agree [company="Phil Bossman"]

@microsoft-github-policy-service agree
@microsoft-github-policy-service agree company="Phil Bossman"


Adding PlatformNotSupportedException to Counter cmdlets when running on IoT.

We have enabled the Counter cmdlets for PowerShell on OneCore for Windows. This means that these cmdlets are available Full Desktop with CoreCLR, Nano Server and IoT. However, one of the dependencies, the '$env:windir\System32\pdh.dll'  assembly, is not available on IoT. Because of this, when the user tries to use the Counter cmdlets on IoT, they will get a  PlatformNotSupportedException.
This PR includes the code change and new test cases to validate that PlatformNotSupportedException is thrown on IoT.

@lzybkr: Thanks for review. In order to run the Export-Counter cmdlet, you need to create a counter (which is not possible on IoT), this is the reason why there is not test for this scenario.
The command would be something like this: Get-Counter  | Export-Counter .