Feature/3delight2

Brief description
Adding 3delight render support to OpenPype
Description
Adding support to render via Maya on 3delight using the Deadline service. This PR adds the necessary structures and changes within OP to invoke rendering.
Given that Deadline hasn't updated support for 3delight since 3delight switched to NSI, we had to add support for "render layers", via 3delight's dlRenderSettings via a pre-render MEL command, and also startFrame and endFrame too. This uses maya's render layers just for their names to map into the dlRenderSetting to use.
Additional info
Given that 3delight uses dlRenderSettings instead of Maya's Render Layers to manage all rendering information, this poses an issue whenever a change in OP's way of handling renders changes. I have tried to get OP to ignore settings and valiations for 3delight when it's active, and hopefully no more changes will be needed.
Resolves #2883

Resolves #2883

Closing in favour of #4319 which is the same but with resolved conflicts.


Fix install script

Change install directory and shortcut path.

Current coverage is 93.18%

Merging #9 into master will not affect coverage as of f747e8b

@@            master      #9   diff @@
======================================
  Files           59      59
  Stmts         1614    1614
  Branches         0       0
  Methods          0       0
======================================
  Hit           1504    1504
  Partial          0       0
  Missed         110     110

Review entire Coverage Diff as of f747e8b

Powered by Codecov. Updated on successful CI builds.

Looks better. :tongue: Thank you!


seems like webpack hot reloading doesn't work

Thanks for reporting this and apologies it's taken so long to resolve.
This has been fixed in<PHONE_NUMBER>a8e7a5eb7343b5605cfa9de4ed9769.


postcss-cli: fix darwin hashes

Description of changes
Noticed this hash mismatch build failure. I'm not sure about the root cause, but everything builds with the updated hashes.
Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[ ] Fits CONTRIBUTING.md.

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

This pull request has been mentioned on NixOS Discourse.


instructions

You dont explain how it works

hmm... project dead.

It's not dead but it's lacking developers. Plus it takes some time to code these kind of things.


Fixes #188

This is a pretty straightforward one.
The bug was in the setting of single bond directions around double bonds.
The code that handles chained double bonds (i.e. things like C/C=C/C=C/C=C/C) and makes sure that the directions are consistent was not properly moving on to set dependent bonds after updating one side of a double bond.

Missed a case. Closing for the moment.

The changes seem straight forward so I'm going to merge this tomorrow.  I will spend some time trying to understand this a bit better, I want to get a better feel for the performance impact of this code ( I suspect it is small, but current cip and stereoE/Z perception are a large chunk of the perception run time)

I looked at this as well. I was at first initially worried about the extra recursion in updateDoubleBondNeighbors, but even so it should still be at most O(# of bonds).

Given that it previously had to hit all of the double bonds too, I don't think the performance of this should be substantially worse than what we were seeing before.
@bp-kelley : you are absolutely right that the CIP and E/Z assignment performance is crap. @NadineSchneider and I have talked about this before and have some ideas about improving it, but that's definitely real work and would need to wait until the next release.

@greglandrum It's not crap per-se, but it has an enormous run-time.  We've talked before about changing bond e/z and cip stereo to "on-demand" so some standard use cases (substructure searching etc) wouldn't need it to be computed by default.  This would make the smiles->parse->sanitize twice as fast.
The difficulty is that a lot of the code uses cip and e/z identification, so this might not really be possible.

The lazy approach is certainly possible, and I think it's the right thing
to do (along with improving the existing algorithm).  We've talked before about changing bond e/z
and cip stereo to "on-demand" so some standard use cases (substructure
searching etc) wouldn't need it to be computed by default. This would make
the smiles->parse->sanitize twice as fast.
The difficulty is that a lot of the code uses cip and e/z identification,
so this might not really be possible.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/rdkit/rdkit/pull/828#issuecomment-204381804

I'd like to go ahead and create the release branch (because April 1 is just the day to do such things), so I'm going to merge this on my own based on the comments above.
Worst case we can fix things with a patch.


explicitly expire token JWT

Hello,
How can we explicitly expire the previous token on re-login or logout functionality?
Please let me know as soon as possible.

The JWT protocol does not have a mechanism of expiring. It has a machanism of blakclisting, and https://github.com/tymondesigns/jwt-auth/wiki has this kind of mechanism

@catalinux Can you please provide me some demo code for it?

@SnehalAmbab that is the only code you need to. Having a token, you could invalidate. You could get that throug GET.
 function deleteToken()
    {

        $data = Input::all();
        $token = $data['token'];
        \Tymon\JWTAuth\Facades\JWTAuth::invalidate($token);

        return json_encode(['response' => 'success']);
    }

@catalinux I want to expire previous token on login.
How can we get previously assigned token to a user?

I am not sure if there is any mechanism implemented on jwt-auth library. How you could do that depends on why you need that.
For instance in the validation process of the token you could check some info you put in the body of your token (for example token_creation), against a database where you have "last time token creation"

You'd probably need to keep a running record of tokens assigned to a user and expire them if they're old or inactive.
Doesn't seem specific to this package. Going to close.


Feature/bill detail reporting

This PR adds the testimony reporting feature to the policy actions component, visible on the Bill Detail page.
I implemented the Report functionality from TestimonyCard, including the toast which displays success over time.
The functionality requires a Testimony object that is not exactly present, so I included "Revision" to be pulled from the useCurrentTestimonyDetails hook.
Within PolicyActions, I have made changes to the definition to the PolicyActionsProps interface to allow the isReporting state and setReporting function. This allows for the report PolicyAction button to use the Report functions.

I have not been able to see the outcome on the back end other than the success toast.

Hola - status update on this? @MarkTrepanier

Hiyo. sorry. I've been in the middle of moving, and between that and work, I haven't had the time to update this branch. I have to merge current dev to my branch and it should should be gold. I just haven't been able to sit at my dev computer

@MarkTrepanier ok thanks. No worries and no rush, just wanted to see where it's at.


Does the npm registry has the lastest blink-mind？

Hello,I just used the command ‘npm install @blink-mind/plugins’ to install the lastest version(0.0.20-beta.12) of plugins,but some plugins I found on github don't exist,such as ExportTopicPlugins.
Maybe the npm registry doesn't update?
Thank you！

Please update.

It is currently in the development stage and has not stabilized, so it will not be pushed to npm for the time being. If you need it now, you can build it by yourself.


Set alpha as default

Use the alpha tag by default to prevent errors that may occur from the unstable tag.
Thanks to @pdurbin on Zulip - https://dataverse.zulipchat.com/#narrow/stream/375812-containers/topic/Dataverse.20Action.20broken/near/426731935

Heads up that "alpha" just shifted from 6.1 to 6.2 and 6.2 requires some new PID settings:
        -Ddataverse.pid.providers=fake
        -Ddataverse.pid.default-provider=fake
        -Ddataverse.pid.fake.type=FAKE
        -Ddataverse.pid.fake.label=FakeDOIProvider
        -Ddataverse.pid.fake.authority=10.5072
        -Ddataverse.pid.fake.shoulder=FK2/

Here's where I added them to the API test runner: https://github.com/gdcc/api-test-runner/commit/a95a8e1d645305b151f49c31a18743f6d7f2b495


A couple of minor gotchas for 8.7

This is on 10.2-RELEASE-p15

Hello,
thanks for the catches. :) Today i brought a update on the road with brings the quarterly version of GitLab to its newest version and fix the rake-issue. If you remove the passage i will merge it.
Another option would be to rephrase it and mention that the newest GitLab version is just available on /latest/.
Greetings,
Torsten

I will go over it again now that the update is out.
By the way, thank you for your work on this port.
Kind regards,
Corvin

I've pushed my amendments. I've also noticed that the newest version available on quarterly 10.2 is still gitlab 8.5.

Hello corv89,
thanks for your changes! I merged them all :)
Greetings,
Torsten


Infer multi-file binaries like src/bin/server/main.rs by convention

Currently cargo infers binaries from files in src/bin. This works if you binary fits in one file, but if you need more than one file, you have to write custom [[bin]] specification in Cargo.toml.
Looks like a reasonable convention for multifile binary projects is this:
src/
  bin/
    server/
        main.rs
        aux.rs
    client/
        main.rs
        foo.rs

So let's infer src/bin/foo/main.rs as a binary named foo?
This should be mostly backwards compatible change. The only failure case is when someone has src/bin/foo/main.rs which is not a binary, and no [[bin]] sections are present, and this seems unlikely.
A potential edge case is
src/
  bin/
    foo.rs
    foo/
      main.rs

This should be an error.

Sounds great to me!

If anyone wants to fix it, the place to look at is this line https://github.com/rust-lang/cargo/blob/263548d9781efb17b72de601665a7cf0ca472ba1/src/cargo/util/toml.rs#L54
and this function https://github.com/rust-lang/cargo/blob/263548d9781efb17b72de601665a7cf0ca472ba1/src/cargo/util/toml.rs#L503.
The tests should probably go into this file: https://github.com/rust-lang/cargo/blob/master/tests/build.rs

Is anybody working on this?

@msehnout not that I know of, feel free to take it!

#4214 enabled this for src/bin, but how about also enabling this pattern for examples (and maybe integration tests)?

@crumblingstatue that sounds plausible! Right now I am refactoring the implementation of this stuff in https://github.com/rust-lang/cargo/pull/4259 though, so, if you'd like to send a PR, it's better to wait for a while :)

Hi @matklad, I think I could try to work on this one. The PR you mentioned is merged already. Is there anything I should be aware of before I start?

Awesome @rwakulszowa ! I think toml/targets.rs is the only file that should me modified, besides the test.

Hey, I have a few questions

the discussion here mentions tests and examples. What about banchmarks?
is there a nice way to test for existence of test binaries? Examples end up in the examples folder, but tests only produce artifacts in the main folder, decorated with hashes; is there a way to pass a regex / prefix string to the assert_that(..., existing_file())?

the discussion here mentions tests and examples. What about banchmarks?

Yeah, the benchmarks could use the same logic

is there a nice way to test for existence of test binaries?

I would probably check that cargo test --test foo works.

Did support for examples with a main.rs file get added as part of this or should that be a separate issue?

Yes - examples, benches and tests follow the same logic and allow
multi-file directories, as long as they contain a main.rs file.
Did you encounter a problem with that?
19.11.2017 17:01 "Sunjay Varma"<EMAIL_ADDRESS>napisał(a):

Did support for examples with a main.rs file get added as part of this or
should that be a separate issue?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rust-lang/cargo/issues/4086#issuecomment-345532072,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AKQgyOsIslY-urII1LDbBZqRuXkU31cdks5s4F7zgaJpZM4Ni3Ta
.

@rwakulszowa Yes, it didn't work. Here's a minimal example:
From the base project created by cargo new --lib <project name>, I added a file examples/dir/main.rs and a file examples/foo.rs.
.
├── Cargo.lock
├── Cargo.toml
├── examples
│   ├── dir
│   │   └── main.rs
│   └── foo.rs
└── src
    └── lib.rs

Both files contain the simple hello world program. When I try to run them, this is what happens:
$ cargo run --example dir
error: no example target named `dir`

Did you mean `foo`?

$ cargo run --example foo
    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
     Running `target/debug/examples/foo`
Hello, world!

The flat file worked, but nesting a file within a directory and having a file called "main.rs" did not work.

Are you sure you are using a recent cargo build? This change got merged in
September, but I'm not sure which cargo release contains it ( @matklad ?)
I have limited network access at the moment, so I'll check the official
release tomorrow, but I tested the feature locally and it works fine.
Maybe the feature didn't make it to the official release yet, or some other
changes modified the behavior. I'll take a look.
19.11.2017 19:42 "Sunjay Varma"<EMAIL_ADDRESS>napisał(a):

