text:
Question re rustdoc reproducibility

When I run cargo rustdoc -- -Z unstable-options --output-format=json on the standard library on an Ubuntu machine, I get the same JSON file each time. This has held regardless of whether I run the command locally or on GitHub's ubuntu-latest runner.
If I add --target x86_64-unknown-linux-gnu and run the command on GitHub's macos-latest runner, I get a slightly different file.
Is this expected?
Generally speaking, what is required to ensure reproducibility of cargo rustdoc's JSON output?
Thank you in advance, and sorry if this is not the right place to ask these questions.

Is this expected?

Honestly I'm not sure. What's the difference between the two files?

Generally speaking, what is required to ensure reproducibility of cargo rustdoc's JSON output?

Also not sure here, sorry. We do test that rustdoc is reproducible in some circumstances here, but that's running exactly the same binary.
More broadly, I'd be happy to take review/merge fixes to rustdoc that increase reproducibility.

@aDotInTheVoid Thank you very much for the reply. I have attached two JSON files. Both were generated by running the following command in the root of Rust's library directory at commit 4392847410ddd67f6734dd9845f9742ff9e85c83:
rustdoc --target x86_64-unknown-linux-gnu -- -Z unstable-options --output-format=json

std-ubuntu.json was generated on an Ubuntu machine. std-mac.json was generated on a machine running macOS Sequoia 15.2.
I can't see an easy way to summarize the differences. However, they seem to include differences in how ids are assigned. For example, in std-ubuntu.json, this is 11002:
    "11002": {
      "crate_id": 1,
      "kind": "function",
      "path": [
        "core",
        "slice",
        "raw",
        "from_raw_parts"
      ]
    },

And in std-macos.json, this is 11002:
    "11002": {
      "crate_id": 1,
      "kind": "struct",
      "path": [
        "core",
        "core_arch",
        "simd",
        "splat",
        "JustOne"
      ]
    },

Do you have any theories as to how this could occur?
std-ubuntu.json
std-macos.json

Do you have any theories as to how this could occur?

Id’s are assigned in order of their appearance to the visitor that collects items.
https://github.com/rust-lang/rust/blob/b76036c88c1fa7b63f412e777e185336848c52d6/src/librustdoc/json/conversions.rs#L154-L158
So the Id’s being different will be caused by something else being different.
Can you reproduce this on a more minimal example?

These are more minimal, but I will continue to try to find a smaller example.
Both of these were produced with the following command in the same commit of the Rust compiler:
cargo +nightly-2024-10-22 rustdoc --target x86_64-unknown-linux-gnu --manifest-path=sysroot/Cargo.toml -- -Z unstable-options --output-format=json

Here is the earliest difference:
    "292": {
      "crate_id": 12,
      "path": [
        "rustc_demangle",
        "legacy",
        "Demangle"
      ],
      "kind": "struct"
    },

    "292": {
      "crate_id": 6,
      "path": [
        "libc",
        "unix",
        "linux_like",
        "linux",
        "gnu",
        "timex"
      ],
      "kind": "struct"
    },

sysroot-ubunutu.json
sysroot-macos.json

I hope this is not getting annoying, but here is a smaller example still. Each was produced by running the following command on a library whose lib.rs contained only #![no_std] (inspired by cargo-public-api):
cargo +nightly-2024-10-22 rustdoc --target x86_64-unknown-linux-gnu --manifest-path=./test-apis/example_api-v0.1.0/Cargo.toml -Zbuild-std -- -Z unstable-options --output-format=json

example_api-ubuntu.json
example_api-macos.json
Please forgive me for not knowing rustdoc internals, but the code you cited in https://github.com/rust-lang/rustdoc-types/issues/44#issuecomment-2564592006 suggests that ids are generated when the JSON is rendered. Is this correct?

I hope this is not getting annoying

No, not at all.
After formatting the files with oj and oj -p 100.9 ./example_api-ubuntu.json > sorted.ubuntu.json && oj -p 100.9 ./example_api-macos.json > sorted.macos.json the diff is alot nicer:
diff --git a/./sorted.macos.json b/./sorted.ubuntu.json
index 60d302c..3050564 100644
--- a/./sorted.macos.json
+++ b/./sorted.ubuntu.json
@@ -285,35 +285,35 @@
     "264": {"crate_id": 1, "kind": "struct", "path": ["core", "core_arch", "simd", "i8x4"]},
     "265": {"crate_id": 1, "kind": "trait", "path": ["core", "ops", "bit", "BitXor"]},
     "266": {"crate_id": 1, "kind": "trait", "path": ["core", "iter", "traits", "marker", "TrustedStep"]},
-    "267": {
+    "267": {"crate_id": 1, "kind": "trait", "path": ["core", "ops", "range", "RangeBounds"]},
+    "268": {
       "crate_id": 1,
       "kind": "trait",
       "path": ["core", "core_simd", "simd", "num", "int", "SimdInt"]
     },
-    "268": {"crate_id": 1, "kind": "module", "path": ["core", "iter"]},
-    "269": {"crate_id": 1, "kind": "struct", "path": ["core", "core_arch", "x86", "cpuid", "CpuidResult"]},
+    "269": {"crate_id": 2, "kind": "struct", "path": ["compiler_builtins", "int", "big", "i256"]},
     "27": {"crate_id": 1, "kind": "struct", "path": ["core", "asserting", "Capture"]},
-    "270": {"crate_id": 1, "kind": "struct", "path": ["core", "char", "EscapeDefault"]},
-    "271": {"crate_id": 1, "kind": "struct", "path": ["core", "panic", "panic_info", "PanicMessage"]},
-    "272": {"crate_id": 1, "kind": "trait", "path": ["core", "marker", "FnPtr"]},
-    "273": {
+    "270": {"crate_id": 1, "kind": "struct", "path": ["core", "core_arch", "x86", "cpuid", "CpuidResult"]},
+    "271": {"crate_id": 1, "kind": "struct", "path": ["core", "char", "EscapeDefault"]},
+    "272": {"crate_id": 1, "kind": "module", "path": ["core", "iter"]},
+    "273": {"crate_id": 1, "kind": "struct", "path": ["core", "panic", "panic_info", "PanicMessage"]},
+    "274": {"crate_id": 1, "kind": "trait", "path": ["core", "marker", "FnPtr"]},
+    "275": {
       "crate_id": 1,
       "kind": "struct",
       "path": ["core", "num", "nonzero", "private", "NonZeroU16Inner"]
     },
-    "274": {"crate_id": 1, "kind": "struct", "path": ["core", "mem", "transmutability", "Assume"]},
-    "275": {
+    "276": {"crate_id": 1, "kind": "struct", "path": ["core", "mem", "transmutability", "Assume"]},
+    "277": {
       "crate_id": 1,
       "kind": "struct",
       "path": ["core", "iter", "adapters", "take_while", "TakeWhile"]
     },
-    "276": {"crate_id": 1, "kind": "struct", "path": ["core", "str", "pattern", "TwoWaySearcher"]},
-    "277": {"crate_id": 1, "kind": "struct", "path": ["core", "str", "BytesIsNotEmpty"]},
-    "278": {"crate_id": 1, "kind": "trait", "path": ["core", "ops", "range", "RangeBounds"]},
-    "279": {"crate_id": 1, "kind": "struct", "path": ["core", "slice", "iter", "ArrayWindows"]},
+    "278": {"crate_id": 1, "kind": "struct", "path": ["core", "str", "pattern", "TwoWaySearcher"]},
+    "279": {"crate_id": 1, "kind": "struct", "path": ["core", "str", "BytesIsNotEmpty"]},
     "28": {"crate_id": 1, "kind": "trait", "path": ["core", "ops", "drop", "Drop"]},
-    "280": {"crate_id": 1, "kind": "enum", "path": ["core", "ffi", "c_void"]},
-    "281": {"crate_id": 2, "kind": "struct", "path": ["compiler_builtins", "int", "big", "i256"]},
+    "280": {"crate_id": 1, "kind": "struct", "path": ["core", "slice", "iter", "ArrayWindows"]},
+    "281": {"crate_id": 1, "kind": "enum", "path": ["core", "ffi", "c_void"]},
     "282": {"crate_id": 1, "kind": "struct", "path": ["core", "str", "iter", "RMatches"]},
     "283": {"crate_id": 1, "kind": "trait", "path": ["core", "intrinsics", "AggregateRawPtr"]},
     "284": {"crate_id": 1, "kind": "struct", "path": ["core", "ffi", "c_str", "FromBytesUntilNulError"]},
@@ -780,10 +780,10 @@
     "601": {"crate_id": 1, "kind": "struct", "path": ["core", "cell", "Ref"]},
     "602": {"crate_id": 1, "kind": "trait", "path": ["core", "convert", "Into"]},
     "603": {"crate_id": 1, "kind": "trait", "path": ["core", "ops", "deref", "DerefPure"]},
-    "604": {"crate_id": 1, "kind": "struct", "path": ["core", "str", "pattern", "MultiCharEqPattern"]},
+    "604": {"crate_id": 1, "kind": "trait", "path": ["core", "hash", "BuildHasher"]},
     "605": {"crate_id": 1, "kind": "struct", "path": ["core", "core_arch", "simd", "i32x2"]},
-    "606": {"crate_id": 1, "kind": "trait", "path": ["core", "convert", "TryInto"]},
-    "607": {"crate_id": 1, "kind": "trait", "path": ["core", "hash", "BuildHasher"]},
+    "606": {"crate_id": 1, "kind": "struct", "path": ["core", "str", "pattern", "MultiCharEqPattern"]},
+    "607": {"crate_id": 1, "kind": "trait", "path": ["core", "convert", "TryInto"]},
     "608": {"crate_id": 1, "kind": "struct", "path": ["core", "option", "Iter"]},
     "609": {"crate_id": 1, "kind": "struct", "path": ["core", "core_arch", "x86", "splat", "JustOne"]},
     "61": {"crate_id": 1, "kind": "trait", "path": ["core", "ops", "arith", "MulAssign"]},

The difference is entirely in the paths field, so it's unclear immediately how to minimize further. It looks like (but I've not checked for sure) that all the same items are present, just with different Ids.

but the code you cited in https://github.com/rust-lang/rustdoc-types/issues/44#issuecomment-2564592006 suggests that ids are generated when the JSON is rendered. Is this correct?

Yep. The Id's (that are used in JSON), are decided in the librustdoc::clean -> rustdoc_types pass (aka rendering)

Yep. The Id's (that are used in JSON), are decided in the librustdoc::clean -> rustdoc_types pass (aka rendering)

Do you think it could be possible that the items are stored in different orders on the two platforms?

authors: aDotInTheVoid smoelius

repo: rust-lang/rustdoc-types


text:
rustfmt does not collapse foo::{self}

use foo::self;

is collapsed to:
use foo;

But this:
use foo::{self};

is kept as is.
Used rustfmt from master (2022 Jun 22) with rustfmt.toml from rustfmt repo.
This behavior doesn't look intentional.

@stepancheg, thanks for reaching out.
I can't find any great documentation on the topic, but the two cases you mention aren't equivalent. The best resource I can link you to are the discussions in #3568, #4681, and https://github.com/rust-lang/rust/issues/60941
A brief summary of the issue is that each import brings different things into scope so converting use foo::{self}; to use foo; could cause compilation problems. rustfmt can't safely make that transformation and leaves the import alone.

@ytmimi thank you for the explanations!

source: gharchive/issue

authors: stepancheg ytmimi

repo: rust-lang/rustfmt

license_type: permissive

license_source: github-api


text:
feat: support formatting Cargo.toml

From the disscussion in https://github.com/rust-lang/rustfmt/issues/4091, rustfmt should support format Cargo.toml since the Style Guide actually already includes a spec for Cargo.toml.
And things to consider include:

formatting logic
experience/usability perspective: (default behavior, cli args/opts, configurable via rustfmt.toml, etc)

As such I'd advise starting with the formatting logic (something that takes in an unformatted string and returns a formatted one) and we'll figure out the rest later on. Feel free to put this in a new mod under src/formatting

Originally posted by @calebcartwright in https://github.com/rust-lang/rustfmt/issues/4091#issuecomment-730716157

I do not think deferring the actual formatting logic to an external library is likely to be a viable candidate for the reasons that I've outlined above. We've got a formatting spec we'd have to follow, and even if one or more versions of said external lib happen to emit the same formatting, there's no guarantee they'd continue to do so (and we couldn't use a pinned version either due to risk of update blockage)

Originally posted by @calebcartwright in https://github.com/rust-lang/rustfmt/issues/4091#issuecomment-914846250
So in this PR I implemented the formatting logic according to the style guide. I used https://github.com/ordian/toml_edit to do so in an extensible way (visitors).

Haven't looked at the diff yet but very excited to see this, thanks so much for getting the process started @xxchan!

@calebcartwright @ytmimi Would you have some time recently to review this PR and give some feedbacks? At least for the general idea and code structure of the PR. 😊

Thank you for your patience @xxchan. I'm currently in the closing steps of prepping the next release, and afterwards I'll circle back to this and some of the larger/older PRs that have been pending

I also want to acknowledge that I've seen this and say that I'll try to carve out some time next week to start a review

@ytmimi Thanks for your review! I will resolve comments later.
For the calling path and tests, do we plan to keep working on this PR or get it merged first?

For the calling path and tests, do we plan to keep working on this PR or get it merged first?

I think I'd be fine either way, but it would definitely be ideal (at least in my opinion) if we could keep iterating on this PR before merging. I'll also wait for @calebcartwright to chime in before we decide how we'll move forward.

For the calling path and tests, do we plan to keep working on this PR or get it merged first?

I think I'd be fine either way, but it would definitely be ideal (at least in my opinion) if we could keep iterating on this PR before merging. I'll also wait for @calebcartwright to chime in before we decide how we'll move forward.

Not sure if this answers any specifics, but generally speaking we can certainly batch the overall implementation across multiple PRs (smaller PRs are always better in my mind). However, let's also make sure that each chunk/PR is complete. We can certainly update signatures, move items around between files/mods, etc. but we should have whatever we add here fully tested and with the api we think makes sense at this point.

Hey @xxchan Thanks again for your work on getting this started. I know you mentioned that you were a little busy https://github.com/rust-lang/rustfmt/issues/4091#issuecomment-1083603647, so I went ahead and rebased your changes on the current master and add the additions to get format_cargo_toml on a path that will be called by rustfmt.
I probably want to add a few more tests, but I think we're in a good place implementation wise.

Excellent can't wait for this to land so that we can stop manually worrying about how Cargo.toml should be formatted. This is the improvement in rust I am most looking forward to this year!

Excellent can't wait for this to land so that we can stop manually worrying about how Cargo.toml should be formatted. This is the improvement in rust I am most looking forward to this year!

Just to be clear, this PR doesn't fully implement the feature in and of itself, just an important first step

I’ll take a first step!
On Sun, 8 May 2022 at 19:23, Caleb Cartwright @.***>
wrote:

Excellent can't wait for this to land so that we can stop manually
worrying about how Cargo.toml should be formatted. This is the improvement
in rust I am most looking forward to this year!
Just to be clear, this PR doesn't fully implement the feature in and of
itself, just an important first step
—
Reply to this email directly, view it on GitHub
https://github.com/rust-lang/rustfmt/pull/5240#issuecomment-1120465190,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGEJCD5QRRVPUC6HQ7QQBLVJABDPANCNFSM5PLIHPZA
.
You are receiving this because you commented.Message ID:
@.***>

Anyone here can suggest more test cases like https://github.com/rust-lang/rustfmt/pull/5240/files#diff-3ab626d68c49333207c9209bf5abb01c7b2eff301470bd5dcc801da3dcf2345f? 😄

I've added a new rule TrimSpaces, it's not described in style guide, but maybe it's expected

Hi @ytmimi @calebcartwright, I added an unstable option format_cargo_toml and integrated the support for Cargo.toml to cargo-fmt, so I think this PR is now ready to be merged and let users to play with it. 😊

Thanks for your review!

I'm not sure if we're ready to add this to cargo fmt.

I believe most of users use cargo fmt instead of using rustfmt directly, and they expect cargo fmt to handle the whole workspace. So I think adding it to cargo fmt is a critical step for this long-awaited feature to have enough exposure and user testing. It's also the reason why I think this PR is good enough to be merged instead of being blocked for too long.
I will resolve other comments soon.

Comments expect those about cargo-fmt resolved.

Would love to use this feature! Is there something that we're waiting on?

Great timing - this is top of my xmas list.
On Wed, 14 Dec 2022 at 08:29, xxchan @.***> wrote:

IMO it's good enough to merge. cc @ytmimi https://github.com/ytmimi
Could you confirm that and update the PR label?
—
Reply to this email directly, view it on GitHub
https://github.com/rust-lang/rustfmt/pull/5240#issuecomment-1350625107,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGEJCATKIHOQELAQ7YG4VTWNGAOPANCNFSM5PLIHPZA
.
You are receiving this because you commented.Message ID:
@.***>

Please take some time on this. We really need this!

Adding to the positive sentiment. This would be really useful for my team and me if this is merged soon! :)

