Swapper pair resetting when attempting chain switch for trade into WETH

Overview
Currently in production, when attempting to switch the the chain of the output asset of a WETH trade, the asset pairs switch the output and input assets.  See Jams for recreations.  Attempts to trigger the bug with assets that are not WETH were not successful.
References and additional details
Hpayne discovery: https://jam.dev/c/73a354a3-e041-42c5-9ff0-4f430ef72674
Tyler recreation: https://jam.dev/c/18c1e2ce-c011-4541-ad83-b4f30226705a
Acceptance Criteria
Changing the chain of the outgoing asset in a x>WETH trade does not reset or switch the pair.  Users are able to use the chain selector successfully when attempting to change the chain of an outout WETH trade.
Need By Date
No response
Screenshots/Mockups
No response
Estimated effort
No response

I don't see any bugs there:
sellAsset => ETH on Base, buyAsset => WETH on Ethereum, if you change the buyAsset chain to Base (ETH), it will select ETH on Base and as you can't swap one same asset to the same asset, we simply switch the assets
You are clicking on Base (ETH), Arbitrum (ETH) which is here to cleary distinguish ETH and WETH which are 2 different assets, if you want to switch ETH to WETH on the same chain, then click on the chain without (ETH)

Closing as it seems logical so far but if @shapeshift/product want to confirm feel free!


READ AND SHARE ,,,,TRUTH COMES TO THE LIGHT

https://www.linkedin.com/posts/robert-genaro-0802782b5_sasa-activity-7277968213903122432-4pOS?utm_source=share&utm_medium=member_android

https://www.linkedin.com/posts/robert-genaro-0802782b5_learn-more-about-data-point-activity-7273758301383761923-6csw?utm_source=share&utm_medium=member_android


Plz i cant install pycurl using pypi

Plz i cant install pycurl using pypi

Can you share more information about the error message you get when trying to install the package? A common issue is what is described here #10


docs: direct users to also install @tanstack/react-query

Motivation
This is a gotcha that someone recently encountered.

BTW looks like axios is another peer dependency, so maybe the docs should reflect that as well.

@epeters3 great catch. updating.


Request not to suppress the output of build script

Sometimes the build script may fail, leaving some useful information (such as the output of GCC) in stdout or stderr.
However, I found that Cargo is not displaying the output of my build script.
I request a feature, that the stderr is displayed by default and stdout is displayed when --verbose is on.
Thanks.

The exmple
I have copied the build.rs from http://doc.crates.io/build-script.html#case-study:-building-some-native-code , as is listed below:
// build.rs

use std::io::Command;
use std::os;

fn main() {
    let out_dir = os::getenv("OUT_DIR").unwrap();

    // note that there are a number of downsides to this approach, the comments
    // below detail how to improve the portability of these commands.
    Command::new("gcc").args(&["src/hello.c", "-c", "-o"])
                       .arg(format!("{}/hello.o", out_dir))
                       .status().unwrap();
    Command::new("ar").args(&["crus", "libhello.a", "hello.o"])
                      .cwd(&Path::new(&out_dir))
                      .status().unwrap();

    println!("cargo:rustc-flags=-L {} -l hello:static", out_dir);
}