@rwakulszowa https://github.com/rwakulszowa Yes, it didn't work. Here's
a minimal example:
From the base project created by cargo new --lib , I added
a file examples/dir/main.rs and a file examples/foo.rs.
.
├── Cargo.lock
├── Cargo.toml
├── examples
│   ├── dir
│   │   └── main.rs
│   └── foo.rs
└── src
└── lib.rs
Both files contain the simple hello world program. When I try to run them,
this is what happens:
$ cargo run --example dir
error: no example target named dir
Did you mean foo?
$ cargo run --example foo
Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
Running target/debug/examples/foo
Hello, world!
The flat file worked, but nesting a file within a directory and having a
file called "main.rs" did not work.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rust-lang/cargo/issues/4086#issuecomment-345543618,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AKQgyEWAvRZWzF4_6nFTQlDQ5X2CNDGPks5s4ISxgaJpZM4Ni3Ta
.

Maybe the feature didn't make it to the official release yet, or some other
changes modified the behavior. I'll take a look.

Yes it seems so. I tried running it with cargo +nightly run --example dir and it worked. Looks like this will probably be out in Rust 1.22 :smile:

Alright!
19.11.2017 20:45 "Sunjay Varma"<EMAIL_ADDRESS>napisał(a):

Maybe the feature didn't make it to the official release yet, or some other
changes modified the behavior. I'll take a look.
Yes it seems so. I tried running it with cargo +nightly run --example dir
and it worked. Looks like this will probably be out in Rust 1.22 😄
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rust-lang/cargo/issues/4086#issuecomment-345548132,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AKQgyGFszm-gsWsYgHdRo9wYHW2a2AVNks5s4JNggaJpZM4Ni3Ta
.


Download all my solutions

Being able to download all my solutions so I can have them locally accessible and back them up myself would be excellent.
This feature could simply download only the solution, but ideally it would bundle them up with information about the Kata (Instructions, etc).

Can't upvote this enough. A severely lacking feature.

Agreed ^.


herbstluftwm: 0.9.1 -> 0.9.2

Motivation for this change
New release.
Things done
This release introduces window titles and now depends on freetype and libXft.
I disabled the test test_title_different_letters_are_drawn for now because it is broken in sandboxed build, probably because of font issue. The NixOS test passse and the screenshot contains a title. I'm using this release for a couple of days now without any issue.
I also fixed the build of the documentation when cross-compiling. It was an instance of #49526 issue + using nativeBuildInputs instead of depsBuildBuild.

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

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

[x] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Determined the impact on package closure size (by running nix path-info -S before and after)
[x] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 114566 at 93c2d520 run on x86_64-linux 1

1 package built:

herbstluftwm

1 suggestion:

warning: missing-patch-comment
Please add a comment on the line above, explaining the purpose of this patch.
Near pkgs/applications/window-managers/herbstluftwm/default.nix:43:5:
   |
43 |     ./test-path-environment.patch
   |     ^


Disposing

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

Fixed with commit 44f1b87. Thank you!


view semantic (broadcast on assign) fixed

Fixes #740

@SylvainCorlay I think you'll be happy that the broadcastable code is used in the assign mechanism now ;)


Handles become unusable if the element is scaled too small

If you scale the element to small the handles becomes unusable (see Appendix 1).
Possible Solution

Move the handles to the outside of the object and add some additional spacing between them (see Appendix 2)

Appendix 1

Appendix 2

duplicated by #1


Unexpected key(s) in state_dict:

When the code load the inception model， it appear this kind of error。
./fid_score.py /home/liuyx/dataset/cyclegan/fastblind-test/testA/bike-packing/ /home/liuyx/dataset/cyclegan/fastblind-test/fakeA/bike-packing/fakea/
Traceback (most recent call last):
File "./fid_score.py", line 262, in
args.dims)
File "./fid_score.py", line 242, in calculate_fid_given_paths
model = InceptionV3([block_idx])
File "/home/liuyx/codes/pytorch-fid/inception.py", line 80, in init
inception = fid_inception_v3()
File "/home/liuyx/codes/pytorch-fid/inception.py", line 207, in fid_inception_v3
inception.load_state_dict(state_dict)
File "/usr/local/lib/python3.5/dist-packages/torch/nn/modules/module.py", line 721, in load_state_dict
self.class.name, "\n\t".join(error_msgs)))
RuntimeError: Error(s) in loading state_dict for Inception3:
Unexpected key(s) in state_dict: "Conv2d_1a_3x3.bn.num_batches_tracked", "Conv2d_2a_3x3.bn.num_batches_tracked", "Conv2d_2b_3x3.bn.num_batches_tracked", "Conv2d_3b_1x1.bn.num_batches_tracked", "Conv2d_4a_3x3.bn.num_batches_tracked", "Mixed_5b.branch1x1.bn.num_batches_tracked", "Mixed_5b.branch5x5_1.bn.num_batches_tracked", "Mixed_5b.branch5x5_2.bn.num_batches_tracked", "Mixed_5b.branch3x3dbl_1.bn.num_batches_tracked", "Mixed_5b.branch3x3dbl_2.bn.num_batches_tracked", "Mixed_5b.branch3x3dbl_3.bn.num_batches_tracked", "Mixed_5b.branch_pool.bn.num_batches_tracked", "Mixed_5c.branch1x1.bn.num_batches_tracked", "Mixed_5c.branch5x5_1.bn.num_batches_tracked", "Mixed_5c.branch5x5_2.bn.num_batches_tracked", "Mixed_5c.branch3x3dbl_1.bn.num_batches_tracked", "Mixed_5c.branch3x3dbl_2.bn.num_batches_tracked", "Mixed_5c.branch3x3dbl_3.bn.num_batches_tracked", "Mixed_5c.branch_pool.bn.num_batches_tracked", "Mixed_5d.branch1x1.bn.num_batches_tracked", "Mixed_5d.branch5x5_1.bn.num_batches_tracked", "Mixed_5d.branch5x5_2.bn.num_batches_tracked", "Mixed_5d.branch3x3dbl_1.bn.num_batches_tracked", "Mixed_5d.branch3x3dbl_2.bn.num_batches_tracked", "Mixed_5d.branch3x3dbl_3.bn.num_batches_tracked", "Mixed_5d.branch_pool.bn.num_batches_tracked", "Mixed_6a.branch3x3.bn.num_batches_tracked", "Mixed_6a.branch3x3dbl_1.bn.num_batches_tracked", "Mixed_6a.branch3x3dbl_2.bn.num_batches_tracked", "Mixed_6a.branch3x3dbl_3.bn.num_batches_tracked", "Mixed_6b.branch1x1.bn.num_batches_tracked", "Mixed_6b.branch7x7_1.bn.num_batches_tracked", "Mixed_6b.branch7x7_2.bn.num_batches_tracked", "Mixed_6b.branch7x7_3.bn.num_batches_tracked", "Mixed_6b.branch7x7dbl_1.bn.num_batches_tracked", "Mixed_6b.branch7x7dbl_2.bn.num_batches_tracked", "Mixed_6b.branch7x7dbl_3.bn.num_batches_tracked", "Mixed_6b.branch7x7dbl_4.bn.num_batches_tracked", "Mixed_6b.branch7x7dbl_5.bn.num_batches_tracked", "Mixed_6b.branch_pool.bn.num_batches_tracked", "Mixed_6c.branch1x1.bn.num_batches_tracked", "Mixed_6c.branch7x7_1.bn.num_batches_tracked", "Mixed_6c.branch7x7_2.bn.num_batches_tracked", "Mixed_6c.branch7x7_3.bn.num_batches_tracked", "Mixed_6c.branch7x7dbl_1.bn.num_batches_tracked", "Mixed_6c.branch7x7dbl_2.bn.num_batches_tracked", "Mixed_6c.branch7x7dbl_3.bn.num_batches_tracked", "Mixed_6c.branch7x7dbl_4.bn.num_batches_tracked", "Mixed_6c.branch7x7dbl_5.bn.num_batches_tracked", "Mixed_6c.branch_pool.bn.num_batches_tracked", "Mixed_6d.branch1x1.bn.num_batches_tracked", "Mixed_6d.branch7x7_1.bn.num_batches_tracked", "Mixed_6d.branch7x7_2.bn.num_batches_tracked", "Mixed_6d.branch7x7_3.bn.num_batches_tracked", "Mixed_6d.branch7x7dbl_1.bn.num_batches_tracked", "Mixed_6d.branch7x7dbl_2.bn.num_batches_tracked", "Mixed_6d.branch7x7dbl_3.bn.num_batches_tracked", "Mixed_6d.branch7x7dbl_4.bn.num_batches_tracked", "Mixed_6d.branch7x7dbl_5.bn.num_batches_tracked", "Mixed_6d.branch_pool.bn.num_batches_tracked", "Mixed_6e.branch1x1.bn.num_batches_tracked", "Mixed_6e.branch7x7_1.bn.num_batches_tracked", "Mixed_6e.branch7x7_2.bn.num_batches_tracked", "Mixed_6e.branch7x7_3.bn.num_batches_tracked", "Mixed_6e.branch7x7dbl_1.bn.num_batches_tracked", "Mixed_6e.branch7x7dbl_2.bn.num_batches_tracked", "Mixed_6e.branch7x7dbl_3.bn.num_batches_tracked", "Mixed_6e.branch7x7dbl_4.bn.num_batches_tracked", "Mixed_6e.branch7x7dbl_5.bn.num_batches_tracked", "Mixed_6e.branch_pool.bn.num_batches_tracked", "Mixed_7a.branch3x3_1.bn.num_batches_tracked", "Mixed_7a.branch3x3_2.bn.num_batches_tracked", "Mixed_7a.branch7x7x3_1.bn.num_batches_tracked", "Mixed_7a.branch7x7x3_2.bn.num_batches_tracked", "Mixed_7a.branch7x7x3_3.bn.num_batches_tracked", "Mixed_7a.branch7x7x3_4.bn.num_batches_tracked", "Mixed_7b.branch1x1.bn.num_batches_tracked", "Mixed_7b.branch3x3_1.bn.num_batches_tracked", "Mixed_7b.branch3x3_2a.bn.num_batches_tracked", "Mixed_7b.branch3x3_2b.bn.num_batches_tracked", "Mixed_7b.branch3x3dbl_1.bn.num_batches_tracked", "Mixed_7b.branch3x3dbl_2.bn.num_batches_tracked", "Mixed_7b.branch3x3dbl_3a.bn.num_batches_tracked", "Mixed_7b.branch3x3dbl_3b.bn.num_batches_tracked", "Mixed_7b.branch_pool.bn.num_batches_tracked", "Mixed_7c.branch1x1.bn.num_batches_tracked", "Mixed_7c.branch3x3_1.bn.num_batches_tracked", "Mixed_7c.branch3x3_2a.bn.num_batches_tracked", "Mixed_7c.branch3x3_2b.bn.num_batches_tracked", "Mixed_7c.branch3x3dbl_1.bn.num_batches_tracked", "Mixed_7c.branch3x3dbl_2.bn.num_batches_tracked", "Mixed_7c.branch3x3dbl_3a.bn.num_batches_tracked", "Mixed_7c.branch3x3dbl_3b.bn.num_batches_tracked", "Mixed_7c.branch_pool.bn.num_batches_tracked".