As soon as it’s in nightly then people can give lots of feedback - even if
it’s behind a flag and not default for now.
On Mon, 6 Feb 2023 at 20:17, Andrew Gazelka @.***>
wrote:

Adding to the positive sentiment. This would be really useful for my team
and me if this is merged soon! :)
—
Reply to this email directly, view it on GitHub
https://github.com/rust-lang/rustfmt/pull/5240#issuecomment-1419693155,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGEJCAETUYSSAORYG7LY6LWWFL6BANCNFSM5PLIHPZA
.
You are receiving this because you commented.Message ID:
@.***>

Are we going to merge this?? We are waiting for it.

Adding to the chorus here: is there something holding this back?

I'd kindly request that folks only comment here if they have feedback salient to the specifics of the proposed implementation. I understand the desire for the feature, but the repeated flavors of "+1" comments don't impact the priority+work vs. bandwidth challenges that we (and frankly most dev tools teams) have, and as such aren't going to result in anything happening more quickly.
These comments also make things a bit more challenging by extending the length of the thread and unnecessarily notifying those that have subscribed in order to be made aware of any substantial updates/movement.

If you want to try this on your project:
git clone https://github.com/rust-lang/rustfmt && cd rustfmt
gh pr checkout 5240
cargo build --release --bin rustfmt --bin cargo-fmt -Zunstable-options --out-dir "$(rustc --print=sysroot)/bin"

This installation is safe and won't pollute other installations.
Then you will be able to use it as cargo +nightly-2023-01-24 fmt on any project. Note you will also need to add format_cargo_toml = true in rustfmt.toml.

I have made a draft PR to a PR to try to resolve the current merge conflict - https://github.com/xxchan/rustfmt/pull/1 but it seems the recent changes in toml_edit by @epage to expose all underlying strings as RawString instead of simple &str made this PR much more difficult.
@xxchan, are you still working on this?  This code was pretty much ready to go until it wasn't, so hoping to resume the work on it :)

@nyurik Thanks for your work! But it seems your merge commit changed Cargo.lock too much, and thus I've manually merged main just now.
If you'd like to create a separate PR to bump toml_edit, I would happily merge it!

@xxchan, are you still working on this? This code was pretty much ready to go until it wasn't, so hoping to resume the work on it :)

I'm not working on it, and not very interested in pushing forward it (although there aren't any blockers AFAIK). But I'm happy to help if anyone wants to improve it (e.g., more tests, bugfix, etc).

@xxchan i would be happy to help with that PR - do you want to maybe add me to your fork?  This way i can push changes directly to your PR (again - only if you do want me to drive that PR forward)?

@nyurik Instead of pushing directly to this PR, it might be better if you either create PRs to be merged into this branch, or create another PR to master directly to replace this PR if you want to make significant changes :)

Thanks @xxchan, I pushed a new PR to upgrade toml_edit crate to the latest version in https://github.com/xxchan/rustfmt/pull/2

🎅 It's top of my Christmas list that with some flag set, nightly can format Cargo.toml files. I've been a really good boy all year.

While this has admittedly not been a priority for us on the Rustfmt team anyway, I also want to make sure that those interested in this feature are aware that the Cargo team have some concerns about the existing Style Guide prescriptions for the toml file and that there's still discussion to be had between the Cargo and Style teams about what the formatting rules should be.

If that's the case, perhaps it would be okay to put this under an unstable option (for example, cargo_toml = true) so that the existing code can be merged without stabilising the formatting? Assuming that the consensus is that it's okay for this code to live in rustfmt, just, not certain what it should do.

I second that if we are simply uncertain of the formatting details, but certain that we need it (as seems to be the consensus), I do think it should be merged under the nightly flag, same as --config imports_granularity=Module.  Options for the name:

include_toml
format_toml
toml
...?

If that's the case, perhaps it would be okay to put this under an unstable option

a config format_cargo_toml is already added https://github.com/rust-lang/rustfmt/pull/5240/files#diff-7bd4f14a75a37432af3ab896bbbe38f88428b490b5d76ed1586f7f473a745e98

the Cargo team have some concerns about the existing Style Guide prescriptions for the toml file and that there's still discussion to be had between the Cargo and Style teams about what the formatting rules should be.

Understand. I also feel some rules are not good enough, and some are missing. But I think

This implementation is extensible and very easy to change
With a working implementation for the current style guide, maybe it's easier to find what can be improved.

the Cargo team have some concerns about the existing Style Guide prescriptions for the toml file and that there's still discussion to be had between the Cargo and Style teams about what the formatting rules should be.

ref to https://github.com/rust-lang/style-team/issues/188

Just like formatting of rust code has changed over time, it's expected that formatting of Cargo.toml files would change over time (and double expected when the feature is only available in nightly). I have no doubt that releasing it to nightly will quickly lead to feedback around what the default formatting style should be. This is what nightly is for is it not?

To be clear, I'm trying to provide transparency about additional challenging external factors above and beyond the fact that this is an extremely low priority for a small, stretched team. I'm not trying to persuade anyone of anything, nor get dragged into a debate.

Just like formatting of rust code has changed over time

Fwiw, it hasn't. The Style Guide has been set in stone from the outset, as have the associated formatting rules. It wasn't until RFC 3338 (from 2022) that a process to change formatting even come into existence.

It's just not a particularly efficient use of our time to review code implementing formatting rules and that the associated test content based on those rules, for rules that are going to change.

To be clear, I'm trying to provide transparency about additional challenging external factors above and beyond the fact that this is an extremely low priority for a small, stretched team. I'm not trying to persuade anyone of anything, nor get dragged into a debate.

Totally understand, and glad that you can express this explicitly.

It's just not a particularly efficient use of our time to review code implementing formatting rules and that the associated test content based on those rules, for rules that are going to change.

FWIW, @ytmimi has spent time reviewing this several rounds, and thought we're on the right track. So I just felt a little confused why to hold off. This seems also not very efficient use of time.
Anyway, I'm not urgent at all to get this landed. But just want to say sth since we got updates from the maintainers' side. 😄

FWIW, @ytmimi has spent time reviewing this several rounds, and thought we're on the right track. So I just felt a little confused why to hold off. This seems also not very efficient use of time.

Understood. The Cargo team's objections are recent, and the prior rounds of review precede those objections.
This has admittedly been a lower priority from the outset, but it was something we were still trying to slowly advance. However, these new objections are now a blocker, and I'm simply communicating that blocker.

If this is about the parts of the style  that are undecided, how about we focus on the core infrastructure and easily agreed to items so this PR can be small and we can more easily iterate over time.  I also assume that the area where the cargo team pushed back are likely to be things people would want configurable so they can be added incrementally over time behind settings.

I'm really trying to avoid getting into broader discussion as well as the specifics of what/why/etc. because I think discussion on PRs should be largely centered review of the "how", the specifics of proposed implementation changes.
Ultimately, this is not something I'm comfortable moving ahead with, neither in whole nor in part, while we have other conversations circling elsewhere including moving some of the subcommands (like cargo-fmt) into Cargo and large unanswered questions around things like sorting.
I know people want this feature, I get it and I get why. For those that just want some/any type of formatting of their Cargo.toml files, several readily available options were previously shared on #4091.
However, this is something net-new and trying to force through for the sake of having something "now" from rustfmt is only going to introduce churn, both on users and on rustfmt itself, and we're not going to do it.
If that makes me the Grinch instead of Santa, then so be it :sweat_smile:

I'm really trying to avoid getting into broader discussion as well as the specifics of what/why/etc. because I think discussion on PRs should be largely centered review of the "how", the specifics of proposed implementation changes.

To be clear, I was trying to highlight what could be dropped to make this easier to move forward, from a cargo team member perspective, not to get into the broader discussion.

Ultimately, this is not something I'm comfortable moving ahead with at this time, neither in whole nor in part,

Please reconsider this.  Focusing on a more incremental approach should make your life much easier and gets people benefits now, rather than waiting for some future date.  We can pick less churn-heavy areas to move forward.

including moving some of the subcommands (like cargo-fmt) into Cargo and large unanswered questions around things like sorting.

I thought you said "no" to moving it?
As for sorting, if we leave that out, then it isn't a problem, right?

I'm going to redirect conversation about design/strategy/timing/etc. back to the issue and will respond there

However, this is something net-new and trying to force through for the sake of having something "now" from rustfmt is only going to introduce churn, both on users and on rustfmt itself, and we're not going to do it. When we do, it will be something we generally feel will be "right" and at least aligned with the anticipated path of the Style Rules.
If that makes me the Grinch instead of Santa, then so be it 😅

My particular concern here, speaking of someone who understands what it's like to contribute changes to large projects on my own time, is that it's incredibly frustrating to leave PRs in limbo like this. I'm fine with stripping out changes that could be changed/cause churn, I'm fine with deciding that you just don't want this change before design is done. What I'm not okay with is a change being open for almost two years in limbo.
It takes a lot of effort to rebase and review a change like this as it gets scrutinised, and it's especially frustrating to continue to have my change left open for months because it's in this weird limbo of not prioritised but not undesired.
The reason why I proposed merging under an unstable option is because it would mean this PR is closed and then additional work can happen in another PR.
Like, I understand the situation this puts you in as a maintainer, but I'm speaking from experience; either:

Merge it as-is
Provide criteria for what form it would need to be, to be merged
Close it

None of this "we don't know what the criteria is, don't want to work on it right now, but like some of what this is right now." That just makes everyone feel worse about it, both maintainers and contributors. IMHO, either decide if there's some portion of this you'd be comfortable merging now (and request those specific changes, likely involving removing pieces) or close this and tell people where they can follow the discussion in the meantime.

Does this produce Cargo.tomls like those cargo publish itself produces?

@glandium while there is work to define and enforce the style for Cargo.toml, I do not expect the cargo team will adjust cargo publish to make the Cargo.toml apply.  The file at that point is mostly for machine consumption.  This would be similar to cargo fix generating code that needs a cargo fmt run applied to it.

Any progress after all this time? What is stopping this work?

This would be very nice addition to the ecosystem!

This PR is blocked, as has been noted in multiple comments and with the label on this PR.
We, the rustfmt team are leaving the PR open because it's as good an implementation as any to pick up if and when the upstream blockers are removed. If the author wants to close the PR that's certainly their prerogative and an option they can take at any point.
I've locked the conversation on this PR because it's been attracting a number off-topic comments that do not offer any concrete feedback on the implementation nor remove the upstream blockers.
Those comments are adding noise and length to the PR which exacerbate the common open source issue of people commenting without reading prior comments, and it's also unnecessarily triggering notifications for those subscribed in order to receive substantive updates.

source: gharchive/pull-request

authors: AurevoirXavier LGLO TerakomariGandesblood andrewgazelka calebcartwright clarfonthey epage evertedsphere gilescope glandium iajoiner joshparallel nyurik xxchan ytmimi


text:
Cannot remove component, but it appears to be there

Problem

Since rustfmt is now on stable, I wanted to remove it from my nightly toolchain, but despite it appearing in rustup component list, it appears not removable (however clippy was removed fine in a similar manner):
% rustup component list --toolchain nightly | grep rustfmt
rustfmt-x86_64-unknown-linux-gnu
% rustup component remove rustfmt --toolchain nightly
error: toolchain 'nightly-x86_64-unknown-linux-gnu' does not contain component 'rustfmt' for target 'x86_64-unknown-linux-gnu'; did you mean 'rust-std'?

Using the full name rustfmt-x86_64-unknown-linux-gnu also doesn't work with the same message.
Steps

Unsure. I've not wanted to mess with the installation too much for fear of losing the repro.
Notes
Output of rustup --version: rustup 1.18.3 (2019-05-23)
Output of rustup show:
% rustup show
Default host: x86_64-unknown-linux-gnu

installed toolchains
--------------------

stable-x86_64-unknown-linux-gnu (default)
nightly-2018-10-07-x86_64-unknown-linux-gnu
nightly-x86_64-unknown-linux-gnu