Note that the script does not check the status code of GCC or AR.
The problem
And it happened that the source does not compile. However Cargo printed out NOTHING helpful to diagnose this problem:
$ cargo build --verbose
   Compiling hello v0.0.1 (file:///tmp/hello)
     Running `rustc build.rs --crate-name build-script-build --crate-type bin -C prefer-dynamic -g --out-dir /tmp/hello/target/build/hello-77de99f14f3cb8ca --emit=dep-info,link -L /tmp/hello/target -L /tmp/hello/target/deps`
     Running `/tmp/hello/target/build/hello-77de99f14f3cb8ca/build-script-build`
     Running `rustc /tmp/hello/src/lib.rs --crate-name hello --crate-type lib -g -C metadata=77de99f14f3cb8ca -C extra-filename=-77de99f14f3cb8ca --out-dir /tmp/hello/target --emit=dep-info,link -L /tmp/hello/target -L /tmp/hello/target/deps -L /tmp/hello/target/build/hello-77de99f14f3cb8ca/out -l hello:static`
error: could not find native static library `hello`, perhaps an -L flag is missing?
Could not compile `hello`.

Caused by:
  Process didn't exit successfully: `rustc /tmp/hello/src/lib.rs --crate-name hello --crate-type lib -g -C metadata=77de99f14f3cb8ca -C extra-filename=-77de99f14f3cb8ca --out-dir /tmp/hello/target --emit=dep-info,link -L /tmp/hello/target -L /tmp/hello/target/deps -L /tmp/hello/target/build/hello-77de99f14f3cb8ca/out -l hello:static` (status=101)

I spent an extra hour figuring out where the problem is, having add some extra code to redirect the output of GCC to a log file.
I admit that there is a bug in the build script that the status code should be checked. But anyway, there need to be a way to debug this, or it will be a pain if this happens on a client's computer, causing a complaining mail.
If the user says --verbose, do verbose.
I know that printing a lot of garbage messes the terminal. So it is reasonable that the output of build script is suppressed.
But why continuing to suppress the output even if the user says --verbose?
I have read in issue #985 that it may be too noisy with --verbose. That's build.rs's stuff. build.rs should filter the output so only useful messages are shown, which is not Cargo's duty since Cargo no nothing about which message is useful.
Compilation takes time, user may want to see what is going on
In the documentation of Cargo, it explained that build scripts may find an extra library or build a library itself.
On the latter case, it may take time. It is better to tell the user why the compilation sticks at this point.
GCC warnings are really useful
If Cargo displays the output only when the build fails, the GCC warnings will be suppressed.
Just like Rust lints, GCC warnings is usually useful to improve the security of the code.
My idea

stderr is always on, and stdout is off unless --verbose is on

Or alternatively, introduce verbosity level

(P.S. I am really sorry that this post is so long and somewhat offensive)

The exmple
I have copied the build.rs from http://doc.crates.io/build-script.html#case-study:-building-some-native-code , as is listed below:
// build.rs

use std::io::Command;
use std::os;

fn main() {
    let out_dir = os::getenv("OUT_DIR").unwrap();

    // note that there are a number of downsides to this approach, the comments
    // below detail how to improve the portability of these commands.
    Command::new("gcc").args(&["src/hello.c", "-c", "-o"])
                       .arg(format!("{}/hello.o", out_dir))
                       .status().unwrap();
    Command::new("ar").args(&["crus", "libhello.a", "hello.o"])
                      .cwd(&Path::new(&out_dir))
                      .status().unwrap();

    println!("cargo:rustc-flags=-L {} -l hello:static", out_dir);
}

Note that the script does not check the status code of GCC or AR.
The problem
And it happened that the source does not compile. However Cargo printed out NOTHING helpful to diagnose this problem:
$ cargo build --verbose
   Compiling hello v0.0.1 (file:///tmp/hello)
     Running `rustc build.rs --crate-name build-script-build --crate-type bin -C prefer-dynamic -g --out-dir /tmp/hello/target/build/hello-77de99f14f3cb8ca --emit=dep-info,link -L /tmp/hello/target -L /tmp/hello/target/deps`
     Running `/tmp/hello/target/build/hello-77de99f14f3cb8ca/build-script-build`
     Running `rustc /tmp/hello/src/lib.rs --crate-name hello --crate-type lib -g -C metadata=77de99f14f3cb8ca -C extra-filename=-77de99f14f3cb8ca --out-dir /tmp/hello/target --emit=dep-info,link -L /tmp/hello/target -L /tmp/hello/target/deps -L /tmp/hello/target/build/hello-77de99f14f3cb8ca/out -l hello:static`
error: could not find native static library `hello`, perhaps an -L flag is missing?
Could not compile `hello`.

Caused by:
  Process didn't exit successfully: `rustc /tmp/hello/src/lib.rs --crate-name hello --crate-type lib -g -C metadata=77de99f14f3cb8ca -C extra-filename=-77de99f14f3cb8ca --out-dir /tmp/hello/target --emit=dep-info,link -L /tmp/hello/target -L /tmp/hello/target/deps -L /tmp/hello/target/build/hello-77de99f14f3cb8ca/out -l hello:static` (status=101)

I spent an extra hour figuring out where the problem is, having add some extra code to redirect the output of GCC to a log file.
I admit that there is a bug in the build script that the status code should be checked. But anyway, there need to be a way to debug this, or it will be a pain if this happens on a client's computer, causing a complaining mail.
If the user says --verbose, do verbose.
I know that printing a lot of garbage messes the terminal. So it is reasonable that the output of build script is suppressed.
But why continuing to suppress the output even if the user says --verbose?
I have read in issue #985 that it may be too noisy with --verbose. That's build.rs's stuff. build.rs should filter the output so only useful messages are shown, which is not Cargo's duty since Cargo no nothing about which message is useful.
Compilation takes time, user may want to see what is going on
In the documentation of Cargo, it explained that build scripts may find an extra library or build a library itself.
On the latter case, it may take time. It is better to tell the user why the compilation sticks at this point.
GCC warnings are really useful
If Cargo displays the output only when the build fails, the GCC warnings will be suppressed.
Just like Rust lints, GCC warnings is usually useful to improve the security of the code.
My idea

stderr is always on, and stdout is off unless --verbose is on

Or alternatively, introduce verbosity level

(P.S. I am really sorry that this post is so long and somewhat offensive)

I think that I should update the example listed to also check that the return code is 0, the real bug here is that the build script should fail if the return code is not 0, which would cause output to show up.
Some other points:

I think I'd probably be fine with a verbosity level. I think that the currently level of --verbose is adequate for most situations, but certainly not all!
If you'd like to see warnings from GCC for something like security, you should really consider turning them into errors rather than relying on Cargo to output them.
I'd be fine with breaking a package down and saying "Running build script" and "building" instead of just one "building foo", but the default set of output for Cargo should be quite small and readable to the extent that it should not output the full output of the build script.

I think that I should update the example listed to also check that the return code is 0, the real bug here is that the build script should fail if the return code is not 0, which would cause output to show up.

I have already stated that there is a bug in the build script.
However if Cargo provides no way to debug this, it will be much more difficult to figure out the build script is wrong. (Since Cargo says "error in linking", most people would probably check the linker at first instead of the build script)

If you'd like to see warnings from GCC for something like security, you should really consider turning them into errors rather than relying on Cargo to output them.

Why aren't Rust warnings treated like this? This is a discrimination against C.
Some other points:

In Rust standard library, std::io::Command suppresses and pipes the output of child processes by default. So if build.rs prints something, it means that he has written extra code to fetch the output GCC and he really wants to print something.
Thus, the filter is already done at build.rs side. Cargo no longer need to do filtering if the user asks not to.

Also, if something goes wrong (for example, the build.rs succeed but the linker failed) and a user submitted a bug report to me, which log should I ask him to attach?
Probably --verbose is best option. I knew there are ./target/build/*/out but they are spread all around, inconvenient to fit in an email attachment.

Why is --verbose printing out all the command lines but not the output of those child processes?
If --verbose is not verbose enough, how can I make Cargo as verbose as it can?

As is known, PyPy is printing out an image of Mandelbrot to entertain the user during the 3-hour compilation.
If a library takes an hour to compile (let's say libavformat or libgtk+ or PyPy), why can't build.rs print a progress bar?

I'm not convening you to let out the output of build.rs with default configuration.
But I request you, please, to let out the output when --verbose is on.
P.S. Maybe a combination of --quiet and --verbose option satisfy some needs?

Idly, I've also faced this issue, but broadly speaking I agree with @alexcrichton on it.
There's no way to 'stream' output from a process. It just can't happen. The Process API doesn't support it. The best you can do is block on stdout and stderr in a thread and wait until the process dies. Without an async io story, the very idea of streaming output from the build command is just a non-starter.
...and without that, I don't really see much benefit from being able to push output to stdout on success.
I mean, what's really the use case for 'This C compile passed, but I want to display some output messages'?
If you want to do debugging, just set the build.rs to always fail and it'll print the output to stderr.
If you want a more comprehensive logging solution (eg. log output of the entire build command to a file) you can use a 3rd party logging library for it.
I feel like if you allow build scripts to push output to stdout, everyone will start doing it, and it'll clutter the cargo build --verbose output like crazy.

@shadowmint
Thank you for your note. I have read the code at cargo::ops::cargo_rustc::custom_build::parse.
It seems that Cargo pipes out all the output to a file, read it into the memory as a string and process it.
The implementation is fairly simple and straight. However I have two questions appended:

Can't pipe work without async API? Doesn't starting a process and waiting at one end of the pipe work?

Since Cargo only cares about stdout, why don't set InheritFd(2) on stderr on --verbose?

@m13253 You can block on the pipe, but that locks the entire thread; cargo runs multiple commands at the same time, and this would halt the entire process it while it performs the build step.
Technically you could create a solution I suppose, where you created a separate thread for each pipe, and used Sender & Receiver to message pass data back to the 'parent' thread. I'm not aware of any existing implementation of that, but I believe it should be technically possible...
Re: stderr output; I think that's just the way Process works. As you said; it (by default) consumes the streams (stderr, stdout). Wouldn't that require changing the Process api to fix?

Re: stderr output; I think that's just the way Process works. As you said; it (by default) consumes the streams (stderr, stdout). Wouldn't that require changing the Process api to fix?

In order to pass stderr, we'll just need to add a .stderr(InheritFd(2)) after Command::new.
However I can't understand the way Cargo's source is organized. Could you help?

Ugghh, debugging of build scripts is such a pain :(
I can't run the script directly from /target/build/*/build-script-build, because it won't get all the env vars it needs. And I can't even print the env vars :)
So it's a black box that's calling a bunch of commands with arguments I'm not sure about, and something doesn't work right, and maybe it has printed why… but I can't see it!

@pornel Once again, if the build script fails, cargo reports the output stderr; so you can totally debug the output and dump the env vars if you want to. Just add:
panic!("nope");

For example:
use std::os::env;
use std::io::Command;
use std::str::from_utf8;
fn main() {
  for value in env().iter() {
    println!("{} -> {}", value.0, value.1);
  }
  let out = Command::new("ls").output().unwrap().output;
  let out_str = from_utf8(out.as_slice());
  println!("{:?}", out_str);
  println!("Hi!");
  panic!("Nope");
}

Yes, panic!() is possible. But it didn't solve the problem.
For example I usually prefer this procedure to debug this kind of script:

Enable "debug mode" in my source (by switching a boolean / set a config value)

Read a char from stdin, this will pause the program. (like a breakpoint)

Start gdb and attach to the process.

Debug the program line by line.

Print things into stderr so that I can see immediately.

Cargo only consumes stdout, but it is managing both stdin and stderr, making  this method unavailable.
There should be a way that I can use gdb for instant debugging.
Anyway, I can still achieve the goal by starting a new XTerm (or AllocConsole on Windows). However this will decrease user experience even more, and is oppose to the original design of Cargo.

@shadowmint Ok, it's good to know that panic! is a workaround for that, but:

It's not documented. "panic" is not mentioned on http://doc.crates.io/build-script.html. The paragraph about output only applies to lines starting with cargo:. Documentation only briefly describes happy path, and only has pseudocode examples.

Having a workaround doesn't solve the problem of cargo being unfriendly and frustrating to newcommers like me. "printf debugging" is the simplest thing that tends to work everywhere, and I have strong expectation that at least --verbose (or other switch documented in -h) should print it.

From @larsbergstrom in #1324

Currently, custom build commands are not printed and their output appears to also be only available to Cargo. It would be great if compiling with --verbose also printed that output.
In Servo, we very frequently shell out to a makefile in these custom build steps, and not being able to see the steps makes it quite difficult to debug them (especially since it can be challenging to recreate the exact lines that cargo passes in, due to the hash-specific directory names, etc.).

Cargo does print the custom build commands:
Running `/Users/doug/dev/rust-all/rust-sys-ruv/target/build/uv-ec54d3eb248926fd/build-script-build`
Running `/Users/doug/dev/rust-all/rust-sys-ruv/target/build/ruv-5686775bd2f9a443/build-script-build`

It just doesn't print the output or the list of env variables passed to them.
Once again, I find myself skeptical that logging the output will be useful unless there's a way to stream that output line by line as the build command generates it. ...and even then, unless the build command invokes commands correctly, it will still work exactly the same way (people just use read_to_end() all the time).
Really, there's no benefit is having cargo run to the end, and then spit out the output to stderr and stdout at the end; the issue with cargo is while its running you want some visibility about what it's actually doing, so you can debug scripts.
For example, if cargo hangs due to xcode ( >___< )  you have no visibility of what happened or why it stopped.
I use a custom file logger for this; but clearly this is a troublesome pain point for people.
Perhaps we can change the way cargo works (although I'm worried about breaking changes here... but still...) so that instead of using env variables, all the arguments are passed on the command line.
This would allow you to trivially run your build script in 'stand alone' mode, by running:
build/ruv-5686775bd2f9a443/build-script-build --OUT_DIR=... --libfoo=...

Running these outside of cargo would then print stdout & stderr as you go; although doubtless people will continue to discover that when build.rs invokes make, or other tools via Command it doesn't usefully log it's output for exactly the same reason.
NB. though that as recently raised in irc, windows has a command line length limit that might make this infeasible.

I just found this obnoxious in a case where my build script succeeded, but screwed up generated link flags, causing the library link to fail.  I resorted to dup2ing /dev/tty to stderr :P

User perspective: First time hacking on a build script helper (@alexcrichton's gcc-rs), and I slammed straight into this. :smiley:

Once again, I find myself skeptical that logging the output will be useful unless there's a way to stream that output line by line as the build command generates it. ...and even then, unless the build command invokes commands correctly, it will still work exactly the same way (people just use read_to_end() all the time).

It would be tremendously helpful on build bots like Travis, Jenkins, AppVeyor, etc. Imagine that you are developing a wrapper around a native library, and you're trying to use Travis, etc. to set up builds for a platform that you don't even have access to locally. The build logs are critical to getting that situation to work. More generally, verbose build logs from buildbots are much preferred over quiet logs from buildbots.
IMO, --verbose should do this.

@briansmith how do propose to do this, technically?
I've said my piece; if you want to hack on it, the code is here: https://github.com/rust-lang/cargo/blob/master/src/cargo/ops/cargo_rustc/custom_build.rs#L149
The execution engine is here: https://github.com/rust-lang/cargo/blob/master/src/cargo/util/process_builder.rs#L89
Try it and see how it works out for you?
I found that without streaming output, having 'log on failure' vs 'log on success' made no tangible difference.

It may be possible to have cargo both stream and capture the output via some pipe trickery on Windows/Unix, and I may also be pretty ok with doing this on multiple -v flags, e.g.:
# Only show commands run
cargo build -v
# Show output of all all commands run (build scripts) as well
cargo build -vv

@alexcrichton That double-v support would be fantastic. I'm pretty sure we would use it by default on our builds for pretty much everything on the builders on Servo, for exactly the reasons @briansmith outlines above. Right now, we have to have an admin log into the build machine, cargo build -v to get the execution line, then try to invoke stuff in the right directory to hopefully get the output (assuming we're lucky enough that it isn't something that only happens on a first-time build through the project!).
cc @metajack

+1 on -vv showing script output.
When running Travis CI I really dislike the idea of having to introduce another build failure(by committing a panic!("fail");) in order to see build script output.

:+1: on -vv or any other way.
Travis is killing my jobs because I'm building ffmpeg from the build.rs and it takes more than 10 minutes.

I just wasted a considerable chunk of my weekend trying to debug a build-script. And it was all because of this 'feature'.
The default way things work now is really terrible, especially for new users. When the script panics you get to see some stdout/stderr, which lead me to believe that stdout/stderr can be printed from the build-script. I spent the rest of my time trying to figure out why I can see it sometimes and other runs it seems to be missing. I thought cargo was linking in the old build script or something.
I agree with the other commenters here that this should be changed. Verbose should mean verbose.

:+1: on a flag of any kind to show build script output.

This has caused me tons of trouble. For a very long time, I thought my Travis CI builds were cross-compiling to x86, but they in fact weren't. The consequence was that the tests passed when actually my 32-bit builds were broken. I would have noticed this much sooner if the build script output had been in the Travis CI logs. When it comes ti CI, there should always be an option to show all the build script output.

@alexcrichton an alternative approach that might placate a lot of people here (including me): currently all build script output is effectively suppressed.  What if there were some prefix that one could include on a line of output from the build script that tells cargo: "Hey, you should report this line of output (minus the leading marker prefix) to the end user of cargo when you get the chance."
(I say "when you get the chance" because I don't particular care if the output is immediately streamed from the process or if one has to wait until the cargo run has finished.)
In my particular use case, there is one build script I have that has some internal safe-guards when it detects non-fatal oddities in the inputs it is processing.  I want the build script to have the option of emitting a warning in such cases without killing the build.

@pnkfelix that seems reasonable, yeah, although I'd still prefer that kind of output to not be emitted during a default cargo build (e.g. no verbose flags). Upstream dependencies and what they're doing in general shouldn't be cluttering up the build output, but path dependencies could potentially emit that kind of information.
For this issue I would personally prefer to tackle this as:

cargo build - stays the same as it is today
cargo build -v - same as today plus perhaps something like what @pnkfelix is thinking
cargo build -vv - same as -v plus streaming of all build scripts' output

I'd want to discuss a little more before having -v dump everything, but it's plausible still I think.

Could -v output just stderr?

I'd prefer the build script to be able to tell cargo "Just let me talk, okay?", which just makes cargo pass all output through (or maybe on a line-by-line basis, dropping all cargo: lines). This way, if I want to build LLVM or something equally large in my build script, I can do so without the user wondering what cargo is doing. Requiring the user to call cargo build -v isn't an option in this case, because the default will still be confusing. Or am I supposed to use a different build system for this use case?

@pornel I'd be amenable to something that distinguishes based on whether it's a "current crate" or not, that would help with not having to worry about upstream scripts producing way too much output.
I also personally think that a clean output on a normal cargo build is typically still what you want by default. As a developer you'll likely pass -v if you want but anyone who checks out the code is unlikely to want to be inundated with output.
@jonas-schievink yeah I agree that cases like building LLVM are pretty bad today. I'd be wary of an upstream script arbitrarily deciding to pollute my terminal with output, however. If that key were available to local scripts, however, it may work well? (local in this case means "path dependencies").
One thing I'd be wary of is that the only way I'd know of to implement streaming output is to have a thread reading a pipe and both recording the data and writing it back to stdout. Doing that on all invocations and/or doing it lazily (e.g. dynamically deciding whether the stdout path is taken) may be somewhat expensive. As I type this though I'm remembering that wait_with_output in libstd spawns threads to do this already, and it's not any problem with Cargo today, so it's probably not something to worry about.

I also personally think that a clean output on a normal cargo build is typically still what you want by default. As a developer you'll likely pass -v if you want but anyone who checks out the code is unlikely to want to be inundated with output.

My first instinct is that we would be better off having that be a convention but not something that is strictly enforced by cargo itself.

To elaborate: the main example of a place where I think non-fatal but non-hidden warnings would be relevant, at least for the current crate and its build script, is when you are doing code generation. (Two cases of this: tango and parser-generators. I think it is important for a code generator to have the option of telling the user "hey the input you just fed into me is technically acceptable, but has some questionable bits."

The main reason that I don't want this hidden behind a -v switch is that the end user may not even realize that they should be passing that switch when they are doing development on that particular crate.

However, maybe we can find a middle ground that both of us could accept: If the build script is also given some way to inspect whether -v was passed in to cargo, then I would be happy, because then I would:

If the -v is absent and the warning scenario crops up, the build script can fatally stop the build (and the error message printed would suggest passing the -v flag on a subsequent cargo invocation to learn why this happened).
If the -v is present and the warning scenario crops up, the build script can emit the warning but not terminate the build.

Then again, this "middle ground" opens the door to bugs where the build products generated by the  build script are predicated on whether -v was passed to cargo, which may be distasteful.
So which of those two paths sound worse to you, @alexcrichton ?

Ah yeah having -v affect the build output like that seems like it would be a little too surprising to me to stomach. I wonder, however, if we could have a scheme such as:

Add a new key, cargo:warning=foo to build script outpu
On normal builds, path dependencies will have warnings printed. This means that basically anything you're working on will have warnings. Note that the warnings are not streamed, however.
On cargo build -v, print warnings for all dependencies.
On cargo build -vv, stream output to the console for all build scripts.

It seems like that may solve the case of parser generators because you likely care about warnings if you're working on them? It would also solve the concurrent output scenario by default as warnings aren't streamed (but rather printed after the fact). It'd then also have a mode for streaming everything to keep up to date with output.

@alexcrichton
I assume by "path dependencies" you are including the current crate as well as things listed via http://doc.crates.io/guide.html#path-dependencies ?
I agree that would resolve my use case of generated source code, and sounds reasonable overall to me.

I might also say we might consider including "git dependencies" for lack of a better term, since those might be even more unstable than locally developed code.
The main point would be that once a crate has been published to crates.io itself, then cargo without -v won't report any cargo:warning=... messages from that crates build script when it is compiled as a dependency.

@pnkfelix ah yeah that's what I mean, we currently use the same metric for determining whether to pass --cap-lints. It's basically a heuristic for "code that you are locally working on".
I'd be a little hesitant to apply it to git dependencies as well because projects like Servo depend on a lot of git repositories, not all of which you're actively working on. It does seem like a possible extension, however!
I agree though that once something has been published I personally view it as important that we shouldn't be printing out tons of warnings that were left in by accident or something like that.

Any updates on this?

This would be really helpful for projects that mix Rust and native code, e.g. ispc-rs where you'd want to see warnings from the ispc compiler when running the build script since it will tell you about possible performance issues and so on.

I concur with @Twinklebear, would be very helpful when working with native code, especially when there's a long chain of crate dependencies. Would be nice to be able to temporarily suppress output muting, at least for simplifying debugging the build process.
Or maybe there could be markers to print things to stdout/stderr that cargo could pick up? Like
// build.rs

fn main() {
    println!("cargo:stderr = A very important warning");
}

I've talked with a few others and https://github.com/rust-lang/cargo/issues/1106#issuecomment-179360074 seems like the most plausible route for this. That being said, streaming output is very difficult to do unfortunately so it may take some time to implement.
I've got a work in progress branch but it'll take some time to flesh it out.

I've run into a subtle problem in under Window 7 64-bit which led me to search for dumping build script output and ended up here.  Building PistonDevelopers/piston-examples (52168ed) works and the next revision (d95e446) fails with a SDL2 linking problem.  The difference is that one of the many dependencies of the Piston stack has changed the linker search path, but it isn't the module that actually links to the SDL2 native library... so naturally I'd like to examine the build script output and figure out which dependency is involved and perhaps work up a reliable solution.
The ability to easily examine build script output will prove to be essential for this sort of problem.  An important property will be to output not only the build script output but to also clearly and unambiguously attribute it to a source; a big pile of output composed together with no indication of what came from where will only frustrate.

@alexcrichton Thanks, that will be great!
We're in the middle of another SM upgrade that has been horribly complicated by this, as it required a bunch of native deps and something somewhere has changed how it's pulling in / linking things, and debugging the native build scripts all across Servo is quite the pain since we don't have any way to generate & search it in a centralized fashion.


Who's using app-datepicker

Hey folks, may I include your amazing work under a section named Who's using app-datepicker that I'm going to add in the README?
Kindly leave your project name and URL (if you don't mind) and I'll include them.
Thank you.

I am using it in google app engine php project and also on google app script project.

@aneesshameed Is it a public project which can be accessible from the Internet? What's the project name and URL?

Opps, both are not public projects.

I have used it in Hey Taxi native android iOS & Android solution at:
https://codecanyon.net/item/hey-taxi-full-native-ios-solution-admin-dashboard/20790575
https://codecanyon.net/item/hey-taxi-full-native-android-solution-admin-dashboard/20052791.
but there seems it doesn't support polymer 2 well. because i have updated it and it doesn't shows neon-animated-pages part.


Unstoppable script with start-stop-daemon and chroot

openrc (OpenRC) 0.39 on Devuan testing.
I have a simple init file:
#!/sbin/openrc-run
pidfile=run/webd.pid
command=main
command_background=true
chroot=/srv
umask=037
start_stop_daemon_args='--chuid nobody:www-data'

When I stop the program, I run into this issue:
root@dev1:~# rc-service webapp start
 * Caching service dependencies ...                                                                                [ ok ]
 * Starting webapp ...                                                                                [ ok ]
root@dev1:~# rc-service webapp status
 * status: started
root@dev1:~# rc-service webapp stop
 * Stopping webapp ...
start-stop-daemon: unable to stat //main (No such file or directory)
 * Failed to stop webapp                                                                                [ !! ]
 * ERROR: webapp failed to stop

Hi,
Does it work if you specify the full path of the command? I came across a link:
https://askubuntu.com/questions/900603/getting-unable-to-stat-bundle-no-such-file-or-directory-even-though-the-fi

Since I’ve moved away from Devuan/OpenRC, I cannot test it right now.

Since I’ve moved away from Devuan/OpenRC, I cannot test it right now.

Gotcha, appreciate the response.


Integration with Token Action HUD

When trying to cast a spell from the stave using the Token Action HUD module, the error "Cannot cast X at n level. Not enough spell slots" is shown. Casting from the sheet itself works fine.
Is it possible to integrate the staves with the Token Action HUD? Is there work to be done on this side or by the developers of TAH?

Should work in version 1.1.2.


It would be really helpful if testing.T has assertion methods like t.AssertEqual(x, y), t.AssertNotEqual(x, y) etc?

I like to rely on standard packages whenever I can. But it seems like the testing package comes with go misses some useful features that current industry uses. One of them is result equality assertion
It would be really helpful if testing.T has assertion methods like t.AssertEqual(x, y), t.AssertNotEqual(x, y) etc
This will make the testing package more idiomatic and standard way to assert things rather than doing with if else boilerplate code all the time or having to rely on third party assertion packages.
Anyway, what I expressed in this issue is solely my own opinion. You may disagree. That's completely ok.

This is covered in the FAQ:
https://golang.org/doc/faq#testing_framework


⚠ Slack has degraded performance

In f0bc7c6, Slack (https://status.slack.com/api/v2.0.0/current) experienced degraded performance:

HTTP code: 200
Response time: 156 ms

Resolved: Slack performance has improved in 1dc3879 after 1 hour, 35 minutes.


sometimes I can't extract files to folder, the error percent is about 1%.

console.log(packageName);
await tar.x({file: filename, C: STATIC_ROOT, onwarn: (c, m, er) => {
        console.log(c);
        console.log(m);
        console.log(er);
      }});

the code like this,
response is:
packageName
EPERM: operation not permitted, chmod '/'
{ [Error: EPERM: operation not permitted, chmod '/']
  errno: -1,
  code: 'EPERM',
  syscall: 'chmod',
  path: '/' }
undefined

I can extract the files to the folder.
But sometimes the response is:
packageName

the files can't be extracted to the folder.
The happen percent is 1%

Maybe k8s reason, close it.


Notify Colin if game server is not responding to stats request

In most cases, this will be due to the game server crashing. This will allow for a quicker response to restart the server.

Resolved by 10c1fa5


Unzip alias

This is a simple method to Unzip a specified file to a given directory.

@Redth Looks good, I'll take a look later to day and merge if I don't find anything else.


[Scheduled] flutter pub upgrade --null-safety

Auto-generated by create-pull-request
See: https://github.com/peter-evans/create-pull-request/blob/master/docs/concepts-guidelines.md#triggering-further-workflow-runs

Codecov Report

Merging #36 (225bf05) into main (f64d156) will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff          @@
##            main     #36   +/-   ##
=====================================
  Coverage   0.00%   0.00%
=====================================
  Files          1       1
  Lines          4       4
=====================================
  Misses         4       4

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

bors merge


Test fails when executed from a generated project

Issue
Even if an etcd server is defined under the PATH of the user, then go test fails
$ export PATH=$PATH:./etcd-v3.3.10-darwin-amd64
$ etcd
2018-12-14 09:56:10.303882 I | etcdmain: etcd Version: 3.3.10
2018-12-14 09:56:10.303993 I | etcdmain: Git SHA: 27fc7e2
2018-12-14 09:56:10.303998 I | etcdmain: Go Version: go1.10.4
2018-12-14 09:56:10.304004 I | etcdmain: Go OS/Arch: darwin/amd64
2018-12-14 09:56:10.304009 I | etcdmain: setting maximum number of CPUs to 8, total number of available CPUs is 8
2018-12-14 09:56:10.304015 N | etcdmain: failed to detect default host (default host not supported on darwin_amd64)
2018-12-14 09:56:10.304022 W | etcdmain: no data-dir provided, using default data-dir ./default.etcd
2018-12-14 09:56:10.304108 N | etcdmain: the server is already initialized as member before, starting as etcd member...
2018-12-14 09:56:10.304481 I | embed: listening for peers on http://localhost:2380
2018-12-14 09:56:10.304642 I | embed: listening for client requests on localhost:2379
2018-12-14 09:56:10.305818 I | etcdserver: name = default
2018-12-14 09:56:10.305831 I | etcdserver: data dir = default.etcd
2018-12-14 09:56:10.305836 I | etcdserver: member dir = default.etcd/member
2018-12-14 09:56:10.305841 I | etcdserver: heartbeat = 100ms
2018-12-14 09:56:10.305845 I | etcdserver: election = 1000ms
2018-12-14 09:56:10.305849 I | etcdserver: snapshot count = 100000
2018-12-14 09:56:10.305861 I | etcdserver: advertise client URLs = http://localhost:2379
2018-12-14 09:56:10.319368 I | etcdserver: restarting member 8e9e05c52164694d in cluster cdf818194e3a8c32 at commit index 6
2018-12-14 09:56:10.319463 I | raft: 8e9e05c52164694d became follower at term 3
2018-12-14 09:56:10.319482 I | raft: newRaft 8e9e05c52164694d [peers: [], term: 3, commit: 6, applied: 0, lastindex: 6, lastterm: 3]
2018-12-14 09:56:10.321916 W | auth: simple token is not cryptographically signed
2018-12-14 09:56:10.322673 I | etcdserver: starting server... [version: 3.3.10, cluster version: to_be_decided]
2018-12-14 09:56:10.322788 E | etcdserver: cannot monitor file descriptor usage (cannot get FDUsage on darwin)
2018-12-14 09:56:10.323283 I | etcdserver/membership: added member 8e9e05c52164694d [http://localhost:2380] to cluster cdf818194e3a8c32
2018-12-14 09:56:10.323431 N | etcdserver/membership: set the initial cluster version to 3.3
2018-12-14 09:56:10.323494 I | etcdserver/api: enabled capabilities for version 3.3
2018-12-14 09:56:11.720234 I | raft: 8e9e05c52164694d is starting a new election at term 3
2018-12-14 09:56:11.720274 I | raft: 8e9e05c52164694d became candidate at term 4
2018-12-14 09:56:11.720299 I | raft: 8e9e05c52164694d received MsgVoteResp from 8e9e05c52164694d at term 4
2018-12-14 09:56:11.720320 I | raft: 8e9e05c52164694d became leader at term 4
2018-12-14 09:56:11.720337 I | raft: raft.node: 8e9e05c52164694d elected leader 8e9e05c52164694d at term 4
2018-12-14 09:56:11.720711 I | etcdserver: published {Name:default ClientURLs:[http://localhost:2379]} to cluster cdf818194e3a8c32
2018-12-14 09:56:11.720803 I | embed: ready to serve client requests
2018-12-14 09:56:11.722034 N | embed: serving insecure client requests on <IP_ADDRESS>:2379, this is strongly discouraged!
^C2018-12-14 09:56:11.745957 N | pkg/osutil: received interrupt signal, shutting down...
2018-12-14 09:56:11.746108 I | etcdserver: skipped leadership transfer for single member cluster

Error
go test ./pkg/...
?       github.com/cmoulliard/my-project/pkg    [no test files]
?       github.com/cmoulliard/my-project/pkg/apis       [no test files]
?       github.com/cmoulliard/my-project/pkg/apis/application   [no test files]
?       github.com/cmoulliard/my-project/pkg/apis/application/install   [no test files]
Running Suite: v1 Suite
=======================
Random Seed:<PHONE_NUMBER>
Will run 1 of 1 specs

[::]:52298
[::]:52299
[::]:52300
panic: exec: "etcd": executable file not found in $PATH

goroutine 88 [running]:
github.com/cmoulliard/my-project/vendor/github.com/kubernetes-incubator/apiserver-builder/pkg/test.(*TestEnvironment).startEtcd(0xc000589080, 0xc000048c00)
        /Users/dabou/Code/go-workspace/src/github.com/cmoulliard/my-project/vendor/github.com/kubernetes-incubator/apiserver-builder/pkg/test/server.go:167 +0x47b
created by github.com/cmoulliard/my-project/vendor/github.com/kubernetes-incubator/apiserver-builder/pkg/test.(*TestEnvironment).Start
        /Users/dabou/Code/go-workspace/src/github.com/cmoulliard/my-project/vendor/github.com/kubernetes-incubator/apiserver-builder/pkg/test/server.go:85 +0xb5
FAIL    github.com/cmoulliard/my-project/pkg/apis/application/v1alpha1  0.090s
?       github.com/cmoulliard/my-project/pkg/client/clientset_generated/clientset       [no test files]
?       github.com/cmoulliard/my-project/pkg/client/clientset_generated/clientset/fake  [no test files]
?       github.com/cmoulliard/my-project/pkg/client/clientset_generated/clientset/scheme        [no test files]
?       github.com/cmoulliard/my-project/pkg/client/clientset_generated/clientset/typed/application/v1alpha1    [no test files]
?       github.com/cmoulliard/my-project/pkg/client/clientset_generated/clientset/typed/application/v1alpha1/fake       [no test files]
?       github.com/cmoulliard/my-project/pkg/client/informers_generated/externalversions        [no test files]
?       github.com/cmoulliard/my-project/pkg/client/informers_generated/externalversions/application    [no test files]
?       github.com/cmoulliard/my-project/pkg/client/informers_generated/externalversions/application/v1alpha1   [no test files]
?       github.com/cmoulliard/my-project/pkg/client/informers_generated/externalversions/internalinterfaces     [no test files]
?       github.com/cmoulliard/my-project/pkg/client/listers_generated/application/v1alpha1      [no test files]
?       github.com/cmoulliard/my-project/pkg/controller [no test files]
Running Suite: Component Suite
==============================
Random Seed:<PHONE_NUMBER>
Will run 1 of 1 specs

[::]:52303
[::]:52304
[::]:52305
panic: exec: "etcd": executable file not found in $PATH

goroutine 84 [running]:
github.com/cmoulliard/my-project/vendor/github.com/kubernetes-incubator/apiserver-builder/pkg/test.(*TestEnvironment).startEtcd(0xc0000b74a0, 0xc0000b87e0)
        /Users/dabou/Code/go-workspace/src/github.com/cmoulliard/my-project/vendor/github.com/kubernetes-incubator/apiserver-builder/pkg/test/server.go:167 +0x47b
created by github.com/cmoulliard/my-project/vendor/github.com/kubernetes-incubator/apiserver-builder/pkg/test.(*TestEnvironment).Start
        /Users/dabou/Code/go-workspace/src/github.com/cmoulliard/my-project/vendor/github.com/kubernetes-incubator/apiserver-builder/pkg/test/server.go:85 +0xb5
FAIL    github.com/cmoulliard/my-project/pkg/controller/component       0.090s
?       github.com/cmoulliard/my-project/pkg/controller/sharedinformers [no test files]
?       github.com/cmoulliard/my-project/pkg/openapi    [no test files]

export PATH=$PATH:./etcd-v3.3.10-darwin-amd64
panic: exec: "etcd": executable file not found in $PATH

@cmoulliard please install etcd into ur system PATH (instead of bash context PATH) or export etcd to ur PATH again before running go test
closing since that i suppose this issue is resolved. feel free to reopen anytime.
/triage support
/close


Molecule 2 Fixes

Molecule 2 Fixes

These changes are not backwards compatible with anything older then Ansible <IP_ADDRESS>
I would recommend creating a release on your current master branch and call it 1.0.

That release version will still allow users to pull it from ansible-galaxy to use if they have older versions of Ansible.

Thank you! I missed for replacing volumes_mounts...
I'm going to tag backwards commits also, I tag v1.0 when I begin using role in production, but usually I don't tagging forked roles for avoid conflicts with upstream. In this case upstream not maintained.
Also thanks for yamllint and verbose testinfra, I supressed it for time saving when migrate to molecule v2, now I have true v2 role :)
I merged PR, going to fix some more (min. ansible version, testinfra inventory lookup).
In next days I will rewrite kapacitor tasks definition method (with backward compatibility), will notify you.

No problem. It was volumes_mounts as well as the command of /sbin/init needed to be passed.
For the yamlint i made a config to excluded the line length rule and the parsing of the molecule folder.
I am following this role now, so when you make your additional changes i will know. :)
Thanks

@mplachter, molecule posted example of using systemd containers - https://molecule.readthedocs.io/en/latest/examples.html#systemd-container , our method too redundantly in access grant, i'll try to follow docs in next fixes.

@popstas sounds good. I'll keep an eye out for your next push sir.


Insert failing with users_pkey unique validation (not passing any id - it is auto generated)

Environment

Elixir version (elixir -v): 1.2.2
Database and version (PostgreSQL 9.4, MongoDB 3.2, etc.): PostgresSQL 9.5.1
Ecto version (mix deps): 2.0.0-beta.2
Database adapter and version (mix deps): 0.11.1
Operating system: OS X 10.11.03 (El Captain)

Current behavior
Having inserted the feeds (I explicitly set the IDs in the feeds), when I try to insert a new user I get the following error:
Ecto.ConstraintError at POST /users
constraint error when attempting to insert struct:

    * unique: users_key

And checking the debug of the query there is no doubt that I am not passing the ID, so it should be auto generated, but it looks like it is trying to use an ID from a user I have already inserted.
[debug] INSERT INTO "users"
("inserted_at","updated_at","email","host_namespace","name","password_hash") VALUES
($1,$2,$3,$4,$5,$6) RETURNING "id"

But when I exclude the repo, and create it again (without running the seeds) it works as expected, and then when I reset the repo again with seeds, this error comes back.
PS: In my feeds, I am defining explicitly the ID to be set.
Expected behavior
I was expecting to insert users normally even when I seed my repo defining their IDs (after that using the auto increment normally)

Looking a little bit more at the problem, it had nothing to to with Ecto. It as actually a problem with Postgres.
It looks like when we insert some data setting the ID explicitly, Postgres does not keep a nice record of the currval('users_id_seq'), which defines the next value to insert when using auto increment.
This link explains the problem a little bit.
What I need to do to get this value back on track was to use setval() function to set it to the bigger ID in the repo, like the code below:
Ecto.Adapters.SQL.query(Repo, "SELECT setval('users_id_seq', (SELECT MAX(id) from \"users\"));", [])

Sorry for the inconvenience and thanks for the job. Phoenix, Ecto and Elixir are awesome!


test: remove flaky color e2e tests

locator.fill() is not stable. Out of 10 tests, there are always 3 or 4 times of failed text inputs.
Removed flaky e2e tests from color-scheme tests until there is a more reliable way of adding the color setting through UI.
What changes are proposed in this pull request?
(Please fill in changes proposed in this fix)
How is this patch tested? If it is not, please explain why.
(Details)
Release Notes
Is this a user-facing change that should be mentioned in the release notes?

[x] No. You can skip the rest of this section.
[ ] Yes. Give a description of this change to be included in the release
notes for FiftyOne users.

(Details in 1-2 sentences. You can just refer to another PR with a description
if this PR is part of a larger change.)
What areas of FiftyOne does this PR affect?

[x] App: FiftyOne application changes
[ ] Build: Build and test infrastructure changes
[ ] Core: Core fiftyone Python library changes
[ ] Documentation: FiftyOne documentation changes
[ ] Other

@lanzhenw can you rebase onto release/v0.23.3? I will sync develop afterward


Consider inserting fillers between lines in manifest files

We have a large monorepo that uses manifests. The manifest file is of course a JSON file that includes a line for each package, that is updated whenever a new version of the package is released. We frequently release multiple packages in succession (in separate PRs). If two of those packages are adjacent in the manifest file, this causes git conflicts since the PRs independently try to modify adjacent lines in the same file.
Our current workaround has been to insert filler lines in our manifest file, in the form of a "fake" package following each real package, to separate out the real packages and ensure that no two occupy adjacent lines in the file. This seems to be working for us for now, but maybe we can consider building a solution into the tool itself.

Thanks for the nice workaround! "separate-pull-requests": true is a really nice feature. Instead of having to require a filler line, if release-please could rebase / merge latest upstream changes to the existing PR that would be awesome.

Got a workaround working without needing to insert filler lines. See https://github.com/googleapis/release-please/issues/1870#issuecomment-1748390833


Legends not working?

visualkeras.layered_view(model, to_file='output.png', legend=True).show()
TypeError: layered_view() got an unexpected keyword argument 'legend'
Not sure what's going on here, everything seems to work but legends=True persists with that error message, any ideas?

Hi @GentianGashi,
please use the issue template to create new issues. Anyway, I guess you have installed visualkeras from pypi? Legends are currently only supported on the master branch. Simply install via git: pip install git+https://github.com/paulgavrikov/visualkeras --upgrade

Ah uninstalling the pypi version and installing the updated github version seems to have fixed it, cheers!


Reading/Writing GeoParquet and GeoParquet schema

Hi Dewey,
Thanks for all of your work on this package. We are really stoked to start using it! I was wondering if the package currently has the ability to read/write GeoParquet format. I have been able to read/write parquet files with a geometry from arrow/geoarrow, but on read it seems to ignore the geoparquet metadata, and it doesn't write it when passed to arrow::write_parquet(). Is this the expected behavior and will the GeoParquet spec expected to be supported at some point? This is a feature we are very interested in, and I am very happy to help contribute in any way I can. Please reach out if I can help in anyway. Thanks again for making this package - It is something we've been hoping for for a while!
Cheers,
Brayden

Thanks so much for your hard work here! Has there been any progress on this? Our data stack requires specifically GeoParquet, and would love to use your package, but at the moment the files geoarrow produces seem to be parquet-storing-geography-as-a-record.


Simplify the new sync API

/cc @zshipko and @dinosaure (for Canopy)
not more Sync.remote and now Store.remote is working (so this fixes #547) and the API is as simple as before: every store where it is possible to use a special remote has a remote function with the right type.

Improve #545

Here's what I was able to do with irmin-graphql:
https://github.com/zshipko/irmin-graphql/blob/master/bin/main.ml#L6
https://github.com/zshipko/irmin-graphql/blob/master/src/irmin_graphql.ml#L35
It's still not 100% ideal, but seems workable! This implementation is a definite improvement over Irmin.remote_uri because now I am able to check for the presence of a valid remote function (see main.ml above)  rather than just having it fail during runtime.
It seems like I may just want to limit irmin-graphql (and other servers) to git-based stores, but I will need to think about that a bit.

It seems like I may just want to limit irmin-graphql (and other servers) to git-based stores, but I will need to think about that a bit.

The current constraint seems to be that the remote function takes cohttp headers + an uri, which I think is fine. But maybe I don't read the right things :-)


My telegram doesn't receive messages from my bot, but my messages show as read

I can't get messages from bots. I can see the robot in the log, went to query GPT, and returned the result, but I can’t receive it in telegram
Similarly, I also tested the official robot of RASAGPT, but I can't get the message, but I can see that my message has been read.
2023-05-11 10:28:48 chat_api               | DEBUG:urllib3.connectionpool:http://rasa-core:5005 "POST /webhooks/telegram/webhook HTTP/1.1" 200 7
2023-05-11 10:28:48 chat_api               | http://rasa-core:5005 "POST /webhooks/telegram/webhook HTTP/1.1" 200 7
2023-05-11 10:28:48 chat_api               | DEBUG:config:[🤖 RasaGPT API webhook]
2023-05-11 10:28:48 chat_api               | Posting data: {"update_id": "398224788", "message": {"message_id": 29, "from": {"id":<PHONE_NUMBER>, "is_bot": false, "first_name": "Link", "last_name": "H", "username": "KaisenseH", "language_code": "zh-hans"}, "chat": {"id":<PHONE_NUMBER>, "first_name": "Link", "last_name": "H", "username": "KaisenseH", "type": "private"}, "date":<PHONE_NUMBER>, "text": "hello", "meta": {"response": "Hello! How may I assist you today?", "tags": ["greeting"], "is_escalate": false, "session_id": "93739abf-ef28-444f-a145-10d66bb38d2a"}}}
2023-05-11 10:28:48 chat_api               |
2023-05-11 10:28:48 chat_api               | [🤖 RasaGPT API webhook]
2023-05-11 10:28:48 chat_api               | Rasa webhook response: success

Tested again, it was my problem, sorry


pkg/metrics: fix data race warning on metrics init hook.

pkg/metrics: fix data race warning on metrics init hook.
This was added to allow for flushing logging metrics that may
have been accumulated at init time (i.e. prior to hive) before
the metrics infra being set up in Hive.
The unlocked access of writing nil to the channel after init is
complete is causing warnings wrt Gos race detector, so adding a lock
is a easy way to clean this up.
Fixes: https://github.com/cilium/cilium/issues/33812

/test

/test


Changed return type of getMaxDuration in PerformAudioPassThru class

Fixes #80.  Changed return type of getMaxDuration from int to Integer.
Signed-off-by: Mike Burke<EMAIL_ADDRESS>

Marking for 3-day offline review.  Anticipated merge date is 1/31/2015 at 3pm.


Update README.md

Codecov Report

Merging #13 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #13   +/-   ##
=======================================
  Coverage   79.16%   79.16%
=======================================
  Files           5        5
  Lines          48       48
  Branches        4        4
=======================================
  Hits           38       38
  Misses         10       10

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 54f803b...fd93851. Read the comment docs.


How to use it with the BM/** case?

Hi @chinarulezzz
Thank you for this code. But is it possible to execute the payload just by clicking the photo? Without adding .html on the end if possible...
Not sure if I understood this use case, but is it automatic that the server will just eliminate the image data and use script?
https://devcondetect.com/blog/2019/2/24/hacking-group-using-polyglot-images-to-hide-malvertsing-attacks
<img src="polyglot.jpg"/> will show the user an image and ignore the JavaScript

<script src="polyglot.jpg"></script> will execute valid JavaScript and ignore the image data.

And can I insert both lines into the html source?
Thanks.

irrelevant to the pixload, sorry.


Help to makefile

How can I save the changes in makefile .I want to make my custom bin file for myself.

Depends on what you mean, the direct answer is you open the Makefile file, you make modifications, and you save it (possibly CTRL+S). Then you compile the software, voilà.
To actually save the changes you create a branch on the local repository and merge changes from time to time.

A lot of thanks


M1 tests failed with failed to resolve flutter_internal/android/sdk/mac-arm64@version:29.0

Following https://github.com/flutter/flutter/issues/87508#issuecomment-947884979, we are adding new M1 arm64 tests to staging for validation: https://flutter-review.googlesource.com/c/infra/+/26927
Some of the tests need android sdk, however we do not have the arm64 version in the cipd packages.
CIPD('ensure_installed') failed with: failed to resolve flutter_internal/android/sdk/mac-arm64@version:29.0 (line 1): no such package: flutter_internal/android/sdk/mac-arm64

Example build: https://ci.chromium.org/ui/p/flutter/builders/staging/Mac_arm64_staging build_aar_module_test/6/overview
/cc @jmagman @zanderso @godofredoc

@blasten Is this something android team will help create, the cipd package? This is blocking the tests migration to M1 hosts.

@blasten Is this something android team will help create, the cipd package? This is blocking the tests migration to M1 hosts.

Nvm, assigning. to myself for an ARM version creation.

@keyonghan in the meantime you could remove android_sdk and open_jdk and leave off build_aar_module_test from the M1 tests (the rest are iOS or macOS) https://flutter-review.googlesource.com/c/infra/+/27060.
Obviously we'd like to test building Android on M1 but it may not be worth blocking test coverage of native macOS desktop https://github.com/flutter/flutter/issues/60118.  Up to you though.

https://flutter-review.googlesource.com/c/infra/+/27061 to unblock the migration.

Thanks @GaryQian for uploading the arm64 version, and it passed the dependency step! But seems we has some failure, maybe related to some packages in this version?
build: https://luci-milo.appspot.com/raw/build/logs.chromium.org/flutter/led/keyonghan_google.com/96fd7247e50ce3d92fad4cce8a7e881c986b12aafe2299687461f215bf87dc1d/+/build.proto
[build_aar_module_test] [STDOUT] stdout: [  +10 ms] Generating /opt/s/w/ir/x/t/flutter_module_test.IsMrE8/hello/.android/Flutter/src/main/java/io/flutter/plugins/GeneratedPluginRegistrant.java
[build_aar_module_test] [STDOUT] stdout: [  +16 ms] 💪 Building with sound null safety 💪
[build_aar_module_test] [STDOUT] stdout: [   +2 ms] Running Gradle task 'assembleAarDebug'...
[build_aar_module_test] [STDOUT] stdout: [   +1 ms] Using gradle from /opt/s/w/ir/x/t/flutter_module_test.IsMrE8/hello/.android/gradlew.
[build_aar_module_test] [STDOUT] stdout: [  +30 ms] executing: [/opt/s/w/ir/x/t/flutter_module_test.IsMrE8/hello/.android/] /opt/s/w/ir/x/t/flutter_module_test.IsMrE8/hello/.android/gradlew -I=/opt/s/w/ir/x/w/recipe_cleanup/tmp3mfu9y46/flutter sdk/packages/flutter_tools/gradle/aar_init_script.gradle -Pflutter-root=/opt/s/w/ir/x/w/recipe_cleanup/tmp3mfu9y46/flutter sdk -Poutput-dir=/opt/s/w/ir/x/t/flutter_module_test.IsMrE8/hello/build/host -Pis-plugin=false -PbuildNumber=1.0 -Pverbose=true -Ptarget=lib/main.dart -Pdart-obfuscation=false -Ptrack-widget-creation=true -Ptree-shake-icons=false -Ptarget-platform=android-arm,android-arm64,android-x64 assembleAarDebug
[build_aar_module_test] [STDOUT] stdout: [  +72 ms] The operation couldn’t be completed. Unable to locate a Java Runtime.
[build_aar_module_test] [STDOUT] stdout:            Please visit http://www.java.com/ for information on installing Java.
[build_aar_module_test] [STDOUT] stdout: [        ] Running Gradle task 'assembleAarDebug'... (completed in 103ms)
[build_aar_module_test] [STDOUT] stderr: [        ] The operation couldn’t be completed. Unable to locate a Java Runtime.
[build_aar_module_test] [STDOUT] stderr:            Please visit http://www.java.com/ for information on installing Java.
[build_aar_module_test] [STDOUT] stderr:
[build_aar_module_test] [STDOUT] stderr:
[build_aar_module_test] [STDOUT] stdout: [   +1 ms] "flutter aar" took 480ms.
[build_aar_module_test] [STDOUT] stderr: [   +1 ms] Gradle task assembleAarDebug failed with exit code 1.
[build_aar_module_test] [STDOUT] stderr: [        ]
[build_aar_module_test] [STDOUT] stderr:            #0      throwToolExit (package:flutter_tools/src/base/common.dart:10:3)
[build_aar_module_test] [STDOUT] stderr:            #1      AndroidGradleBuilder.buildGradleAar (package:flutter_tools/src/android/gradle.dart:670:7)
[build_aar_module_test] [STDOUT] stderr:            <asynchronous suspension>
[build_aar_module_test] [STDOUT] stderr:            #2      AndroidGradleBuilder.buildAar (package:flutter_tools/src/android/gradle.dart:156:7)
[build_aar_module_test] [STDOUT] stderr:            <asynchronous suspension>
[build_aar_module_test] [STDOUT] stderr:            #3      BuildAarCommand.runCommand (package:flutter_tools/src/commands/build_aar.dart:141:5)
[build_aar_module_test] [STDOUT] stderr:            <asynchronous suspension>
[build_aar_module_test] [STDOUT] stderr:            #4      FlutterCommand.run.<anonymous closure> (package:flutter_tools/src/runner/flutter_command.dart:1165:27)
[build_aar_module_test] [STDOUT] stderr:            <asynchronous suspension>
[build_aar_module_test] [STDOUT] stderr:            #5      AppContext.run.<anonymous closure> (package:flutter_tools/src/base/context.dart:150:19)

Seems we are still missing openjdk package (thanks @GaryQian for pointing this out). We need a mac-arm64 version as well.

Tried a couple of things, but still no luck.

use same mac-amd64 version (simply changed config to mac-arm64), hit (build)

/opt/s/w/ir/x/t/flutter_module_test.whMHhq/hello/.android/gradlew: line 160: /opt/s/w/ir/cache/java/contents/Home/bin/java: Bad CPU type in executable

use latest  java17 (arm64), hit (build)

 FAILURE: Build failed with an exception.
[build_aar_module_test] [STDOUT] stdout:
[build_aar_module_test] [STDOUT] stdout:            * Where:
[build_aar_module_test] [STDOUT] stdout:            Settings file '/opt/s/w/ir/x/t/flutter_module_test.hSfWTX/hello/.android/settings.gradle' line: 6
[build_aar_module_test] [STDOUT] stdout:
[build_aar_module_test] [STDOUT] stdout:            * What went wrong:
[build_aar_module_test] [STDOUT] stdout:            A problem occurred evaluating settings 'android_generated'.
[build_aar_module_test] [STDOUT] stdout:            > BUG! exception in phase 'semantic analysis' in source unit '/opt/s/w/ir/x/t/flutter_module_test.hSfWTX/hello/.android/include_flutter.groovy' Unsupported class file major version 61
[build_aar_module_test] [STDOUT] stdout:

Based on https://stackoverflow.com/questions/68597899/bug-exception-in-phase-semantic-analysis-in-source-unit-buildscript-unsup, seems the latest version is not supported yet.

use java11 (arm64) from Azul (oracle doesn't have an arm64 version for java11), hit (build)

Target android_aot_profile_android-arm failed: ProcessException: Bad CPU type in executable

@blasten @GaryQian Do you have any insight re the above error in bullet 3?

Finally this test passes: https://ci.chromium.org/raw/build/logs.chromium.org/flutter/led/keyonghan_google.com/50a793f7f11c255679028d9c9d658c9b397a444ae1d88c40c41083689b4d9921/+/build.proto?server=chromium-swarm.appspot.com.
Enabling in staging mac/android: https://flutter-review.googlesource.com/c/infra/+/29121


docs: Add a guide on how to document REST API endpoints.

@timabbott, @YagoGG: FYI :)

@YagoGG @brickbite I'd love it if you two can give it a review.  @YagoGG as someone who's worked on this system, and @brickbite as someone who hasn't :)

(For @brickbite, you can build it as ReadTheDocs would using tools/build-docs and access it at <IP_ADDRESS>:9991/docs)

@YagoGG got it up, that was right. thanks!
@eeshangarg
Might be good to include a link to show where contributions will end up (https://zulipchat.com/api). I hadn't gone through it before, and had to poke around to find it

On the content overall: the process of going about this seems clear, with mentions of specific files to make edits to and where to get examples. I can also get an idea of how things are connected by reading it, so that's good!

@YagoGG, @brickbite: Thank you so much for your feedback! I addressed all of your points! Please let me know if there is anything else you'd like me to change! :)
@timabbott: FYI :)

Great, merged, after adding a few more changes in ce4f00bd8402359708bf1dcdbf1cb3cc95274d7e (the main thing being that I think the right flow is for them to write the test with a print statement, and get the fixture that way).  A few things that this makes me notice we could improve:

We could get rid of the step to add things to the test_ functions, which feels janky (and instead just call all the functions in the TEST_FUNCTIONS dict)
We could eventually get rid of the TEST_FUNCTIONS dict step too, by just making these methods on a test class.
If we wanted to really get fancy, I could imagine a flag that makes the test_against_fixture function auto-output the JSON fixtures for you if the fixture doesn't exist and/or even add it to the output, replacing the manual-feeling copy/paste flow.  May be more work than it's worth, though.
It'd be super cool if we had a test that would compare the REQ arguments against the tests.  I think it might be possible to do this sort of check by some convoluted path involving (1) patching has_request_variables to store post_params as an attribute on the view function (2) having a mapping to find the view function, ideally just doing a lookup using urls.py so it's automated and (3) comparing the list of post_params to the documented arguments list.

@YagoGG FYI for this idea.


⚠ Bofrost.lu has degraded performance

In f758db0, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1159 ms

Resolved: Bofrost.lu performance has improved in 8166ed7 after 15 minutes.


Install mode

Problem:

Support ability to install harvester to a machine without configuring the node.
Solution:

PR introduces a new install mode, which allows users to install the harvester binaries to disk, without configuring the k8s components.
This allows users to install harvester and ship devices to remote location for configuration on first boot.
In addition, the PR also introduces generation of a pre-installed qcow2 image which can be later used with the new install mode and automatic installation to stream disk to image, there by improving provisioning times in public cloud providers like equinix metal.
In automatic install mode, if a config_url is provided, then the same is also written to disk, and node will auto configure on the first boot, ensuring faster provisioning.
Related Issue:
https://github.com/harvester/harvester/issues/2198
Test plan:

is there a test artifact for the qcow2 image?

we dont have one yet, however i can make a custom image available for you.

I wouldn't say no, but only if it is just a minor effort.

This functionality would be very useful when deploying on a bare-metal server in a datacenter (eg. Hetzner).
Any idea when this functionality will be released?

Hi @ibrokethecloud Do you have a sample configuration file for PXE boot (install mode) ? https://docs.harvesterhci.io/v1.1/install/pxe-boot-install#preparing-ipxe-boot-scripts

easiest way to test stream mode is via libvirt.

choose direct kernel boot:

specify the kernel and initrd files

please use the following kernel arguments:

ip=dhcp net.ifnames=1 rd.cos.disable rd.noverifyssl root=live:http://<IP_ADDRESS>:8000/harvester-d814995-dirty-rootfs-amd64.squashfs harvester.install.automatic=true harvester.scheme_version=1 harvester.install.device=/dev/vda  harvester.os.password=password harvester.install.raw_disk_image_path=http://<IP_ADDRESS>:8000/harvester-d814995-dirty-amd64.raw harvester.install.mode=install console=tty1 harvester.install.tty=tty1 harvester.install.config_url=http://endpoint:8000/userdata.yaml harvester.install.management_interface.interfaces="name:enp1s0" harvester.install.management_interface.method=dhcp harvester.install.management_interface.bond_options.mode=balance-tlb harvester.install.management_interface.bond_options.miimon=100 harvester.install.power_off=true

change config_url to point to a valid location: harvester.install.config_url=http://endpoint:8000/userdata.yaml
change  root to valid endpoint for squashfs
change harvester.install.raw_disk_image_path to valid location of raw image file

the userdata will be as follows:
#cloud-config
scheme_version: 1
token: token           # replace with a desired token
os:
  password: p@ssword   # replace with a your password
  ntp_servers:
  - 0.suse.pool.ntp.org
  - 1.suse.pool.ntp.org
install:
  mode: create
  automatic: true
  vip_mode: dhcp

once the image is streamed, the VM will power off, please disable direct kernel boot and harvester should boot normally.

rebased changes from master.

last commit uses zstd to compress raw image, which brings down the file size to around 20G.
stream-disk now decompresses the image, which has manage to bring down complete install time to around 14mins.

@mergify backport v1.2


List artist his own shows, query sort by release date.

Sorting not happened yet, but at least the artists can see their own shows


Error: Unable to import module 'handler': No module named 'botocore.docs'

Context
Deploying Flask app Python 3.6, and getting this error.

Expected Behavior

The successful deployment of the app
Actual Behavior

Throwing the following error.
Unable to import module 'handler': No module named 'botocore.docs'
Your Environment

Zappa version used: 0.47.1
Operating System and Python version: Ubuntu 18.04 LTS, Python 3.6
The output of pip freeze:

alembic==1.0.5
aniso8601==4.0.1
argcomplete==1.9.3
asn1crypto==0.24.0
Authlib==0.10
boto3==1.9.75
botocore==1.12.75
certifi==2018.11.29
cffi==1.11.5
cfn-flip==1.1.0.post1
chardet==3.0.4
Click==7.0
cryptography==2.4.2
docutils==0.14
durationpy==0.5
Flask==1.0.2
Flask-Cors==3.0.7
flask-marshmallow==0.9.0
Flask-Migrate==2.3.1
Flask-RESTful==0.3.7
Flask-SQLAlchemy==2.3.2
Flask-WTF==0.14.2
future==0.16.0
gevent==1.4.0
greenlet==0.4.15
gunicorn==19.9.0
hjson==3.0.1
idna==2.8
itsdangerous==1.1.0
Jinja2==2.10
jmespath==0.9.3
jwcrypto==0.6.0
kappa==0.6.0
lambda-packages==0.20.0
Mako==1.0.7
MarkupSafe==1.1.0
marshmallow==2.17.0
marshmallow-sqlalchemy==0.15.0
placebo==0.8.2
psycopg2==<IP_ADDRESS>
pycparser==2.19
PyMySQL==0.9.3
python-dateutil==2.6.1
python-dotenv==0.10.1
python-editor==1.0.3
python-jwt==3.2.4
python-slugify==1.2.4
pytz==2018.9
PyYAML==3.13
requests==2.21.0
s3transfer==0.1.13
six==1.12.0
SQLAlchemy==1.2.15
toml==0.10.0
tqdm==4.19.1
troposphere==2.4.0
Unidecode==1.0.23
urllib3==1.24.1
Werkzeug==0.14.1
wsgi-request-logger==0.4.6
WTForms==2.2.1
zappa==0.47.1

Your zappa_settings.py:

{
  "dev": {
    "app_function": "app.app",
    "aws_region": "us-east-1",
    "profile_name": "default",
    "project_name": "pahm-auth",
    "runtime": "python3.6",
    "s3_bucket": "zappa-y15ujoow7",
    "exclude": [
      "*.egg-info",
      "*.eggs",
      ".coverage",
      "*.env",
      "*.db",
      "*.tox",
      ".pytest_cache",
      ".idea",
      ".github",
      "tox",
      "dist",
      "build",
      "docs",
      "scripts",
      "htmlcov",
      "node_modules"
    ]
  },
  "dev_ap_northeast_1": {
    "aws_region": "ap-northeast-1",
    "extends": "dev"
  },
  "dev_ap_northeast_2": {
    "aws_region": "ap-northeast-2",
    "extends": "dev"
  },
  "dev_ap_northeast_3": {
    "aws_region": "ap-northeast-3",
    "extends": "dev"
  },
  "dev_ap_south_1": {
    "aws_region": "ap-south-1",
    "extends": "dev"
  },
  "dev_ap_southeast_1": {
    "aws_region": "ap-southeast-1",
    "extends": "dev"
  },
  "dev_ap_southeast_2": {
    "aws_region": "ap-southeast-2",
    "extends": "dev"
  },
  "dev_ca_central_1": {
    "aws_region": "ca-central-1",
    "extends": "dev"
  },
  "dev_cn_north_1": {
    "aws_region": "cn-north-1",
    "extends": "dev"
  },
  "dev_cn_northwest_1": {
    "aws_region": "cn-northwest-1",
    "extends": "dev"
  },
  "dev_eu_central_1": {
    "aws_region": "eu-central-1",
    "extends": "dev"
  },
  "dev_eu_west_1": {
    "aws_region": "eu-west-1",
    "extends": "dev"
  },
  "dev_eu_west_2": {
    "aws_region": "eu-west-2",
    "extends": "dev"
  },
  "dev_eu_west_3": {
    "aws_region": "eu-west-3",
    "extends": "dev"
  },
  "dev_sa_east_1": {
    "aws_region": "sa-east-1",
    "extends": "dev"
  },
  "dev_us_east_2": {
    "aws_region": "us-east-2",
    "extends": "dev"
  },
  "dev_us_west_1": {
    "aws_region": "us-west-1",
    "extends": "dev"
  },
  "dev_us_west_2": {
    "aws_region": "us-west-2",
    "extends": "dev"
  }
}

hi @git-albertomarin,
You've excluded docs module from botocore by excluding docs directory in zappa config.
This is the way shutils.copytree works with exlusions....
"exclude": [
      "*.egg-info",
      "*.eggs",
      ".coverage",
      "*.env",
      "*.db",
      "*.tox",
      ".pytest_cache",
      ".idea",
      ".github",
      "tox",
      "dist",
      "build",
      "docs",  // <---- the problem is here
      "scripts",
      "htmlcov",
      "node_modules"
    ]
```json

@M0dM
Thanks for the answer! I had given up on this, I'll give it another try.


Android RAM <= 2.0 GB Throws Error

Thanks for the library. Had issues with users in production that have RAM <= 2.0GB.
After getting hold of an Android phone with 2.0GB RAM, I debugged the issue.
I learnt that the methods from the mmkv library produce the following error:
"Wrong password or storage corrupt"
Is there a requirement that I missed? Can this library accommodate users with RAM <= 2.0GB?
Cheers!

@wegory What version of the library are you using in production?

@wegory What version of the library are you using in production?

I'm using lib 0.3.7.
From the reviews on Play Store, I can say that at least 5 users had the issue. Some of them had Android 10. They had RAM <= 2.0GB.
The device that I tested was Android 7.

I'm using lib 0.3.7.
From the reviews on Play Store, I can say that at least 5 users had the issue. Some of them had Android 10. They had RAM <= 2.0GB.
The device that I tested was Android 7.

The current latest version of the lib is 0.4.2. You should test using the latest version and see if the error is there.

The current latest version of the lib is 0.4.2. You should test using the latest version and see if the error is there.

Will do. Thanks. Are there any breaking changes? Couldn't find the changelog.

Will do. Thanks. Are there any breaking changes? Couldn't find the changelog.

@wegory you can find the release notes here: https://github.com/ammarahm-ed/react-native-mmkv-storage/releases
Curious what you find! I'm just starting to investigate mmkv for my app as well

@wegory you can find the release notes here: https://github.com/ammarahm-ed/react-native-mmkv-storage/releases
Curious what you find! I'm just starting to investigate mmkv for my app as well


onProgress stops getting called if playing is set to false

I want to start playing the video (a local .mp4) when the loading state reaches a certain level, let's say 0.5.
However, when the playing parameter is set to false, onProgress only get's called initially, and then stops getting called. Am I misunderstanding the concept of onProgress? Shouldn't the video continue being loaded, even if the media isn't playing? I can see in the demo that when the video is paused, loading doesn't take place. Is there any way to achieve what I want then, or is it a browser specific thing?

It's true that onProgress stops being called when playing is false. However, it's also true that onProgress is not called when the played or loaded amounts do not change. It is up to the browser how much of a file they load as they play, and even though preload is set to auto in the HTML element, modern browsers are very good at only downloading what they need to play.
If you are attempting to wait until the browser can play the entire media, there is a canplaythrough event that we could perhaps add a prop for, but I'm not sure how consistently this event is fired across different browsers.

Thanks, that's more or less what I figured was going on.
I'm not sure about canplaythrough. A quick search says that it should be a more or less reliable event across browsers, although when they fire it seems to be a bit inconsistent. It's up to you if that's a prop you'd like to add. I know i'd like to try it!

Hi @CookPete
would you be able to make that canplaythrough optional somehow? (ie we can choose to listen for it or not.... in fact all of those events really).
That event was absolutely critical for a (non-react) video I did for a banner, in order to load enough for the video to (attempt to) play through without buffering. Tested on throttled connection in chrome and it worked great. So having access to it would be very useful.
regards
J

@jmp909 This is actually already possible by passing attributes into the fileConfig prop, like so:
<ReactPlayer
  url={file.mp3}
  playing
  fileConfig={{
    attributes: {
      onCanPlayThrough: () => console.log('Now I can play it through')
    }
  }}
/>

In fact, any other media event is supported in this way, with the on prefix and camelcased to keep React happy.

Is there any way to track how much the video has loaded while it is paused?
onBuffer gets triggered, but I can't find a way to get the exact buffer value while not progressing!

@belohlavek The onProgress event doesn't fire whilst paused due to this commit which was an attempt to fix this issue. There is probably a better solution that allows loaded amounts to still be reported whilst paused, so I'll look into it.
It may even be worth splitting onProgress into onPlayedProgress and onLoadedProgress or something to keep things cleaner. Maybe something for v1.0.

@CookPete onProgress is not being called every progressFrequency milliseconds in my app, it's only being called once after what seems to progressFrequency milliseconds. Are you sure that this shouldn't be
_this.progressTimeout = setInterval(_this.progress, _this.props.progressFrequency);
instead of
_this.progressTimeout = setTimeout(_this.progress, _this.props.progressFrequency);?

Hey @priyathamkat yeah there seems to be a bug in the most recent version which I will look into. Good spot.
It doesn't need to be setInterval because setTimeout is being repeatedly set every time this.progress is called, which is a better technique for various reasons.


Carto providing Overture in BigQuery

Hi - I know you've been working to get Overture data into BigQuery. Carto just announced today that Overture data is available as a public data project and they are helping with ingestion: https://carto.com/blog/overture-maps-data-now-on-the-cloud-use-it-with-carto
Not sure if/how this affects your work here but wanted to point it out.

I did see that. The more the merrier, the Carto team is awesome, and everyone should probably use their platform. For people who want to DIY their own load, this will still be here.


Initial version without the wanted partitioning

@varkoly no updates since @jreidinger reviewed it. Closing by it by now but feel free to reopen it if needed.


No tab completion on macOS when installed from brew

I am under the assumption that the az CLI should have tab-completion, at least for the top-level commands such az group and such.  For me, there is no tab completion.
When I searched online some people mentioned having to source a certain tab completion in their .bash_profile, but nothing in the installation instructions mentions this.
So I'm not sure if there is something broken or if there is a step I am missing.  Any help would be appreciated.
Thanks.
Environment summary
macOS 10.13.3
Installed from brew using instructions here:
https://docs.microsoft.com/en-us/cli/azure/install-azure-cli?view=azure-cli-latest
Shell Type:  iTerm2 3.1.5 with bash

This helped me too, thanks.

At the end of the brew install, it should say this:
==> Caveats
Bash completion has been installed to:
  /usr/local/etc/bash_completion.d
==> Summary
🍺  /usr/local/Cellar/azure-cli/2.0.25: 8,504 files, 47.0MB

Then, to enable completion, you can source that file with:
source /usr/local/etc/bash_completion.d/az

To make your terminal always load that file, you can add it to your ~/.bash_profile

Maybe it should... but it does not. Any way we could force it?

Same here, just installed azure-cli and no completions are installed, have they been removed?


enhancement/successful deployment

When I run the prompt "Is NOPD's use of facial recognition technology effective?" on local I receive the following response: "Answer: Based on the provided transcripts, it seems that the effectiveness of NOPD's use of facial recognition technology is still uncertain. The speaker mentions that there were only six requests for facial recognition in the fourth quarter of 2022, and of those six requests, there were only three matches. Additionally, one of those matches was incorrect, which NOPD was able to identify. As of the data produced and sent, there were no arrests resulting from the matches. The speaker also notes that the low number of requests for facial recognition is reasonable, as the technology is only used in cases of violent crimes and as a last resort. Many criminals in the city are easily identifiable without the use of facial recognition, as they commit crimes in front of cameras or witnesses. Therefore, it is expected that the number of requests and matches would be low. However, the speaker does express some concerns about the potential for police abuse of the technology. Despite the safeguards in place to ensure compliance with the law and constitutional requirements, the speaker acknowledges that there is always a risk of unauthorized pursuits or other abuses of power. Overall, based on the limited information provided in the transcripts, it is unclear whether NOPD's use of facial recognition technology is effective. While the low number of requests and matches may suggest that the technology is not being used extensively, it is also possible that it is simply being used in a targeted and strategic manner. Without additional information, it is difficult to make a definitive assessment of the technology's effectiveness."
The vercel preview doesn't seem to be pulling from all of the transcripts. I assume that this behavior is expected.
The query to response timeframe is quick on local. Curious as to how it changes when pushed.


Update Composer dependencies (2022-03-02-00-03)

Visual regression test passed!
View the visual regression test report


Do not set system look and feel if using GTK.

There is a longstanding bug with the OptionPane icons when in Linux, specifically related to attempting to get them while having the look and feel set to GTK. See: https://community.oracle.com/tech/developers/discussion/1359028/uimanager-geticon-optionpane-warningicon-on-linux.
This results in a null pointer exception on the calls
combWarningButton.setIcon(AppImage.getScaledIcon(AppImage.UI_WARNING, 16, 16)); timeWarningButton.setIcon(AppImage.getScaledIcon(AppImage.UI_WARNING, 16, 16));
in MainFrame.java.

Verified the program now opens on both Linux (Pop!_OS 20.10 OpenJDK 11) and Windows 10 (Java 8 JRE). Linux uses the generic Swing UI, Windows still uses same UI as before. Verified chip import and calculation on Linux.


GitHub powered CMS

Implement something like https://github.com/oscarnevarezleal/gh-cms but using Nim instead of Go.
It is just a YAML to build https://github.com/oscarnevarezleal/gh-cms/blob/main/.github/workflows/gh-on-issue.yml
Another YAML to serve https://github.com/oscarnevarezleal/gh-cms/blob/main/.github/workflows/gh-serve.yml
People can add content via GitHub Issues https://github.com/oscarnevarezleal/gh-cms/issues
Then page is live at GitHub Pages https://oscarnevarezleal.github.io/gh-cms
It is a CMS hosted by GitHub Actions and GitHub Issues and GitHub Pages, for free basically.
🙂

nice.
will need a Nimib twist. like all nim code in markdown is executed. :)

mmh, indeed could be a sort of nim playground with logging... everyone comes and can run his own code... I like the idea! we should definitely do it!

I think you can Moderate issues interaction from here https://github.com/pietroppeter/nimib/settings/interaction_limits


Unable to Paste OTP Using Ctrl + V in Input Field

When attempting to paste a 5-digit OTP into a 6-digit input field using Ctrl + V, the input becomes unresponsive upon typing the 6th digit. The input field stops accepting any further input, and only switching between input fields works. This issue prevents users from easily entering their OTP.

Thanks for pointing this out.
I didn't notice this issue existed.
Turns out it just needs one more condition in the pin-input logic.
It's gonna be fixed in #17


x/pkgsite: Trim HTTP or HTTPS Scheme from Source Code links

Trimming the URL by creating a new template function which trims the
scheme of the URL
Modified the tests in server_test.go, sample.go accordingly.
Fixes golang/go#40943

This is not passing all the errors when I run ./all.bash. The failing test -
--- FAIL: TestFetchOverviewDetails (0.07s)
    overview_test.go:57: constructOverviewDetails("github.com/valid/module_name/foo", "v1.0.0") mismatch (-want +got):
          &frontend.OverviewDetails{
          	... // 4 identical fields
          	ReadMeSource<EMAIL_ADDRESS>          	Redistributable: true,
        - 	RepositoryURL:   "github.com/valid/module_name",
        + 	RepositoryURL:   "https://github.com/valid/module_name",
          }

Can someone guide me how can I amend the code to accommodate this?
Thanks


Bluepill should print the UUID of the simulator created.

When debugging failures, it'd be useful if bluepill printed the UUID of the simulator when it creates a new one.  E.g.
[ FAILED ] (1) Completed: [1] Create Simulator

Doesn't help debugging failures. If it printed the UUID we could go dig for crash logs.

Fixed by #32


Upgrade docs theme

Will this be the solution to all our problems????

Yesssss the Plotly issue is gone :heart_eyes: We no longer need a for of the RTD Sphinx Theme, and also the typographies of the headings are fixed :heart:


Security groups can be mail enabled only

Current Teams DLP policy only allows mail enabled security groups. adding that information to avoid any confusion to the customers.

Learn Build status updates of commit 86463d1:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

microsoft-365/compliance/dlp-microsoft-teams.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the learn.microsoft.com contributor guidesPost your question in the Learn support channel

@chrfox Please merge this PR. Thanks

Learn Build status updates of commit efbf3ca:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

microsoft-365/compliance/dlp-microsoft-teams.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the learn.microsoft.com contributor guidesPost your question in the Learn support channel


Write lock conflict

Log id: d58f77ad249bcad098ab411c
Details on what happens when attempting to delete a file while transferring a folder on OS X. Operation eventually finished without additional user interaction.

Thanks for the report.  Hmm, that's an odd error message, it doesn't look like it's coming from KBFS.  What programs were you using for transfer, and what showed you that error message?
I do see some timeout errors in your keybase log, but those are expected in the current release under some situations (we should be fixing them soon).  I don't know how they'd end up showing you a lock error though.

This was a drag-and-drop via the Finder for the transfer, and a Cmd-Del
in the Finder folder for the delete. The message I believe was via the
normal thing-used-to-be-known-as-a-growl notification.
Attempts to replicate a couple times so far have failed (Log ID
5f306ec74e18857120bacb1c):

Drag and drop large archive
Delete file from active transfer folder
Works shrug

On 2/21/17 4:52 PM, Jeremy Stribling wrote:

Thanks for the report. Hmm, that's an odd error message, it doesn't
look like it's coming from KBFS. What programs were you using for
transfer, and what showed you that error message?
I do see some timeout errors in your keybase log, but those are
expected in the current release under some situations (we should be
fixing them soon). I don't know how they'd end up showing you a lock
error though.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/keybase/client/issues/5969#issuecomment-281508811,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB4qxiMZT9y-0p0oOrLqRbVuGt8v27-jks5re2qngaJpZM4MH9pv.

Closing due to non-reproducibility.


Package won't compile

Hi,
is this package still mantained? It fails when I try to compile the 0.5 version for hackage with a bunch of errors in the pretty.hs file.
Bests
Carlo

I have the same issue, such a shame for this awesome tool!

Could you copy paste the errors here?

[1 of 2] Compiling Pretty           ( Pretty.hs, dist/build/visual-prof/visual-prof-tmp/Pretty.o )
Pretty.hs:663:23:
Not in scope: data constructor ‘UnBangedTy’
Perhaps you meant one of these:
‘BangedTy’ (imported from Language.Haskell.Exts.Syntax),
‘A.BangedTy’ (imported from Language.Haskell.Exts.Annotated.Syntax),
‘UnpackedTy’ (imported from Language.Haskell.Exts.Syntax)
Pretty.hs:895:23: Not in scope: data constructor ‘PNeg’
Pretty.hs:937:23: Not in scope: data constructor ‘PExplTypeArg’
Pretty.hs:986:17:
Not in scope: type constructor or class ‘GuardedAlts’
Perhaps you meant one of these:
‘GuardedRhs’ (imported from Language.Haskell.Exts.Syntax),
‘A.GuardedRhs’ (imported from Language.Haskell.Exts.Annotated.Syntax)
Pretty.hs:987:17:
Not in scope: data constructor ‘UnGuardedAlt’
Perhaps you meant one of these:
‘UnGuardedRhs’ (imported from Language.Haskell.Exts.Syntax),
‘A.UnGuardedRhs’ (imported from Language.Haskell.Exts.Annotated.Syntax)
Pretty.hs:988:17:
Not in scope: data constructor ‘GuardedAlts’
Perhaps you meant one of these:
‘GuardedRhss’ (imported from Language.Haskell.Exts.Syntax),
‘A.GuardedRhss’ (imported from Language.Haskell.Exts.Annotated.Syntax),
‘GuardedRhs’ (imported from Language.Haskell.Exts.Syntax)
Pretty.hs:990:17:
Not in scope: type constructor or class ‘GuardedAlt’
Perhaps you meant one of these:
‘GuardedRhs’ (imported from Language.Haskell.Exts.Syntax),
‘A.GuardedRhs’ (imported from Language.Haskell.Exts.Annotated.Syntax)
Pretty.hs:991:17:
Not in scope: data constructor ‘GuardedAlt’
Perhaps you meant one of these:
‘GuardedRhs’ (imported from Language.Haskell.Exts.Syntax),
‘A.GuardedRhs’ (imported from Language.Haskell.Exts.Annotated.Syntax)
Pretty.hs:1214:13:
Not in scope: data constructor ‘A.IHead’
Perhaps you meant ‘A.DHead’ (imported from Language.Haskell.Exts.Annotated.Syntax)
Pretty.hs:1286:31:
Not in scope: data constructor ‘A.IHead’
Perhaps you meant ‘A.DHead’ (imported from Language.Haskell.Exts.Annotated.Syntax)
Pretty.hs:1355:33:
Not in scope: type constructor or class ‘A.GuardedAlts’
Perhaps you meant ‘A.GuardedRhs’ (imported from Language.Haskell.Exts.Annotated.Syntax)
Pretty.hs:1356:27:
Not in scope: ‘sGuardedAlts’
Perhaps you meant ‘sGuardedRhs’ (imported from Language.Haskell.Exts.Annotated.Simplify)
Pretty.hs:1358:33:
Not in scope: type constructor or class ‘A.GuardedAlt’
Perhaps you meant ‘A.GuardedRhs’ (imported from Language.Haskell.Exts.Annotated.Syntax)
Pretty.hs:1359:27:
Not in scope: ‘sGuardedAlt’
Perhaps you meant ‘sGuardedRhs’ (imported from Language.Haskell.Exts.Annotated.Simplify)
Pretty.hs:1398:17:
Not in scope: data constructor ‘A.CxParen’
Perhaps you meant one of these:
‘A.TyParen’ (imported from Language.Haskell.Exts.Annotated.Syntax),
‘A.Paren’ (imported from Language.Haskell.Exts.Annotated.Syntax),
‘A.PParen’ (imported from Language.Haskell.Exts.Annotated.Syntax)

I have the same issue. It's reproducible.

This project needs a stack.yaml with working resolver. This would guarantee correct compilation at all times.


Document Resources should be able to accept any content type

From what I can see currently it is only possible to send JSON documents.

Hi @thomasturrell thanks for the report!
You are right, it seems that there is a type requirement for key/value pairs when sending document data. The xAPI specification seems fairly wooly on the subject (and links through to broken/missing sections).
I cannot see anything in the xAPI spec that specifically states it must be a JSON object, would changing the interface type to any or unknown satisfy this requirement?

There is a section in the specification on content types which might be useful.
Documents can have any content type.
I have seen LRPs send activity states with a variety of different content types. In the wild JSON isn't used for documents a frequently as you might assume.
I'm not sure if that helps!

Very good! That section gives me confidence that an LRS should accept any content type. I'll see what I can put together to implement and test this scenario.

Looks good to me. I approved your pull request (which seems a bit weird, hopefully you don't mind!)

@thomasturrell sorry I've left this so long!
I've got a proof of concept put together locally so far, it involves having to manually pass the content type of the data in the headers which I think is ok. I'm not sure if it's possible or even wise to try and determine the type automatically.

No need to apologise, I'm very interested in this project but I am not using it yet so it's not a road block for me.
I think you are right, the content type will have to be calculated by the caller. I guess the method could assume that the content is JSON unless told otherwise.


Fix fix leading with left join without leftside condition

Proposed changes
When left join with no edge in outer side, we should add outer side to minimal require of left tables

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

run buildall

run buildall

run feut

run beut


{KeyVault} Fix deserialization bug on importing certificate with its own policy

Fix #13304
CERT_POLICY=$(az keyvault certificate show --vault-name $SOURCE_FIRST_PARTY_KEY_VAULT_NAME  -n azds1sp --query policy)

az keyvault secret download --vault-name $SOURCE_FIRST_PARTY_KEY_VAULT_NAME --file ./azds1SP -n azds1sp  --encoding base64

az keyvault certificate import --vault-name $FIRST_PARTY_KEY_VAULT_NAME --file ./azds1SP -n azds1sp -p "$CERT_POLICY"

This will throw an error:
Unable to build a model: Unable to deserialize response data. Data: 2020-04-30T21:43:42+00:00, unix-time, TypeError: an integer is required (got type str), DeserializationError: Unable to deserialize response data. Data: 2020-04-30T21:43:42+00:00, unix-time, TypeError: an integer is required (got type str)

This checklist is used to make sure that common guidelines for a pull request are followed.

[x] The PR title and description has followed the guideline in Submitting Pull Requests.

[x] I adhere to the Command Guidelines.

KeyVault


feature req: add function chaining to all set...() functions -- return T&

I request all set...() functions to support function chaining by returning a reference to themselves.
This is widely used across languages. Can be used both in C++ and in python bindings (python loves these).
Could combine with #355 as a task "make get() const and set() return T&"
myColorImgFrame.setCategory(2).setWidth(500).setHeight(200);
// or everything with rvalues
myfunc(myqueue->get<dai::ImgFrame>().setCategory(2).setWidth(500).setHeight(200));

Fixes are trivial
// old
void ImgFrame::setCategory(unsigned int category) {
    img.category = category;
}

// new
ImgFrame& ImgFrame::setCategory(unsigned int category) {
    img.category = category;
    return *this;
}

Setup

all

Repro
Found while writing my app and having to make temp variables just to set...() some things.

Thought about it as well, I think it will fit nicely.
Will address soon