When the code load the inception model， it appear this kind of error。
./fid_score.py /home/liuyx/dataset/cyclegan/fastblind-test/testA/bike-packing/ /home/liuyx/dataset/cyclegan/fastblind-test/fakeA/bike-packing/fakea/
Traceback (most recent call last):
File "./fid_score.py", line 262, in
args.dims)
File "./fid_score.py", line 242, in calculate_fid_given_paths
model = InceptionV3([block_idx])
File "/home/liuyx/codes/pytorch-fid/inception.py", line 80, in init
inception = fid_inception_v3()
File "/home/liuyx/codes/pytorch-fid/inception.py", line 207, in fid_inception_v3
inception.load_state_dict(state_dict)
File "/usr/local/lib/python3.5/dist-packages/torch/nn/modules/module.py", line 721, in load_state_dict
self.class.name, "\n\t".join(error_msgs)))
RuntimeError: Error(s) in loading state_dict for Inception3:
Unexpected key(s) in state_dict: "Conv2d_1a_3x3.bn.num_batches_tracked", "Conv2d_2a_3x3.bn.num_batches_tracked", "Conv2d_2b_3x3.bn.num_batches_tracked", "Conv2d_3b_1x1.bn.num_batches_tracked", "Conv2d_4a_3x3.bn.num_batches_tracked", "Mixed_5b.branch1x1.bn.num_batches_tracked", "Mixed_5b.branch5x5_1.bn.num_batches_tracked", "Mixed_5b.branch5x5_2.bn.num_batches_tracked", "Mixed_5b.branch3x3dbl_1.bn.num_batches_tracked", "Mixed_5b.branch3x3dbl_2.bn.num_batches_tracked", "Mixed_5b.branch3x3dbl_3.bn.num_batches_tracked", "Mixed_5b.branch_pool.bn.num_batches_tracked", "Mixed_5c.branch1x1.bn.num_batches_tracked", "Mixed_5c.branch5x5_1.bn.num_batches_tracked", "Mixed_5c.branch5x5_2.bn.num_batches_tracked", "Mixed_5c.branch3x3dbl_1.bn.num_batches_tracked", "Mixed_5c.branch3x3dbl_2.bn.num_batches_tracked", "Mixed_5c.branch3x3dbl_3.bn.num_batches_tracked", "Mixed_5c.branch_pool.bn.num_batches_tracked", "Mixed_5d.branch1x1.bn.num_batches_tracked", "Mixed_5d.branch5x5_1.bn.num_batches_tracked", "Mixed_5d.branch5x5_2.bn.num_batches_tracked", "Mixed_5d.branch3x3dbl_1.bn.num_batches_tracked", "Mixed_5d.branch3x3dbl_2.bn.num_batches_tracked", "Mixed_5d.branch3x3dbl_3.bn.num_batches_tracked", "Mixed_5d.branch_pool.bn.num_batches_tracked", "Mixed_6a.branch3x3.bn.num_batches_tracked", "Mixed_6a.branch3x3dbl_1.bn.num_batches_tracked", "Mixed_6a.branch3x3dbl_2.bn.num_batches_tracked", "Mixed_6a.branch3x3dbl_3.bn.num_batches_tracked", "Mixed_6b.branch1x1.bn.num_batches_tracked", "Mixed_6b.branch7x7_1.bn.num_batches_tracked", "Mixed_6b.branch7x7_2.bn.num_batches_tracked", "Mixed_6b.branch7x7_3.bn.num_batches_tracked", "Mixed_6b.branch7x7dbl_1.bn.num_batches_tracked", "Mixed_6b.branch7x7dbl_2.bn.num_batches_tracked", "Mixed_6b.branch7x7dbl_3.bn.num_batches_tracked", "Mixed_6b.branch7x7dbl_4.bn.num_batches_tracked", "Mixed_6b.branch7x7dbl_5.bn.num_batches_tracked", "Mixed_6b.branch_pool.bn.num_batches_tracked", "Mixed_6c.branch1x1.bn.num_batches_tracked", "Mixed_6c.branch7x7_1.bn.num_batches_tracked", "Mixed_6c.branch7x7_2.bn.num_batches_tracked", "Mixed_6c.branch7x7_3.bn.num_batches_tracked", "Mixed_6c.branch7x7dbl_1.bn.num_batches_tracked", "Mixed_6c.branch7x7dbl_2.bn.num_batches_tracked", "Mixed_6c.branch7x7dbl_3.bn.num_batches_tracked", "Mixed_6c.branch7x7dbl_4.bn.num_batches_tracked", "Mixed_6c.branch7x7dbl_5.bn.num_batches_tracked", "Mixed_6c.branch_pool.bn.num_batches_tracked", "Mixed_6d.branch1x1.bn.num_batches_tracked", "Mixed_6d.branch7x7_1.bn.num_batches_tracked", "Mixed_6d.branch7x7_2.bn.num_batches_tracked", "Mixed_6d.branch7x7_3.bn.num_batches_tracked", "Mixed_6d.branch7x7dbl_1.bn.num_batches_tracked", "Mixed_6d.branch7x7dbl_2.bn.num_batches_tracked", "Mixed_6d.branch7x7dbl_3.bn.num_batches_tracked", "Mixed_6d.branch7x7dbl_4.bn.num_batches_tracked", "Mixed_6d.branch7x7dbl_5.bn.num_batches_tracked", "Mixed_6d.branch_pool.bn.num_batches_tracked", "Mixed_6e.branch1x1.bn.num_batches_tracked", "Mixed_6e.branch7x7_1.bn.num_batches_tracked", "Mixed_6e.branch7x7_2.bn.num_batches_tracked", "Mixed_6e.branch7x7_3.bn.num_batches_tracked", "Mixed_6e.branch7x7dbl_1.bn.num_batches_tracked", "Mixed_6e.branch7x7dbl_2.bn.num_batches_tracked", "Mixed_6e.branch7x7dbl_3.bn.num_batches_tracked", "Mixed_6e.branch7x7dbl_4.bn.num_batches_tracked", "Mixed_6e.branch7x7dbl_5.bn.num_batches_tracked", "Mixed_6e.branch_pool.bn.num_batches_tracked", "Mixed_7a.branch3x3_1.bn.num_batches_tracked", "Mixed_7a.branch3x3_2.bn.num_batches_tracked", "Mixed_7a.branch7x7x3_1.bn.num_batches_tracked", "Mixed_7a.branch7x7x3_2.bn.num_batches_tracked", "Mixed_7a.branch7x7x3_3.bn.num_batches_tracked", "Mixed_7a.branch7x7x3_4.bn.num_batches_tracked", "Mixed_7b.branch1x1.bn.num_batches_tracked", "Mixed_7b.branch3x3_1.bn.num_batches_tracked", "Mixed_7b.branch3x3_2a.bn.num_batches_tracked", "Mixed_7b.branch3x3_2b.bn.num_batches_tracked", "Mixed_7b.branch3x3dbl_1.bn.num_batches_tracked", "Mixed_7b.branch3x3dbl_2.bn.num_batches_tracked", "Mixed_7b.branch3x3dbl_3a.bn.num_batches_tracked", "Mixed_7b.branch3x3dbl_3b.bn.num_batches_tracked", "Mixed_7b.branch_pool.bn.num_batches_tracked", "Mixed_7c.branch1x1.bn.num_batches_tracked", "Mixed_7c.branch3x3_1.bn.num_batches_tracked", "Mixed_7c.branch3x3_2a.bn.num_batches_tracked", "Mixed_7c.branch3x3_2b.bn.num_batches_tracked", "Mixed_7c.branch3x3dbl_1.bn.num_batches_tracked", "Mixed_7c.branch3x3dbl_2.bn.num_batches_tracked", "Mixed_7c.branch3x3dbl_3a.bn.num_batches_tracked", "Mixed_7c.branch3x3dbl_3b.bn.num_batches_tracked", "Mixed_7c.branch_pool.bn.num_batches_tracked".

Hi,
I have the same error, do you have any solution? thanks

I can not reproduce this error. Which version of pytorch and torchvision are you using?
As a workaround, you should be able to avoid this error by changing this line
https://github.com/mseitzer/pytorch-fid/blob/011829daeccc84341c1e8e6061d10a640a495573/inception.py#L207
to
inception.load_state_dict(state_dict, strict=False)

inception.load_state_dict(state_dict, strict=False) resolves the issue.
Thank you
Am Sa., 13. Juni 2020 um 15:39 Uhr schrieb mseitzer <
<EMAIL_ADDRESS>
I can not reproduce this error. Which version of pytorch and torchvision
are you using?
As a workaround, you should be able to avoid this error by changing this
line
https://github.com/mseitzer/pytorch-fid/blob/011829daeccc84341c1e8e6061d10a640a495573/inception.py#L207
to
inception.load_state_dict(state_dict, strict=False)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/mseitzer/pytorch-fid/issues/34#issuecomment-643618098,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJH6PL23A5MGDS46KGPR7F3RWNXPVANCNFSM4NZCS7HQ
.


MauiTaskListApp crashes in release mode

MauiTaskListApp crashes after splash screen in release mode on device

please provide details about your device

iPhone 15Sent from my iPhoneOn 15 Feb 2024, at 19:26, Vladislav Antonyuk @.***> wrote:
please provide details about your device
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

https://github.com/dotnet/efcore/issues/32496


JB-618 - New Pause payments UI

What does this PR do and why?
Closes https://linear.app/peel/issue/JB-618/new-pause-payments-ui
Screenshots or screen recordings
If applicable, provide screenshots or screen recordings to demonstrate the changes.
Acceptance checklist

[ ] I have evaluated the Approval Guidelines for this PR.
[ ] (if relevant) I have tested this PR in all supported browsers.
[ ] (if relevant) I have tested this PR in dark mode and light mode (if applicable).

Current dependencies on/for this PR:

main

PR #3875   👈

This comment was auto-generated by Graphite.

@wraeth-eth started a stack merge that includes this pull request via Graphite.

@wraeth-eth merged this pull request with Graphite.


Remove git checkout HEAD^2 from CodeQL GHA workflow

Motivation:
The CodeQL workflow is reporting a warning
"1 issue was detected with this workflow: git checkout HEAD^2 is no longer necessary. Please remove this step as Code Scanning recommends analyzing the merge commit for best results."
Modification:
Removed the unnecessary part following the instruction from link
Result:
No more warnings.

thanks


DESKTOP GPU recognized as MOBILE GPU

Hello sir,
First I just want to thank you for creating this utility it is incredibly useful !
My problem is: So when i visit your demo site https://timvanscherpenzeel.github.io/detect-gpu/ I get the correct detection on my gpu Tier: GPU_DESKTOP_TIER_3
Type: BENCHMARK - nvidia geforce gtx 980 ti.
But I npm installed the package today and when i use it locally with this code:
import { getGPUTier } from 'detect-gpu';
const GPUTier = getGPUTier({
mobileBenchmarkPercentages: [0, 50, 30, 20], // (Default) [TIER_0, TIER_1, TIER_2, TIER_3]
desktopBenchmarkPercentages: [0, 50, 30, 20], // (Default) [TIER_0, TIER_1, TIER_2, TIER_3]
});
    console.log(GPUTier);

I get tier: GPU_MOBILE_TIER_1 type:FALLBACK
I have a canvas element using three.js already inside my html maybe that is somehow interfering i dont know.

Ok i just figured out what causes this on your demo site: If i open devtools in Chrome (press F12) the detection changes to GPU_MOBILE_TIER but when I exit devtools and view your demo site in normal mode it  goes back to GPU_DESKTOP_TIER and shows the correct GPU...

Hi Eddy,
It is this way because it first checks your user agent to determine on what kind of device you are on and then your GPU to categorise it in the correct tier.
Kind regards,
Tim


Await the async result of unmarking an issue

The unmark functionality is neither returning nor await-ing the Promise returned from the call to Stale#unmarkIssue.
This is not strictly necessary but would be the best practice to avoid hypothetical race conditions when invoking unmark but then continuing on before actually verifying the status/result of the inner activity.
If this is specifically  not desired, then I would instead suggest adding a comment here to explain why.

FYI, this bit of code has been this way since it was first implemented slightly over 3 years ago:
https://github.com/probot/stale/commit/a1ad9e97929d317b3cf9de25c6c6a718800888c9#diff-168726dbe96b3ce427e7fedce31bb0bcR19-R21

