Decoration of requests

Is your feature request related to a problem? Please describe.
Elasticsearch requests have accompanying "descriptor" types (e.g. SearchRequestDescriptor<TDocument>) to incrementally configure requests in a fluent API style. However, unlike other fluent builders, they don't expose their state, so there's no way to know what has already been specified for the request. This leaves me unable to "decorate" requests: checking what has been set and altering it if necessary (e.g. "if no sort is specified, sort by timestamp").
The situation is somewhat better if you decline the fluent syntax in favor of SearchRequest and friends. However, even these types occasionally let you set state that is then no longer publicly accessible (e.g. the indicies on an OpenPointInTimeRequest).
Aside from decoration, this also becomes a pain point when trying to mock responses to requests with inscrutable state.
Describe the solution you'd like
Any state specified on a request model should be accessible in order to support decoration and other use cases.
Describe alternatives you've considered
It's possible to create custom POCOs that resemble ES request types for decoration/testing, but the mapping becomes tedious.
Additional context
Honestly not a fan of the two worlds between descriptors/requests. It makes things more cluttered when there are already too many types/signatures. Though most APIs have overloads for both, there are still times when I need a request and all I have is a descriptor or vice versa, and the types do not share an ancestor as they did in the NEST client (once again, the lack of accessible state means I can't even convert them manually).
Rant over. Still a fan of the v8 client. Please keep supporting/improving!

Hi @kmcclellan,

Though most APIs have overloads for both, there are still times when I need a request and all I have is a descriptor or vice versa, and the types do not share an ancestor as they did in the NEST client

The descriptor design is inherited from NEST but we dropped the common interface with the request. In part, it was a design decision to get rid of the bloat of interfaces that didn't add much value. It was also a technical decision at the time when STJ didn't support polymorphic deserialization directly. It would have forced us to have custom converters which again required more work to generate and extra code in the assembly. That second item would potentially be solved with the new attributes today, but we'd have to bump the minimum version of STJ we pull in.

However, unlike other fluent builders, they don't expose their state, so there's no way to know what has already been specified for the request.

Descriptors are subtly different to a builder which would hold the state as methods are called. They represent a fluent way to define requests, but the implementation detail is hidden. In our case, execution of the configure actions is deferred until the last possible minute. This allows users to prepare default descriptor instances and reuse them in various ways. Individual properties can be tweaked multiple times without causing extra allocations.

It's possible to create custom POCOs that resemble ES request types for decoration/testing, but the mapping becomes tedious.

This is usually our suggestion for usecases like yours. However, we are fully aware this has some drawbacks - like the rather big maintenance overhead.

Some of the descriptors implement the IBuildableDescriptor interface that provides a method to convert descriptors to their corresponding request classes. I will consider supporting this interface for all descriptor types to provide a way to check internal state for cases where performance/allocations are not a major concern.
We will as well discuss about make all properties of the request objects settable.

They represent a fluent way to define requests, but the implementation detail is hidden. In our case, execution of the configure actions is deferred until the last possible minute.

I understand the desire to encapsulate the serialization implementation. I think this could be preserved while granting access to partially configured request state. In the case of descriptor members which take delegates, it would make sense to provide this as an argument when they are invoked.

var search = new SearchRequestDescriptor<MyDocument>();

search.Sort(
    sorts =>
    {
        sorts.Add(new SortOptionsDescriptor<MyDocument>().Field(x => x.MyField));
    });

// This code doesn't have to know about the previous code.
search.Sort(
    sorts =>
    {
        if (sorts.Count == 0)
        {
            sorts.Add(new SortOptionsDescriptor().Field("@timestamp"));
        }
    });

This allows users to prepare default descriptor instances and reuse them in various ways. Individual properties can be tweaked multiple times without causing extra allocations.

I'm not sure if this is as useful as you think. For one, I'm rarely able to reuse descriptor instances. This would mean executing the exact same request multiple times, whereas usually there are slight differences based on one or more runtime arguments. For two, it's hard to "tweak" properties without knowing what their current state is (e.g. "sort by timestamp if no sort is specified").
I realize these are not simple changes and would likely require an architectural paradigm shift. As things stand, I don't find descriptors very useable.

I understand the desire to encapsulate the serialization implementation. I think this could be preserved while granting access to partially configured request state. In the case of descriptor members which take delegates, it would make sense to provide this as an argument when they are invoked.

It's not only about serialization, but as well about the descriptor implementation itself. The example code you've shown looks like a mix of descriptor and initializer style. I personally don't see the advantage over the plain initializer style here (assuming the request objects expose all of their state).

I'm not sure if this is as useful as you think. For one, I'm rarely able to reuse descriptor instances. This would mean executing the exact same request multiple times, whereas usually there are slight differences based on one or more runtime arguments.

There are some good cases where it's possible to reuse a descriptor. For instance, you could prepare a complete query and execute it on different .Index(). In this regard, the current descriptor implementation is as powerful as using plain request objects. The second call to a method always overrides the corresponding property.

For two, it's hard to "tweak" properties without knowing what their current state is (e.g. "sort by timestamp if no sort is specified").

I agree with that statement, but in these cases you can pass the plain request objects around or implement your own POCO wrappers. It's just not the intended usecase for these descriptors.
That being said, I will definitely think about some possible improvements (a few non breaking ones are mentioned in my previous comment).

I created an evaluation task for possible improvements on my internal TODO list. Closing this issue for now.


Add support for conditioned cross-field validations

Description :

We need to be able to run validations on fields under certain conditions that may happen when this and/or another field changes.

Requirements :

When having two fields (password & confirm_password), validate the field confirm_password matches the password when the password changes. But if they don't match, only the confirm_password should be in an incorrect status.
if any of the fields change (password or confirm_password) that validation should be triggered and if they match, the confirm_password should be correct (only if the confirm_password's other validations are correct)
This validations should be triggered only if both fields are not empty.

Use case :

User types some text in the password field -> Nothing happens and the password field is marked as correct.
Then he types the same thing in the confirm_password field. While writing the input shows an error saying that the passwords does not matches, but at the end the field is marked as correct.
Then the user types something different in the password field. Password field should be correct along as all its validations are correct, but the confirm_password should be in an incorrect state because the passwords do not match anymore.

Notes :

This was detected during the development of #19 . But this case is out of scope of that ticket and can be tackled separatelly as it is not a blocking issue at all.

We could try to implement a workaround, like creating an special field just for that validation while triggering it from both textviews 🤔


nixos/tang: create module for tang server

This commit adds a module for the tang server and the related nixos test.
Things done

Built on platform(s)

[X] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[X] Tested, as applicable:

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

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

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

[X] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 247037 run on x86_64-linux 1

1 package blacklisted:

nixos-install-tools

Thank you for this work!
I've copy-pasted the module code to config for installation of my new network-presence (low performance) machine in https://github.com/kravemir/nixos-config/commit/7b5a0fe9a8016fba355053d3b1cfa75305e92628, and it works successfully.
Is there any expectation when this PR will be merged into nixpkgs?

Note that #257525 goes further in the configuration of nixos to use clevis.
This PR sets the bases to deploy the tang service in a secure way. Maybe we should merge both work ?

@ofborg test

@ofborg test tang


Add m.fragment()

As announced in #1241, I've also added ./hyperscript, which combines render/hyperscript, render.raw and render.fragment.

LGTM

In ES6, it would have been tempting to implement it as
function fragment(...args) {
    return hyperscript(fragment, ...args)
}

and convert fragment to '[' in hyperscript.

Thinking about this a bit more, what about m(m.fragment [, attrs] [, children...]) where m.fragment is just a sentinel object attached to hyperscript? That way we could avoid duplicating the hyperscript logic.

I'm thinking the signature should be simpler, like m.fragment(attrs, children) (no optional args). The overload fragment(attrs) seems pointless, and fragment(children) is generally going to be the same thing as children

This is a really good point: a new fragment hyperscript signature only makes sense in the case of having both attrs, children, at which point it is simply the default hyperscript signature without the leading argument. Are we dead set against that? m( attrs, children )

So I chopped off a good deal out of it.


Enable painting segmentations and increase slicing performance

make launchable from within napari
load segmentations with 'r+'
use napari-ome-zarr for tomogram to increase performance

Ooops, the failing tests seem to be examples from the cookie cutter.


[VS Code] Live Share does not work with Remote - SSH  on Darwin

Issue Type: Bug
logs.zip

Install Remote SSH (https://github.com/Microsoft/vscode-remote-release)
Log in to a remote machine using Remote SSH
Select Live Share and paste in code.

Expected result:
Live Share starts
Actual result:
Live Share reports an internet connectivity error
Extension version: 1.0.950
VS Code version: Code 1.38.1 (b37e54c98e1a74ba89e03073e5a3761284e3ffb0, 2019-09-11T13:31:32.854Z)
OS version: Darwin x64 18.7.0
Remote OS version: Linux x64 4.15.0-1050-aws
Remote OS version: Linux x64 4.14.133-88.105.amzn1.x86_64

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-7660U CPU @ 2.50GHz (4 x 2500)

GPU Status
2d_canvas: enabledflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onnative_gpu_memory_buffers: enabledoop_rasterization: disabled_offprotected_video_decode: unavailable_offrasterization: enabledskia_deferred_display_list: disabled_offskia_renderer: disabled_offsurface_synchronization: enabled_onvideo_decode: enabledviz_display_compositor: disabled_offwebgl: enabledwebgl2: enabled

Load (avg)
4, 4, 4

Memory (System)
16.00GB (0.09GB free)

Process Argv
-psn_0_127007

Screen Reader
no

VM
0%

Item
Value

Remote
SSH: martim-dev

OS
Linux x64 4.15.0-1050-aws

CPUs
Intel(R) Xeon(R) CPU E5-2686 v4 @ 2.30GHz (2 x 2299)

Memory (System)
7.79GB (2.92GB free)

VM
0%

Item
Value

Remote
SSH: prod-data_source

OS
Linux x64 4.14.133-88.105.amzn1.x86_64

CPUs
Intel(R) Xeon(R) CPU E5-2676 v3 @ 2.40GHz (1 x 2400)

Memory (System)
0.96GB (0.20GB free)

VM
0%

Thanks for reporting the issue. Can you please share your logs in order to investigate the issue? You can access them via the Live Share: Export Logs command from the command palette (ctrl + shift + p) and attach them to this issue.

Thanks, logs added!

FYI, also experiencing this with Windows 10, so the problem isn't unique to Darwin.

@lostintangent FYI

We’ve made improvements in this area since this issue was filed. We believe this may have improved your experience and are closing this issue. If this issue still persists for you, please comment on the issue and let us know. Thank you.


Guild.members or Guild.fetchMembers() does not fetch all

I'm trying to fetch all members of a guild here to randomly select one. After thinking my randomizer was broke, I decided to just output all member objects from the collection and check if they all have a username. I found out only 11 members were being fetched and not all the members, regardless if they were online or not.
I'm going to try this with the Channel object instead and see how that goes.

TextChannel object of #general results in the same thing but doubles the list.

please come here for moar help thx

It expired...

Click here


userVariables are not available in global hooks

What is your Scenario?
I want to set project config which is unique in every test run, by creating new environment instance before tests run. It will contains for expample, base url to web page, api url e.t.c. I will use it in a lot of files, with tests, hooks e.t.c, so it should be available everywhere. In global hooks I want tu use this project config to send some requests to api.
What is the Current behavior?
userVariables are available every where apart from global hooks.
In global hooks it's returns null
What is the Expected behavior?
userVariables should be available in global hooks to set additional data in userVariables, which will be usefull in tests/local tests hooks
What is your TestCafe test code?
In runner.js I pass this config to userVariables by:
import createTestCafe from 'testcafe';
import { setConfig } from './setConfig.js';

(async () => {
    // create new environment instance
    const newConfig = { // In real life it's getting from api
        apiUrl: 'http://localhost:3000',
        baseUrl: 'http://localhost:3001',
        baseUrl2: 'http://localhost:3002',
    };

    const options = {
        hostname: 'localhost',
        port1:    1337,
        port2:    1338,
        userVariables: { newConfig }
    };

    const testcafe = await createTestCafe(options);
    const runner = testcafe.createRunner()
    const failedTests = await runner
        .src('./tests/test.js')
        .browsers('chrome')
        .run({
            disableNativeAutomation: true,
            hooks: {
                testRun: {
                    before: () => {
                        setConfig(newConfig)
                    }
                },
            }
        });

    console.log(failedTests);

    await testcafe.close();
})();

setConfig.js
import testcafe from 'testcafe';
const { userVariables } = testcafe;

export const setConfig = () => {
    //send some request to userVariables.apiUrl
    userVariables.additionalData = 'test' //data from request
}

Steps to Reproduce

Create testcafe runner createTestCafe
Pass userVariables there
Set new data in userVariables by global hooks

TestCafe version
3.6.0
Node.js version
18.17.0
Command-line arguments
node runner.js
Other
Found this bug by trying to resolve this problem: https://stackoverflow.com/questions/78476786/dynamic-data-are-not-available-in-test-files-testcafe-3-6-0

Hello @JakubMaz,
The issue is that userVariables in your case is part of the TestCafe object you created. Therefore, when you import it in setConfig.js, you cannot access it. You can create a closure for userVariables in your setConfig function to be able to modify it in global hooks.
setConfig.js

export const setConfig = (userVariables) => {
    return (config) => {
        userVariables.config = config;
    }
}

runner.js
import createTestCafe from 'testcafe';
import { setConfig } from './setConfig.js';

(async () => {
    // create new environment instance
    const newConfig = { // In real life it's getting from api
        apiUrl: 'http://localhost:3000',
        baseUrl: 'http://localhost:3001',
        baseUrl2: 'http://localhost:3002',
    };

    const options = {
        hostname: 'localhost',
        port1:    1337,
        port2:    1338,
        userVariables: { newConfig }
    };

    const testcafe = await createTestCafe(options);

   const setNewConfig = setConfig(testcafe.configuration._options.userVariables.value);

    const runner = testcafe.createRunner()
    const failedTests = await runner
        .src('./tests/test.js')
        .browsers('chrome')
        .run({
            disableNativeAutomation: true,
            hooks: {
                testRun: {
                    before: () => {
                        setNewConfig(newConfig)
                    }
                },
            }
        });

    console.log(failedTests);

    await testcafe.close();
})();

However, testcafe.configuration._options.userVariables.value is not part of the public API and can be changed at any time. Please use it with caution.
Please let us know your results.

We have other priorities at the moment, and this usage scenario is not popular enough among our users. Thus, we can't rise its priority. If there is more demand for this feature in the future, we will reconsider this task.
Thank you for your understanding.


Specific commands to rustfmt leave it and the terminal unresponsive

Describe the bug
The caret jumps into next empty line but nothing is printed. It still blinks. I can even scroll and type. But when typing again no commands of any kind are accepted even those that are known to work. No errors/warnings/infos are printed. All it does when I hit enter is that the caret jumps into beginning of the next empty line.
The Windows task manager doesn't say that rustfmt.exe isn't responding anymore or crashed. Just waiting doesn't seem to yield any new printed information either.
These two commands, rustfmt --version and rustfmt SomeInvalidOptionHere responded normally.
To Reproduce
Use PowerShell, or Windows Terminal(MS Store) or CLion, or VSCode, or any terminal should have the same problem when typing these commands:
rustfmt
rustfmt -v
rustfmt --v
Expected behavior
I figure command rustfmt should print usage information like cargo or rustup for that matter does.
The rustfmt -v and rustfmt --v should print the version of rustfmt just like rustfmt --version does.
Meta

rustfmt version: rustfmt 1.4.15-stable (530eadf4 2020-06-02)
From where did you install rustfmt?: rustup, rustup update
How do you run rustfmt: PowerShell, Windows Terminal(MS Store), CLion, VSCode on Windows 10 Home 64bit

Thanks for following up!
If you run rustfmt --help you'll see the supported flags. For printing the version of rustfmt, that's -V (note upper case) or --version. --v is not a supported flag, and -v is the shorthand flag for the verbose option. I thought you'd mentioned on the other thread that -V wasn't displaying information which would be a different story.
The issue is that a required argument to rustfmt is the inputs of the things to actually format (either files or stdin), and in the cases you've mentioned you haven't provided any input and you haven't issued a special command.

I can confirm that rustfmt --help works.
Regarding the expected behaviors:
With the lower case -v, I would expect it to print back that I placed it in an invalid spot message.
With the upper case --v, I would expect it to print an invalid shorthand message like with rustfmt SomeInvalidOptionHere.
If my statements are correct regarding the expected behaviors I mentioned. I will then edit the OP.

I thought you'd mentioned on the other thread that -V wasn't displaying information which would be a different story.

That's my bad again. Long story short, I bluntly assumed that it's all lower case always. But then failed to stick to my own wrong assumption subconsciously.
For what it's worth, my 2 cents. I always would stick to lower case to avoid confusion. Letters like 'V' and 'v' are so similar when their cases unlike 'R' and 'r', etc. Also you will have to remember in addition to what a shorthand does and its name, also its case.

With the lower case -v, I would expect it to print back that I placed it in an invalid spot message.

The flag isn't in an invalid spot, it's just the case that when a list of files isn't passed to rustfmt, it assumes that the code to format will come from stdin. As calebcartwright said, this is why your terminal emulator appears to hang after calling rustfmt without files; it is waiting for a flush of the stdin buffer.
You can see all the options with rustfmt --help. Though, the help menu could be clearer that without file args, rustfmt runs on stdin.

@NickelCoating

For what it's worth, my 2 cents. I always would stick to lower case to avoid confusion. Letters like 'V' and 'v' are so similar when their cases unlike 'R' and 'r', etc. Also you will have to remember in addition to what a shorthand does and its name, also its case.

Please note that rustfmt has to support both --version and --verbose, both of which obviously start with the same batch of letters, and accordingly both can't have a shorthand of -v :wink:
Using -V as the shorthand flag for --version is pretty canonical (try running rustc -V and rustc -v for example, and I don't see us changing this.

Regarding the expected behaviors:
With the lower case -v, I would expect it to print back that I placed it in an invalid spot message.
With the upper case --v, I would expect it to print an invalid shorthand message like with rustfmt SomeInvalidOptionHere.

As @ayazhafiz noted, the experience you are seeing in your terminal doesn't have anything to do with an "invalid spot", you just haven't provided any input to rustfmt, so you need to do so and send an EOF (which I believe even with a Powershell terminal will still be CTRL+D)
For example:
# enter `rustfmt -v` to run rustfmt with verbose mode enabled and provide rust code via stdin
$ rustfmt -v
# rustfmt will now be sitting waiting for you to provide stdin

next type some Rust code
$ rustfmt -v
fn bar (   )  {
println!("foo")   ; }

fn main( ) {
 bar();

}

Then send an EOF (CTRL+D), and you'll see the formatted version of your input printed by rustfmt
$ rustfmt -v
fn bar (   )  {
println!("foo")   ; }

fn main( ) {
 bar();

}
fn bar() {
    println!("foo");
}

fn main() {
    bar();
}
$

With the upper case --v, I would expect it to print an invalid shorthand message like with rustfmt SomeInvalidOptionHere.

rustfmt will tell you when it gets an invalid option, but --v is equivalent to -v (I forgot the CLI parser was smart enough to drop the extra - instead of yelling at you)
$ rustfmt src/main.rs --fakeness --check
Unrecognized option: 'fakeness'

But -v and --v will both get you verbose mode:
$ rustfmt src/main.rs -v --check
Using rustfmt config file /home/caleb/dev/rustfmt-sandbox/nickelcoating/.rustfmt.toml for /home/caleb/dev/rustfmt-sandbox/nickelcoating/src/main.rs
Formatting /home/caleb/dev/rustfmt-sandbox/nickelcoating/src/main.rs
Spent 0.000 secs in the parsing phase, and 0.000 secs in the formatting phase

$ rustfmt src/main.rs --v --check
Using rustfmt config file /home/caleb/dev/rustfmt-sandbox/nickelcoating/.rustfmt.toml for /home/caleb/dev/rustfmt-sandbox/nickelcoating/src/main.rs
Formatting /home/caleb/dev/rustfmt-sandbox/nickelcoating/src/main.rs
Spent 0.000 secs in the parsing phase, and 0.000 secs in the formatting phase

Well, with all that said though. That would mean because of the ability to take source directly via stdin, that it's not even possible to just print help content by just typing rustfmt, just like with cargo or rustup!?
So, everything is by design, and there is no bug here at all in this issue. There is no freezing just this shadowy thing that asks me to write code without telling me what it wants from me really.
Maybe for the next noob like myself who may run into this, there could be a bit more clarity?
How about instead of [options] <file> , it read [options] <filename.rs/stdin source>. I so wasn't expecting to actually be able to type in actual code via terminal in that moment.
And for those like me who think they can just type rustfmt like cargo and rustup for help content. It would be good if it just said that it wants actual code from me by actually saying it like "Type source code below:" if possible.
... my 2 cents. And the OP needs changing now it seems. :)

rustfmt, just like with cargo or rustup!?

I don't think those are valid comparison points. rustfmt explicitly has to support formatting from stdin, neither cargo nor rustup have such features or requirements. If they did (even though it makes no sense), the behavior would be the same.

that it wants actual code from me by actually saying it like "Type source code below:" if possible.

we don't know what's in stdin til we look at it :wink:  and we wouldn't want to spam users with spurious messages either. For example:
$ echo "fn main (   )  {          }" | rustfmt

unequivocally should not have a "type source code below" text in stdout.

How about instead of [options]  , it read [options] <filename.rs/stdin source>

@ayazhafiz mentioned this earlier as well, and I agree tweaking the help text would be beneficial. However, we also need folks to do take a look at documentation when they start working with a new tool as well instead of making assumptions about how it does/should work.
https://github.com/rust-lang/rustfmt#running
(emphasis mine)

You can run Rustfmt by just typing rustfmt filename if you used cargo install. This runs rustfmt on the given file, if the file includes out of line modules, then we reformat those too. So to run on a whole module or crate, you just need to run on the root file (usually mod.rs or lib.rs). Rustfmt can also read data from stdin.

I feel like the origin for this thread was that our issue template asked you to run rustfmt -V to  get and provide the version, but you were trying to use rustfmt -v instead :smile:

How about instead of [options] , it read [options] <filename.rs/stdin source>

@ayazhafiz mentioned this earlier as well, and I agree tweaking the help text would be beneficial. However, we also need folks to take a look at documentation when they start working with a new tool as well, instead of making assumptions about how it does/should work.

You are of course right. But regarding help it seems it only reads in the docs:

You can run rustfmt --help for information about available arguments.

and

rustfmt can also read data from stdin.

It never says that rustfmt alone doesn't work like with the others. And the others are learned first. So, you get used to that, it's shorter. Yeah, it says that stdin is also possible. But it doesn't say when or how. To make things worse <file> is just well, the file name or path maybe. While <filename.rs/stdin source> is damn direct about when and how and what.

I feel like the origin for this thread was that our issue template asked you to run rustfmt -V to get and provide the version, but you were trying to use rustfmt -v instead

I'm afraid that you are still correct and I noticed already myself. I already made the rule for myself to read stuff twice even if I have the feeling that I got it.  Sorry for that. I still hope that I wasn't a complete waste of time.
Regarding the cases, if I had a choice, I still would go for -vs for version. And -vb for verbose. Instead of the cases upper and lower.

It never says that rustfmt alone doesn't work like with the others

None of the other tools have to accept a random string of rust code from stdin and emit the formatted result to stdout either though.
We strive to keep as similar an experience as possible across the tools, but ultimately rustfmt is a formatting tool with different usage patterns than other tools and vice versa; stdin is just one of those differences.
I mentioned earlier that I'm more than receptive to tweaking documentation in anyway that helps, but I just don't think we should be in the business of trying to document what a tool doesn't do nor enumerating incorrect assumptions.
At the end of the day, if you happen to be running rustfmt directly instead of cargo fmt, then you've got to explicitly let rustfmt know what the thing is that you want it to format.

Regarding the cases, if I had a choice, I still would go for -vs for version. And -vb for verbose. Instead of the cases upper and lower.

I appreciate you sharing your perspective, but as I mentioned before we're not going to change this. Worth noting that if we did it would actually make rustfmt different from other rust tooling rustc, cargo, rls, clippy, rustup, etc. for the common capability of printing the version of the tool:
$ rustc -V
rustc 1.45.0 (5c1f21c3b 2020-07-13)
$ cargo -V
cargo 1.45.0 (744bd1fbb 2020-06-15)
$ rls -V
rls 1.41.0 (085f24b 2020-05-28)
$ rustup -V
rustup 1.22.1 (b01adbbc3 2020-07-08)
$ rustfmt -V
rustfmt 1.4.15-stable (530eadf 2020-06-02)

I already made the rule for myself to read stuff twice even if I have the feeling that I got it.  Sorry for that. I still hope that I wasn't a complete waste of time.

No worries, we've all done it before :laughing:

I've opened #4336 to track improving the docs/help text output to better stdin in a separate/dedicated thread.
I believe the original item behind this issue has been addressed and that there's no other actionable items from this thread, but will leave the issue open for another day or so in case you have any other thoughts or questions.

A note could look like this: #4337


Add Electron 1_1 boards

This board was created by Justin.
I don't know if these PR is revelant, if not discard it.

Thanks for the contribution!


chatbots use case - fix broken collab URL

The current Collab URL returns a 404, since there is no chatbots directory under use_cases.

thanks @thatfiredev!


Fix issue #109

Per the changes in the README, this adds a specific method call, withVersion12Support() to the TerraformValidateStage class.  Internally, the TerraformValidateCommand.instance() now returns a command with no arguments while TerraformValidateCommand.instanceWithCheckVars() holds the previous behavior.
Furthermore, the TerraformInitCommand now has a default constructor that assigns an empty string to the environment.  However, it is private and can (should) only be created through TerraformInitCommand.initWithoutBackend(), which will always set the -backend=false argument and ignore any -backend-config= arguments. The empty string is used because some plugins (S3BackendPlugin for example) assume that the environment is not null.  Who knows what external plugins assume that also.
The -backend=false option is supported on the terraform init command as far back as 0.9.0.  This holds with the current implied supported versions, since 0.8.x requires a SOURCE argument and does not support executing terraform init [-dash-args] ...] in a directly.
TL;DR: All changes are supported from 0.9.0 and up, which is already what we supported.  To enable >=0.12.0 support properly you need to set a flag on the Validate stage.

Can you pull against v5.3-dev branch?

Done.

Note that this does nothing to address hashicorp/terraform#21408.  While they have accepted it as a bug, I don't see much progress on it.  The workarounds are to either set the region in the aws provider to a terraform variable or set the AWS_DEFAULT_REGION environment variable to a placeholder value when running validate.

Can you help me understand the -backend=false piece? I’m not entirely caught up on 0.12 changes.

My understanding is that you only need -backend=false to disable a previously initialized backend https://www.terraform.io/docs/commands/init.html#backend-initialization.  By default,  TerraformEnvironmentStage will not initialize a backend (assuming you haven’t enabled a plugin that will add a backendConfig. As such, backend=false shouldn’t be necessary - but as it’s written, it will  always be  added unless a backConfig is added. That doesn’t seem like a necessity.  If what I’ve said is correct, I think I’d prefer to change initWithoutBackend to  instead be withoutBackend, which could then simply append backend=false to backendConfigs.  <— this allows you to explicitly undo a previously initialized backend, if that’s what you explicitly  want to do,  but  if NOT, then the previous behavior remains (meaning, if no backends were configured, then backend=false will not be set).

Can we be more clever with how we handle versions?  withVersion12Support sets an unpleasant precedence - what  happens if version 0.13 creates breaking changes?  Do we add a  withVersion13Support?  Ack.  What this issue reveals is a poor choice on my part - https://github.com/manheim/terraform-pipeline/blob/0233f1e41ab83d442e7f8736b41621b19ca81750/src/TerraformValidateCommand.groovy#L62.  I should never have REQUIRED that -check-variables=false be part of the TerraformValidateCommand. <-- During  the initial development of this library, I made several of these poor choices.  What I did later, was to break this behavior out into "default plugins", and then later expand on the plugin's behavior.

If I were to try to take that approach for this issue, I think maybe we need a TerraformPlugin.  Maybe if such a Plugin existed, it could have  a withVersion() method, we could then isolate all the version-specific behavior in one place.

TerraformPlugin.init() - would implement the existing behavior across the appropriate plugins (using pre-0.12 flags like -check-variables)
TerraformPlugin.withVersion('0.12').init() - would NOT  add check-variables
TerraformPlugin.withVersion('FutureBreakingVersion').init() - would do other things that specific to that future breaking version.

^-- We could even be clever, and take the solution above, and skip and explicit call  to withVersion.  What if we checked for the presence of a .terraform-version file?  If such a file existed, we could automatically call withVersion with the appropriate value.  Then terraform-pipeline would auto-configure for the appropriate version without the user needing to do anything at all.

I just want to say for the record I rebased on the updated v5.3-dev branch and it still gave me those merge conflicts. -_-
Anyway, rewritten as a plugin.  Squashed.  Successful run using the code here:
https://account-management-bento.awsmancsnp.manheim.com/blue/organizations/jenkins/PingFederate%2Fmanheim-pingfederate-docker/detail/master/62/pipeline
The failure is because there we haven't added the e2e.tfvars file and is unrelated to the terraform 0.12 support.

Merging PR.  The Issue #109 was updated with information about more work to be done before publishing an official release.

Continued in https://github.com/manheim/terraform-pipeline/pull/177


[ignition-fuel-tools4] Add new port 🤖

What does your PR fix?

This PR adds a new port for the new major  version of the ignition-fuel-tools library.

Which triplets are supported/not supported?

All tested triplet (for which the dependency are actually available) should be supported.

Does your PR follow the maintainer guide?

I hope.

As discussed in https://github.com/microsoft/vcpkg/pull/7781, different major version of ignition robotics libraries (https://ignitionrobotics.org/) can be installed side by side, so each new major version is added as a new port.
In particular, ignition-fuel-tools4 is a dependency for Gazebo 11 (http://gazebosim.org/blog/gazebo11) and for Ignition Robotics Citadel (that contains Ignition Gazebo 3, see https://www.openrobotics.org/blog/2019/12/11/ignition-citadel-released).

The hash value seems incorrect:
File does not have expected hash:
          File path: [ D:/downloads/temp/ignitionrobotics-ign-fuel-tools-ignition-fuel-tools4_4.3.0.tar.gz ]
      Expected hash: [ a656fed74fb2138b3bcf7d35b25ad06da95cfb9a3ad7ded2c9c54db385f55ea310fd1a72dcf6400b0a6199e376c1ba2d11ee2a08c66e3c2cc8b2ee1b25406986 ]
        Actual hash: [ 451d7bcd195a8ce41c3a7d64ad936c8c0812cbc7af03dbe75cbdc359599bf1f828595833c1758d4de8e37c37730bb852de95b2256ff9134af4ab197df2b66a8b ]

The hash value seems incorrect:
File does not have expected hash:
          File path: [ D:/downloads/temp/ignitionrobotics-ign-fuel-tools-ignition-fuel-tools4_4.3.0.tar.gz ]
      Expected hash: [ a656fed74fb2138b3bcf7d35b25ad06da95cfb9a3ad7ded2c9c54db385f55ea310fd1a72dcf6400b0a6199e376c1ba2d11ee2a08c66e3c2cc8b2ee1b25406986 ]
        Actual hash: [ 451d7bcd195a8ce41c3a7d64ad936c8c0812cbc7af03dbe75cbdc359599bf1f828595833c1758d4de8e37c37730bb852de95b2256ff9134af4ab197df2b66a8b ]

The hash value seems incorrect:
File does not have expected hash:
          File path: [ D:/downloads/temp/ignitionrobotics-ign-fuel-tools-ignition-fuel-tools4_4.3.0.tar.gz ]
      Expected hash: [ a656fed74fb2138b3bcf7d35b25ad06da95cfb9a3ad7ded2c9c54db385f55ea310fd1a72dcf6400b0a6199e376c1ba2d11ee2a08c66e3c2cc8b2ee1b25406986 ]
        Actual hash: [ 451d7bcd195a8ce41c3a7d64ad936c8c0812cbc7af03dbe75cbdc359599bf1f828595833c1758d4de8e37c37730bb852de95b2256ff9134af4ab197df2b66a8b ]

My bad, I fixed it now in https://github.com/microsoft/vcpkg/pull/15581/commits/4d9f918ce58d776ca70b57be5056fa964610f5a1 . However, I marked it as WIP as I did not tested it on all the platforms supported by CI.

The hash value seems incorrect:
File does not have expected hash:
          File path: [ D:/downloads/temp/ignitionrobotics-ign-fuel-tools-ignition-fuel-tools4_4.3.0.tar.gz ]
      Expected hash: [ a656fed74fb2138b3bcf7d35b25ad06da95cfb9a3ad7ded2c9c54db385f55ea310fd1a72dcf6400b0a6199e376c1ba2d11ee2a08c66e3c2cc8b2ee1b25406986 ]
        Actual hash: [ 451d7bcd195a8ce41c3a7d64ad936c8c0812cbc7af03dbe75cbdc359599bf1f828595833c1758d4de8e37c37730bb852de95b2256ff9134af4ab197df2b66a8b ]

My bad, I fixed it now in https://github.com/microsoft/vcpkg/pull/15581/commits/4d9f918ce58d776ca70b57be5056fa964610f5a1 . However, I marked it as WIP as I did not tested it on all the platforms supported by CI.

Linux build is broken by the libzip pkg-config files, that will be fixed by https://github.com/microsoft/vcpkg/pull/15589/files . I had already added the same changes here, so if the CI works we can wait for https://github.com/microsoft/vcpkg/pull/15589/files to be merged and we can rebase.

Linux build is broken by the libzip pkg-config files, that will be fixed by https://github.com/microsoft/vcpkg/pull/15589/files . I had already added the same changes here, so if the CI works we can wait for https://github.com/microsoft/vcpkg/pull/15589/files to be merged and we can rebase.

@traversaro
PR #15589 has been merged to master now.  You might need to revert the changes about libzip  in this PR.

@traversaro
PR #15589 has been merged to master now.  You might need to revert the changes about libzip  in this PR.

Thanks @NancyLi1013 !

Thanks @NancyLi1013 !


Feature/helm operator naming

operator helm chart changes:

remove extraResources
rename domainsNamespaces to domainNamespaces
rename operatorImage, to image
rename operatorImagePullPolicy to imagePullPolicy
rename operatorImagePullSecrets to imagePullSecrets
rename operatorServiceAccount to serviceAccount
improve the utilities for validating customer supplied value overrides

PLEASE WAIT ON REVIEWING THIS - I STILL NEED TO RENAME THE OPERATORIMAGEXYZ PROPERTIES

Hi Tom, my PR got merged this morning https://github.com/oracle/weblogic-kubernetes-operator/pull/413, you may have to sync with develop branch before merging this PR.

Hi Vanaja,
Thanks for the heads up.  I already caught up with develop a few minutes ago, so should have your changes.
I've fired off the jenkins java integration tests - fingers crossed.
-Tom

On Sep 18, 2018, at 12:47 PM, Vanajakshi Mukkara<EMAIL_ADDRESS>wrote:
Hi Tom, my PR got merged this morning #413 https://github.com/oracle/weblogic-kubernetes-operator/pull/413, you may have to sync with develop branch before merging this PR.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/oracle/weblogic-kubernetes-operator/pull/417#issuecomment-422466237, or mute the thread https://github.com/notifications/unsubscribe-auth/AgjgeH8u2u8yRPA-JzK_IZ0eJLuXAO0Cks5ucSOYgaJpZM4Wt5yO.

Reviewed changes in the java integration tests, looks good.


Date in the SRPM logs page

Suggested by @SpyTec here:

On a sidenote, can we get datetime printed on the SRPM builds and not just time? I can't tell if these logs are old or not without looking at the commits

We can add a new entry before logs or edit the formatting of the logs.

Defintely a good suggestion. Though we are using a human-friendly time descrption, e.g.:
Copr build > Build for fedora-rawhide-x86_64 started an hour ago, status: success

Should we add 2 more lines with absolute values for "build submitted" and "build finished"?

Defintely a good suggestion. Though we are using a human-friendly time descrption, e.g.:
Copr build > Build for fedora-rawhide-x86_64 started an hour ago, status: success

Should we add 2 more lines with absolute values for "build submitted" and "build finished"?

If I understand the original proposal correctly, then a datetime should be added to the SRPM logs page, not the results page.
As the former can be shared without the later, and as there is currently no way to get back to the results page from an SRPM logs page, I think the request makes sense :slightly_smiling_face:
Should the title of this issue be updated to reflect the actual request?

If I understand the original proposal correctly, then a datetime should be added to the SRPM logs page, not the results page.
As the former can be shared without the later, and as there is currently no way to get back to the results page from an SRPM logs page, I think the request makes sense :slightly_smiling_face:
Should the title of this issue be updated to reflect the actual request?

If I understand the original proposal correctly, then a datetime should be added to the SRPM logs page, not the results page.

By result page, I mean any page we link, but yes we can change the title to be more precise.
And it looks like we need need to add a nicely formatted datetime before the logs or improved the log format.

If I understand the original proposal correctly, then a datetime should be added to the SRPM logs page, not the results page.

By result page, I mean any page we link, but yes we can change the title to be more precise.
And it looks like we need need to add a nicely formatted datetime before the logs or improved the log format.

The task of this is to:

Add human-friendly date and time of the build before logs.
Or, tweak the log formatter to provide the nicer date-time format.

The format should fulfil:

Contains date and time.
Is in UTC and/or the zone is clear.

This has been fixed by the move to the dashboard status pages (currently on stage, will be on prod on Monday).
Example:

https://dashboard.stg.packit.dev/results/srpm-builds/4305


SyntaxError: Unexpected end of JSON input

Hi,
I've started getting this error and could use some clues. It's probably related to my project but why would standardjs fail like this:
><EMAIL_ADDRESS>standard /Users/marcobarbosa/Repos/<repo>
> standard 'src/**/*.js'

standard: Unexpected linter output:

SyntaxError: Unexpected end of JSON input
    at Object.parse (native)
    at Object.parseRecursion [as parse] (/Users/marcobarbosa/Repos/<repo>/node_modules/circular-json/build/circular-json.node.js:182:15)
    at readJSON (/Users/marcobarbosa/Repos/<repo>/node_modules/flat-cache/utils.js:15:25)
    at Object.load (/Users/marcobarbosa/Repos/<repo>/node_modules/flat-cache/cache.js:25:23)
    at Object.create (/Users/marcobarbosa/Repos/<repo>/node_modules/flat-cache/cache.js:158:9)
    at Object.load (/Users/marcobarbosa/Repos/<repo>/node_modules/flat-cache/cache.js:144:17)
    at Object.create (/Users/marcobarbosa/Repos/<repo>/node_modules/file-entry-cache/cache.js:13:27)
    at new CLIEngine (/Users/marcobarbosa/Repos/<repo>/node_modules/eslint/lib/cli-engine.js:463:38)
    at /Users/marcobarbosa/Repos/<repo>/node_modules/standard-engine/index.js:107:16
    at /Users/marcobarbosa/Repos/<repo>/node_modules/deglob/index.js:51:12

JSON input? Is it trying to read JSON files?
Using Node v6.92 and standard 8.6.0.
I also get this by running standard directly in the terminal (after installing it globally).
Do you have any ideas?

Maybe your package.json is invalid?

@LinusU Thanks for the tip! I just double checked and it's valid JSON.
Also, here's a npm-debug.log running on node v6.1.0. There are no prestandard or poststandard tasks.
0 info it worked if it ends with ok
1 verbose cli [ '/Users/marcobarbosa/.nvm/versions/node/v6.1.0/bin/node',
1 verbose cli   '/Users/marcobarbosa/.nvm/versions/node/v6.1.0/bin/npm',
1 verbose cli   'run',
1 verbose cli   'standard' ]
2 info using<EMAIL_ADDRESS>3 info using<EMAIL_ADDRESS>4 verbose run-script [ 'prestandard', 'standard', 'poststandard' ]
5 info lifecycle<EMAIL_ADDRESS><EMAIL_ADDRESS>6 silly lifecycle<EMAIL_ADDRESS>no script for prestandard, continuing
7 info lifecycle<EMAIL_ADDRESS><EMAIL_ADDRESS>8 verbose lifecycle<EMAIL_ADDRESS>unsafe-perm in lifecycle true
9 verbose lifecycle<EMAIL_ADDRESS>PATH: /Users/marcobarbosa/.nvm/versions/node/v6.1.0/lib/node_modules/npm/bin/node-gyp-bin:/Users/marcobarbosa/Repos/<repo>d/node_modules/.bin:/Users/marcobarbosa/.nvm/versions/node/v6.1.0/bin:/Users/marcobarbosa/.rvm/gems/ruby-2.3.0/bin:/Users/marcobarbosa/.rvm/gems/ruby-2.3.0@global/bin:/Users/marcobarbosa/.rvm/rubies/ruby-2.3.0/bin:/Users/marcobarbosa/google-cloud-sdk/bin:/opt/local/bin:/opt/local/sbin:/Applications/MAMP/bin/php/php5.6.7/bin/php:/Users/marcobarbosa/.nvm/versions/node/v6.1.0/bin:/Users/marcobarbosa/bin:/usr/local/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/MacGPG2/bin:/Users/marcobarbosa/.rvm/bin
10 verbose lifecycle<EMAIL_ADDRESS>CWD: /Users/marcobarbosa/Repos/<repo>d
11 silly lifecycle<EMAIL_ADDRESS>Args: [ '-c', 'standard \'src/**/*.js\'' ]
12 silly lifecycle<EMAIL_ADDRESS>Returned: code: 1  signal: null
13 info lifecycle<EMAIL_ADDRESS>Failed to exec standard script
14 verbose stack Error<EMAIL_ADDRESS>standard: `standard 'src/**/*.js'`
14 verbose stack Exit status 1
14 verbose stack     at EventEmitter.<anonymous> (/Users/marcobarbosa/.nvm/versions/node/v6.1.0/lib/node_modules/npm/lib/utils/lifecycle.js:239:16)
14 verbose stack     at emitTwo (events.js:106:13)
14 verbose stack     at EventEmitter.emit (events.js:191:7)
14 verbose stack     at ChildProcess.<anonymous> (/Users/marcobarbosa/.nvm/versions/node/v6.1.0/lib/node_modules/npm/lib/utils/spawn.js:24:14)
14 verbose stack     at emitTwo (events.js:106:13)
14 verbose stack     at ChildProcess.emit (events.js:191:7)
14 verbose stack     at maybeClose (internal/child_process.js:850:16)
14 verbose stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:215:5)
15 verbose pkgid<EMAIL_ADDRESS>16 verbose cwd /Users/marcobarbosa/Repos/<repo>d
17 error Darwin 16.1.0
18 error argv "/Users/marcobarbosa/.nvm/versions/node/v6.1.0/bin/node" "/Users/marcobarbosa/.nvm/versions/node/v6.1.0/bin/npm" "run" "standard"
19 error node v6.1.0
20 error npm  v3.8.6
21 error code ELIFECYCLE
22 error<EMAIL_ADDRESS>standard: `standard 'src/**/*.js'`
22 error Exit status 1
23 error Failed at the<EMAIL_ADDRESS>standard script 'standard 'src/**/*.js''.
23 error Make sure you have the latest version of node.js and npm installed.
23 error If you do, this is most likely a problem with the <repo>d package,
23 error not with npm itself.
23 error Tell the author that this fails on your system:
23 error     standard 'src/**/*.js'
23 error You can get information on how to open an issue for this project with:
23 error     npm bugs <repo>d
23 error Or if that isn't available, you can get their info via:
23 error     npm owner ls <repo>d
23 error There is likely additional logging output above.
24 verbose exit [ 1, true ]

Note it mentions EventEmitter, is that related to my code or to some lib standard uses?
standard task in my package.json:
"standard": "standard 'src/**/*.js'",

Also tried ignoring JSON:
"standard": {
    "ignore": [
      "src/**/*.json"
    ]
  }

This issue is caused by an invalid cache file, which can happen if standard crashes or if you kill standard with Ctrl-C while it is running.
This was a bug in a dependency of standard, which is now fixed. See for more information: https://github.com/eslint/eslint/issues/7748

Thanks @feross !

i saw this issue is over here, but i am suffering about this issue as 'syntaxerror: unexpected end of json input' when i am trying to edit order. I had trying to realized the previous solutions. but i am not clear. anyone can explain easily to solve the issue. Opencart version is <IP_ADDRESS>

@smnayeem Sorry, you're posting on a completely different issue tracker that has nothing to do with OpenCart. Good luck figuring out your issue, though!

'SyntaxError: Unexpected end of JSON input' the same issue


App model rework around resource types and connection string emission for containers

Fixes:
https://github.com/dotnet/aspire/issues/1164
https://github.com/dotnet/aspire/issues/1088
This PR is a fairly major change to all the resource types built into Aspire.Hosting to support a model where calls like AddRedisContainer actually outputs a container resource to the manifest (container.v0) with enough configuration such that it can run within a given orchestrator.
It introduces three new key concepts:

Container resources can now explicitly declare a connectionString field in the manifest. When a resource connection string is referenced this field can be used.
Because the content of connectionString cannot be determined at manifest publishing time it now contains placeholder values that the deployment tool is expected to process and replace as appropriate.
There is a new per resource field inputs (optional) which tells the deployment tool when it should prompt the user (or generate) inputs such as a password.

The following JSON manifest is produces from tests/testproject/TestProject.AppHost and contains the built-in resource types that employ this model.
Note that as part of this change, we have removed AddXYZConnection(...) methods and associated resource types as we found they added minimal value beyond just adding an environment variable. Also note that we've added a non-container version of most of the resource types (e.g. AddRedis(...) vs. AddRedisContainer(...)). Locally these methods do much the same thing, but when the manifest is produced the first option does not produce a container.v0 resource, it produces redis.v0 like it previously did.
Ideally folks will use these more abstract builder methods (e.g. AddRedis(...)) instead of the container orientated counterpart. Deployment tools that target cloud environments should preference the use of managed services with better operational support, particularly in production deployment scenarios.
Deployment tools may wish to warn users that they are using container builder methods vs. abstract resource type builder methods when deploying to production, although the containerized versions should still continue to work.
{
  "resources": {
    "servicea": {
      "type": "project.v0",
      "path": "../TestProject.ServiceA/TestProject.ServiceA.csproj",
      "env": {
        "OTEL_DOTNET_EXPERIMENTAL_OTLP_EMIT_EXCEPTION_LOG_ATTRIBUTES": "true",
        "OTEL_DOTNET_EXPERIMENTAL_OTLP_EMIT_EVENT_LOG_ATTRIBUTES": "true"
      },
      "bindings": {
        "http": {
          "scheme": "http",
          "protocol": "tcp",
          "transport": "http"
        },
        "https": {
          "scheme": "https",
          "protocol": "tcp",
          "transport": "http"
        }
      }
    },
    "serviceb": {
      "type": "project.v0",
      "path": "../TestProject.ServiceB/TestProject.ServiceB.csproj",
      "env": {
        "OTEL_DOTNET_EXPERIMENTAL_OTLP_EMIT_EXCEPTION_LOG_ATTRIBUTES": "true",
        "OTEL_DOTNET_EXPERIMENTAL_OTLP_EMIT_EVENT_LOG_ATTRIBUTES": "true"
      },
      "bindings": {
        "http": {
          "scheme": "http",
          "protocol": "tcp",
          "transport": "http"
        },
        "https": {
          "scheme": "https",
          "protocol": "tcp",
          "transport": "http"
        }
      }
    },
    "servicec": {
      "type": "project.v0",
      "path": "../TestProject.ServiceC/TestProject.ServiceC.csproj",
      "env": {
        "OTEL_DOTNET_EXPERIMENTAL_OTLP_EMIT_EXCEPTION_LOG_ATTRIBUTES": "true",
        "OTEL_DOTNET_EXPERIMENTAL_OTLP_EMIT_EVENT_LOG_ATTRIBUTES": "true"
      },
      "bindings": {
        "http": {
          "scheme": "http",
          "protocol": "tcp",
          "transport": "http"
        },
        "https": {
          "scheme": "https",
          "protocol": "tcp",
          "transport": "http"
        }
      }
    },
    "workera": {
      "type": "project.v0",
      "path": "../TestProject.WorkerA/TestProject.WorkerA.csproj",
      "env": {
        "OTEL_DOTNET_EXPERIMENTAL_OTLP_EMIT_EXCEPTION_LOG_ATTRIBUTES": "true",
        "OTEL_DOTNET_EXPERIMENTAL_OTLP_EMIT_EVENT_LOG_ATTRIBUTES": "true"
      }
    },
    "nodeapp": {
      "type": "executable.v0",
      "workingDirectory": "../nodeapp",
      "command": "node",
      "args": [
        "C:\\Code\\dotnet\\aspire\\tests\\testproject\\TestProject.AppHost\\..\\nodeapp\\app.js"
      ],
      "env": {
        "NODE_ENV": "production",
        "PORT": "{nodeapp.bindings.http.port}"
      },
      "bindings": {
        "http": {
          "scheme": "http",
          "protocol": "tcp",
          "transport": "http"
        }
      }
    },
    "npmapp": {
      "type": "executable.v0",
      "workingDirectory": "../nodeapp",
      "command": "npm",
      "args": [
        "run",
        "start"
      ],
      "env": {
        "NODE_ENV": "production",
        "PORT": "{npmapp.bindings.http.port}"
      },
      "bindings": {
        "http": {
          "scheme": "http",
          "protocol": "tcp",
          "transport": "http"
        }
      }
    },
    "sqlservercontainer": {
      "type": "container.v0",
      "image": "mcr.microsoft.com/mssql/server:2022-latest",
      "env": {
        "ACCEPT_EULA": "Y",
        "MSSQL_SA_PASSWORD": "{sqlservercontainer.inputs.password}"
      },
      "bindings": {
        "tcp": {
          "scheme": "tcp",
          "protocol": "tcp",
          "transport": "tcp",
          "containerPort": 1433
        }
      },
      "connectionString": "Server={sqlservercontainer.bindings.tcp.host},{sqlservercontainer.bindings.tcp.port};User ID=sa;Password={sqlservercontainer.inputs.password};TrustServerCertificate=true;",
      "inputs": {
        "password": {
          "type": "string",
          "secret": true,
          "default": {
            "generate": {
              "minLength": 10
            }
          }
        }
      }
    },
    "mysqlcontainer": {
      "type": "container.v0",
      "image": "mysql:latest",
      "env": {
        "MYSQL_ROOT_PASSWORD": "{mysqlcontainer.inputs.password}"
      },
      "bindings": {
        "tcp": {
          "scheme": "tcp",
          "protocol": "tcp",
          "transport": "tcp",
          "containerPort": 3306
        }
      },
      "connectionString": "Server={mysqlcontainer.bindings.tcp.host};Port={mysqlcontainer.bindings.tcp.port};User ID=root;Password={mysqlcontainer.inputs.password}",
      "inputs": {
        "password": {
          "type": "string",
          "secret": true,
          "default": {
            "generate": {
              "minLength": 10
            }
          }
        }
      }
    },
    "rediscontainer": {
      "type": "container.v0",
      "image": "redis:latest",
      "bindings": {
        "tcp": {
          "scheme": "tcp",
          "protocol": "tcp",
          "transport": "tcp",
          "containerPort": 6379
        }
      },
      "connectionString": "{rediscontainer.bindings.tcp.host}:{rediscontainer.bindings.tcp.port}"
    },
    "postgrescontainer": {
      "type": "container.v0",
      "image": "postgres:latest",
      "env": {
        "POSTGRES_HOST_AUTH_METHOD": "scram-sha-256",
        "POSTGRES_INITDB_ARGS": "--auth-host=scram-sha-256 --auth-local=scram-sha-256",
        "POSTGRES_PASSWORD": "{postgrescontainer.inputs.password}"
      },
      "bindings": {
        "tcp": {
          "scheme": "tcp",
          "protocol": "tcp",
          "transport": "tcp",
          "containerPort": 5432
        }
      },
      "connectionString": "Host={postgrescontainer.bindings.tcp.host};Port={postgrescontainer.bindings.tcp.port};Username=postgres;Password={postgrescontainer.inputs.password};",
      "inputs": {
        "password": {
          "type": "string",
          "secret": true,
          "default": {
            "generate": {
              "minLength": 10
            }
          }
        }
      }
    },
    "rabbitmqcontainer": {
      "type": "container.v0",
      "image": "rabbitmq:3-management",
      "env": {
        "RABBITMQ_DEFAULT_USER": "guest",
        "RABBITMQ_DEFAULT_PASS": "{rabbitmqcontainer.inputs.password}"
      },
      "bindings": {
        "tcp": {
          "scheme": "tcp",
          "protocol": "tcp",
          "transport": "tcp",
          "containerPort": 5672
        },
        "management": {
          "scheme": "http",
          "protocol": "tcp",
          "transport": "http",
          "containerPort": 15672
        }
      },
      "connectionString": "amqp://guest:{rabbitmqcontainer.inputs.password}@{rabbitmqcontainer.bindings.management.host}:{rabbitmqcontainer.bindings.management.port}",
      "inputs": {
        "password": {
          "type": "string",
          "secret": true,
          "default": {
            "generate": {
              "minLength": 10
            }
          }
        }
      }
    },
    "mongodbcontainer": {
      "type": "container.v0",
      "image": "mongo:latest",
      "bindings": {
        "tcp": {
          "scheme": "tcp",
          "protocol": "tcp",
          "transport": "tcp",
          "containerPort": 27017
        }
      },
      "connectionString": "{mongodbcontainer.bindings.tcp.host}:{mongodbcontainer.bindings.tcp.port}"
    },
    "sqlserverabstract": {
      "type": "container.v0",
      "image": "mcr.microsoft.com/mssql/server:2022-latest",
      "env": {
        "ACCEPT_EULA": "Y",
        "MSSQL_SA_PASSWORD": "{sqlserverabstract.inputs.password}"
      },
      "bindings": {
        "tcp": {
          "scheme": "tcp",
          "protocol": "tcp",
          "transport": "tcp",
          "containerPort": 1433
        }
      },
      "connectionString": "Server={sqlserverabstract.bindings.tcp.host},{sqlserverabstract.bindings.tcp.port};User ID=sa;Password={sqlserverabstract.inputs.password};TrustServerCertificate=true;",
      "inputs": {
        "password": {
          "type": "string",
          "secret": true,
          "default": {
            "generate": {
              "minLength": 10
            }
          }
        }
      }
    },
    "mysqlabstract": {
      "type": "container.v0",
      "image": "mysql:latest",
      "env": {
        "MYSQL_ROOT_PASSWORD": "{mysqlabstract.inputs.password}"
      },
      "bindings": {
        "tcp": {
          "scheme": "tcp",
          "protocol": "tcp",
          "transport": "tcp",
          "containerPort": 3306
        }
      },
      "connectionString": "Server={mysqlabstract.bindings.tcp.host};Port={mysqlabstract.bindings.tcp.port};User ID=root;Password={mysqlabstract.inputs.password}",
      "inputs": {
        "password": {
          "type": "string",
          "secret": true,
          "default": {
            "generate": {
              "minLength": 10
            }
          }
        }
      }
    },
    "redisabstract": {
      "type": "container.v0",
      "image": "redis:latest",
      "bindings": {
        "tcp": {
          "scheme": "tcp",
          "protocol": "tcp",
          "transport": "tcp",
          "containerPort": 6379
        }
      },
      "connectionString": "{redisabstract.bindings.tcp.host}:{redisabstract.bindings.tcp.port}"
    },
    "postgresabstract": {
      "type": "container.v0",
      "image": "postgres:latest",
      "env": {
        "POSTGRES_HOST_AUTH_METHOD": "scram-sha-256",
        "POSTGRES_INITDB_ARGS": "--auth-host=scram-sha-256 --auth-local=scram-sha-256",
        "POSTGRES_PASSWORD": "{postgresabstract.inputs.password}"
      },
      "bindings": {
        "tcp": {
          "scheme": "tcp",
          "protocol": "tcp",
          "transport": "tcp",
          "containerPort": 5432
        }
      },
      "connectionString": "Host={postgresabstract.bindings.tcp.host};Port={postgresabstract.bindings.tcp.port};Username=postgres;Password={postgresabstract.inputs.password};",
      "inputs": {
        "password": {
          "type": "string",
          "secret": true,
          "default": {
            "generate": {
              "minLength": 10
            }
          }
        }
      }
    },
    "rabbitmqabstract": {
      "type": "container.v0",
      "image": "rabbitmq:3-management",
      "env": {
        "RABBITMQ_DEFAULT_USER": "guest",
        "RABBITMQ_DEFAULT_PASS": "{rabbitmqabstract.inputs.password}"
      },
      "bindings": {
        "tcp": {
          "scheme": "tcp",
          "protocol": "tcp",
          "transport": "tcp",
          "containerPort": 5672
        },
        "management": {
          "scheme": "http",
          "protocol": "tcp",
          "transport": "http",
          "containerPort": 15672
        }
      },
      "connectionString": "amqp://guest:{rabbitmqabstract.inputs.password}@{rabbitmqabstract.bindings.management.host}:{rabbitmqabstract.bindings.management.port}",
      "inputs": {
        "password": {
          "type": "string",
          "secret": true,
          "default": {
            "generate": {
              "minLength": 10
            }
          }
        }
      }
    },
    "mongodbabstract": {
      "type": "mongodb.server.v0"
    },
    "integrationservicea": {
      "type": "project.v0",
      "path": "../TestProject.IntegrationServiceA/TestProject.IntegrationServiceA.csproj",
      "env": {
        "OTEL_DOTNET_EXPERIMENTAL_OTLP_EMIT_EXCEPTION_LOG_ATTRIBUTES": "true",
        "OTEL_DOTNET_EXPERIMENTAL_OTLP_EMIT_EVENT_LOG_ATTRIBUTES": "true",
        "ConnectionStrings__sqlservercontainer": "{sqlservercontainer.connectionString}",
        "ConnectionStrings__mysqlcontainer": "{mysqlcontainer.connectionString}",
        "ConnectionStrings__rediscontainer": "{rediscontainer.connectionString}",
        "ConnectionStrings__postgrescontainer": "{postgrescontainer.connectionString}",
        "ConnectionStrings__rabbitmqcontainer": "{rabbitmqcontainer.connectionString}",
        "ConnectionStrings__mongodbcontainer": "{mongodbcontainer.connectionString}",
        "ConnectionStrings__sqlserverabstract": "{sqlserverabstract.connectionString}",
        "ConnectionStrings__mysqlabstract": "{mysqlabstract.connectionString}",
        "ConnectionStrings__redisabstract": "{redisabstract.connectionString}",
        "ConnectionStrings__postgresabstract": "{postgresabstract.connectionString}",
        "ConnectionStrings__rabbitmqabstract": "{rabbitmqabstract.connectionString}",
        "ConnectionStrings__mongodbabstract": "{mongodbabstract.connectionString}"
      },
      "bindings": {
        "http": {
          "scheme": "http",
          "protocol": "tcp",
          "transport": "http"
        },
        "https": {
          "scheme": "https",
          "protocol": "tcp",
          "transport": "http"
        }
      }
    }
  }
}

ping @ellismg @davidfowl @prom3theu5

Proof of concept: https://github.com/dotnet/aspire/pull/1165

Made some changes for Postgres. Specifically, we no longer use the trust auth method either locally for for inner loop. Instead with use the scram-sha-256 password exchange method. It stops the password being transmitted via clear text (using a challenge mechanism). The connection still isn't TLS though - but its better than auth mode being trust if someone is deploying onto an internal container network.

@davidfowl @ellismg @prom3theu5 ... big push! Let me hear your thoughts and feedback.

Quite a lot of rework in aspirate for third party component support for things like Postgres and Redis now though, but hopefully the amount of data about what comprises a container in the manifest is enough to construct custom deployments for them etc

Why? Those resources are still abstract resources that the deployment tool needs to handle. This PR just makes container resources more explanatory.

@mitchdenny do you plan to update the templates to use AddRedis instead of AddRedisContainer?

Just because of how I implemented components is all
Each component had its own processor like https://github.com/prom3theu5/aspirational-manifests/blob/main/src/Aspirate.Processors/Redis/RedisProcessor.cs
I agree it simplifies a lot of that just needs a more “intelligent” processor for the container type.
They way I implemented component types was with their own processors and own set of templates so the processor for redis It explicitly chose a redis template with lower resource limits set etc
https://github.com/prom3theu5/aspirational-manifests/blob/main/src/Aspirate.Cli/Templates/redis.hbs
I can use the type to control the selection of which template :)
Now on a container if you change the custom image for redis to joeblogs:about-stuff there is no way to know that it's redis.
Components like redis don't technically need a service as well as a deployment defining.
Don't worry. I'll just produce a container processor and rework all the custom templates into one unified templated template.
Sent from Outlook for iOShttps://aka.ms/o0ukef

From: David Fowler @.>
Sent: Wednesday, December 6, 2023 5:00:13 PM
To: dotnet/aspire @.>
Cc: David Sekula @.>; Mention @.>
Subject: Re: [dotnet/aspire] App model rework around resource types and connection string emission for containers (PR #1165)
Quite a lot of rework in aspirate for third party component support for things like Postgres and Redis now though, but hopefully the amount of data about what comprises a container in the manifest is enough to construct custom deployments for them etc
Why? Those resources are still abstract resources that the deployment tool needs to handle. This PR just makes container resources more explanatory.
—
Reply to this email directly, view it on GitHubhttps://github.com/dotnet/aspire/pull/1165#issuecomment-1843295775, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AALSYEQ4XUDRWXZR35U46FDYICQB3AVCNFSM6AAAAABACRHCSCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBTGI4TKNZXGU.
You are receiving this because you were mentioned.Message ID: @.***>

Just because of how I implemented components is all
Each component had its own processor like https://github.com/prom3theu5/aspirational-manifests/blob/main/src/Aspirate.Processors/Redis/RedisProcessor.cs
I agree it simplifies a lot of that just needs a more “intelligent” processor for the container type.
The way I implemented component types was with their own processors and own set of templates so the processor for redis It explicitly chose a redis template with lower resource limits set etc. now each type will just be container.v0
https://github.com/prom3theu5/aspirational-manifests/blob/main/src/Aspirate.Cli/Templates/redis.hbs
I can use the type to control the selection of which template. Now on a container if you change the custom image for redis to joeblogs:about-stuff there is no way to know that it's redis.
Components like redis don't technically need a service as well as a deployment defining.
Don't worry. I'll just produce a container processor and rework all the custom templates into one unified templated template.

One thing we should consider is not having containers require a custom manifest but instead using annotations. That would let the manifest writing happen without so much custom logic in each container (I worry about the amount of copy pasta required for new containers)

We are already pretty late, so if you are happy to do so can we defer that to preview 3. I think we would probably need an InputAnnotation and a ConnectionStringAnnotation.

@mitchdenny The sql client doesn't work anymore after this PR, the password is invalid for sa when resolving SqlConnection. Or is there something else to do than AddDatabase() in the host and AddSqlServerClient in the app?

What does your app host look like so I can repro.

I am not sure there is a problem here, I just tested it with tests/testprogram/TestProgram.AppHost. Here was my methodology:

Start the app host.
Go to integration service /health endpoint and verify that everything is healthy.
Go to Docker Desktop and stop the SQL server instances (there are two of them)
Hit the health endpoint again ... should now be unhealthy.
Start both containers again ... should eventually go healthy again.


Wait for onclose

Because closing happens in a browser background thread.
https://github.com/Level/level.js/blob/8c9f713e8db7e0383a733504c5996e507ae7fff5/index.js#L118-L121

Nevermind. From the spec:

The "close" event only fires if the connection closes abnormally, e.g. if the origin’s storage is cleared, or there is corruption or an I/O error. If close() is called explicitly the event does not fire.


Field level @auth has unexpected behaviour (iam provider)

Describe the bug
When I use field level authentication on a @model so that public (unauth IAM requests) have update permissions on a given field, public users can then update any of the fields.
Also, when making a graphql mutation request to update the field in question, the update succeeds but the response always contains null for that value.
Amplify CLI Version
4.29.7
To Reproduce
Using IAM as the authentication method, with the front end users either logged in (authenticated) or not (unauthenticated)
Say I have this model
type Order
@model
@key(name: "byOrderMonth", fields: ["month", "createdAt"], queryField: "byOrderMonth")
@auth(rules: [{allow: public, operations: [read], provider: iam}, {allow: private, provider: iam}]) {
  id: ID!
  month: String!
  createdAt: AWSDateTime!
  updatedAt: AWSDateTime
  items: [ItemLine!]!
  status: Status!
  total: Int!
  orderNotes: String
  customerArrived: Boolean
}

As expected, the unauthenticated front end users can read an order but any mutations are blocked as they don't have permissions. Now say I modify the customerArrived field to be:
customerArrived: Boolean @auth(rules: [{allow: public, operations: [read, update], provider: iam}])

I can then update this field from the front end Amplify.API client with gql mutation,
e.g.
const input = {
    id: orderId, customerArrived: true, orderNotes: 'hello',
  };
const result = await API
  .graphql(graphqlOperation(mutations.updateOrder, { input }));

but:

When updating the field, the response from the mutation will always have customerArrived: null
I can also update any of the other fields with an unauthenticated user (orderNotes is changed to 'hello' and this is returned on the mutation response as well)

Expected behavior
I would expect that after modifying the schema like so, I can then only update that field with unauth user, and if I try to update any other fields it should fail the request.
Also, I would expect that on the mutation response, I would get the updated value e.g. customerArrived: true
Desktop (please complete the following information):

OS: Mac
Node Version. 10.15.0

Additional context
My solution to get around this issue will have to be removing the field level auth and exposing a lambda endpoint just to update that one field as the lambda will have sufficient permissions.

Hi, your point 2 is a security flaw that has been pointed out before. The documentation was updated to note this possibility, although I can understand that it is very hard to catch the nuance unless you already know the details
From the docs:

In addition an owner can perform an update operation on the Todo object, only when the content field is present as a part of the input.

The issue was first pointed out in #2241 , I've previously fed back that the documentation needs to be more explicit here and here

The GraphQL transformer does not support IAM and API Key provider in field level. The reason is that the passed context doesn't have the necessary information in when executing resolver code like a JWT token from Cognito User Pools has. I have created an PR to update the docs to clarify this further, and also we can make a DX improvement to warn when field level auth is added with either IAM or API Key provider. I've added a backlog task for this and will raise it with the team.
For explanation on the null issue when updating the field, the response from the mutation will always have customerArrived: null. This is an documented behavior to protect field level results in subscriptions as subscription uses the output of a mutation and publishes it to all the subscribers.

Per-Field with subscriptions

When setting per-field @auth the Transformer will alter the response of mutations for those fields by setting them to null in order to prevent sensitive data from being sent over subscriptions. For example in the schema below:"


Nested CSS was detected, but CSS nesting has not been configured correctly.

📚 Subject area/topic
PostCSS with Tailwind Plugin
📋 Page(s) affected (or suggested, for new content)
https://docs.astro.build/es/guides/styling/#postcss
📋 General description or bullet points (if proposing new content)
Hello,
After following the steps from the Docs, I get the error on the console (check screenshots).
Seems that somehow PostCSS config has some conflicts with Tailwind, following the Astro Doc.

MacOSX Ventura 13.5.1
VSCode
"astro": "^3.1.0",
package.json:

{
  "name": "sm_astro",
  "type": "module",
  "version": "0.0.1",
  "browserslist": [
    "defaults"
  ],
  "scripts": {
    "dev": "bun --bun astro dev",
    "start": "astro dev",
    "build": "astro build",
    "preview": "astro preview",
    "astro": "astro"
  },
  "dependencies": {
    "@astrojs/partytown": "^2.0.0",
    "@astrojs/sitemap": "^3.0.0",
    "@astrojs/tailwind": "^5.0.0",
    "@typescript-eslint/parser": "^6.7.0",
    "astro": "^3.1.0",
    "astro-icon": "^0.8.1",
    "autoprefixer": "^10.4.15",
    "eslint-plugin-astro": "^0.29.0",
    "eslint-plugin-jsx-a11y": "^6.7.1",
    "tailwindcss": "^3.3.3"
  },
  "devDependencies": {
    "bun-types": "^1.0.2",
    "eslint": "^8.49.0"
  }
}

Changed from:
const autoprefixer = require('autoprefixer');

module.exports = {
   plugins: [
      autoprefixer(),
   ]
};

To:
module.exports = {
   plugins: {
      'tailwindcss/nesting': {}, <--- Needs this
      tailwindcss: {},
      autoprefixer: {},
   }
};

After that, the error from the console goes away :).

🖥 Reproduction in StackBlitz (if reporting incorrect content or code samples)
https://stackblitz.com/edit/github-elgzfe-pwwt3m?file=src%2Flayouts%2FLayout.astro,postcss.config.cjs,package.json

Hey there @xexiu. After looking at this issue and the documentation, my understanding is that Astro does not enable the tailwindcss/nesting plugin by default. The TailwindCSS documentation covers this here, but you can use the other syntax as well like so:
const autoprefixer = require('autoprefixer');
const tailwindNesting = require('tailwindcss/nesting');

module.exports = {
  plugins: [tailwindNesting(), autoprefixer()],
};

The Vite/Tailwind error message also seems fairly user-friendly, at least from my point of view, explaining the source of the error, how to fix it, and a corresponding link to documentation.
[vite:css] Nested CSS was detected, but CSS nesting has not been configured correctly.
Please enable a CSS nesting plugin *before* Tailwind in your configuration.
See how here: https://tailwindcss.ocm/docs/using-with-preprocessors#nesting

If there's anything that I may have missed, I'm open to discussion about it, these are just my thoughts.
And I guess I'd more like to open this up to others to see if this implementation detail is something out of the norm for either Vite or Astro, or something that should be covered more in depth in the Astro documentation specifically (either via a link or a small section).

Closing this as not something for us to document when an error message with explanation exists for this case.


Going sudoless with udisksctl

With this commit, there is no need on Raspbian and probably other ARM Linux Desktops to enable passwordless sudo, as long as udisks2 is installed and loop is built into the kernel.
I tested this on x86 Linux Desktop, RPi4 LibreELEC (both mainly to make sure I didn't break anything else) and RPi4 Raspbian (as user pi, but with nopasswd disabled) and didn't find any issues.
This would resolve #246

Codecov Report

Merging #267 into master will decrease coverage by 0.20%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #267      +/-   ##
==========================================
- Coverage   77.51%   77.31%   -0.21%
==========================================
  Files          18       18
  Lines        1819     1838      +19
==========================================
+ Hits         1410     1421      +11
- Misses        409      417       +8

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 08de301...0326362. Read the comment docs.

In general I like this improvement, except for my two remarks.

Codecov Report

Merging #267 into master will decrease coverage by 1.67%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #267      +/-   ##
==========================================
- Coverage   78.12%   76.45%   -1.68%
==========================================
  Files          18       18
  Lines        1838     1809      -29
==========================================
- Hits         1436     1383      -53
- Misses        402      426      +24

Impacted Files
Coverage Δ

lib/inputstreamhelper/utils.py
90.90% <0.00%> (-9.10%)
:arrow_down:

test/xbmcgui.py
75.69% <0.00%> (-3.60%)
:arrow_down:

lib/inputstreamhelper/__init__.py
75.40% <0.00%> (-2.74%)
:arrow_down:

test/test_api.py
92.59% <0.00%> (-1.16%)
:arrow_down:

test/xbmcaddon.py
85.00% <0.00%> (-0.72%)
:arrow_down:

test/xbmc.py
59.03% <0.00%> (-0.25%)
: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 72830e8...f473850. Read the comment docs.

I'll close this and redo it once #304 is merged. I'll probably also add an option to use p7zip then.


Remove last trailing line for directives-only files

There are two hardlines that are added that do not need to.

The first one is when there's an empty line afterwards, we want to remove it. The solution I opted for to fix this one is to trimRight the originalText so that globally it's never going to return yes for the isNextLineEmpty.
The second one is at the end of Program, but we already printed it inside of the directive itself, so we can just add a condition to make sure it's only printed when there's a body or a comment, but not a directive.

Fixes #527

I'm not sure I understand why we only want to add a line if there was any contents in the file. Shouldn't we still add a newline at the end even for files with only directives?
I'll merge this but I'm going to make a list of things to follow-up with you (since you are away).

I swear, there's a bug in github/travis when pushing to someone else's branch :( It doesn't seem to check out the right code. This should pass, and I'll watch master.

If you look at the way we print directives, we always put a hardline after each one. So if there's just a directive the hardline is already printed

Ah I see. I misread the snapshot tests. Thanks!


Future provider memory leak

Describe the bug
Listeners are added when they shouldn't be when using future providers. This leads to a memory leak since the listeners are never removed.
Dependencies
flutter_riverpod: 2.5.1
riverpod_annotation: 2.3.5
riverpod_generator: 2.4.0
riverpod_lint: 2.3.10

Code
@riverpod
Future<int> a(ARef ref) async {
  print('buildA');
  ref.onAddListener(() {
    print('addA');
  });
  ref.onRemoveListener(() {
    print('removeA');
  });
  ref.onCancel(() {
    print('cancelA');
  });
  await Future.delayed(const Duration(seconds: 5));
  await ref.watch(bProvider.future);
  return 5;
}

@riverpod
Future<int> b(BRef ref) async {
  print('buildB');
  ref.onAddListener(() {
    print('addB');
  });
  ref.onRemoveListener(() {
    print('removeB');
  });
  ref.onCancel(() {
    print('cancelB');
  });
  return 6;
}

class SomeScreen extends ConsumerWidget {
  @override
  Widget build(BuildContext context, WidgetRef ref) {
    ref.watch(aProvider);
    return Container();
  }
}

If you display SomeScreen, then click back within 5 seconds (the delay in aProvider), the following is printed:
buildA
addA
removeA
cancelA
buildB
addB

A listener for bProvider is added but never removed even though nothing is listening to aProvider anymore. Shouldn't aProvider check its own aliveness before adding a listener to bProvider on the line ref.watch(bProvider.future)?
Expected behavior
The listener on bProvider should never be added

I guess I just expected both A and B to be disposed when I leave the page. I expected the state of B to be reset when I go back to the page, but it remains. Why should a disposed resource A keep its dependencies B alive?
I find it weird that an unused auto-dispose provider can still be listening to something. This fundamentally causes a memory leak because if you:

Navigate to SomeScreen
Go back
Repeat steps 1-2 many times

In the end, you'll only have one SomeScreen mounted, so A will end up with one listener. B will have 1 useful listener and many other "ghost" listeners that are never cleared. So if those steps are repeated, you end up with 1 million listeners on b even though only one of them is for a resource that isn't disposed? There's no way that this can be expected behavior.
Why doesn't the watch method in A check if A is used/not disposed before adding the listener to B?

My project relies on this task being fixed urgently. If I were to make a PR and it's merged successfully, could it be a part of a minor release, or would it have to wait until 3.0 anyway?

It depends on the changes involved. But if it has to be a 3.0.0 fix, you could always stick to using your fork in the meantime

I'm not exactly sure how to fix this. If provider a in my example is disposed since we left the screen, should it be allowed to watch anything? Or should A wait until it has no listeners and its build is completed before disposing?

@rrousselGit I managed to fix it by simply checking the _mounted status in ref functions and throwing error if not but I don't know if it could cause any other issues?
here's the pr https://github.com/rrousselGit/riverpod/pull/3598

I've got the same bug (which was hard to catch).
A temporary solution is to update aProvider to watch the future before the await:
@riverpod
Future<int> a(ARef ref) async {
  print('buildA');
  ref.onAddListener(() {
    print('addA');
  });
  ref.onRemoveListener(() {
    print('removeA');
  });
  ref.onCancel(() {
    print('cancelA');
  });
  final bFuture = ref.watch(bProvider.future);
  await Future.delayed(const Duration(seconds: 5));
  await bFuture;
  return 5;
}

@AhmedLSayed9 that kinda works but you would end up making that network call even if provider is disposed and there's no need. also it gets quite messy the more futures you have in your provider.
but if you ok with waiting all those futures even when disposed you might want to consider keepAlive link instead in this case you only have 2 extra lines no matter how many futures you have
@riverpod
Future<int> a(ARef ref) async {
  print('buildA');
  ref.onAddListener(() {
    print('addA');
  });
  ref.onRemoveListener(() {
    print('removeA');
  });
  ref.onCancel(() {
    print('cancelA');
  });

  final keepAliveLink = ref.keepAlive(); // make it non disposable

  await Future.delayed(const Duration(seconds: 5));
  await ref.watch(bProvider.future);

  keepAliveLink.close(); // release

  return 5;
}

you would end up making that network call even if provider is disposed

This would occur in both cases. I'd use CancelToken for that matter anyway.
The KeepAliveLink will prevent aProvider from being disposed if bProvider throws an error.

you would end up making that network call even if provider is disposed

This would occur in both cases. I'd use CancelToken for that matter anyway.

you might want to consider keepAlive link instead

The KeepAliveLink will prevent aProvider from being disposed if bProvider throws an error.

This would occur in both cases. I'd use CancelToken for that matter anyway.

Yup that's why I said if you ok with that. Some requests unfortunately can't be canceled e.g supabase db calls, etc

The KeepAliveLink will prevent aProvider from being disposed if bProvider throws an error.

Fair enough. You'd want to have a wrapper function that would handle with try/catch/finally which gets quite ugly regardless.
The proper solution is to just throw when trying to use watch/listen of disposed refs which is coming in v3. For now we may just have to stick to a fork

The proper solution is to just throw when trying to use watch/listen of disposed refs which is coming in v3. For now we may just have to stick to a fork

It seems weird to me that a framework exception like that would be thrown in a provider. The programmer didn't really do anything wrong and shouldn't have to handle such exception. If they have a try/catch block in there, that new exception will change the control flow of the provider. Why should having no listeners on the provider change control flow in the build method like this?
It seems more natural to me to have a "disposing" state along with a "disposed" state of a provider. If an auto dispose future provider loses its last listener, it should go into a "disposing" state and remain in that state until it's current build is completed. If a different provider tries to listen to a "disposing" provider, Riverpod would just make a new instance of the provider and let the build method of the "disposing" instance run out. If a "disposing" provider tries to use its ref to watch another provider, Riverpod should let it. Then once the "disposing" provider is done building, it would dispose and clear all of its dependencies.
Normal async functions in dart can't be cancelled, you can only ignore their result. It seems weird to me to fight that behavior by throwing exceptions.


[Feat] Add a weapon slelction option in search

What problem is this solving
When I want to get some hilarious moment I found it difficult to find taser kill part, I have to enter the specific match and find taser kills in each round. So I guess maybe there is a better solution?
Proposed solution
In "search" page, there can be a weapon selection option.
Describe alternatives you've considered
No response

The Knife kills event in the "Search" page filter on knife and tazer kills.
The label will be clearer in the next release.

OK thanks.


Show default service png for catalogs

Fixes missing image logos for catalogs created without uploading a new
image.
Also update .nvmrc to use the same node version as travis.
https://www.pivotaltracker.com/story/show/138143341
@miq-bot add_label euwe/no, bug

@jjlangholtz needs rebase

@chriskacerguis I'm a bit confused as to why this needs a rebase when there are no conflicts.

@jjlangholtz it says it is out of date.

I think the way it is set up every time a PR is merged it will make every other PR out of date.
So instead of requiring a rebase only when there are conflicts, we need to rebase every time a change is merged, conflict or not.

@jjlangholtz that's not the usual behavior I see.

@chriskacerguis I just noticed this morning. I rebased this PR once and then when another one got merged (with no conflicts) I saw this one become out-of-date again.


Finally moving on open-source YourKit license

I couldn't decide on a good spot for it previously, because the logo they sent me was really big compared to anything else we had up.  And then I forgot.  Proposing this for now (copied from fs2), and am fine with alternatives.

I just realized me + you = two.  My first merge, very exciting.


RuntimeError of nnls ceases DYNAMITE

During running of DYNAMITE-BayesLOSVD, one model had a RuntimeError of optimise.nnls, and the weights of this model was not solved.
"""
Traceback (most recent call last):
  File<EMAIL_ADDRESS>line 125, in worker
    result = (True, func(*args, **kwds))
  File<EMAIL_ADDRESS>line 48, in mapstar
    return list(map(*args))
  File "/home/myang/dynamite_v2/dynamite/model_iterator.py", line 301, in create_and_run_model
    weight_solver = mod.get_weights(orblib)
  File "/home/myang/dynamite_v2/dynamite/model.py", line 595, in get_weights
    weights, chi2_tot, chi2_kin = weight_solver.solve(orblib)
  File "/home/myang/dynamite_v2/dynamite/weight_solvers.py", line 661, in solve
    solution = optimize.nnls(A, b)
  File<EMAIL_ADDRESS>line 82, in nnls
    raise RuntimeError("too many iterations")
RuntimeError: too many iterations
"""

This error ceased the code, and the status of all models in this iteration were False*3.  And I cannot continue running DYNAMITE.
Is there any way to get over this problem?

Closed because any legacy_fortran binary failing will no longer crash DYNAMITE...


Fixes bad resource usage in rendering

D3D11 is quite strict about how resources are supposed to be used - read/write & CPU access. This changes Tex2DKind and BufferKind into one uniform ResourceKind (because it's the same thing really). And it is more strict about usage:

Static is not allowed to update, resource is immutable, data provided at creation
Dynamic allows CPU to update GPU resource occasionally via UpdateSubresource
Stream allows CPU to update GPU resource often via Map/Unmap (currently unused)

This should fix #148. And maybe #215.

Thanks Martins!


error missing dll

i tried running the program and an error message popped out
api-ms-win-shcore-scaling-l1-1-1.dll missing

What operating system are you using? This program is only tested in latest version of Windows 10, so if it doesn't work on previous version, then I will have to make sone changes.

im using win 7

https://github.com/Soreepeong/XivAlexander/blob/0b0d5b6880a3c2a3451891d64bc975582ca7f87a/XivAlexander/App_Window_Base.cpp#L82
Use GetDeviceCaps(..., LOGPIXELSX or LOGPIXELSY) instead if GetDpiForMonitor (Windows 8.1+) is unavailable.

Try again with the latest release.

Hi,
The previous error was solved, but a new one immediately fires:
The procedure entry point GetSystemTimePreciseAsFileTime could not be located in the dynamic link library KERNEL32.dll.

Thanks for trying to support older systems, good luck!


BUG-Data Node should disappear from additional_data_nodes

Description
Data Nodes when attached to a task should disappear from the additional_data_nodes section.
How to reproduce

Create a config and scenario, enter the scenario view
Create a Data Node
Add the Data Dode in the additional_data_nodes
Attach it to a task

Expected behavior
It should disappear from the list of additional data nodes as it is now attached to a task.
Screenshots

Runtime environment

Taipy Studio Config version: 2.0.0

I thought this was supported if not encouraged?

What do you mean? If a data node is linked to a task, it is not an additional_data_nodes or at least, this is what I think

Absolutely. An additional data node is a data node part of the scenario that is not linked to any task of the scenario.


[ZEPPELIN-5413] Throw proper error message when user set execution.runtime-mode in flink sql

What is this PR for?
execution.runtime-mode is available in flink sql-client, but it is not available in zeppelin flink interpreter. So we need to throw proper error message when user set execution.runtime-mode in flink sql.
What type of PR is it?
[Improvement]
Todos

[ ] - Task

What is the Jira issue?

https://issues.apache.org/jira/browse/ZEPPELIN-5413

How should this be tested?

Manually tested

Screenshots (if appropriate)
Questions:

Does the licenses files need update? No
Is there breaking changes for older versions? No
Does this needs documentation? No

Will merge if no more comment


modal trick needed

I'm looking for a way to force the page to refresh when closing modal pop-up. I found several solutions but none of them works (or I cant' implement it into my code probably because of syntax problems)...

Hi, @karaspr! Thank you for using our products. You must put the reload function in the hidden event of the modal. Please see here how to use the modal hidden event.
Regards,
Dragos

please confirm: I should put
$('#myModal').on('hidden.bs.modal', function (e) {
location.reload();
}) .  <-- is it correct?
but WHERE should I put it? Can I have a hint?

Hi! Yes, it is correct and you can put it in the js file in assets/js folder.
Regards,
Dragos


Compiler crashers: Use canonical "-emit-silgen" to trigger crash case.

Hi @practicalswift, I don't follow why you want to make this particular change. Can you provide more background in the commit message?

this will make the test run faster, and still exposes the crash.  LGTM.

@rudkx It is faster and more in line with how other similar test cases are handled :-)


TypeError while uploading results

Trying to upload the arachni scan results into local setup of defectdojo and facing the below type error. Any idea how to resolve?
pip status:
defectdojo_api 1.1.4
Command:
python  defectdojo_api/examples/dojo_ci_cd.py --product 1 --file "defectdojo_api/examples/sample-scan-files/arachni/arachni.afr.json" --scanner=“Arachni Scan" --host="http://<IP_ADDRESS>/" --api_key="xxx" --user=“admin"
Output:
Traceback (most recent call last):
  File "dojo_ci_cd.py", line 241, in <module>
    class Main:
  File "dojo_ci_cd.py", line 290, in Main
    summary(dd, engagement_id, test_ids, max_critical, max_high, max_medium)
  File "dojo_ci_cd.py", line 166, in summary
    print "Total Number of Vulnerabilities: " + str(findings.data["meta"]["total_count"])
TypeError: string indices must be integers

@ # @
Duplicate of 11#
Please try pip install -I defectdojo_api==1.1.3


ci: add arm64 test job

Based on #197
This commit adds a CI job for running test on arm64 arch with qemu.
The idea is just building test binaries with go test -c and running
these built test binaries inside the emulation. This would reduce the
cost of build time in emulation.

virtually no overhead!


MWPW-144683 Article Header Unit Test

Add unit test for the article header and add mocks
Functionality for original PR (https://github.com/adobecom/bacom-blog/pull/37) was no longer needed but wanted to keep the unit tests

Related to: MWPW-144683
Test URLs:
N/A

Not blocking, but I do wonder if this unit test doesn't belong in Milo itself? I understand we are testing the implementation that occurs in our utils.js, but wondering if we could skip some of the mocks by adding the test in milo? Or even what about the test in Milo was inadequate to catch our use case?

I don't think that tests in milo would adequately cover our use case. The article header block in milo requires a very specific input or else it errors out and the block doesn't build correctly. That's essentially what we're testing here: Does the code in bacom blog utils provide correctly formatted data for the article header block to use?

Not blocking, but I do wonder if this unit test doesn't belong in Milo itself? I understand we are testing the implementation that occurs in our utils.js, but wondering if we could skip some of the mocks by adding the test in milo? Or even what about the test in Milo was inadequate to catch our use case?

I don't think that tests in milo would adequately cover our use case. The article header block in milo requires a very specific input or else it errors out and the block doesn't build correctly. That's essentially what we're testing here: Does the code in bacom blog utils provide correctly formatted data for the article header block to use?
Edit: It's possible that we could avoid mocking milo libs by rewriting buildArticleHeader but I don't see why we should. What's the objection to the way I'm mocking? It came from a suggestion by Okan.

No objection to the way it's done. Just finding the test interesting, and what it necessitates interesting. "Does the code in bacom blog utils provide correctly formatted data for the article header block to use" is not something I think we've tested for in other consumer repos, and it exposes that the article-header may have been built incorrectly from the start according to current Milo practices. Nothing to be done in this PR, but food for thought nonetheless.