active toolchain
----------------

stable-x86_64-unknown-linux-gnu (default)
rustc 1.35.0 (3c235d560 2019-05-20)

If the component were installed it'd have (installed) after it in the component list.

Oh! So this is my misunderstanding then, I thought rustup component list only listed installed components. I'll make sure to pass --installed. Sorry for the noise! :-)

authors: cdown kinnison


text:
subscribe error: no relays specified when gossip enabled

Describe the bug
I've got a strange bug when update to latest nostr-sdk, but I didn't know how to debug it. I've a simple subscribe like this:
let filter = Filter::new()
      .authors(authors)
      .kind(Kind::Metadata)
      .limit(200);

if let Err(e) = client.subscribe(vec![filter], Some(opts)).await {
    println!("Subscribe error: {}", e);
}

After that, I got this error Subscribe error: no relays specified, but there are tons of relays already connected.
I think there are some bugs in this part
// Collect targets map
let mut map: HashMap<Url, Vec<Filter>> = HashMap::new();
for (url, filters) in targets.into_iter() {
    map.insert(url.try_into_url()?, filters);
}

// Check if urls set is empty
if map.is_empty() {
    return Err(Error::NoRelaysSpecified);
}

To Reproduce
Expected behavior
Subscribe work normally when gossip enabled
Build environment

Library: nostr-sdk
Language: Rust
Language version: 1.81
Tag/commit: 4da48df
OS+version: macOS 15

Weird, I can't reproduce it. Can you share a full example? Including the discovery relays and public keys used?

Yup, this issue somehow only occur on Lume app, I can't reproduce it on other project too. I will dig more and report back.

authors: reyamir yukibtc

repo: rust-nostr/nostr

license: MIT


text:
A simple hello world does not display in Qemu

I followed the instructions on https://github.com/rust-osdev/bootloader/blob/main/README.md and  https://github.com/rust-osdev/bootloader/blob/main/docs/create-disk-image.md and got all successfully setup
A simple code  hello world code like that shown below in my test kernel, builds but when I run, Qemu opens quite alright and shows a series of info. Unfortunately, it never ends up showing my Hello World. I am not using any custom linker. Am I missing something?
#![no_std]
#![no_main]
#![feature(alloc_error_handler)]

bootloader_api::entry_point!(my_entry_point);

fn my_entry_point(bootinfo: &'static mut bootloader_api::BootInfo) -> ! {

 let display_cursor_position = 0xb8000 as *mut u8;
 let hello = b"Hello World";
    for (i, &byte) in hello.iter().enumerate() {
        unsafe {
            *display_cursor_position.offset(i as isize * 2) = byte;
            *display_cursor_position.offset(i as isize * 2 + 1) = 0x0f;
        }
    }
loop {}
}

#[panic_handler]
fn panic(_info: &core::panic::PanicInfo) -> ! {
    loop {}
}

/// The global allocator type.
#[derive(Default)]
pub struct Allocator;

unsafe impl GlobalAlloc for Allocator {
    unsafe fn alloc(&self, layout: Layout) -> *mut u8 {
        alloc(layout) as *mut u8
    }
    unsafe fn dealloc(&self, ptr: *mut u8, _layout: Layout) {
        dealloc(ptr, _layout);
    }
}

/// If there is an out of memory error, just panic.

#[alloc_error_handler]
fn my_allocator_error(_layout: Layout) -> ! {
    panic!("out of memory");
}

/// The static global allocator.
#[global_allocator]
static GLOBAL_ALLOCATOR: Allocator = Allocator;

We don't use the VGA text mode because it is not compatible with UEFI booting. Instead, we set up a pixel-based framebuffer, which you can access through the bootinfo.framebuffer field.
As this buffer is pixel-based instead of text-based, you have to do the font rendering yourself. I recommend to use the noto_sans_mono_bitmap for that as a start. See our internal framebuffer submodule as an example.
Hope this helps!

We don't use the VGA text mode because it is not compatible with UEFI booting. Instead, we set up a pixel-based framebuffer, which you can access through the bootinfo.framebuffer field.
As this buffer is pixel-based instead of text-based, you have to do the font rendering yourself. I recommend to use the noto_sans_mono_bitmap for that as a start. See our internal framebuffer submodule as an example.
Hope this helps!

This approach worked. I was able to see the "Hello, World". Thank you.

authors: phil-opp piosystems

repo: rust-osdev/bootloader


text:
Recursive Index in page tables?

Is it always index 0? Should this be passed in the BootInfo struct?

We used to hardcode the index to 511, but this changed with #71. Now we dynamically look for a free level 4 entry. The chosen index is indirectly reported through the recursive_page_table_addr field in the BootInfo:
https://github.com/rust-osdev/bootloader/blob/90f5b8910d146d6d489b70a6341d778253663cfa/src/bootinfo/mod.rs#L32-L34
It shouldn't be 0, however, because the bootloader maps itself to that slot…

Thanks! I eventually figured that out. Perhaps a "get recursive index" method could be added that just masks out bits 21:12 and returns a PageTableIndex?

authors: mark-i-m phil-opp


text:
macos-latest builds failing

With the following linker error:
  = note: ld: in /Users/runner/.rustup/toolchains/1.46.0-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libstd-3704639a9502890d.rlib(lib.rmeta), archive member 'lib.rmeta' with length 4900080 is not mach-o or llvm bitcode file '/Users/runner/.rustup/toolchains/1.46.0-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libstd-3704639a9502890d.rlib'
          clang: error: linker command failed with exit code 1 (use -v to see invocation)

Probably related to M1: https://github.com/fltk-rs/fltk-rs/issues/956
No idea what a meaningful fix would be.

Appears to be an issue that needs to be solved at the compiler level: https://github.com/rust-lang/rust/issues/103044
The issue was closed only recently which means the fix will only be available in newer rust versions. Will need to adjust CI to reflect that.

Appears to be an issue that needs to be solved at the compiler level: rust-lang/rust#103044
The issue was closed only recently which means the fix will only be available in newer rust versions. Will need to adjust CI to reflect that.

Actually, it's a bit simpler than that - rust < 1.54 does not work on macos >= 12: https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/.E2.9C.94.20How.20can.20I.20fix.20Rust.201.2E53.2E0.20or.20earlier.20to.20run.20on.20macOS.2012.2E6.3F/near/299263887
As a result the PR adjusts the CI workflow to test MSRV on macos-11 only.

repo: rust-pcap/pcap


text:
updates to fix merge of jsrs-common and jsrs-types

Merging is necessary so that the JsScope trait can have access to GcError, which needs access to JsVar, JsPtrEnum, Binding, and UniqueBinding.
See rustoscript/js.rs-common#4.

:+1: LGTM

authors: djmally saghm

license: mit

license_source: bigquery


text:
Testing osm2pgsql PR #2134 for reducing conections

Testing https://github.com/joto/osm2pgsql/tree/fewer-db-conns

Connections before -- 41 idle!

Connections after -- 3 idle.

Remove extra -d from osm2pgsql-replication command after more strict option checking implemented https://github.com/osm2pgsql-dev/osm2pgsql/pull/2115
Sets repo/branch back to production setting.  Leaving the new  repo URL.

Adding a few more notes about connection volume with replication.  The initial load had a connection pattern similar to a single load w/out replication (sustained 41 idle connections).  Where things could get really nasty connection-wise was the replication update steps.
Before the patch the default PgOSM Flex layerset would consume 207 connections for replication updates.  It's a relatively short time, but compared to Postgres' default max_connections=100 that can be shocking.

After the change to osm2pgsql, the total connection load  drops to 17 (-92% diff)

repo: rustprooflabs/pgosm-flex


text:
Add as_ptr and as_mut_ptr methods

This is useful for moving across a matrix/slice in unsafe code and for converting slices to other types (e.g. ndarray::ArrayView).
Edit: If you'd like to guarantee that the pointer is aligned and non-null for empty matrices too, that would be great. I just didn't know if you'd like to make that guarantee, so I left it out.

Thanks!

If you'd like to guarantee that the pointer is aligned and non-null for empty matrices too, that would be great. I just didn't know if you'd like to make that guarantee, so I left it out.

How would this be done?

It always struck me as a little odd that ptr is a method on Storage, instead of ContiguousStorage.

Having it be a method on Storage seems like it introduces the implicit requirement that it's possible to construct a pointer to the start of the storage space of the matrix, which would preclude implementing, for instance, a HashMapStorage.

I assume you're thinking about a sparse representation with indices as keys and matrix elements as values? From what I can tell, Storage is restricted to accessing elements by offsetting a pointer. (For example, it has a strides method.) Note that getting a pointer and shape/strides is necessary for non-contiguous matrix types like MatrixSlice in addition to contiguous matrix types, and a trait like Storage allows operating in a uniform way on both contiguous and non-contiguous matrices. If sparse representations are desired in the future, I'd suggest adding a separate, more general trait.

Thanks @jturner314! I will merge this now for today's release.
The discussion about alignment is worth keeping in mind so I will create an issue for that.

authors: jswrenn jturner314 sebcrozet

repo: rustsim/nalgebra


text:
Coordinate with the Portability WG

Linked issue: https://github.com/rust-lang-nursery/portability-wg/issues/10

I'm gonna close this as https://github.com/japaric/libm is a good example of how coordination is happening, and otherwise I'm not sure if this issue itself will help along too much!

authors: Pauan alexcrichton

repo: rustwasm/team


text:
Don't force TextDe/Encoder

Currently the generated JS shim calls TextDe/Encoder, even if it's not required by the user.
This forces users to provide a polyfill even when not needed.
Even if just a stub is provided as a polyfill, like done in the wasm-audio-worklet example, it would still require the class TextDe/Encoder to be defined, which prevents support detection by downstream users.
This adjust calls to TextDe/Encoder to do nothing if it's not available.
I don't think this has any use-case outside audio worklets.
This doesn't prevent users from using an actual polyfill if desired.
Cc @lukaslihotzki.
Fixes #2367.

So I agree that TextDe/Encoder isn't needed outside of audio worklets, but your diff here removed the code from audio worklets where I do need it. Was that intentional? What is the best way to get this polyfilled inside of an Audio worklet?
https://github.com/rustwasm/wasm-bindgen/commit/78421dc53ccbe9dc4be437cd8b09961cb8159ddc#diff-07cf5528c3f9b4e22f2489de3616bd3ec5adbfeea002b3cad8d7f9d9cd5c68b0

It was intentional indeed, as its not required anymore to get audio worklets to run.
Using the usual Worklet.addModule() beforehand should perfectly suffice to inject any polyfill.
In general though I would recommend against using it in audio worklets, as any kind of memory allocation inside the audio worklet can cause stuttering among other issues, which is why the API was removed there to begin with. See https://github.com/WebAudio/web-audio-api/issues/2499#issuecomment-2002470074 for more information.

authors: BlinkyStitt daxpedda

repo: rustwasm/wasm-bindgen


text:
test_permuted_global_pool: Fixed seldom-occurring (~1% of cases) assert failure

The test I added yesterday failed sometimes due to numerical issues in the order of operations between the permuted and non-permuted data - I should have checked that more. Your new test fails less, but still does so in ~1% of the cases.
I've therefore updated the test to use the same order for both the global_pool operations and the operation directly on the tensor. This makes the test somewhat more ugly (since it mostly replicated the same tests as test_global_pool, contrary to your changes in 14b628e18fdefc250915ddc7b7b39f7880dad6cf); however, the asserts will not fail (tested with 100k iterations; my first test failed in ~10% of cases; your updated one in ~1%; this one doesn't).

Cool :)

Codecov Report

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

@@          Coverage Diff          @@
##           master   #486   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files         120    120
  Lines        3531   3531
=====================================
  Hits         3531   3531

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 14b628e...818291e. Read the comment docs.

authors: codecov-io fdiehl rusty1s


text:
Checkbox: Copy files

Implementation detail: os.rename vs shutils.move

Done with commit: 50eea4ebca4973344e175047f40b4e83b5e6e0f5

repo: rwarnking/image-sorter


text:
Repositories, naming and structure

I find the current structure and naming of DISCO repositories confusing. Would it
e.g.:
https://github.com/rwmbook/registry
https://github.com/mamund/2018-02-sacon-workshop/tree/master/examples
Would it make sense to crate a DISCO org on GitHub and move the spec and examples there?

yep -- this started as as super MVP project for a single talk and has grown into something more.
i have created an org here: https://github.com/open-disco and added you as a member.

authors: mamund zdne

repo: rwmbook/registry-docs


text:
Fixing Everything at Once

Fix image conversion loop header

Add readme section to mention known limitations on other operating systems than windows

Add script section to convert inline images to image blocks (needs confirmation)

Add script section to explicitly remove bibliography from section numeration if that is not already the case

Fixed literally everything, including but not limited to:

Figures, images, tables, chapters and anything in between are now referenced throughout the document accurately and consistently.
Various breakages with chapters and sections that normally required manual fixing are now handled in the script, no manual fixes required for them at all anymore.
Tables with appendices that are special and merged are now formatted and fixed completely within the script and they do not require any manual fixing at all anymore.
Randomly occuring characters that disrupt the expect flow of the text are now removed within the script automatically.
There are some changes in the old functions and one of them is deleted completely. There was no other way if we wanted to set the references appropriately. The removed sections' functionality is implemented in other, newly added functions, if it was necessary.

Now, with discretion, the script should handle anything and everything fixing related. That is, the manual fixing section should not be required anymore. No not merge yet, needs testing.
I tested all the individual functions and code blocks manually and they all do work perfectly. Whether or not applying all of them consecutively would cause some kind of unexpected behavior or breakage is not known, because I did not conduct any tests on the module as a whole. There might also be some side-effects that I missed that might need fixing, but for the time, there seems to be none.
I have readjusted the sequence in which we call the fixing functions to accomodate for the new functionality, and to ensure that new functions would not break. This is important because some of them have to be called before others to perform the fixes. e. g. setting the reference links needs to be done after getting rid of the <<>> stuff. There are more like this that I already handled. There might be more of these that I could not think of, these will be discovered and fixed once I test the standalone module as a whole.

Needless to say, I only addressed the manual fixes that you mentioned to me. Now I noticed there are two little ones that I missed:

Setting document attributes
Removing the various tables in the beginning.

This should not be hard to add too.

Tested everything at once. There were problems, maybe unsurprisingly. They are all fixed. I also simplified the code wherever possible and split it into many modular pieces, and added comments for readibility, as well as renamed function as suggested.