From a Slack conversation with @tcbyrd about this PR:

@JamesMGreene: Any insights here?
@tcbyrd: Not off the top of my head. We had a bad habit of not returning in early Probot code, which this is. I'm not sure how it all interacts with the scheduled timeouts, but definitely sounds like it could be a reason why it sometimes closes things that were unmarked or labeled to not close


We can have this cool login using Google and Github..

Add functionality to allow users to log in using their Google or GitHub accounts. This can be achieved by integrating services like Clerk or Cloudinary. The feature will enhance user experience by providing simple and secure third-party authentication options.

This issue is already open. Please have a look on all opened issues before opening a new one.


why check networdID in deleteNetwork function

   driver.networkID = ""
    emptyResponse(w)
    log.Infof("Deleting plugin cache for network %s", nid)

    if driver.networkID == "" {
            log.Errorf("invalid network id")
    }
    n := driver.network(driver.networkID)
    if n == nil {
            log.Errorf("could not find network with id %s in plugin cache", nid)
    }

this logic must print error log, but why?

You're spot on. Thanks for that. Btw, PR 964 is ipvlan in libnetwork for native support. Closing this out. Thanks!


Remove log tags

Rails' log_tag feature interferes with the log_rage JSON formatting, resulting in [log_tags] {log_rage} format. Since log_rage includes the request_id and anything else that log_tags could include we are not using log_tags in our application logging.
This also updates the log_rage configuration to add additional fields as per our other apps' configuration.
What problem does this pull request solve?
Trello: https://trello.com/c/dpoVXgXj/1361-fix-product-page-log-formatting
Makes produce-pages logging consistent with other apps. Improves the formatting for better searching and filtering within Splunk.
Things to consider when reviewing
Original log format:
I, [2023-12-05T08:57:38.265725 #1]  INFO -- : [2d913798-3786-4b45-b6c0-6eab5a4c2f4e] {"method":"GET","path":"/ping","format":"html","controller":"HeartbeatController","action":"ping","status":200,"allocations":132,"duration":0.39,"view":0.22}

After the change deployed to dev to check:
{"level":"INFO","time":"2023-12-05T11:58:58.129+00:00","method":"GET","path":"/get-started","format":"html","controller":"PagesController","action":"get_started","status":200,"allocations":3780,"duration":3.88,"view":3.36,"host":"www.dev.forms.service.gov.uk","user_ip":"<IP_ADDRESS>","request_id":"be1ab926-a860-4c7f-b90f-87111fa540b8"}

Deployed commit for the log line above (current head of this branch):
forms-product-page  COMPLETED  3        3        0        0       forms-product-page-deploy:development-branch-b809cf973d77ee7eaaad88c1b1cf636e70a3e28b-1701777195

We don't appear to set a session id on product-pages so the config does not include logging its hash.
Tests
We don't test the lograge setup or appending to payload in any of the other apps as far as I can see. There are tests for the EventLogger in admin and runner, but not the configuration of lograge nor for appending to the lograge payload within the base controller in some kind of request spec. I would gladly add such tests but after some experimentation I cannot see how to access the LogRage payload within an rpsec assertion on a request spec on the ApplicationController... I'm satisfied at present that the configuration works, tests would be useful for regression but this change aligns product-pages with the other apps' and I've tested it out in development environment (log extracts above).
Things to check:

Does it work when run on your machine?
Is it clear what the code is doing?
Do the commit messages explain why the changes were made?
Are there all the unit tests needed?
Has all relevant documentation been updated?

Thanks @thomasiles I've cherry-picked your commit onto this branch because I think it is useful


bug: actions.terminal doesn't work for ssh buffer

Did you check the docs and existing issues?

[X] I have read the docs
[X] I have searched the existing issues

Neovim version (nvim -v)
v0.9.1
Operating system/version
Linux 6.4.8-arch1-1 - Arch
Describe the bug
Can't open terminal window in an ssh oil buffer
Steps To Reproduce

Map actions.terminal to a key in the config
Open an ssh oil buffer with oil-ssh://
Press the key to launch terminal

Expected Behavior
Terminal should open with the remote shell, nothing happens.
Directory structure
No response
Repro
-- save as repro.lua
-- run with nvim -u repro.lua
-- DO NOT change the paths
local root = vim.fn.fnamemodify("./.repro", ":p")

-- set stdpaths to use .repro
for _, name in ipairs({ "config", "data", "state", "runtime", "cache" }) do
  vim.env[("XDG_%s_HOME"):format(name:upper())] = root .. "/" .. name
end

-- bootstrap lazy
local lazypath = root .. "/plugins/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
  vim.fn.system({
    "git",
    "clone",
    "--filter=blob:none",
    "--single-branch",
    "https://github.com/folke/lazy.nvim.git",
    lazypath,
  })
end
vim.opt.runtimepath:prepend(lazypath)

-- install plugins
local plugins = {
  "folke/tokyonight.nvim",
  {
        "stevearc/oil.nvim",
        config = function()
            require("oil").setup({
              -- add any needed settings here
            keymaps = {
                ["<leader>t"] = "actions.open_terminal",
            },

            })
        end,
  },
  -- add any other plugins here
}
require("lazy").setup(plugins, {
  root = root .. "/plugins",
})

vim.cmd.colorscheme("tokyonight")
-- add anything else here

Did you check the bug with a clean config?

[X] I have confirmed that the bug reproduces with nvim -u repro.lua using the repro.lua file above.

Should be fixed!

Thanks, is there way to either open terminal in a different buffer or go back to oil buffer from terminal?

I found a workaround for the latter question, require("oil.actions").open_terminal.callback()

If you're looking to open it in a different window, you can open the window however you like (e.g. vim.cmd.vsplit()) and then call the action require("oil.actions").open_terminal.callback()


CLI: Simplify provider-specific kube resources

Currently, the provider has to implement an AsObjects interface that
returns a slice of objects. The only implementation of this interface is
for AWS which is assiged to a variable of the interface type, which
forces a type assertion two lines later.
All of this is needlessly complicated, we can simply pass a slice of
client objects from the provider-specific part into the genreric part
instead.

What this PR does / why we need it:
Which issue(s) this PR fixes (optional, use fixes #<issue_number>(, fixes #<issue_number>, ...) format, where issue_number might be a GitHub issue, or a Jira story:
Fixes #
Checklist

[ ] Subject and description added to both, commit and PR.
[ ] Relevant issues have been referenced.
[ ] This change includes docs.
[ ] This change includes unit tests.

/retest

Thanks!
/lgtm


Send raw telemetry to Discovery Engine from Wasm Plugin

https://github.com/accuknox/dev2/pull/216

Moving to blocked due to https://github.com/5GSEC/SentryFlow/pull/17

Completed by https://github.com/5GSEC/SentryFlow/pull/17.


Refac workspace to follow rust guidelines.

This PR clarifies the rust workspace with its members:

liana: The lianad and liana-cli crate
liana-gui: The gui crate to build the graphical interface
liana-ui: A crate to quickly iterate on a design system

It allows to have coordination across crates easier, consistent build and shared dependency versions.
As a result the build processes in the guix container and the macos container are way faster as the dependencies are built only once.
The overall MSRV is changed for rust 1.71.1, which is the liana-gui MSRV.
Only one rust version is used for all the crates.
This PR is also a change of vision of the project. The liana daemon is not used as it is. It is too much cumbersome. It should be at the service of the future applications and for now at the service of the GUI.
The security aspects of the project should be aware of what the end user is using and in reality it is the liana-gui binary.

reviewed bc774e95 commit with this command to sort out move-only changes:
git diff --diff-filter=M b46efc6 bc774e95
diff --git a/Cargo.toml b/Cargo.toml
index c348d97..fdb819a 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -1,75 +1,7 @@
-[package]
-name = "liana"
-version = "8.0.0"
-authors = ["Antoine Poinsot<EMAIL_ADDRESS>-edition = "2018"
-repository = "https://github.com/wizardsardine/liana"
-license-file = "LICENCE"
-keywords = ["bitcoin", "wallet", "miniscript", "inheritance", "recovery"]
-description = "Liana wallet daemon"
-exclude = [".github/", ".cirrus.yml", "tests/",  "test_data/", "contrib/", "pyproject.toml"]
-
-[[bin]]
-name = "lianad"
-path = "src/bin/daemon.rs"
-required-features = ["daemon"]
-
-[[bin]]
-name = "liana-cli"
-path = "src/bin/cli.rs"
-required-features = ["daemon"]
-
-[features]
-default = ["daemon"]
-daemon = ["libc"]
-nonblocking_shutdown = []
-
-[dependencies]
-# For managing transactions (it re-exports the bitcoin crate)
-miniscript = { version = "11.0", features = ["serde", "compiler", "base64"] }
-
-# Coin selection algorithms for spend transaction creation.
-bdk_coin_select = "0.3"
-
-# For Electrum backend. This is the latest version with the same bitcoin version as
-# the miniscript dependency.
-bdk_electrum = { version = "0.14" }
-
-# Don't reinvent the wheel
-dirs = "5.0"
-
-# We use TOML for the config, and JSON for RPC
-serde = { version = "1.0", features = ["derive"] }
-toml = "0.5"
-serde_json = { version = "1.0", features = ["raw_value"] }
-
-# Logging stuff
-log = "0.4"
-fern = "0.6"
-
-# In order to have a backtrace on panic, because the
-# stdlib does not have a programmatic interface yet
-# to work with our custom panic hook.
-backtrace = "0.3"
-
-# Pinned to this version because they keep breaking their MSRV in point releases...
-# FIXME: this is unfortunate, we don't receive the updates (sometimes critical) from SQLite.
-rusqlite = { version = "0.30", features = ["bundled", "unlock_notify"] }
-
-# To talk to bitcoind
-jsonrpc = { version = "0.17", features = ["minreq_http"], default-features = false }
-
-# Used for daemonization
-libc = { version = "0.2", optional = true }
-
-# Used for generating mnemonics
-getrandom = "0.2"
-
-# Used for the hot signer
-bip39 = "2.0"
-
-# Additional entropy for generating mnemonics
-[target.'cfg(target_arch = "x86")'.dependencies]
-rdrand = "0.8"
-[target.'cfg(target_arch = "x86_64")'.dependencies]
-rdrand = "0.8"
+[workspace]
+resolver = "2"
+members = [
+  "liana",
+  "liana-gui",
+  "liana-ui",
+]

ACK 6175ca7b58324a19ba7d8309fac4f18e6a07c178


Helm upgrade failed: cannot patch "certificates.cert-manager.io" with kind CustomResourceDefinition: "" is invalid.

Describe the bug:

I am experiencing a failed upgrade from 1.2.0 to 1.3.0 with Helm.
Error: cannot patch "certificates.cert-manager.io" with kind CustomResourceDefinition:  "" is invalid: patch: Invalid value:
...
cannot convert int64 to float64

This seems identical to https://github.com/jetstack/cert-manager/issues/3644 so not sure if I should have reopened that one. Although that issue should have been fixed.
Expected behaviour:

I expected the crd to be patched correctly.
Steps to reproduce the bug:

Upgrade cert-manager from 1.2.0 to 1.3.0 with Helm
Environment details::

Kubernetes version: 1.18.8
Cloud-provider/provisioner: AKS
cert-manager version: 1.3.0
Install method: e.g. helm/static manifests: Helm with terraform provider

/kind bug

Hi @Flasheh ,
Thank you very much for opening the issue!
I can reproduce this on my v1.20  kind cluster.
Steps to reproduce the issue:
helm install   cert-manager jetstack/cert-manager   --namespace cert-manager --create-namespace --version v1.2.0 --set installCRDs=true
helm upgrade cert-manager jetstack/cert-manager   --namespace cert-manager --version v1.3.0 --set installCRDs=true
We will look at fixing this ASAP.
We are also currently looking at having automated upgrade tests with releases, so hopefully there should be less of these kind of issues in the future!
I assume this might be the same problem with another CRD field.

/assign

Appears to be an issue with the new revisionHistoryLimit field that has a minimum value of 1.

I was not able to reproduce the issue, what steps should I take to have the error show up?

🧵 Shell commands I used to do the 1.2 → 1.3 update with installCRDs=true
The upgrade test:
#! /usr/bin/env bash
set -ueo pipefail

export KUBECONFIG=/tmp/ugpradetest

k3d cluster delete ugpradetest || true
k3d cluster create ugpradetest

helm repo list | grep -q jetstack || helm repo add jetstack https://charts.jetstack.io

# STEP 1: install the old version.
TAG=v1.2.0
helm upgrade --install cert-manager jetstack/cert-manager --version $TAG --set installCRDs=true
kubectl wait --for=condition=available deploy/cert-manager-webhook --timeout=3m
kubectl get deploy -owide

# STEP 2: smoke test using a self-signed issuer.
kubectl apply -f- <<EOF
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: smoketest-selfsigned-issuer
spec:
  selfSigned: {}
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: smoketest-cert
spec:
  secretName: smoketest-cert-tls
  commonName: smoketest-cert
  dnsNames:
  - example.com
  issuerRef:
    name: smoketest-selfsigned-issuer
    kind: Issuer
EOF
kubectl wait --for=condition=ready certificate smoketest-cert

# STEP 3: upgrade to a newer tag.
TAG=v1.3.0
helm upgrade --install cert-manager jetstack/cert-manager --version $TAG --set installCRDs=true
kubectl wait --for=condition=available deploy/cert-manager-webhook --timeout=3m
kubectl get deploy -owide

# STEP 4: smoke test the reissuance of an old certificate.
kubectl cert-manager renew smoketest-cert
kubectl wait --for=condition=issuing=true certificate smoketest-cert
kubectl wait --for=condition=ready=true certificate smoketest-cert

% ./mine/manual-upgrade-tests.sh
INFO[0000] Deleting cluster 'ugpradetest'
INFO[0000] Deleted k3d-ugpradetest-serverlb
INFO[0001] Deleted k3d-ugpradetest-server-0
INFO[0001] Deleting cluster network 'k3d-ugpradetest'
INFO[0001] Deleting image volume 'k3d-ugpradetest-images'
INFO[0001] Removing cluster details from default kubeconfig...
INFO[0001] Removing standalone kubeconfig file (if there is one)...
INFO[0001] Successfully deleted cluster ugpradetest!
INFO[0000] Prep: Network
INFO[0000] Created network 'k3d-ugpradetest'
INFO[0000] Created volume 'k3d-ugpradetest-images'
INFO[0001] Creating node 'k3d-ugpradetest-server-0'
INFO[0001] Creating LoadBalancer 'k3d-ugpradetest-serverlb'
INFO[0001] Starting cluster 'ugpradetest'
INFO[0001] Starting servers...
INFO[0001] Starting Node 'k3d-ugpradetest-server-0'
INFO[0008] Starting agents...
INFO[0008] Starting helpers...
INFO[0008] Starting Node 'k3d-ugpradetest-serverlb'
INFO[0009] (Optional) Trying to get IP of the docker host and inject it into the cluster as 'host.k3d.internal' for easy access
INFO[0012] Successfully added host record to /etc/hosts in 2/2 nodes and to the CoreDNS ConfigMap
INFO[0012] Cluster 'ugpradetest' created successfully!
INFO[0012] --kubeconfig-update-default=false --> sets --kubeconfig-switch-context=false
INFO[0012] You can now use it like this:
kubectl config use-context k3d-ugpradetest
kubectl cluster-info
Release "cert-manager" does not exist. Installing it now.
NAME: cert-manager
LAST DEPLOYED: Mon Apr 12 10:22:52 2021
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
cert-manager has been deployed successfully!

In order to begin issuing certificates, you will need to set up a ClusterIssuer
or Issuer resource (for example, by creating a 'letsencrypt-staging' issuer).

More information on the different types of issuers and how to configure them
can be found in our documentation:

https://cert-manager.io/docs/configuration/

For information on how to configure cert-manager to automatically provision
Certificates for Ingress resources, take a look at the `ingress-shim`
documentation:

https://cert-manager.io/docs/usage/ingress/
deployment.apps/cert-manager-webhook condition met
NAME                      READY   UP-TO-DATE   AVAILABLE   AGE     CONTAINERS     IMAGES                                            SELECTOR
cert-manager              0/1     1            0           2m33s   cert-manager   quay.io/jetstack/cert-manager-controller:v1.2.0   app.kubernetes.io/component=controller,app.kubernetes.io/instance=cert-manager,app.kubernetes.io/name=cert-manager
cert-manager-cainjector   1/1     1            1           2m33s   cert-manager   quay.io/jetstack/cert-manager-cainjector:v1.2.0   app.kubernetes.io/component=cainjector,app.kubernetes.io/instance=cert-manager,app.kubernetes.io/name=cainjector
cert-manager-webhook      1/1     1            1           2m33s   cert-manager   quay.io/jetstack/cert-manager-webhook:v1.2.0      app.kubernetes.io/component=webhook,app.kubernetes.io/instance=cert-manager,app.kubernetes.io/name=webhook
issuer.cert-manager.io/smoketest-selfsigned-issuer created
certificate.cert-manager.io/smoketest-cert created
certificate.cert-manager.io/smoketest-cert condition met
Release "cert-manager" has been upgraded. Happy Helming!
NAME: cert-manager
LAST DEPLOYED: Mon Apr 12 10:25:36 2021
NAMESPACE: default
STATUS: deployed
REVISION: 2
TEST SUITE: None
NOTES:
cert-manager has been deployed successfully!

In order to begin issuing certificates, you will need to set up a ClusterIssuer
or Issuer resource (for example, by creating a 'letsencrypt-staging' issuer).

More information on the different types of issuers and how to configure them
can be found in our documentation:

https://cert-manager.io/docs/configuration/

For information on how to configure cert-manager to automatically provision
Certificates for Ingress resources, take a look at the `ingress-shim`
documentation:

https://cert-manager.io/docs/usage/ingress/
deployment.apps/cert-manager-webhook condition met
NAME                      READY   UP-TO-DATE   AVAILABLE   AGE     CONTAINERS     IMAGES                                            SELECTOR
cert-manager-cainjector   1/1     1            1           2m49s   cert-manager   quay.io/jetstack/cert-manager-cainjector:v1.3.0   app.kubernetes.io/component=cainjector,app.kubernetes.io/instance=cert-manager,app.kubernetes.io/name=cainjector
cert-manager              1/1     1            1           2m49s   cert-manager   quay.io/jetstack/cert-manager-controller:v1.3.0   app.kubernetes.io/component=controller,app.kubernetes.io/instance=cert-manager,app.kubernetes.io/name=cert-manager
cert-manager-webhook      1/1     1            1           2m49s   cert-manager   quay.io/jetstack/cert-manager-webhook:v1.3.0      app.kubernetes.io/component=webhook,app.kubernetes.io/instance=cert-manager,app.kubernetes.io/name=webhook
Manually triggered issuance of Certificate default/smoketest-cert
certificate.cert-manager.io/smoketest-cert condition met
certificate.cert-manager.io/smoketest-cert condition met

Note: I really need to add a "manual upgrade check" step to our release-process; even better, we should have that automated 😅

@maelvls FWIW last time we had that issue not all of us could reproduce it.

@maelvls @irbekrm It seems to be related to kubernetes version somehow.
I could not reproduce it locally either using k3d until i set it to the same minor version as one of the AKS clusters I tested.
k3d cluster create ugpradetest --image rancher/k3s:v1.18.13-k3s1
Using that image results in the same failed upgrade,

@maelvls can you reproduce it with Kubernetes < v1.20?
I think my late night debugging yesterday got me confused as to which version I am working against 😆
It seems like this has been fixed in v1.20 as Helm folks say, see this comment

Ohhh I was able to reproduce the issue with Kubernetes v1.19.9!!

👉 Commands to reproduce
#! /usr/bin/env bash
set -ueo pipefail

export KUBECONFIG=/tmp/ugpradetest

k3d cluster delete ugpradetest || true
k3d cluster create ugpradetest --image=docker.io/rancher/k3s:v1.19.9-k3s1

helm repo list | grep -q jetstack || helm repo add jetstack https://charts.jetstack.io

# STEP 1: install the old version.
TAG=v1.2.0
helm upgrade --install cert-manager jetstack/cert-manager --version $TAG --set installCRDs=true
kubectl wait --for=condition=available deploy/cert-manager-webhook --timeout=3m
kubectl get deploy -owide

# STEP 2: smoke test using a self-signed issuer.
kubectl apply -f- <<EOF
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: smoketest-selfsigned-issuer
spec:
  selfSigned: {}
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: smoketest-cert
spec:
  secretName: smoketest-cert-tls
  commonName: smoketest-cert
  dnsNames:
  - example.com
  issuerRef:
    name: smoketest-selfsigned-issuer
    kind: Issuer
EOF
kubectl wait --for=condition=ready certificate smoketest-cert

# STEP 3: upgrade to a newer tag.
TAG=v1.3.0
helm upgrade --install cert-manager jetstack/cert-manager --version $TAG --set installCRDs=true
kubectl wait --for=condition=available deploy/cert-manager-webhook --timeout=3m
kubectl get deploy -owide

# STEP 4: smoke test the reissuance of an old certificate.
kubectl cert-manager renew smoketest-cert
kubectl wait --for=condition=issuing=true certificate smoketest-cert
kubectl wait --for=condition=ready=true certificate smoketest-cert

% ./mine/manual-upgrade-tests.sh
INFO[0000] Deleting cluster 'ugpradetest'
INFO[0000] Deleted k3d-ugpradetest-serverlb
INFO[0010] Deleted k3d-ugpradetest-server-0
INFO[0010] Deleting cluster network 'k3d-ugpradetest'
INFO[0010] Deleting image volume 'k3d-ugpradetest-images'
INFO[0010] Removing cluster details from default kubeconfig...
INFO[0010] Removing standalone kubeconfig file (if there is one)...
INFO[0010] Successfully deleted cluster ugpradetest!
INFO[0000] Prep: Network
INFO[0000] Created network 'k3d-ugpradetest'
INFO[0000] Created volume 'k3d-ugpradetest-images'
INFO[0001] Creating node 'k3d-ugpradetest-server-0'
INFO[0004] Pulling image 'docker.io/rancher/k3s:v1.19.9-k3s1'
INFO[0060] Creating LoadBalancer 'k3d-ugpradetest-serverlb'
INFO[0060] Starting cluster 'ugpradetest'
INFO[0060] Starting servers...
INFO[0060] Starting Node 'k3d-ugpradetest-server-0'
INFO[0066] Starting agents...
INFO[0066] Starting helpers...
INFO[0066] Starting Node 'k3d-ugpradetest-serverlb'
INFO[0067] (Optional) Trying to get IP of the docker host and inject it into the cluster as 'host.k3d.internal' for easy access
INFO[0068] Successfully added host record to /etc/hosts in 2/2 nodes and to the CoreDNS ConfigMap
INFO[0068] Cluster 'ugpradetest' created successfully!
INFO[0068] --kubeconfig-update-default=false --> sets --kubeconfig-switch-context=false
INFO[0068] You can now use it like this:
kubectl config use-context k3d-ugpradetest
kubectl cluster-info
Release "cert-manager" does not exist. Installing it now.
NAME: cert-manager
LAST DEPLOYED: Mon Apr 12 13:57:11 2021
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
cert-manager has been deployed successfully!

In order to begin issuing certificates, you will need to set up a ClusterIssuer
or Issuer resource (for example, by creating a 'letsencrypt-staging' issuer).

More information on the different types of issuers and how to configure them
can be found in our documentation:

https://cert-manager.io/docs/configuration/

For information on how to configure cert-manager to automatically provision
Certificates for Ingress resources, take a look at the `ingress-shim`
documentation:

https://cert-manager.io/docs/usage/ingress/
deployment.apps/cert-manager-webhook condition met
NAME                      READY   UP-TO-DATE   AVAILABLE   AGE     CONTAINERS     IMAGES                                            SELECTOR
cert-manager-cainjector   0/1     1            0           2m43s   cert-manager   quay.io/jetstack/cert-manager-cainjector:v1.2.0   app.kubernetes.io/component=cainjector,app.kubernetes.io/instance=cert-manager,app.kubernetes.io/name=cainjector
cert-manager              0/1     1            0           2m43s   cert-manager   quay.io/jetstack/cert-manager-controller:v1.2.0   app.kubernetes.io/component=controller,app.kubernetes.io/instance=cert-manager,app.kubernetes.io/name=cert-manager
cert-manager-webhook      1/1     1            1           2m43s   cert-manager   quay.io/jetstack/cert-manager-webhook:v1.2.0      app.kubernetes.io/component=webhook,app.kubernetes.io/instance=cert-manager,app.kubernetes.io/name=webhook
Error from server (InternalError): error when creating "STDIN": Internal error occurred: failed calling webhook "webhook.cert-manager.io": Post "https://cert-manager-webhook.default.svc:443/mutate?timeout=10s": x509: certificate signed by unknown authority
Error from server (InternalError): error when creating "STDIN": Internal error occurred: failed calling webhook "webhook.cert-manager.io": Post "https://cert-manager-webhook.default.svc:443/mutate?timeout=10s": x509: certificate signed by unknown authority

Ohhh you are right, I was able to reproduce the issue with Kubernetes v1.19.9!! wait for a minute

Hopefully not another issue?

Folks, we have implemented a fix (hopefully) for this issue in #3882 .
We are now going to make a patch release for v1.3.0 with the fix #3886  so hopefully everyone will be able to upgrade.
Apologies for the inconvenience and a massive thanks to @Flasheh for raising the issue!

We have now released a patch that should fix this issue https://github.com/jetstack/cert-manager/releases/tag/v1.3.1
Do let us know if there are more issues.

I came trying to upgrade from v1.9.1 to v1.10.2 (Kubernetes v1.24.8, Helm v3.10.3).  My first two attempts failed with
Error: UPGRADE FAILED: release cert-manager failed, and has been rolled back due to atomic being set: cannot patch "certificates.cert-manager.io" with kind CustomResourceDefinition: Timeout: request did not complete within requested timeout - context deadline exceeded

The third attempt succeeded.
After the second attempt, I diffed the v1.9.1 manifest against the output of helm template for v1.10.2 (using the same set of command line options as the upgrade).  The diff was huge but I noticed that that was mostly caused by a different ordering of the resources.
Seeing that several people, including myself, have trouble reproducing this, I was wondering whether the resource ordering is stable and, if not, that might be a cause for this error.  Just a thought.


fix roundrobin_router when access the maximum of int32 will produce a…

… minus index value which will cause panic

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

maybe "let it crash" ?

The method [roundRobinRoutee]just used by [RouteMessage],and input param index *int32is only &state.index which default minimum value is 0.
Because unique creation method is [source code]：
func (config *roundRobinPoolRouter) CreateRouterState() Interface {
	return &roundRobinState{}
}

So，i think this modification is unnecessary at present .

Nice catch!
@alex023 The index field is incremented each time a message is sent. So if index is int32 max, i will overflow to a negative (int32 min), which after modulus becomes a negative index in the array access :)

@alex023 It's not about the minimum value of state.index, it's about the maximum value of state.index

Oh, I did not think about that。v_v


add regression test for rmi multiple tags without f

regression test to show https://github.com/docker/docker/issues/12135 does not exist

LGTM

LGTM


#2 Fixed Delphi package and created a Delphi test project (and project group)

Please check it out.

@nunopicado thank you.


Black background around image frame

Curious if you have encountered issues where your resized images have a pesky black background around them. Despite setting the background to array(255,255,255) I cannot seem to get rid of this black area around the frame....
    /**
     * Return the URL for the image SRC
     *
     * @param Mage_Catalog_Model_Category $object
     * @return string
     */
    public function getImageUrl($category)
    {
        /* @var $img FirstScribe_Client_Helper_Catalog_Category_Image */
        $img = Mage::helper('firstscribe_client/catalog_category_image');
        $img->init($category, 'featured_image');
        $img->keepFrame(true);
        $img->keepTransparency(true);
        $img->keepAspectRatio(true);
        $img->backgroundColor(array(255,255,255));
        $img->resize(250);

        return $img->__toString();
    }

Example Result:

The image helper itself is a class only very slightly modified from your typical UMC image helper, geared towards catalog/category entities. I've extended it just enough to support the necessary paths:
<?php
/**
 * catalog/category image helper
 *
 * @category    FirstScribe
 * @package     FirstScribe_Client
 * @author      Darren Felton<EMAIL_ADDRESS> */
class FirstScribe_Client_Helper_Catalog_Category_Image extends FirstScribe_Client_Helper_Catalog_Image_Abstract
{
    /**
     * image subdir
     * @var string
     */
    protected $_subdir = 'catalog/category';

}

<?php
/**
 * abstract catalog module image helper
 *
 * @category    FirstScribe
 * @package     FirstScribe_Client
 * @author      Darren Felton<EMAIL_ADDRESS> */
abstract class FirstScribe_Client_Helper_Catalog_Image_Abstract extends FirstScribe_Client_Helper_Image_Abstract
{
    /**
     * get the image base dir
     *
     * @access public
     * @return string
     */
    public function getImageBaseDir()
    {
        return Mage::getBaseDir('media').DS.$this->_subdir.DS;
    }

    /**
     * get the image url for object
     *
     * @access public
     * @return string
     */
    public function getImageBaseUrl()
    {
        return Mage::getBaseUrl('media').$this->_subdir.'/';
    }

    /**
     * get image url
     *
     * @access protected
     * @return mixed (string|bool)
     */
    protected function _getImageUrl()
    {
        if (!$this->_image) {
            return false;
        }
        if ($this->_scheduledResize) {
            return $this->getImageBaseUrl().$this->_resizeFolderName.'/'.$this->_getDestinationImagePrefix().'/'.$this->_image;
        } else {
           return $this->getImageBaseUrl().$this->_image;
        }
    }

}

Finally FirstScribe_Client_Helper_Image_Abstract is the typical UMC abstract image helper
After an hour of banging my head to the wall I did find this article which is regarding this exact same topic but copying Varien_Image_Adapter_G2 to my local codePool and performing the modifications in the article yielded no results.
Any thoughts here? Have your image resizing with $imgHelper->keepFrame(true) parameter encountered this issue before?

I've narrowed down the true source of the problem. Magento's very own Varien_Image_Adapter_Abstract::backgroundColor() method is intended to be a getter/setter but the $this->_backgroundColor = $value statement is mistakenly not inside the method's main if statement. I don't know if this is a newly introduced bug of Magento or not... don't really care I guess, but I'll submit a report to them about it.
Until Magento fixes their own code, it wasn't too hard to revise the UMC generated abstract image helper to accommodate for the bug in the Varien image processor. If I have time I'll try to update my branch of your extension and create a pull request.
Just need to add this code to your Abstract Image Helper
    /**
     * background color (r,g,b)
     * @var array
     */
    protected $_backgroundColor = array(255, 255, 255);

Then revise your backgroundColor() method to accomodate for Varien's inability to serve as a proper getter/setter.
    /**
     * Get/set keepBackgroundColor
     *
     * @access public
     * @param array $value
     * @return mixed(bool|{{Namespace}}_{{Module}}_Helper_Image_Abstract)
     */
    public function backgroundColor($value = null)
    {
        if ($value !== null) {
            $this->_backgroundColor = $value;
        }

        return $this->_getImageProcessor()->backgroundColor($this->_backgroundColor);
    }

Just killing the subject a bit more...
Looks like someone already reported the main issue here.
Anyways, solution for UMC until Magento get's their sh*t together provided above :)  I'll create a pull request if you don't beat me to it.

@dfelton Feel free to open a PR. This project is kind of suspended for now from my point of view. I don't have time to add more things to it.

@tzyganu
Hello Marius.
Just want to extend one final thank you regarding your UMC 1.9. It came in handy again this year when I was working on a project. Also very much impressed my colleagues when I showed them your tool.
I'm going to close this issue mainly so that it can disappear from my own Issues page.
Cheers.


Local support

Me and a few people have successfully got our Panasonic AC local and away from cloud comfort.
It works faster, it's more reliable, it's local and it has the same climate integration and features you would expect.
And thanks to espthings for designing the circuit board with esp32 and logic converter it can be connected to the AC plug and play. No more AC going offline due to a version mismatch or an API changing!
Yesterday I finished designing the case for it. (Still need to get some blue filement though)
I would highly recommend checking it out. Its more then worth it!

Great to hear!
I'm fed up with the unreliability of the PCC app lately and now it seems they are blocking my IP address (from my home WiFi I can't access PCC App, switching to 4G I can).
So I am starting soldering today! I have 8 units in my home.

Definitely that's exciting and interesting news. I'd love to move local and not be reliant on the cloud. Where can we check out your work please?

That certainly is interesting. I would very much liek to be able to control the thermostat without reliance on the cloud.  Where can we check it out / find out more please?

https://github.com/DomiStyle/esphome-panasonic-ac/tree/dev-cztacg1

Awesome work, thank you!

Thank you but i don't have access to a printer. Also if I understand it correctly the module will fit into the original case :-)

Who can I contact to get a couple of those, please? I have two A/C’s and none of them are stable in HA. I really need it to keep the WAF at a satisfying level.

since i have been using these modules not once had problems. The integration on this page is nice but it is more a temporary fix. Everytime panasonic changes anything to the app or the cloud the AC will fall of the grid again.
This is the link to the guy who makes them. He has only one left. You can make them yourself. I did so using hardware for a few bucks. https://www.espthings.io/index.php/2021/08/03/esp32-based-panasonic-airconditioning-wifi-interface/
This is the link to make them yourself: https://github.com/DomiStyle/esphome-panasonic-ac

I think the issue can be closed now as it's clear where to get local support.


Adds support for hint text on select inputs in Dialogs.

While it's not explicitly called out in their documentation, it is
supported (tested empirically), and it's shown in screenshots on
https://api.slack.com/best-practices/creating-useful-dialogs

LGTM, thanks.


Depend on faraday 0.8.X as 0.9.0 breaks compatibility

0.9.0 seems to have changed how open_timeout is handled, so running the
test suite with 0.9.0 raises the following error:
NoMethodError: undefined method `open_timeout=' for
#<Faraday::ConnectionOptions:0x007ff0220da470>

superseded by #30


Return meaningful exit status depending on compilation result

Thanks for making the awesome qb!
This pull request changes qb so that when compilation fails or qb encounters other errors, exit with the exit code of 1 instead of just doing return from main which seems to result in the exit code 0.
This will enable doing things like qb && ./program in order to compile the program and then run it if but only if compilation was successful.
Also I am including a fix that I needed to do in order to compile qb. I believe the regression was introduced in 29539608bd391d8383aa0b0650f99ad35829b2e2. You might want to check compiler_darwin.go too.

Thank you! 🎉


Bump minimal required Maven version from 3.2.3 to 3.2.5

@mbiarnes could you please take a look? We need to upgrade the Jenkins jobs to use the newer Maven version. I believe I did most of the updates already, but if you find anything else that is missing, please let me know.

+1


Fixed #26267 -- Fixed BoundField to reallow slices of subwidgets.

https://code.djangoproject.com/ticket/26267

add "reallow" to docs/spelling_wordlist

By the way, the "1.8.x" prefix is only for commits on the stable branch. Now that your PR is to master, you can drop it.

merged in b41268135995cef46d40e550f9301fab20cf330d, thanks!


mm-common: 1.0.2 -> 1.0.3

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for mm-common is: "Common build files of GLib/GTK C++ bindings"
meta.homepage for mm-common is: "https://www.gtkmm.org"
meta.changelog for mm-common is: ""
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

Warning: no invocation of /nix/store/bbs3bdfwcxjh7qjnr4gdlwsqn6j1xddv-mm-common-1.0.3/bin/mm-common-get had a zero exit code or showed the expected version

/nix/store/bbs3bdfwcxjh7qjnr4gdlwsqn6j1xddv-mm-common-1.0.3/bin/mm-common-prepare passed the binary check.

1 of 2 passed binary check by having a zero exit code.

1 of 2 passed binary check by having the new version present in output.

found 1.0.3 with grep in /nix/store/bbs3bdfwcxjh7qjnr4gdlwsqn6j1xddv-mm-common-1.0.3

found 1.0.3 in filename of file in /nix/store/bbs3bdfwcxjh7qjnr4gdlwsqn6j1xddv-mm-common-1.0.3

directory tree listing: https://gist.github.com/d583144a5bd25f5fcf072cc88b30c704

du listing: https://gist.github.com/b28df198c81f7467fc87176c600f92c7

Rebuild report (if merged into master) (click to expand)

6 total rebuild path(s)

2 package rebuild(s)

2 x86_64-linux rebuild(s)
2 i686-linux rebuild(s)
0 x86_64-darwin rebuild(s)
2 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
glom
mm-common

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/bbs3bdfwcxjh7qjnr4gdlwsqn6j1xddv-mm-common-1.0.3 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A mm-common https://github.com/r-ryantm/nixpkgs/archive/65fb0203850fe824763f545e72dfef420a08295c.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/bbs3bdfwcxjh7qjnr4gdlwsqn6j1xddv-mm-common-1.0.3
ls -la /nix/store/bbs3bdfwcxjh7qjnr4gdlwsqn6j1xddv-mm-common-1.0.3/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

2 packages built:

glom
mm-common

Maintainer pings
cc @hedning @jtojnar @dasj19 @maxeaubrey for testing.

@ofborg eval


Update release notes for v1.6.1

@MikeHart85, do you want to incorporate #963 into the release notes too?

Yes, adding that as well.
I think we should also merge in #969 if possible. The change looks good to me, given the discussion in the issue, but another pair of eyes would be great. Could someone else also have a look and hit the merge button?

Good point. Done.

I think this is ready to merge, unless there are any other PRs we want to include?
If everything looks ready to go, I'll proceed with the release as soon as someone merges these notes.


Task: create example API <-> web site connection

Plan
As requested in today's meeting by @grayside, @engelke and myself should collaborate to create an example connection between the API and the website.
We're aiming to have an example (hard-coded) response for at least one API resource (likely Campaigns) available by Wednesday evening. We can then integrate that response into the frontend.
Observations + questions

The content-api folder seems to demonstrate the API itself converting from HTTP requests to Python objects. @engelke is this something we can rely on? (It makes my job significantly easier vs. having the website parse HTTP responses, but I don't want to rely on this without asking.)
The website currently uses this file to store sample data. (This is being moved to website/sample_data.py in this PR). I assume the datatypes we use in this [initial] demo will be either the same as those, or fairly similar?

This was completed some time ago.


DNS Proxy support hosts

Hello,
Please support hosts at DNS Proxy, it would be great to add new or overwrite existing address records (could be used as ad blocker)
Thank you.

Please refer to https://gost.run/en/tutorials/dns/#custom-domain-name-resolution


How to make a "loading popup", to be closed at the end of processing or timeout

Hello,
Not a bug but a question about usage.
I wish to open a popup during a http request / answer processing
and then to close programatically the popup (or after timeout).
How to ?
Best regards.

Hello, branch is dead ?


regulation of VEGF rec. sign. path.

I'd like to request three new terms to describe
regulation of the VEGF receptor signaling pathway:
New terms and definitions (all zfin:DH):
regulation of vascular endothelial growth factor
receptor signaling pathway (GO:NEW):
Any process that modulates the frequency, rate or
extent of vascular endothelial growth factor receptor
signaling pathway activity.
positive regulation of vascular endothelial growth
factor receptor signaling pathway (GO:NEW):
Any process that activates or increases the rate of
vascular endothelial growth factor receptor signaling
pathway activity.
negative regulation of vascular endothelial growth
factor receptor signaling pathway (GO:NEW):
Any process that stops, prevents or reduces the rate of
vascular endothelial growth factor receptor signaling
pathway activity.
These defs have been modeled after those for the
analogous terms for the fgf receptor signaling pathway.
the 'regulation of....' term should be a part-of child
of GO:0048010 'vascular endothelial growth factor
receptor signaling pathway'.  The + and - regulation of
terms should each be isa children of the 'regulation
of...' term.
Each of the new terms should have an exact synonym
using 'VEGF' as an acronym for vascular endothelial
growth factor.
Keep up the good work!
-Doug
Reported by: doughowe
Original Ticket: "geneontology/ontology-requests/1709":https://sourceforge.net/p/geneontology/ontology-requests/1709

thanks www.movied.org


Play buttons do not appear in tutorial for IE9

Repro steps:

Launch tutorial in IE9
Scroll down to a "playable" snippet, e.g. the first one under Backbon.Events

Expected:
Play button appears. Clicking it plays the demo.
Observed:
No play button appears.
Note that setting the page to IE8 mode resolves the issue.

There's a fix for this (apparently) currently on master. It will go out to Backbonejs.org on the next release.


Fetch'-ing on Darwin retrieves .tar.gz instead of .dmg

Typo in: missing ( ) to combine the check.

name: get JDK tarball (as tar.gz file)

Change:
when: ansible_pkg_mgr != "yum" or ansible_pkg_mgr != "zypper" and ansible_os_family != 'Darwin'
Into:
when: (ansible_pkg_mgr != "yum" or ansible_pkg_mgr != "zypper") and ansible_os_family != 'Darwin'

See PR #39 . It has been there for ages now with no sign of actually being accepted.


Lint yaml

jenkins test dev-centos7_cluster

jenkins test dev-docker_cluster

jenkins test luminous-centos7_cluster

jenkins test luminous-docker_cluster

unrelated failures

This PR has broken all Debian/Ubuntu development deployments because the handler isn't executed after the development repo is added. This means that when attempting to install a development version of Ceph in Ubuntu, we will see 10.2.10 being installed


I tried it it doesnt work

The prefixing doesnt work at all

Give us some more info

in cmd it said that he finished , and I find a new file in the folder dist but when I check the file I dont find any prefixes

@Soularix Give us your css file

How you add Autoprefixer to your project? You use gulp-postcss or what? What do you write in your project to add Autoprefixer?

css file :
body {
font-family: Tahoma;
font-weight: normal;
line-height: 1.7;
background: #F1F6F5;
font-size:14px;
border-radius:10px;
}
gulptask :
gulp.task('prefixing', function() {
return gulp.src('css/style.css')
.pipe(autoprefixer())
.pipe(gulp.dest('dist'));
});
when I run gulp prefixing it does create a style.css file in dist but without adding border-radius prefix

That's because by default autoprefixer adds prefixes to this browsers > 1%, last 2 versions, Firefox ESR, Opera 12.1. They all supports border-radius without prefixes. You can try add animation property for visible result.

I tried transition also

The same thing
http://caniuse.com/#feat=css-transitions

ah last 2 versions , well ty TrySound ;)


give me ksma

DkSM9gHmXgvw39mQUrwFxVDqUuK7bA2MGjbD85b5k3dA5T6

here are the instructions for the faucet, https://github.com/kusamanetwork/faucet this is the wrong repo.


whit if the model has subsample , just change the timming ?

whit if the model has subsample , just change the timming ?

soved by subsample


fix: Recommendations chunks ordering answers

Fixes issue where recommendation chunks were ordering any answers that they were attached to.
Fixes namespaces for the mappers

Added unit tests 👍


Add support for importModuleSpecifierEnding options

I have in my  project webpack.config.js:
const SRC = join(__dirname, `src`);
module.exports = {
// <some params><some params>
  resolve: {
    extensions: [`.jsx`, `.js`],
    modules: [
      SRC,
      `node_modules`,
    ],
  },
// <other params>
}

Relative import autocomplete work well:
import Test from ../test/test.jsx;
When i type ../test popup appears with relative suggestion from current file to test.jsx and it is ok.
But if i type:
import Test from components/test - vim doesn't understand me and doesn't suggest  from from <projectRoot>/src/components/... as i want.
How can i solve this problem?

I found a solution. Plugin work perfect. Just need add tsconfig.json with:
{
  "compilerOptions": {
    "allowJs": true,
    "baseUrl": "./src"
  }
}

Another problem: plugin doesn't suggest file extension.
I found this commit:
https://github.com/microsoft/vscode/pull/90405/files
@chemzqm, can you add support for  "javascript.preferences.importModuleSpecifierEnding"  and "typescript.preferences.importModuleSpecifierEnding" options please?

@chemzqm, after you update I'm just added "javascript.preferences.importModuleSpecifierEnding": "js" to my coc-settings.json and all auto imports and code suggesting works as it should - perfect.
Thank you!


Full-density based model in OpenCL

Fixes #35
Implements the full-density based model according to https://pubs.acs.org/doi/10.1021/acs.jcim.1c01323 in OpenCL, with all of the different vdW damping methods consistent with the CPU code.
Additionally, there is some code reorganization in the OpenCL code. Particurlarly in ocl.field, there is an added new class called DataGrid with methods for easily getting all the required data (electron densities, hartree potential) from disk to the device memory and back, as well as providing some methods to access operations on the OpenCL device.
Also changes the convolution integral into a cross-correlation, which gets rid of an array reversal.

@NikoOinonen Before I do to review, I would like to ask about ppafm_gui.py in current master branch. When I just run it  without any installation it fails, and before it was working. Do you have idead what is the problem? I guess it is due to some reorganization you did
(Maybe I can make new issue for this? but anyway)
prokophapala@prokophapala-Lenovo-ideapad-Y700-15ISK:~/git/ppafm/ppafm/cli/gui$ ./ppafm_gui.py
Traceback (most recent call last):
  File "/home/prokophapala/git/ppafm/ppafm/cli/gui/./ppafm_gui.py", line 16, in <module>
    import ppafm.common as PPU
ModuleNotFoundError: No module named 'ppafm'

@ProkopHapala I did not implement this in the GUI yet. I want to do it at some point, but I will have to think how to best interface it with all of the required input files and parameters etc.
I looked at the differences between the OCL and CPU calculated force fields, and they are almost identical. The final scans look a bit different, but I think this is actually due to some difference in the relaxation parameters (which is something that should be investigated).
CPU:

OCL:

The different Tip_z is due to different calculation of the distance (which I actually think is bugged in plot_results.py)

I looked at the differences between the OCL and CPU calculated force fields, and they are almost identical. The final scans look a bit different, but I think this is actually due to some difference in the relaxation parameters

Yes, I also think so


Webhook doesn't fire on creation or deletion of a repository that does not belong to an organisation

Steps to reproduce

Set up a default webhook; in my case, I used a Gitea webhook with JSON POST, but I would be surprised if the details mattered.
Create a new repository under a user, i.e. outside of an organisation.

Expected behaviour
A repository webhook event is sent to signal the creation of the new repository.
Actual behaviour
No webhook call.
Repository creation and deletion events are only executed when the repo belongs to an organisation:
https://github.com/go-gitea/gitea/blob/2c5b3c72e8ebdf94ac764267fa78e4a0c5e93dc6/modules/notification/webhook/webhook.go#L102
https://github.com/go-gitea/gitea/blob/2c5b3c72e8ebdf94ac764267fa78e4a0c5e93dc6/modules/notification/webhook/webhook.go#L117
While that probably made sense in the past, it doesn't mix well with default webhooks nor with the new system-wide webhooks (#10546). Those should fire on all repositories.
(I have not tested system-wide webhooks, but given the code mentioned above, it should behave the same.)
System information

Gitea version (or commit ref): 1.11.6
Git version: not relevant
Operating system: unknown, but I can ask if it matters
Database (use [x]):

[ ] PostgreSQL
[x] MySQL
[ ] MSSQL
[ ] SQLite

Can you reproduce the bug at https://try.gitea.io:

[ ] Yes (provide example URL)
[ ] No
[ ] Not relevant
[x] Can't test currently

Log gist: not relevant

#9180 is a partial duplicate of this but only mentions deletion, not creation.

Yes, this is still valid.

Default webhooks themselves don't do anything, they just are webhooks that get automatically added to fresh repos as far as I'm aware. System webhooks logically should, seeing as they're wider than just a repo in scope. I'll have a poke around to solve it for them.
However, this begs the question, should individual repos also fire a create (only if a default is defined) and delete event for their webhooks? I can't really come up with an argument for no in such a case, but I might be overlooking something.


Permit contents element within bibl, biblStruct, and monogr elements

Currently, an enumeration of the contents of a bibliographic entity can only be included within a FRBR-compliant bibliographic description; that is, within expression, manifestation, and work, or in seriesStmt and titlePage.
Allowing <bibl>, <biblStruct>, and <monogr> elements to contain <contents> would provide a method of listing the contents of a bibliographic entity without having to resort to go down the FRBR route.

With the addition of a new <biblFull> element that can appear alongside <bibl> or <biblStruct>, proposed in my comments on #1078, this issue can be closed.


Slow performance with shadow dom

I'm not exactly sure if this is an bug within CodeMirror or we're doing something wrong. But basically when we insert large amount of content (e.g. https://raw.githubusercontent.com/GerritCodeReview/gerrit/master/Documentation/rest-api-changes.txt for example), scrolling and clicking is slow. I've managed to reproduce in non-shadow-dom too if using height:auto on .CodeMirror. You can see here https://codepen.io/edgenard/pen/mEWeNX (you can try and insert the content first without the height:auto then with it. Notice the performance difference?). There is this codepen (shadow dom) https://codepen.io/ilyagladko/details/KKdXamm which once you insert the content you can see the performance issue.
We use shadow dom for our element codemirror-editor (https://github.com/GerritCodeReview/plugins_codemirror-editor/blob/master/gr-editor/gr-editor.js & https://github.com/GerritCodeReview/plugins_codemirror-editor/blob/master/gr-editor/codemirror-element.js).
We use the height:auto on our element but removing it does not fix the issue though.

Found why, it's because of viewportMargin: Infinity but then why does height: auto cause the performance issue too?

Oh I guess it's just doing viewportMargin infinity if the height is auto? That seems like a bug since it should use the default value or the one you set.

Oh I guess it's just doing viewportMargin infinity if the height is auto?

It's not really, in that that option isn't being overridden, it's just that if the editor has the height of the content, viewporting doesn't work (since it relies on the editor's scrollbox).
CodeMirror 6 has a more general viewporting implementation that'll also use the window's scrollbox, but this is unlikely to ever be added to version 5.x.

I've found a hacky solution for this issue: https://gerrit-review.googlesource.com/c/plugins/codemirror-editor/+/313422.
Basically uses the search add-on so users can still search the entire document... but we also set the size (height) using setSize. It's hacky as if you have for example the developer tools open the size is much smaller (and doesn't resize when you close it). But it does the job I want


Fix link to Getting Started Guide

The link is currently pointing to:
https://wiki.edgexfoundry.org/display/FA/Get+EdgeX+Foundry+-+Users
Which has been replaced by:
https://docs.edgexfoundry.org/Ch-GettingStartedUsers.html
This PR updates the link

I'll try the scripts and submit PRs as I find issues.


⚠ SceneTime has degraded performance

In b04d378, SceneTime ($ST) experienced degraded performance:

HTTP code: 200
Response time: 23711 ms

Resolved: SceneTime performance has improved in 2616ddc.


rename test.TestCtx to test.Context

Description of the change:
rename test.TestCtx to test.Context
Motivation for the change:
Remove:

// todo(camilamacedo86): The no lint here is for type name will be used as test.TestCtx by other packages, and
//  that stutters; consider calling this Ctx (golint)
// However, was decided to not move forward with it now in order to not introduce breakchanges with the task to
// add the linter. We should to do it after.

IMO, a name change because of a lint error is not sufficient reason to make a breaking change. I think this should be closed.

@joelanford I agree, although this should have been Context from the start. I'm fine holding this until we discuss what we're doing with the test framework.

Hi @joelanford,

IMO, a name change because of a lint error is not sufficient reason to make a breaking change. I think this should be closed.

The lint complains because is NOT a good practice has test.TestX or cache.Cache in Go.
And then, also that if users add the test-framework in their project and use any lint as this one may face this as well. So, IMO would be great o this tiny change now then after. WDYT? Would you reconsider that?

We decide not to do it now.

Working on to apply @joe suggestion.

Hi @joelanford it is following your suggestion now please let us know if you are ok with.

All, solved please feel free to check. @joelanford

Hi @estroz,
I fund just one reference which was missing and it is fixed. Could you please check now? If you still find someplace that should be updated please, let me know.


Fix create if exists live tests

Apply an equivalent test change to datalake that we made in blobs

API change check for com.azure:azure-storage-blob
API changes are not detected in this pull request for com.azure:azure-storage-blob

API change check for com.azure:azure-storage-file-datalake
API changes are not detected in this pull request for com.azure:azure-storage-file-datalake


Consistency between versions and release tags?

Hi,
Just wondering if the yara version check between a compiled rule file and yara could be relaxed a little rather than having to match exactly?  Would it be possible to allow, say, the second minor version numbers to be different but the compiled rules file to still be usable?  For example, a rules file compiled with 4.0.2 would still be usable with yara 4.0.5?  Any combination of a 4.0.x compiled rules file and 4.0.y yara version would be ok to use together, but not, say 4.x and 4.y.  Or even a later version of yara, eg 4.0.5 still being able to use an earlier version of a compiled rules file, eg 4.0.2, but not the other way around (eg 4.0.2 yara can't run 4.0.5 rules file).  Or is this just a recipe for disaster?
Thanks for your time.

Actually, looking at this again.  It seems the code in the releases are consistent, ie release 4.0.2 and release 4.0.5 both create and read compiled rules files with hdr.version of 17.  But the latest code in the repo, the major.minor.micro is 4.0.2 and creates compiled rules files with hdr.version 18.  This is a little inconsistent and confusing compared to the code in the releases! :) (and what was tripping me up in my first comment).  I shall just stick to the code in the releases and not build yara from master in the repo.
However I still have a suggestion.  Perhaps the version and the tag (major.minor numbers) could be consistent.  For example, major.minor of 4.0 could correspond to version 40.  Then when you need to change to version 41, update the tags/major.minor to be 4.1.  Then its easy to know which versions of yara are going to work with which versions of a compiled rules file.  That is, if I update to say, yara 4.1, then I know its not going to be able to read my version 40 compiled rules files.
Another suggestion, perhaps add this internal version number to the --version option.  Eg yara -v yields 4.0.5 (internal v17).  And you can find out the version of a compiled rules file with, say, yara -V compiled_rules_file.yar ... 17.

Just a quick comment: there is a v4.0.x branch where the releases have been coming from.


Improve CloudSchedulerJobFailed playbook

We should improve CloudSchedulerJobFailed playbook and add information for each cloud scheduler job we have (similar to what we have in the Verification Server).
I have most of the information for most jobs, but still need insight into export-importer-cschedule and export-importer-worker.
@sethvargo can you add some info about what these 2 jobs are doing?

export-importer-cschedule invokes the /schedule endpoint of the export-import service. It downloads and parses the remote index file, applies any rewrite rules, and stores the results in the database. It does not download the actual export zip files themselves, just the references in the index. It syncs index files and applies rewrite rules. The export-importer-worker uses the data synced by cschedule to actually download import the export files. They work together, but are separate processes because the worker has retry logic and can handle partial success.

All background jobs have been refactored to be forward-progress alerts. This is now obsolete.


Add: partner support to metadata parsing

closes #92
This is a small fix to parse the partners in our issues and then return the value in our model.
NOTE: need to test the full workflow including exporting to yaml before merging this so i'll open as a draft. i suspect i have to add a key somewhere to reorder the data.
Also note that this pr inspired #91 because the code to parse the header is super hard to follow.

This is working now BUT the categories are doing something funky --
    - data-retrieval
    - data-extraction
    - data-processing/munging
    - data-deposition
    - data-validation and-testing
    - workflow-automation
    - database-interoperability

will revisit that piece and potential pydantic validators to cleanup.


GZIP compression not working for upload via S3 gateway

Describe the bug
When uploading an XML file via S3 interface, using the aws command line tool, GZIP compression does not seem to be used.
Upload command:
aws --endpoint-url http://localhost:8333 s3 cp thing.xml s3://testing/05.xml

Resulting weed metadata:
> fs.meta.cat buckets/testing/05.xml
{
  "name": "05.xml",
  "isDirectory": false,
  "chunks": [
    {
      "fileId": "4,01ea64ba49af31",
      "offset": "0",
      "size": "182734",
      "mtime": "1590696448015795451",
      "eTag": "5c9dd265",
      "sourceFileId": "",
      "fid": {
        "volumeId": 4,
        "fileKey": "125540",
        "cookie":<PHONE_NUMBER>
      },
      "sourceFid": null,
      "cipherKey": null,
      "isGzipped": false
    }
  ],
  "attributes": {
    "fileSize": "0",
    "mtime": "1590696448",
    "fileMode": 432,
    "uid": 13005,
    "gid": 13005,
    "crtime": "1590696448",
    "mime": "application/xml",
    "replication": "",
    "collection": "testing",
    "ttlSec": 0,
    "userName": "",
    "groupName": [
    ],
    "symlinkTarget": "",
    "md5": "jj33SNkPighNdGeVXKLLFw=="
  },
  "extended": {
  }
}

EDIT TO ADD: also tried aws --endpoint-url http://wbgrp-svc169.us.archive.org:8333 s3 cp thing.xml s3://testing/06.xml --content-encoding application/gzip, and the new file (06.xml) as also not compressed ("isGzipped": false).
System Setup
Running on Ubuntu Xenial.
weed version: version 8000GB 1.79 linux amd64
Invocation (with systemd) as a single process:
/usr/local/bin/weed server -dir /srv/seaweedfs/data -s3 -s3.port 8333 -volume.max 0 -volume.index=leveldb2 -volume.port 8380 -master.port 9333 -filer no -whiteList <IP_ADDRESS> -master.volumeSizeLimitMB 250000

Expected behavior
isGzipped flag true after uploading thing.xml with mimetype application/xml.
Additional context
It could be possible that the -filer no flag and running as a single processing is causing issues? Without that flag (and specifying a port number), get errors on upload. For this deployment expecting to only ever use the S3 interface (replacing a current deployment of minio), so do not need (or want) the filter API.
I have read this function: https://github.com/chrislusf/seaweedfs/blob/master/weed/util/compression.go#L56
and it seems like this file should get compressed.

The actual file on volume server is already compressed. This is not visible to filer.
Filer is required for S3 API. It will automatically start if S3 is enabled.