Please see this document. It is generated completely and solely using the script. No manual fixes. Please take a look and report what is missing, what needs manual fixing, what is broken (if I missed anything). I will try to further develop the script to handle the fixes that you think are missing.

Multiple things are broken:

Images are not defined as blocks
Images are used as titles
Image/Table/Subclause References do not work
Formating bugs
Others

Please install PyCharm and AsciiDoc Viewer Plugin.
If you have generated an asciidoc file, try to generate an html file (one click in asciidoc plugin for pycharm) from that.
Compare the content of the generated HTML with the source DOCX and check if everything is alright.
Do think twice before writing a script for some issue, do the script only if you are sure, that the issue can come in various documents and your script is general enought to solve that issue in different documents

Ok. The table splitting works on most documents, not always, and never causes breakage. So leaving it as is. Sometimes manual table splitting is still needed. Reference works in any case. Ordering might sometimes need manual fixing. The amount of manual fixing is minimized to its limits so that not even half the manual fixing isrequired as before, but unfortunately eliminating it completely is not possible because there is too big of a deviation between documents and their structure.
Whatever there is, it is tested and documented and simplified. Readme is also updated. Merging.

authors: monsieuremre zrgt


text:
Prodigy membership

can u pls update the membership so that it works for podigy english
Thanks u are realy helpful

javascript:(function(_0x7344e,_0x13af63){function _0x565339(_0x96a15,_0x339b71,_0x416dcd,_0x1d0112,_0x464eb1){return _0x2e32(_0x464eb1- -0x144,_0x416dcd);}function _0x123315(_0x4ddc86,_0x13e4e4,_0x3222aa,_0xb36037,_0xf7da4d){return _0x2e32(_0xb36037- -0x19f,_0xf7da4d);}function _0x205799(_0x43629d,_0x3c7bba,_0x38ffe6,_0x3ed9be,_0x4e63b0){return _0x2e32(_0x3ed9be-0xa4,_0x38ffe6);}function _0x36b9b1(_0x595c0e,_0x170ffb,_0xbac571,_0x4a3ba0,_0x1ba9ef){return _0x2e32(_0x170ffb- -0x147,_0xbac571);}var _0x5a854=_0x7344e();function _0x54eeff(_0x3f4703,_0xbc3c8e,_0x42a3cd,_0x504397,_0x1fbe4b){return _0x2e32(_0xbc3c8e-0x41,_0x1fbe4b);}while(!![]){try{var _0x25078a=-parseInt(_0x54eeff(0x1be,0x178,0x1d2,0x13b,0x163))/(-0x1*-0x3e3+0x3ec+-0x3e70x2)+-parseInt(_0x205799(0x1f9,0x241,0x1a9,0x1f3,0x223))/(0x78e+-0x672+0x8d-0x2)+parseInt(_0x565339(-0x45,-0x7e,-0x1d,-0x91,-0x4b))/(-0x3430x4+-0x12ad0x2+-0x1*-0x3269)(parseInt(_0x205799(0x1d2,0x15e,0x1d2,0x17d,0x170))/(0x17ea+0x12-0x18e+0x4160x1))+-parseInt(_0x36b9b1(-0xac,-0x5d,-0xb,-0x96,-0x26))/(-0x1090+0xb-0x1e9+0x2598)+-parseInt(_0x205799(0x262,0x1d4,0x235,0x20f,0x1d1))/(-0x20xba0+-0xae7+0x222d)(parseInt(_0x36b9b1(-0x18,-0xb,0x3f,-0x20,-0x2e))/(0x21d+0x10x371+0x5-0x11b))+parseInt(_0x54eeff(0x121,0x151,0x108,0x11e,0x143))/(-0x1b30+-0x2625+0x415d)(parseInt(_0x565339(-0x4e,-0x2d,-0x5b,0x33,-0x24))/(0x29f-0x7+-0xa00x2f+0x2fc2))+parseInt(_0x565339(-0x4b,-0x6b,-0xf,-0x7c,-0x4d))/(0xb0d+-0x1a4c+0x70x22f)(parseInt(_0x123315(-0x16,-0x7e,-0x6,-0x28,0xe))/(0x20e7-0x1+0x5ed+0x1b05));if(_0x25078a===_0x13af63)break;else _0x5a854'push';}catch(_0x4749bb){_0x5a854'push';}}}(_0x16e8,0xda5b9+0xc36cf+0x1*-0xb901f));function 0x16e8(){var 0x15f257=['kLDsS','to','CfVWM','FKBga','wxmEG','KhpAj','FDLsS','user','buleN','738Ftrcoh','split','EfETc','XEXIi','dKNJp','PGXzx','tdlKu','cxVgD','_stat','lZrld','GwTkm','KYzvY','toStr','gdMiX','mxmNX','info','vjMdn','FCXWj','ncdQZ','lengt','|4|2|','jLsDA','vPvec','195878zJohVq','WJBTv','SHcrT','Deiqi','saegK','2386139AfRAfr','game','WpdtD','n()\x20','fCjpP','NwTjE','OfBGa','tVVmT','RyIKH','osUuX','kevQv','aMtFV','pwveg','cDPjC','Xejwx','3|1|5','QZwfY','gexgT','RQWnw','858880RlfdXx','rnzjB','ZVOGu','bind','tzUgF','searc','_curr','sourc','oXcbs','PSvpr','conso','xMpLz','eOWDk','WjllX','xcgCr','Fikcn','QRWzE','btaGC','XOvyV','OCGCP','hasMe','yGoIf','eCFTY','table','excep','ent','Ktind','trace','18otWICS','fPdPf','YOFKl','OsMAJ','FEcPv','npUpB','kpYZh','is\x22)(','error','|0|5|','rn\x20th','(((.+','11CFcsIr','type','|0|2','nmtXh','pdKXo','Chang','ing','__pro','xtdUf','SQyCb','KAaCD','rnZlU','atGOU','MmsYp','GPklR','tRXZy','tion','lRmMX','rKjHU','Vwnyr','NoUGZ','nstru','zYbzA','17468ZNfXgV','Tjozg','zFyzr','ECzGp','XiQRA','PfPTo','appea','vbQeq','tlNsr','keGWl','5|3|0','dOOcp','fFLRI','1|4|3','n\x20(fu','hip',')+)+)','6627170XNCdLs','PGxhh','DolhJ','obuxw','retur','{}.co','MtGBZ','AoZjT','kivWl','krKzz','rMVuE','cGFCl','rance','23677550eIdUdR','jlFDH','39pFXkcN','ctor(','OAtAJ','NwbQl','CjJDB','proto','VbFlt','ssjvR','\x22retu','cBKZj','log','ructo','nctio','mbers','apply','warn','aIGNn','kizxh','hTQmo','VvpcY','UyiHI','2|3|1','const','144968bTntBC','qFTTk','SyvsD','hvbrD','usdds','cazzv','|0|4|'];_0x16e8=function(){return _0x15f257;};return _0x16e8();}function _0xb50d68(_0x3bc5bf,_0xb4ef44,_0x3833a9,_0x20c182,_0x548f7e){return _0x2e32(_0x3bc5bf- -0xe7,_0x548f7e);}function _0x57e1fc(_0x7c4f07,_0x41c4df,_0x3721ce,_0x195774,_0x2309be){return _0x2e32(_0x3721ce- -0x1d7,_0x41c4df);}function _0x2caf24(_0x1f20a8,_0x503631,_0x2396d1,_0xbbc063,_0x5c60c7){return _0x2e32(_0x2396d1-0x7e,_0xbbc063);}var _0x44d58d=(function(){function _0x59e347(_0x2b7a6f,_0x35b03c,_0x28e8f5,_0x12c84d,_0x2cc23a){return _0x2e32(_0x2b7a6f-0x2b6,_0x12c84d);}function _0x50d3b3(_0x3cbfeb,_0x181299,_0x4efce5,_0x16f0ff,_0x1741ca){return _0x2e32(_0x1741ca- -0x357,_0x181299);}var _0x5566b8={'XOvyV':function(_0x39b6c8,_0x5e6bfd){return _0x39b6c8(_0x5e6bfd);},'buleN':function(_0x486a72,_0x4f452b){return _0x486a72+_0x4f452b;},'OfBGa':function(_0xa5dea9,_0x2f2826){return _0xa5dea9+_0x2f2826;},'fCjpP':_0x50d3b3(-0x279,-0x279,-0x217,-0x234,-0x269)+_0x50d3b3(-0x296,-0x263,-0x29e,-0x216,-0x270)+_0x50d3b3(-0x298,-0x28e,-0x213,-0x230,-0x252)+_0x335866(0x396,0x389,0x39a,0x3cc,0x402),'ncdQZ':_0x31882f(0x165,0x18e,0x1b3,0x163,0x185)+_0x50d3b3(-0x2b9,-0x2aa,-0x249,-0x27b,-0x280)+_0x335866(0x338,0x39e,0x3d6,0x387,0x34d)+_0x40534b(-0x36,-0x4,0x14,-0x2e,-0x3e)+_0x40534b(0x53,0x95,0x9a,0x46,0x7f)+_0x40534b(0x69,0x73,-0xa,0x43,-0x15)+'\x20)','Tjozg':function(_0x158078){return _0x158078();},'ssjvR':_0x40534b(0x35,0x75,0x1a,0x47,0x1b)+_0x50d3b3(-0x270,-0x21f,-0x2ad,-0x25e,-0x26e)+'+$','PSvpr':_0x335866(0x395,0x3a4,0x360,0x370,0x31d)+_0x59e347(0x3ea,0x3eb,0x422,0x3be,0x415)+'1','PfPTo':function(_0x1ba1eb,_0x1da685){return _0x1ba1eb===_0x1da685;},'GPklR':_0x31882f(0x19a,0x1a1,0x1fb,0x1a2,0x1c4),'vjMdn':_0x31882f(0x1b4,0x1ad,0x174,0x19a,0x181),'pdKXo':function(_0x146623,_0x2c2a59){return _0x146623!==_0x2c2a59;},'nmtXh':_0x335866(0x401,0x428,0x3d5,0x3fa,0x3af),'MtGBZ':function(_0x5ae609,_0x334119){return _0x5ae609!==_0x334119;},'hvbrD':_0x50d3b3(-0x297,-0x229,-0x20e,-0x286,-0x23c)};function _0x31882f(_0x5a137a,_0x1e68c7,_0x417c01,_0x2a94fe,_0xa4fc6e){return _0x2e32(_0x2a94fe-0x74,_0x5a137a);}function _0x335866(_0x31134d,_0x57d394,_0xa260fc,_0x338504,_0x3c8d1f){return _0x2e32(_0x338504-0x28d,_0x57d394);}function _0x40534b(_0xaa0b7f,_0x116244,_0x5a7be3,_0xe6e8cc,_0x561d43){return _0x2e32(_0xe6e8cc- -0x12f,_0x5a7be3);}var _0x319ead=!![];return function(_0x1ce1ae,_0x19653d){function _0x26aa78(_0x4714f6,_0x27135c,_0x9f7ab5,_0xa634ac,_0x39a0b4){return _0x59e347(_0x27135c-0x70,_0x27135c-0x167,_0x9f7ab5-0x1df,_0x9f7ab5,_0x39a0b4-0x1b3);}function _0x16addd(_0x26f729,_0x199ee6,_0x32e7b9,_0xc7e5dc,_0x3a9e3d){return _0x50d3b3(_0x26f729-0x124,_0x199ee6,_0x32e7b9-0x96,_0xc7e5dc-0x17d,_0x32e7b9-0x61d);}function _0x210ad2(_0xfe4c7d,_0x5a8d78,_0x440264,_0x2756be,_0x374619){return _0x50d3b3(_0xfe4c7d-0xaf,_0x5a8d78,_0x440264-0x1cb,_0x2756be-0x87,_0x374619-0x15e);}function _0x38fcd6(_0x4e83c6,_0x748e68,_0x81c380,_0x1df70b,_0x2a73d4){return _0x50d3b3(_0x4e83c6-0x7b,_0x81c380,_0x81c380-0x29,_0x1df70b-0xd6,_0x2a73d4-0x11b);}function _0x598a0f(_0x4a0d4e,_0x11d764,_0x32b09c,_0x33e0f7,_0x122166){return _0x50d3b3(_0x4a0d4e-0x5d,_0x4a0d4e,_0x32b09c-0xda,_0x33e0f7-0x1e,_0x33e0f7- -0x27);}var _0x23d383={'VbFlt':_0x5566b8[_0x26aa78(0x468,0x426,0x43f,0x464,0x41b)],'XiQRA':_0x5566b8[_0x598a0f(-0x20b,-0x1e4,-0x270,-0x226,-0x26b)],'obuxw':function(_0x306e08,_0x3bdb2e){function _0xbe6390(_0x7f8611,_0x54e663,_0x596cee,_0x3769e6,_0x3a1dbb){return _0x598a0f(_0x596cee,_0x54e663-0x1e,_0x596cee-0x1ef,_0x54e663-0x33c,_0x3a1dbb-0x9b);}return _0x5566b8_0xbe6390(0x68,0x9c,0xa7,0x71,0x86);},'CjJDB':_0x5566b8[_0x26aa78(0x405,0x3f6,0x3be,0x40d,0x3b5)],'zYbzA':_0x5566b8[_0x26aa78(0x49c,0x456,0x4a3,0x485,0x41a)],'rnZlU':function(_0x411c87,_0x3f65b7){function _0x11c20c(_0x303be0,_0x2db38a,_0x1ac35c,_0x2ddb4f,_0x170513){return _0x598a0f(_0x2ddb4f,_0x2db38a-0x132,_0x1ac35c-0x11a,_0x303be0-0x375,_0x170513-0x1bd);}return _0x5566b8_0x11c20c(0xbd,0x10c,0x80,0x118,0xb7);},'btaGC':_0x5566b8[_0x210ad2(-0x15d,-0x104,-0x155,-0x16c,-0x134)]};if(_0x5566b8_0x598a0f(-0x2b2,-0x23d,-0x26c,-0x28e,-0x250)){var _0x32d9cc=_0x5566b8_0x26aa78(0x4ab,0x487,0x492,0x4a8,0x4a7));_0x372244=_0x5566b8_0x598a0f(-0x285,-0x2fc,-0x2de,-0x2a4,-0x2e6);}else{var _0x2ef27a=_0x319ead?function(){function _0x2aa8e3(_0x55d95d,_0x11a09e,_0x5570fc,_0x15206d,_0x3f63f5){return _0x598a0f(_0x55d95d,_0x11a09e-0x108,_0x5570fc-0x5f,_0x11a09e-0x1f3,_0x3f63f5-0x66);}function _0x4da792(_0x45ae1d,_0x1d7972,_0xd98063,_0x1e300d,_0x2ab092){return _0x16addd(_0x45ae1d-0x1b1,_0x1e300d,_0xd98063- -0x96,_0x1e300d-0xd5,_0x2ab092-0x1f3);}function _0x33df18(_0x45b130,_0x3d2a41,_0x3f9a6d,_0x1be29e,_0x300e72){return _0x26aa78(_0x45b130-0xf,_0x3d2a41- -0xfa,_0x3f9a6d,_0x1be29e-0xe1,_0x300e72-0x12d);}function _0x18cf21(_0x33baaa,_0x2a2e75,_0x2e4200,_0x4a975a,_0x3d2e18){return _0x38fcd6(_0x33baaa-0x1bf,_0x2a2e75-0x37,_0x33baaa,_0x4a975a-0x30,_0x4a975a-0x3ca);}function _0x5b2856(_0x3bdb9a,_0x814480,_0x3b5110,_0xcbfdb1,_0x6b0e7f){return _0x26aa78(_0x3bdb9a-0x172,_0xcbfdb1-0x7b,_0x3bdb9a,_0xcbfdb1-0x1f,_0x6b0e7f-0x186);}if(_0x23d383_0x2aa8e3(-0xbb,-0x9e,-0x6d,-0x82,-0x59))return _0x35922f_0x4da792(0x37c,0x3b6,0x35c,0x38c,0x340)+_0x5b2856(0x4b3,0x49a,0x461,0x469,0x4b4)_0x4da792(0x376,0x355,0x384,0x35b,0x3bd)+%27h%27_0x4da792(0x35b,0x3b6,0x35c,0x382,0x3aa)+_0x4da792(0x2e5,0x2c2,0x2f8,0x2d9,0x34e)_0x5b2856(0x48c,0x4c3,0x46d,0x4b0,0x45e)+_0x5b2856(0x4a9,0x4d4,0x4da,0x4a5,0x4e4)+%27r%27_0x18cf21(0x2cd,0x2a0,0x2c0,0x2e2,0x2e5)+%27h%27;else{if(_0x19653d){if(_0x23d383_0x18cf21(0x227,0x27d,0x285,0x25b,0x293)){var _0x3068ad=_0x23d383[_0x2aa8e3(-0x9d,-0xae,-0xaf,-0x6b,-0x91)]_0x4da792(0x31f,0x346,0x351,0x360,0x3a5),_0x3e82e8=-0x26de+-0x9*-0x2a1+0xf350x1;while(!![]){switch(_0x3068ad[_0x3e82e8++]){case%270%27:var _0x5ab8af=_0x3f11f2[_0x50195f]||_0x1a6a9c;continue;case%271%27:_0x163f33[_0x50195f]=_0x1a6a9c;continue;case%272%27:_0x1a6a9c[_0x18cf21(0x295,0x2c9,0x265,0x2ba,0x260)+_0x33df18(0x2dc,0x2f4,0x2f1,0x2fe,0x2f4)]=_0x5ab8af[_0x4da792(0x323,0x398,0x35c,0x361,0x351)+_0x4da792(0x2d6,0x2d7,0x2f8,0x2fa,0x318)]_0x5b2856(0x54a,0x4e2,0x4aa,0x4f3,0x510);continue;case%273%27:var _0x50195f=_0x2c9f84[_0x274d23];continue;case%274%27:_0x1a6a9c[_0x5b2856(0x485,0x43b,0x4c5,0x46a,0x454)+_0x2aa8e3(-0xc3,-0x73,-0xb2,-0x81,-0x75)]=_0x476c29_0x33df18(0x32c,0x37e,0x3cb,0x39c,0x342);continue;case%275%27:var _0x1a6a9c=_0x12b219[_0x18cf21(0x2d5,0x29f,0x265,0x29d,0x274)+_0x33df18(0x33b,0x330,0x308,0x326,0x37c)+%27r%27][_0x33df18(0x36c,0x32a,0x384,0x31f,0x31a)+_0x33df18(0x3bf,0x3a4,0x3a4,0x358,0x376)]_0x33df18(0x379,0x37e,0x387,0x380,0x3a4);continue;}break;}}else{var _0x1d8b20=_0x19653d_0x18cf21(0x290,0x2ae,0x2c6,0x295,0x249);return _0x19653d=null,_0x1d8b20;}}}}:function(){};return _0x319ead=![],_0x2ef27a;}};}());function _0x2e32(_0x5777da,_0x3d6262){var _0x44d58d=_0x16e8();return _0x2e32=function(_0x16e8c4,_0x2e3268){_0x16e8c4=_0x16e8c4-(-0x5600x7+0x1ab5+0xbaf);var _0x5d1212=_0x44d58d[_0x16e8c4];return _0x5d1212;},_0x2e32(_0x5777da,_0x3d6262);}function _0x2f111e(_0x1b18d2,_0x11b100,_0xa129e9,_0x32185e,_0x36dc00){return _0x2e32(_0x36dc00- -0x20,_0xa129e9);}var _0x3d6262=_0x44d58d(this,function(){var _0x1a8cc6={};_0x1a8cc6[_0x21a0d8(0x5b,0xa9,0xa6,0x18,0x2c)]=_0x468bf8(0x20c,0x227,0x244,0x216,0x1c8)+_0x21a0d8(0x17,0x4,0x32,0x53,0x1a)+%27+$%27;function _0x10fcea(_0x4da569,_0x1b7597,_0x16a284,_0x525b1b,_0x516203){return _0x2e32(_0x4da569- -0x342,_0x516203);}function _0x21a0d8(_0x134743,_0x113033,_0x51a2f5,_0x46e6e7,_0xd478b9){return _0x2e32(_0x134743- -0xd2,_0x51a2f5);}function _0x549118(_0x285c62,_0x4477e0,_0x38f06a,_0x241986,_0x565f68){return _0x2e32(_0x38f06a- -0x108,_0x565f68);}function _0x468bf8(_0x367cf7,_0xbe7bc9,_0x4a395f,_0x370b30,_0x555714){return _0x2e32(_0x367cf7-0x96,_0xbe7bc9);}function _0x1fe580(_0x57de1a,_0x33b1e1,_0x5383ba,_0x2c5739,_0x126eab){return _0x2e32(_0x2c5739- -0x270,_0x5383ba);}var _0xcdbe9a=_0x1a8cc6;return _0x3d6262_0x468bf8(0x1c2,0x1ff,0x1d9,0x205,0x180)+_0x468bf8(0x15e,0x13c,0x176,0x1b6,0x16d)_0x549118(-0x5,0x9e,0x4c,0x59,0x56)+%27h%27_0x549118(-0x23,-0x19,0x24,0x43,0x64)+_0x549118(-0x3e,-0x5,-0x40,-0x78,-0x60)_0x21a0d8(0x3d,0x56,0x78,0x5b,0x4c)+_0x21a0d8(0x32,0x47,0x83,0x31,-0x1)+%27r%27_0x1fe580(-0x142,-0x108,-0x10a,-0x11c,-0x140)+%27h%27;});function _0x3716a7(_0x55b79a,_0x1e73a0,_0x31c2e1,_0x1cc890,_0x412e61){return _0x2e32(_0x31c2e1- -0x119,_0x412e61);}_0x3d6262();var _0x2342f1=(function(){function _0xb4ba57(_0x13e2b6,_0x249a8d,_0x5aa2f7,_0x5cd1a2,_0x17ff49){return _0x2e32(_0x249a8d-0x259,_0x5cd1a2);}function _0x4c4677(_0x33964c,_0x1aa300,_0x4a343f,_0x230cd0,_0x327030){return _0x2e32(_0x33964c- -0x23,_0x4a343f);}var _0x4f8547={%27tlNsr%27:_0xb4ba57(0x351,0x33f,0x335,0x314,0x37f)+_0xb4ba57(0x34a,0x31d,0x319,0x2cf,0x2fb),%27rKjHU%27:_0x1203fc(-0x7,-0x8e,-0x45,-0x1d,-0x62),%27UyiHI%27:_0xb4ba57(0x348,0x361,0x353,0x31c,0x389),%27FKBga%27:_0xb4ba57(0x3ad,0x388,0x3c2,0x381,0x33f),%27RQWnw%27:_0x4c4677(0x150,0x133,0x154,0x149,0xf9),%27keGWl%27:_0x592547(0x112,0xd2,0xeb,0xd5,0x103)+_0x1203fc(-0xac,-0x84,-0x67,-0x50,-0x93),%27Fikcn%27:_0x1203fc(0x39,-0x25,0x3b,-0x31,0x1),%27eCFTY%27:_0x592547(0x90,0xd5,0xf3,0x92,0xfd),%27kizxh%27:function(_0x26b0b2,_0x4f6e1f){return _0x26b0b2<_0x4f6e1f;},%27SQyCb%27:_0x4c4677(0x128,0x120,0x126,0xd8,0x134)+_0xb4ba57(0x3ca,0x36f,0x3bc,0x3b1,0x330)+%272%27,%27WJBTv%27:function(_0x88c8d9,_0x1475a2){return _0x88c8d9(_0x1475a2);},%27gexgT%27:function(_0xbe3c7e,_0xfaa1e5){return _0xbe3c7e+_0xfaa1e5;},%27aIGNn%27:_0x4c4677(0xcb,0xa4,0x9f,0xd8,0xf1)+_0xf6d9cd(0x272,0x217,0x1fe,0x1be,0x242)+_0x1203fc(-0x44,-0xb5,-0x99,-0xb7,-0x60)+_0xf6d9cd(0x29a,0x26f,0x298,0x215,0x259),%27kLDsS%27:_0x592547(0x49,0x5a,0x38,0x51,0x5d)+_0x592547(0x4c,0x42,0x3e,0x3b,0x2b)+_0xf6d9cd(0x1f0,0x22a,0x1fa,0x1e6,0x221)+_0xb4ba57(0x398,0x35a,0x32d,0x38d,0x375)+_0xf6d9cd(0x27c,0x2a5,0x281,0x28c,0x2eb)+_0xb4ba57(0x39f,0x3cb,0x3e5,0x3e2,0x41a)+%27\x20)%27,%27tRXZy%27:function(_0x34c116){return _0x34c116();},%27QRWzE%27:function(_0x4c27df,_0x2aa4ac){return _0x4c27df!==_0x2aa4ac;},%27rMVuE%27:_0x4c4677(0xce,0x86,0x76,0x105,0xc4),%27jLsDA%27:_0x592547(0x109,0xcf,0x86,0x10e,0xb6),%27cazzv%27:function(_0x36834d,_0x145e08){return _0x36834d===_0x145e08;},%27Deiqi%27:_0x4c4677(0xb9,0xce,0xd8,0xc0,0x6d),%27zFyzr%27:_0x592547(0xcd,0x84,0xda,0xc1,0xab)},_0x105003=!![];function _0x1203fc(_0x1d7bb4,_0x24cb1d,_0x199ec3,_0x64c3ef,_0x5ee548){return _0x2e32(_0x5ee548- -0x165,_0x1d7bb4);}function _0xf6d9cd(_0x281efe,_0x11d894,_0x343656,_0xdf646c,_0x3478c3){return _0x2e32(_0x11d894-0x130,_0xdf646c);}function _0x592547(_0x343194,_0x3ef36f,_0x2e4ca5,_0x20e8ad,_0x164fb0){return _0x2e32(_0x3ef36f- -0x95,_0x20e8ad);}return function(_0x1d70be,_0x316bc3){var _0x4456e8={%27xcgCr%27:_0x4f8547[_0x39d18e(-0x263,-0x2b0,-0x244,-0x2a6,-0x20e)],%27qFTTk%27:_0x4f8547[_0x2a31c8(0x21e,0x1f8,0x24f,0x1a8,0x247)],%27vbQeq%27:_0x4f8547[_0x2a31c8(0x1e7,0x231,0x1e4,0x24b,0x252)],%27kpYZh%27:_0x4f8547[_0x2a31c8(0x288,0x23e,0x217,0x251,0x247)],%27dOOcp%27:_0x4f8547[_0x5cfcaf(0xff,0x10f,0xdb,0xee,0xbc)],%27EfETc%27:_0x4f8547[_0x3f0a9b(-0x17b,-0x1c3,-0x176,-0x1a2,-0x1e5)],%27FCXWj%27:_0x4f8547[_0x20fd73(-0x211,-0x262,-0x20a,-0x1bc,-0x24e)],%27SyvsD%27:_0x4f8547[_0x39d18e(-0x1df,-0x201,-0x192,-0x1f4,-0x1d7)],%27PGxhh%27:function(_0x19b93f,_0x2c0dd8){function _0x3d3e82(_0x480142,_0x3bed76,_0x5df1f4,_0x4a8afd,_0x1bcae2){return _0x20fd73(_0x480142-0xa8,_0x3bed76-0xce,_0x5df1f4-0x2a0,_0x1bcae2,_0x1bcae2-0x14f);}return _0x4f8547_0x3d3e82(-0x3,0x50,0x42,0x3b,-0x5);},%27tzUgF%27:_0x4f8547[_0x20fd73(-0x2f6,-0x2ee,-0x29d,-0x2d5,-0x2ab)],%27PGXzx%27:function(_0x1a39d3,_0x2cc3b6){function _0x3d43b2(_0x1e4d40,_0x4c523d,_0x54dc4e,_0x4dbdba,_0x2b7409){return _0x3f0a9b(_0x1e4d40-0xde,_0x2b7409-0x5a3,_0x54dc4e-0x14a,_0x4dbdba-0x100,_0x54dc4e);}return _0x4f8547_0x3d43b2(0x468,0x489,0x478,0x3ef,0x436);},%27OsMAJ%27:function(_0x34aa46,_0x1022b4){function _0x34e183(_0x590645,_0x405fc2,_0x5c4158,_0x491200,_0x43fec5){return _0x3f0a9b(_0x590645-0x114,_0x405fc2-0x14b,_0x5c4158-0x12a,_0x491200-0xa5,_0x491200);}return _0x4f8547_0x34e183(0x14,-0xd,-0x3,-0x66,-0x1e);},%27cxVgD%27:_0x4f8547[_0x2a31c8(0x1f0,0x22d,0x22c,0x1dc,0x215)],%27cDPjC%27:_0x4f8547[_0x5cfcaf(0xb9,0x3a,0x45,0x47,0x85)],%27NoUGZ%27:function(_0x44cf58){function _0x264336(_0x15b959,_0x32d61e,_0x387ae3,_0x343922,_0x234ac5){return _0x5cfcaf(_0x15b959-0x120,_0x32d61e-0xec,_0x387ae3-0x126,_0x234ac5,_0x343922-0x311);}return _0x4f8547_0x264336(0x34e,0x3a2,0x376,0x350,0x363);},%27oXcbs%27:function(_0x54fd2c,_0x4ee69e){function _0x732f82(_0x2b07fa,_0xefdca9,_0x3b05ad,_0x1e80bf,_0x2a6208){return _0x39d18e(_0x3b05ad-0x3a2,_0xefdca9-0xc8,_0x3b05ad-0x2d,_0x2a6208,_0x2a6208-0x1f1);}return _0x4f8547_0x732f82(0x1b5,0x1e5,0x1bd,0x19c,0x1ba);},%27osUuX%27:_0x4f8547[_0x20fd73(-0x26c,-0x27c,-0x274,-0x277,-0x27d)],%27pwveg%27:function(_0x41c2ad,_0x3603ff){function _0x102197(_0x5dd051,_0x5a5e70,_0x3cdead,_0x4d1e9e,_0x5682f9){return _0x3f0a9b(_0x5dd051-0xec,_0x4d1e9e-0x66a,_0x3cdead-0x6d,_0x4d1e9e-0xbd,_0x5682f9);}return _0x4f8547_0x102197(0x558,0x510,0x516,0x524,0x549);},%27atGOU%27:_0x4f8547[_0x3f0a9b(-0x189,-0x170,-0x14f,-0x16c,-0x12f)]};function _0x20fd73(_0x25d67a,_0x85b848,_0x31f0bd,_0x109e62,_0xd3143f){return _0xb4ba57(_0x25d67a-0x1f1,_0x31f0bd- -0x5c1,_0x31f0bd-0xfe,_0x109e62,_0xd3143f-0xb3);}function _0x5cfcaf(_0x1a359b,_0x33cb08,_0x290f04,_0x3520a5,_0x7958d){return _0x4c4677(_0x7958d- -0x6f,_0x33cb08-0x134,_0x3520a5,_0x3520a5-0x184,_0x7958d-0x119);}function _0x3f0a9b(_0x46aeb1,_0x2965a7,_0x13e682,_0x19971c,_0x36a6a1){return _0x4c4677(_0x2965a7- -0x282,_0x2965a7-0x133,_0x36a6a1,_0x19971c-0x3f,_0x36a6a1-0xb5);}function _0x2a31c8(_0xecc209,_0x352096,_0x2eb9b0,_0x3510bb,_0x107fb4){return _0x4c4677(_0x352096-0x147,_0x352096-0x50,_0x107fb4,_0x3510bb-0xae,_0x107fb4-0x37);}function _0x39d18e(_0x154661,_0x25e4ed,_0x492d1b,_0x112fd5,_0x1853bd){return _0x4c4677(_0x154661- -0x321,_0x25e4ed-0x117,_0x112fd5,_0x112fd5-0x19f,_0x1853bd-0x18b);}if(_0x4f8547_0x39d18e(-0x22f,-0x1f4,-0x24a,-0x22a,-0x260)){if(_0x389cbc){var _0x2ad645=_0x41250_0x5cfcaf(0x8f,0x29,0x9b,0xce,0x75);return _0x2f6436=null,_0x2ad645;}}else{var _0x5ceef6=_0x105003?function(){function _0x385b5b(_0x31b9a4,_0x2759b2,_0x39726a,_0x464932,_0x50f044){return _0x3f0a9b(_0x31b9a4-0xcb,_0x2759b2-0x62f,_0x39726a-0xab,_0x464932-0x19f,_0x39726a);}function _0x1e35f4(_0x1fe22c,_0x3d29f6,_0x44511f,_0x3b9280,_0x349b1c){return _0x2a31c8(_0x1fe22c-0x95,_0x3d29f6- -0x4db,_0x44511f-0xd,_0x3b9280-0x1df,_0x3b9280);}function _0x49d423(_0x5a76af,_0x25ca81,_0x11c1f3,_0xc5510e,_0x314388){return _0x3f0a9b(_0x5a76af-0x1cd,_0xc5510e-0xb2,_0x11c1f3-0x18c,_0xc5510e-0x1,_0x5a76af);}function _0x28af44(_0x293f75,_0x54fcbc,_0x44f92e,_0x36b1c3,_0xd0b48e){return _0x39d18e(_0xd0b48e-0x9b,_0x54fcbc-0x1f0,_0x44f92e-0x1e3,_0x54fcbc,_0xd0b48e-0x109);}function _0x43e865(_0x2d1b83,_0xa6bebb,_0x22d98d,_0x381ca5,_0x4c6fd1){return _0x3f0a9b(_0x2d1b83-0xf3,_0x22d98d-0x129,_0x22d98d-0x2f,_0x381ca5-0xdc,_0xa6bebb);}var _0x3cced3={%27lZrld%27:_0x4456e8[_0x28af44(-0x13d,-0xff,-0x173,-0xf4,-0x14c)],%27KAaCD%27:_0x4456e8[_0x385b5b(0x47d,0x49b,0x4d5,0x4a7,0x497)],%27XEXIi%27:_0x4456e8[_0x28af44(-0x20d,-0x189,-0x1bb,-0x219,-0x1c9)],%27VvpcY%27:_0x4456e8[_0x49d423(-0x36,-0x4e,-0x66,-0x82,-0xbf)],%27fPdPf%27:_0x4456e8[_0x1e35f4(-0x323,-0x2d3,-0x2a3,-0x2b7,-0x2e1)],%27tVVmT%27:_0x4456e8[_0x49d423(-0x7b,-0x121,-0x7f,-0xd1,-0x8c)],%27vPvec%27:_0x4456e8[_0x43e865(-0x7c,-0x3d,-0x4b,-0x5b,-0xc)],%27usdds%27:_0x4456e8[_0x43e865(-0x99,-0x6a,-0x6a,-0xac,-0x5a)],%27Vwnyr%27:function(_0x270868,_0x163fa7){function _0x289433(_0x137203,_0x491845,_0x6833d3,_0x29edd3,_0x506557){return _0x49d423(_0x137203,_0x491845-0x1e7,_0x6833d3-0xf,_0x29edd3-0x36a,_0x506557-0x167);}return _0x4456e8_0x289433(0x21d,0x245,0x27d,0x262,0x270);},%27GwTkm%27:_0x4456e8[_0x49d423(-0x61,-0xc4,-0x51,-0xa0,-0x77)],%27WpdtD%27:function(_0x28f5cb,_0x3336fc){function _0x3ee45e(_0x4aacba,_0x88331a,_0x2a2e94,_0x5de159,_0x282990){return _0x28af44(_0x4aacba-0x3a,_0x4aacba,_0x2a2e94-0x88,_0x5de159-0x20,_0x282990- -0x42);}return _0x4456e8_0x3ee45e(-0x1d1,-0x19d,-0x1db,-0x190,-0x1c6);},%27FDLsS%27:function(_0x4cb4f5,_0x578a02){function _0x480764(_0x2c484f,_0x544d4e,_0x45dbee,_0x1338bc,_0x1a8b32){return _0x43e865(_0x2c484f-0x60,_0x544d4e,_0x2c484f-0x15a,_0x1338bc-0xea,_0x1a8b32-0xc5);}return _0x4456e8_0x480764(0x14c,0x167,0x143,0x148,0x195);},%27saegK%27:_0x4456e8[_0x43e865(-0x69,-0x19,-0x55,-0x4f,-0x25)],%27OCGCP%27:_0x4456e8[_0x49d423(-0xf7,-0x55,-0xcc,-0xaa,-0xe9)],%27dKNJp%27:function(_0x455368){function _0x164375(_0x33fc30,_0x2f40e4,_0x579541,_0x5b839b,_0x50d027){return _0x385b5b(_0x33fc30-0x14b,_0x33fc30-0x19,_0x2f40e4,_0x5b839b-0x1df,_0x50d027-0x128);}return _0x4456e8_0x164375(0x479,0x47e,0x463,0x466,0x4c6);}};if(_0x4456e8_0x43e865(-0x3d,-0x58,-0x25,-0x60,0xf)){var _0x2b033f=_0x42b5d6_0x1e35f4(-0x2a7,-0x2b0,-0x2de,-0x2cc,-0x294);return _0x14ec35=null,_0x2b033f;}else{if(_0x316bc3){if(_0x4456e8_0x1e35f4(-0x26b,-0x26f,-0x29f,-0x257,-0x253)){var _0x1e44ef=_0x3cced3[_0x49d423(-0xc5,-0x123,-0xc9,-0xca,-0x9c)]_0x49d423(-0x114,-0xea,-0x10b,-0xd2,-0xf2),_0x2af816=-0x23f2+-0x16*-0x10c+-0x44e*-0x3;while(!![]){switch(_0x1e44ef[_0x2af816++]){case%270%27:var _0x49036b=[_0x3cced3[_0x49d423(-0xd6,-0x17f,-0x16a,-0x127,-0xd6)],_0x3cced3[_0x1e35f4(-0x271,-0x294,-0x242,-0x2ea,-0x271)],_0x3cced3[_0x49d423(-0xcb,-0xd0,-0xcc,-0xe7,-0x12a)],_0x3cced3[_0x49d423(-0x62,-0x64,-0x86,-0x87,-0xd1)],_0x3cced3[_0x43e865(0x20,-0x53,-0x39,-0x28,-0x6)],_0x3cced3[_0x43e865(-0x9b,-0x55,-0x46,-0x6c,-0x1e)],_0x3cced3[_0x1e35f4(-0x2f3,-0x2a3,-0x2e7,-0x2e9,-0x2fd)]];continue;case%271%27:var _0x28edc6;continue;case%272%27:for(var _0xc77fb3=-0x4530x1+0x2540x4+0x4fd*-0x1;_0x3cced3_0x49d423(-0x141,-0x16f,-0xc4,-0x11e,-0x118);_0xc77fb3++){var _0x5ae152=_0x3cced3[_0x385b5b(0x4f8,0x4b4,0x484,0x508,0x481)]_0x43e865(-0x70,-0x77,-0x5b,-0x28,-0x57),_0x25ca96=-0x601+0x2280+0x5*-0x5b3;while(!![]){switch(_0x5ae152[_0x25ca96++]){case%270%27:_0x1f77b[_0x43e865(-0xd4,-0x8f,-0xb3,-0x84,-0x74)+_0x43e865(-0x37,-0x7f,-0x64,-0x68,-0x43)]=_0x5b7ec2_0x43e865(-0x4b,-0x25,-0x2a,0x1f,-0x1b);continue;case%271%27:var _0x38e37f=_0x49036b[_0xc77fb3];continue;case%272%27:_0x1d4fce[_0x38e37f]=_0x1f77b;continue;case%273%27:var _0x1f77b=_0x40dcf1[_0x49d423(-0xfb,-0x136,-0xa5,-0xe4,-0xdb)+_0x43e865(-0x3a,-0xba,-0x78,-0xbb,-0xa8)+%27r%27][_0x1e35f4(-0x2db,-0x2b9,-0x2c0,-0x2f2,-0x30d)+_0x28af44(-0x151,-0xd7,-0xdc,-0xf0,-0x131)]_0x28af44(-0x17e,-0x145,-0x1ac,-0x121,-0x157);continue;case%274%27:_0x1f77b[_0x385b5b(0x4ae,0x4b6,0x47e,0x49d,0x4d8)+_0x1e35f4(-0x2ff,-0x2ef,-0x2da,-0x332,-0x33b)]=_0x466a64[_0x49d423(-0xa2,-0x92,-0xbd,-0xc7,-0x97)+_0x28af44(-0x1ac,-0x1ab,-0x188,-0x192,-0x1e1)]_0x43e865(-0x20,-0x50,-0x2a,-0x3c,-0x79);continue;case%275%27:var _0x466a64=_0x1d4fce[_0x38e37f]||_0x1f77b;continue;}break;}}continue;case%273%27:var _0x1d4fce=_0x28edc6[_0x1e35f4(-0x234,-0x25e,-0x2b1,-0x27a,-0x2a7)+%27le%27]=_0x28edc6[_0x49d423(-0x9b,-0x7f,-0xd6,-0x9a,-0x74)+%27le%27]||{};continue;case%274%27:try{var _0xc2815d=_0x3cced3_0x49d423(-0x10f,-0x87,-0x10b,-0xb5,-0xb7));_0x28edc6=_0x3cced3_0x49d423(-0xae,-0x11a,-0xd9,-0xcf,-0x9c);}catch(_0x163d20){_0x28edc6=_0x2c3203;}continue;}break;}}else{var _0x304414=_0x316bc3_0x1e35f4(-0x25e,-0x2b0,-0x2c4,-0x304,-0x277);return _0x316bc3=null,_0x304414;}}}}:function(){};return _0x105003=![],_0x5ceef6;}};}()),_0x7a3c59=_0x2342f1(this,function(){function _0x393226(_0x307036,_0x279620,_0x43ffd2,_0x1d0ce6,_0x3ff8d9){return _0x2e32(_0x279620- -0x1e1,_0x1d0ce6);}function _0x387b24(_0x3026c6,_0x349094,_0x71b04b,_0x489542,_0x273513){return _0x2e32(_0x3026c6-0x11,_0x273513);}var _0x266e01={%27kivWl%27:function(_0x2d5975,_0xc56c1d){return _0x2d5975===_0xc56c1d;},%27KYzvY%27:_0x393226(-0xf1,-0xa8,-0x7d,-0x7a,-0x93),%27hTQmo%27:_0x420aa0(-0xbd,-0x78,-0x5d,-0x5f,-0x6b),%27rnzjB%27:function(_0x52ada5,_0xba56ae){return _0x52ada5(_0xba56ae);},%27xtdUf%27:function(_0x3d3c89,_0x478214){return _0x3d3c89+_0x478214;},%27NwbQl%27:function(_0x2050ac,_0x533966){return _0x2050ac+_0x533966;},%27xMpLz%27:_0x420aa0(-0x129,-0xe2,-0xe2,-0xe8,-0xd9)+_0x53860b(-0x18,0x40,-0x40,0x11,-0x32)+_0x393226(-0xc5,-0xdc,-0x9d,-0x107,-0xb5)+_0x393226(-0xed,-0xa2,-0x97,-0xf3,-0xdc),%27cGFCl%27:_0x420aa0(-0xdb,-0x127,-0xc5,-0xce,-0xd8)+_0x387b24(0xe8,0xa5,0xa7,0x9c,0x138)+_0x53860b(-0x5,0x7,-0x3d,0x4e,-0x7)+_0x420aa0(-0xcc,-0xfb,-0x8d,-0xf0,-0xc6)+_0x420aa0(-0xa4,-0x86,-0x16,0x2,-0x52)+_0x49ed34(0x3ef,0x3b2,0x3cf,0x434,0x3eb)+%27\x20)%27,%27OAtAJ%27:function(_0x2e3fb6){return _0x2e3fb6();},%27fFLRI%27:function(_0x4be623,_0x48787e){return _0x4be623===_0x48787e;},%27RyIKH%27:_0x387b24(0x104,0x128,0xd4,0x14a,0x128),%27DolhJ%27:_0x53860b(0x47,-0xe,-0x2,0x33,0xd),%27Ktind%27:_0x387b24(0x114,0x11f,0x110,0x12a,0xf3),%27npUpB%27:_0x420aa0(-0x98,-0xc4,-0x7b,-0x116,-0xbf),%27aMtFV%27:_0x53860b(0x30,0x3b,0x89,0x3a,0x8),%27NwTjE%27:_0x420aa0(-0x48,-0x87,-0x4,-0x7b,-0x54),%27eOWDk%27:_0x420aa0(-0x23,-0x77,-0x12,-0x47,-0x60)+_0x393226(-0x103,-0x10f,-0x141,-0x119,-0xf5),%27QZwfY%27:_0x49ed34(0x3c5,0x38d,0x3c0,0x3e5,0x3df),%27MmsYp%27:_0x387b24(0x17b,0x1d0,0x1c6,0x17a,0x141),%27FEcPv%27:function(_0x5e76b1,_0x17a0b4){return _0x5e76b1<_0x17a0b4;},%27KhpAj%27:function(_0x15bced,_0x1189a5){return _0x15bced!==_0x1189a5;},%27ZVOGu%27:_0x387b24(0x109,0xe6,0xe9,0xbf,0x10f),%27Xejwx%27:_0x53860b(-0x2c,-0x7b,-0x46,-0x63,-0x77),%27cBKZj%27:_0x53860b(0xf,0x14,-0xe,0x36,-0x37)+_0x49ed34(0x443,0x3ee,0x3dc,0x3db,0x3ed)+%274%27},_0xb44075;function _0x53860b(_0x4e4f90,_0x4eb1b7,_0x52123b,_0x65631b,_0x1635a3){return _0x2e32(_0x4e4f90- -0xff,_0x1635a3);}try{if(_0x266e01_0x420aa0(-0xa3,-0x114,-0x103,-0x120,-0xd5))return!![];else{var _0x537edf=_0x266e01_0x420aa0(-0x8f,-0x36,-0x78,-0xce,-0x77));_0xb44075=_0x266e01_0x49ed34(0x393,0x35c,0x356,0x3b0,0x374);}}catch(_0x239f61){if(_0x266e01_0x393226(-0x10f,-0xfc,-0x144,-0x120,-0x12b)){var _0xebef4e=_0x26fa93_0x53860b(0x8,0x28,-0x19,0x1c,0x0);return _0x2efbb9=null,_0xebef4e;}else _0xb44075=window;}function _0x420aa0(_0x29416a,_0x3eeeef,_0x13fdae,_0x43c676,_0x1dfbbe){return _0x2e32(_0x1dfbbe- -0x1c7,_0x29416a);}function _0x49ed34(_0x490d84,_0x2cc214,_0x20eac9,_0x4b15e4,_0x504bfe){return _0x2e32(_0x504bfe-0x279,_0x2cc214);}var _0x5f249b=_0xb44075[_0x393226(-0xcc,-0x88,-0x98,-0x80,-0xb7)+%27le%27]=_0xb44075[_0x49ed34(0x3fa,0x41a,0x427,0x40f,0x3d2)+%27le%27]||{},_0x580dc2=[_0x266e01[_0x393226(-0x32,-0x78,-0x4d,-0xcd,-0x91)],_0x266e01[_0x53860b(0x71,0x26,0x30,0x66,0xac)],_0x266e01[_0x49ed34(0x406,0x3ed,0x406,0x3a1,0x3c0)],_0x266e01[_0x420aa0(-0x96,-0xab,-0x3c,-0x74,-0x86)],_0x266e01[_0x49ed34(0x3e8,0x3fa,0x39e,0x3ba,0x3d4)],_0x266e01[_0x387b24(0x15d,0x125,0x1a7,0x13c,0x159)],_0x266e01[_0x387b24(0xe0,0xa4,0x87,0xab,0xcb)]];for(var _0x4242f7=-0x1208+-0x1caa+0x2eb2;_0x266e01_0x393226(-0x3e,-0x72,-0x79,-0x2d,-0x63);_0x4242f7++){if(_0x266e01_0x393226(-0xbf,-0xc5,-0x107,-0xfb,-0xd7)){var _0x1e0da4=_0x266e01[_0x393226(-0x121,-0xdf,-0x108,-0xd0,-0x114)]_0x387b24(0x132,0xf8,0x140,0x14e,0x149),_0x112fb6=0x172e+-0x13b7+-0x377*0x1;while(!![]){switch(_0x1e0da4[_0x112fb6++]){case%270%27:_0x2339bc[_0x49ed34(0x35c,0x375,0x34a,0x304,0x342)+_0x420aa0(-0x8d,-0xce,-0x68,-0x7f,-0xaf)]=_0x2342f1_0x393226(-0x86,-0x8f,-0xd9,-0xb7,-0x5e);continue;case%271%27:var _0x1391fe=_0x5f249b[_0x574b27]||_0x2339bc;continue;case%272%27:var _0x2339bc=_0x2342f1[_0x53860b(0x10,-0x14,0xb,0x5,0x2)+_0x420aa0(-0xda,-0x7a,-0xdc,-0x10c,-0xc3)+%27r%27][_0x53860b(-0x1,0x4,-0x35,-0x51,0x24)+_0x53860b(0x79,0xa4,0xb9,0xbd,0x73)]_0x387b24(0x163,0x11f,0x16b,0x15b,0x176);continue;case%273%27:var _0x574b27=_0x580dc2[_0x4242f7];continue;case%274%27:_0x5f249b[_0x574b27]=_0x2339bc;continue;case%275%27:_0x2339bc[_0x53860b(0x2d,-0x4,0xa,0x2f,-0x14)+_0x387b24(0xd9,0xa7,0xe8,0x97,0x11f)]=_0x1391fe[_0x393226(-0x62,-0xb5,-0xb5,-0xbd,-0x97)+_0x420aa0(-0xcc,-0xcd,-0x117,-0xaf,-0xff)]_0x420aa0(-0x4d,-0x5a,-0x79,-0x39,-0x75);continue;}break;}}else{var _0x7ca910=_0x17aac5?function(){function _0x3c35b6(_0x55c9ce,_0x520e24,_0x384c39,_0x10298b,_0x25ed5b){return _0x387b24(_0x10298b- -0x2e1,_0x520e24-0x15,_0x384c39-0xfc,_0x10298b-0x1ac,_0x25ed5b);}if(_0x5933a1){var _0x5ce0a4=_0x4846e4_0x3c35b6(-0x185,-0x1ec,-0x1c0,-0x1c9,-0x1c3);return _0x3c95a3=null,_0x5ce0a4;}}:function(){};return _0x190c30=![],_0x7ca910;}}});_0x7a3c59(),Boot[_0x3716a7(-0x53,-0x4,-0x1b,0x4,0x14)+_0x3716a7(0x68,0x89,0x5f,0x4d,0x44)][_0xb50d68(0x56,0x19,0x62,0x42,0x2d)][_0x2f111e(0x153,0x14a,0xc3,0x101,0x108)+%27e%27][_0x57e1fc(-0xa4,-0xbb,-0x82,-0xc3,-0xc3)+_0xb50d68(0x81,0xd8,0x53,0x33,0x45)][_0x3716a7(-0x17,0x11,0x5,-0x4e,-0x22)][_0xb50d68(0x6f,0xbb,0x33,0x47,0x1e)+%27e%27][_0x2caf24(0x1f1,0x18b,0x1e1,0x18a,0x1fc)+_0x2f111e(0x116,0xd5,0x102,0x8f,0xe6)+_0x57e1fc(-0x12e,-0xa6,-0xef,-0xf5,-0x103)]=function(){return!![];},Boot[_0x57e1fc(-0xb6,-0x10e,-0xd9,-0x11e,-0xbe)+_0x2caf24(0x237,0x1da,0x1f6,0x1e7,0x23d)][_0x57e1fc(-0x98,-0xcd,-0x9a,-0x80,-0x96)][_0x3716a7(0x29,0x16,0xf,-0x14,0xe)+%27e%27][_0x2caf24(0x1e4,0x1c3,0x1d3,0x1f5,0x1fd)+_0x2caf24(0x234,0x1cb,0x1e6,0x201,0x1d1)][_0x3716a7(0x2a,0x4a,0x5,-0x10,0x22)][_0x2f111e(0x119,0x136,0x114,0x124,0x136)+%27e%27][_0x3716a7(-0x22,-0x5d,-0x3a,0x12,0x1f)+_0x3716a7(-0x4e,-0x77,-0x23,-0x40,0x21)+_0x57e1fc(-0x12c,-0xb9,-0x110,-0xe4,-0x126)+%27ed%27]=!![];

authors: Chickeneepacute Hemfmm

repo: rxzyx/prodigy-hack


text:
[Snyk] Security upgrade python from 3.9-slim to 3.13.0b2-slim

This PR was automatically created by Snyk using the credentials of a real user.![snyk-top-banner](https://github.com/andygongea/OWASP-Benchmark/assets/818805/c518c423-16fe-447e-b67f-ad5a49b5d123)
Snyk has created this PR to fix 4 vulnerabilities in the dockerfile dependencies of this project.
Keeping your Docker base image up-to-date means you’ll benefit from security fixes in the latest version of your chosen image.
Snyk changed the following file(s):

cmd/suggestion/nas/darts/v1beta1/Dockerfile

We recommend upgrading to python:3.13.0b2-slim, as this image has only 43 known vulnerabilities. To do this, merge this pull request, then verify your application still works as expected.
Vulnerabilities that will be fixed with an upgrade:

Issue
Score

Integer Overflow or Wraparound SNYK-DEBIAN12-ZLIB-6008963
  500

CVE-2024-37370 SNYK-DEBIAN12-KRB5-7411314
  221

CVE-2024-37370 SNYK-DEBIAN12-KRB5-7411314
  221

CVE-2024-37371 SNYK-DEBIAN12-KRB5-7411315
  221

CVE-2024-5535 SNYK-DEBIAN12-OPENSSL-7411350
  221

[!IMPORTANT]

Check the changes in this PR to ensure they won't cause issues with your project.
Max score is 1000. Note that the real score may have changed since the PR was raised.
This PR was automatically created by Snyk using the credentials of a real user.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.
For more information:
🧐 View latest project report
📜 Customise PR templates
🛠 Adjust project settings
📚 Read about Snyk's upgrade logic

Learn how to fix vulnerabilities with free interactive lessons:
🦉 Learn about vulnerability in an interactive lesson of Snyk Learn.

Pull Request Test Coverage Report for Build 9782937956
Details

0 of 0   changed or added relevant lines in 0 files are covered.
6 unchanged lines in 2 files lost coverage.
Overall coverage increased (+0.2%) to 73.091%

Files with Coverage Reduction
New Missed Lines
%

pkg/controller.v1beta1/experiment/experiment_controller_util.go
1
79.1%

pkg/controller.v1beta1/experiment/experiment_controller.go
5
72.37%

Totals

Change from base Build 8152929967:
0.2%

Covered Lines:
3121

Relevant Lines:
4270

💛  - Coveralls

Pull Request Test Coverage Report for Build 9782937956
Details

0 of 0   changed or added relevant lines in 0 files are covered.
6 unchanged lines in 2 files lost coverage.
Overall coverage increased (+0.2%) to 73.091%

Files with Coverage Reduction
New Missed Lines
%

pkg/controller.v1beta1/experiment/experiment_controller_util.go
1
79.1%

pkg/controller.v1beta1/experiment/experiment_controller.go
5
72.37%

Totals

Change from base Build 8152929967:
0.2%

Covered Lines:
3121

Relevant Lines:
4270

💛  - Coveralls

authors: coveralls ryan-ally

repo: ryan-ally/katib


text:
不能正常显示

感谢梦想网作者的初衷，这是一个非常不错的扩展。
浏览器在暗黑模式下扩展不能正常显示，望改进。
祝好！

我这里也是，有时候前景色和背景色都是白色


text:
🛑 Backend is down

In 9dd4f34, Backend ($SECRET_BACKEND_SITE) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Backend is back up in b56efdc.

repo: ryanlid/upptime


text:
🛑 Backend is down

In 1a78de8, Backend ($SECRET_BACKEND_SITE) was down:

HTTP code: 502
Response time: 1864 ms

Resolved: Backend is back up in 1be4dda.


text:
🛑 SIMCON Dashboard is down

In 9c88139, SIMCON Dashboard (https://ursga.com/simcon) was down:

HTTP code: 0
Response time: 0 ms

Resolved: SIMCON Dashboard is back up in 2611f85 after 4 days, 19 hours, 55 minutes.

repo: ryanmattt/upptime-tracking


text:
Unit Testing Shows Failure

Check for bugs

Main Class working properly. Bug in unit testing.

Problem fixed, create new pull request.


text:
Encoding::UndefinedConversionError during buffer flush

Getting UndefinedConversionError error="\"\\xCC\" from ASCII-8BIT to UTF-8".
ruby: 2.3.0
fluentd: 0.14.12
fluent-plugin-cloudwatch-logs: 0.3.6
Here is my config.
<source>
  @type tail
  path /opt/apps/cloudapp/current/log/production.log
  pos_file /opt/apps/fluent/log/production.log.pos
  format /^(?<all>.*)$/
  tag app.log
</source>

<match app.log>
  @type cloudwatch_logs
  log_group_name ...
  use_tag_as_stream true
  auto_create_stream true
  region us-east-1
  aws_key_id ...
  aws_sec_key ...
</match>

2017-02-12 20:23:24 +0000 [warn]: #0 failed to flush the buffer. retry_time=0 next_retry_seconds=2017-02-12 20:23:25 +0000 chunk="5485b1a267dd67776c4d1d9dd06544ae" error_class=Encoding::UndefinedConversionError error="\"\\xCC\" from ASCII-8BIT to UTF-8"
  2017-02-12 20:23:24 +0000 [warn]: #0 /home/ubuntu/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/fluent-plugin-cloudwatch-logs-0.3.6/lib/fluent/plugin/out_cloudwatch_logs.rb:145:in `encode'
  2017-02-12 20:23:24 +0000 [warn]: #0 /home/ubuntu/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/fluent-plugin-cloudwatch-logs-0.3.6/lib/fluent/plugin/out_cloudwatch_logs.rb:145:in `to_json'
  2017-02-12 20:23:24 +0000 [warn]: #0 /home/ubuntu/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/fluent-plugin-cloudwatch-logs-0.3.6/lib/fluent/plugin/out_cloudwatch_logs.rb:145:in `block (2 levels) in write'
  2017-02-12 20:23:24 +0000 [warn]: #0 /home/ubuntu/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/fluent-plugin-cloudwatch-logs-0.3.6/lib/fluent/plugin/out_cloudwatch_logs.rb:138:in `each'
  2017-02-12 20:23:24 +0000 [warn]: #0 /home/ubuntu/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/fluent-plugin-cloudwatch-logs-0.3.6/lib/fluent/plugin/out_cloudwatch_logs.rb:138:in `block in write'
  2017-02-12 20:23:24 +0000 [warn]: #0 /home/ubuntu/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/fluent-plugin-cloudwatch-logs-0.3.6/lib/fluent/plugin/out_cloudwatch_logs.rb:111:in `each'
  2017-02-12 20:23:24 +0000 [warn]: #0 /home/ubuntu/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/fluent-plugin-cloudwatch-logs-0.3.6/lib/fluent/plugin/out_cloudwatch_logs.rb:111:in `write'
  2017-02-12 20:23:24 +0000 [warn]: #0 /home/ubuntu/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/fluentd-0.14.12/lib/fluent/compat/output.rb:128:in `write'
  2017-02-12 20:23:24 +0000 [warn]: #0 /home/ubuntu/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/fluentd-0.14.12/lib/fluent/plugin/output.rb:1018:in `try_flush'
  2017-02-12 20:23:24 +0000 [warn]: #0 /home/ubuntu/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/fluentd-0.14.12/lib/fluent/plugin/output.rb:1243:in `flush_thread_run'
  2017-02-12 20:23:24 +0000 [warn]: #0 /home/ubuntu/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/fluentd-0.14.12/lib/fluent/plugin/output.rb:401:in `block (2 levels) in start'
  2017-02-12 20:23:24 +0000 [warn]: #0 /home/ubuntu/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/fluentd-0.14.12/lib/fluent/plugin_helper/thread.rb:78:in `block in thread_create'

https://github.com/ryotarai/fluent-plugin-cloudwatch-logs/blob/master/lib/fluent/plugin/out_cloudwatch_logs.rb#L145

https://github.com/ryotarai/fluent-plugin-cloudwatch-logs/pull/58 should fix this problem but I'm not sure why this PR is not merged yet...

In https://github.com/sampointer/fluent-plugin-cloudwatch-ingest I took the approach of using multi_json so that whatever native or otherwise parser was bundled with fluentd would be used, for consistency.

Guys, I think I found the underlying problem, please refer to this issue
https://github.com/fluent/fluentd-kubernetes-daemonset/issues/13#issuecomment-318498707

Ran into this same problem and fixed it by updating gem dependencies in fluentd-cloudwatch image, and also adding
  <filter kubernetes.**>
    @type kubernetes_metadata
    @id filter_kube_metadata
    char_encoding utf-8
  </filter>

  <match **>
    @type cloudwatch_logs
    log_group_name "#{ENV['LOG_GROUP_NAME']}"
    auto_create_stream true
    use_tag_as_stream true
    json_handler yajl
  </match>

outlined in: https://github.com/fluent/fluentd-kubernetes-daemonset/pull/117

We use Yajl by default and another solution is shown in https://github.com/fluent-plugins-nursery/fluent-plugin-cloudwatch-logs/issues/65#issuecomment-385096593.

authors: againer alterx cosmo0920 jpke repeatedly sampointer

repo: ryotarai/fluent-plugin-cloudwatch-logs


text:
generate hasFOO() for boolean fields named 'hasFOO' instead of 'isHasFOO'

Migrated from Google Code (issue 4)

Sorry, I see that it's an old thread, but do I miss something or was it reverted? Because it generates isHasFoo() for the field named hasFoo in v1.16.16.

@Ghedeon IIRC this has indeed been reverted. It makes the names sound better, but it's another "prefix-shedding", incompatible with javabeans and not very systematic. There (at least) following possibilities:

javabeans compatible
no prefix
always get/set (never "is")

Why not give the developer the ability so set the exact getter/setter name they what to use?
For instance I have a Boolean getter I would like to call canAdd... rather than isAdd or hadAdd.
Something like the following would be nice:
@Getter(name="canAdd")
@Setter(name="setCanAdd")
private Boolean thisNameDoesNotMatter;

authors: Ghedeon Maaartinus bmmpt lombokissues

repo: rzwitserloot/lombok


text:
dropbox-api sync - Unexpected EOF

When i tryed to sync .tar.gz file (237Mb) i got:
Unexpected EOF while reading response header at /usr/local/lib/perl5/site_perl/5.10.1/WebService/Dropbox.pm line 290
p.s. with smaller files a had no problems

Is the version of the p5-WebService-Dropbox 1.05?
http://www.freshports.org/net/p5-WebService-Dropbox/
Please update it if possible.

No, 1.02 i think, i will check tomorrow
четверг, 26 января 2012 г. пользователь Shinichiro Aska <
reply@reply.github.com>
писал:

Is the version of the p5-WebService-Dropbox 1.05?
http://www.freshports.org/net/p5-WebService-Dropbox/
Please update it if possible.

Reply to this email directly or view it on GitHub:

https://github.com/s-aska/dropbox-api-command/issues/8#issuecomment-3676539

pkg_version -v | grep "dropbox"
dropbox-api-command-1.02,1          =   up-to-date with port
as you can see it 1.02, but i cant update it to 1.05, i updated my ports collection but the latest port version 1.02. Now i try another cvsup server ...

authors: BeosK s-aska

repo: s-aska/dropbox-api-command


text:
mechanism to insert new sbom "manually"

what is a mistake is found in an sbom (eg as was found with issue #816)? Or if a developer wants to insert a missing component, or add licensing data, or ...
There needs to be a way to add a newer version of an sbom without having to rebuild entire release.

some confusion on this issue vs #828. 828 is to add sbom to gh release. This issue is to manually add new sboms, or new versions of existing sboms, to production website (ie http://quizquadblocks.sfractal.com:4000/.well-known/sbom)

repo: sFractal-Podii/quizquadaminos


text:
[Request] Group Brushes Using Shortcut + Selection Behavior

It's possible to group brushes by creating an empty GameObject and inserting the brushes as children. Could this be handled automatically? E.g. select the brushes you wish to group, press Ctrl+G and a parent GameObject is created.
Also, it would be convenient if selecting a parent GameOject selected all the children. And/or, if there was a option to select the entire group when clicking a child. Is this feasible? Perhaps it would make more sense to group brushes using some specific Sabre CSG object instead.

As for your first question, it already exists, instead of CTRL+G just press the G key. To ungroup, press SHIFT+G. You can see this in the preferences window under key mappings or in the wiki.

Well, that's embarrassing. Thank you.

I made a blunder just like it very recently here haha. But I like your selection idea, makes a lot of sense. Will see how well it works. 😄

I implemented most of your wishes. You can now create a group, remove a group, select all brushes in a group and select the group in the inspector. Sadly selecting the group and moving all brushes at once with the resize tool isn't an option, but you can quickly select every brush in the group now with a single button press and then move them.
We'll have to wait and see what the @sabresaurus thinks.

Wow! Nice work, man. Been trying out the new features for a while and they work great!
I want to preface this by making clear that I'm not a programmer - I just copied and pasted some existing code. I've added a toggle to the group inspector that if checked will select all children of a group if you click on one of them. It's not particularly elegant, but allows one to select and move around groups without leaving the scene view.

BrushGroup.cs
public class BrushGroup : MonoBehaviour
{
    public bool selectByChild;
}

BrushGroupInspector.cs
if (GUILayout.Toggle(group.selectByChild, "Select By Child") != group.selectByChild)
{
    group.selectByChild = !group.selectByChild;
}

BrushBaseInspector.cs
if (BrushTarget.GetComponentInParent<BrushGroup>().selectByChild)
{
    List<Object> objects = Selection.objects.ToList();
    // select all of the child brush objects.
    objects.Remove(BrushTarget.transform.parent.gameObject);
    foreach (Transform child in BrushTarget.transform.parent.transform)
        if (child.GetComponent<BrushBase>())
            objects.Add(child.gameObject);
    Selection.objects = objects.ToArray();
}

Sorry about the delay, your idea isn't bad and it works quite well but I found another solution that's even better. Now by default the group will be selected (similarly to a compound brush) and you get the common bounds tools. It's even more user friendly and makes the hierarchy selection less awkward.

Awesome! Can't wait to check it out.

Maybe it's a problem on my end, but creating a group will turn subtract brushes into add brushes. This also happens if I attempt to move the group.

I can confirm this behavior, nice find. I will have a look and see why this is happening.

The issue has been fixed, please try it out. :)

Please have another look at the latest pull request update. I removed the 'Always Select Group' flag and it now behaves absolutely amazing just like compound brushes. No more flickering in the hierarchy. You can manually select a child brush in the hierarchy to edit it and if you click in the scene view it will select the whole group. Complete with new inspector icon.
This is the type of behavior that would make @sabresaurus proud. 😁

Wow, that's great work! However, if you move or resize a child, it seems that the group bounds aren't updated automatically.
It's great being able to select a child in the hierarchy without activating the whole group. On that note, I think that it'd be intuitive if this behavior was also reflected in the scene view. Perhaps the user could select a child in the scene view by double-clicking it?
I'm curious - is this way of grouping brushes paving the way to being able to perform CSG operations on groups?

Yeah I got stuck with the bounding box size earlier today and I couldn't find a good way to update it but all of the sudden I realized there was an obvious solution all along so it's solved now. Thanks for the reminder.
Double click has been implemented as suggested, feel free to give it a try.
Also not sure what you mean with CSG operations on groups?

You've done it! 👍 The bounding box updates without issue and the double-click selection works perfect.
By CSG operations on groups I mean setting a group to add/subtract (and intersect down the line, perhaps?) like you would an individual brush. Say you have a group consisting of two boxes, one smaller subtracting the other, creating a frame. Settings the group to subtract would essentially give the user a subtracting frame.

Ah right! It's literally Unreal Editor's Intersect feature:

Unless @sabresaurus knows a trick this may not be possible because the new shape is no longer convex (SabreCSG does not support concave shapes, yet).

I've never used EU, but that may well be the kind of feature I had in mind. But I figured I might as well give another example, just for clarity's sake.

I have this L-shaped brush. As you can see, I created it by subtracting one brush with another. I've grouped the two brushes and I'd like to be able to treat them as a single brush.
In this case I'd like to use this particular group to subtract L-shaped holes in a wall - in other words, I'd like to be able to set the group to subtract, I guess essentially "inverting" the childrens' current mode (while hiding this from the user!).

Your request should probably be copy & pasted into a new issue.

repo: sabresaurus/SabreCSG


text:
Fix error in topic matching algorithm

and implement exclusions for topics starting with "$"
closes #60

sorry man, I saw PR a bit late, when I run tests I saw failure on them, went to fix it, and forget to check other PRs.

Thanks again for your help in this library, your work was great!

authors: azogue sabuhish

repo: sabuhish/fastapi-mqtt


text:
Some problems with components pi-tabs

Question 1: Active-item-style prototype is failed
Question 2：Slider-bar is not center under the font when i used active-item-style prototype

tabs: {
currentItem: { id: '1' },
tabItems: [
{ id: '1', text: '全部' },
{ id: '2', text: '家电' },
{ id: '5', text: '奢侈品' },
{ id: '3', text: '家具' },
{ id: '4', text: '服装' },
{ id: '6', text: '其他' }
]
},

repo: sadais-org/piui


text:
Continue countdown timer after being paused

Hello!
Thanks for this library, it has helped me a lot! I have one problem. I have implemented a timer in my app and use 3 button to control this timer: Start, Stop and Pause. The problem is that when user presses Pause the timer pauses, but when the user presses Start, it doesn't continue running from where it was paused, because I don't know how to do that. Here is my code:
`import UIKit
import MagicTimer
class TimerVC: UIViewController {
@IBOutlet weak var timer: MagicTimerView!

@IBOutlet weak var startButton: UIButton!

@IBOutlet weak var pauseButton: UIButton!

@IBOutlet weak var stopButton: UIButton!

@IBAction func pressedStartButton(_ sender: Any) {
    startButton.isHidden = true
    pauseButton.isHidden = false
    stopButton.isHidden = false

    timer.mode = .countDown(fromSeconds: currentTaskDefaultTime)
    timer.isActiveInBackground = true
    timer.startCounting()

}

@IBAction func pressedPauseButton(_ sender: Any) {
    timer.stopCounting()
    startButton.isHidden = false
    completeTaskButton.isHidden = true
}

@IBAction func pressedStopButton(_ sender: Any) {
    timer.resetToDefault()
    startButton.isHidden = false
    pauseButton.isHidden = true
    stopButton.isHidden = true
}

override func viewDidLoad() {
    super.viewDidLoad()

    timer.font = UIFont(name: "Comfortaa-Semibold", size: 50)

    //hides by default the buttons
    pauseButton.isHidden = true
    stopButton.isHidden = true
}

}
`
Please help me
Sincerely yours
Nurlan

I have tried to use elapsedTime in the function pressedStartButton to change continue timer from (default time - elapsedTime) if elapsedTime>0, but I get this error:
'elapsedTime' is inaccessible due to 'internal' protection level

Hi;
Your sample code is the same as the MagicTimer example please review the example. If the issue exists in the example re-open another issue.

If you want to resume timer just call startCounting() method.

authors: dvlpd sadeghgoo

repo: sadeghgoo/MagicTimer