Moons of Peril Draft

WIP
Antechamber general:

Eclipse braziers:

They look a little less sad now.
Ancient shrine:

Blood Moon entrance:

Blue Moon entrance:

Eclipse Moon entrance:

Eclipse Moon arena:

Giants Den:

Cam Torum stuff:

Closes: #410

I've done a run of perilous moons to have a look, and almost everything seems pretty solid :+1:. I'm on the fence about attaching lights to all of the tiny fires making up those temporary flame walls, since that's a lot of lights. These mushroom lights are a bit too bright or too short radius too (and they need a better name ofc):

I took the liberty to update this PR, hope that's fine 🙂 What's left to do for this PR in your view?

Of course! This was right before I took my month long break so I kinda forgot what I had left to do, I think it was something something to do with tie overrides in the entrance hall with the big D20 since the floor looks like tiles and it currently is just dirt, I think it was pretty much ready for merging besides that and the couple issues you brought up

I've done a run of perilous moons to have a look, and almost everything seems pretty solid 👍. I'm on the fence about attaching lights to all of the tiny fires making up those temporary flame walls, since that's a lot of lights. These mushroom lights are a bit too bright or too short radius too (and they need a better name ofc):

Ah and regarding the lights on the fires, yeah it is a lot but it does make it look quite a bit better imo, is it possible to define world positions for lights and only have them show if a particular object is on screen?

This should be ready for review, maybe do another run through and double check the areas you pointed out before? As for the lights on the long lines of fires, if you deem them too excessive just snip them out before merging and we can revist it later.


Paginate notifications

/notifications and read_notifications can get long, especially for admins, so should be paged.
/developers has an infinite scroll example powered by pagy and Turbo which could be replicated for these two views.
Now that #133 is merged in this can be addressed with the new component!

Hey @joemasilotti! If you don't mind, I can pick this one!

Sure, go for it! I'll add it to the In progress column.


The sum aggregate function only works on int values

The sum aggregate function only operates on int values. Add  a sum function that works on real values, and also min and max functions for all data types.
I'm not sure whether SML's type system would allow sum, min and max to be polymorphic functions, or whether we would need a separate function for each type.

Fixed in ae39674933c99d9806246d3839d770dd3033e3fa.
We made sum work for both int and float values by making it a Macro. The macro looks at the type derived for the call and generates code accordingly.


Update localization for zh-CN (synchronized with crowdin too)

add new localization strings

uhhh....I want to update the README too. So wait a minute.

done.


Fix broken novendor feature

$ cargo test --features novendor

  = note: /usr/lib/gcc/x86_64-alpine-linux-musl/12.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: target/debug/deps/tests-81d77a8d8e24cc4f.v49whvrqu4l5awr.rcgu.o: in function `tests::tests::test':
          tests/tests.rs:19: undefined reference to `libbpf_set_print'
          collect2: error: ld returned 1 exit status

  = help: some `extern` functions couldn't be found; some native libraries may need to be installed or have their path specified
  = note: use the `-l` flag to specify native libraries to link
  = note: use the `cargo:rustc-link-lib` directive to specify the native libraries to link with Cargo (see https://doc.rust-lang.org/cargo/reference/build-scripts.html#cargorustc-link-libkindname)

Hmm. This feature was added in this commit by @danobi, and apparently broken by me in this commit when I removed bindings.c (since it was no longer necessary).
I have a few questions:

If this change broke novendor, then I'm confused about how we ever knew to link with libbpf in the first place. It looks to me like we were only using pkg_config to find the correct include path. Was the cc crate using this to infer that it should add -lbpf?
Before I broke novendor, were we linking statically or dynamically? Or, rather, I guess my real question is: should this be "cargo:rustc-link-lib=bpf" or "cargo:rustc-link-lib=static=bpf"? If we should be trying to statically link, then we probably also need to output "cargo:rustc-link-lib=static=z" and "cargo:rustc-link-lib=static=elf".

If this change broke novendor, then I'm confused about how Rust ever knew to link with libbpf in the first place.

When novendor is disabled (default), you build the vendored libbpf and tell rustc to link it statically here.
You haven’t noticed it because it’s not covered in the CI job and apparently no one has actually used this feature until now.

Before I broke novendor, were we linking statically or dynamically?

Statically.

Or, rather, I guess my real question is: should this be "cargo:rustc-link-lib=bpf" or "cargo:rustc-link-lib=static=bpf"?

The former when novendor is enabled (i.e. linking against system-provided libbpf), the latter when novendor is disabled (i.e. statically linking vendored libbpf).

If we should be trying to statically link, then we probably also need to output "cargo:rustc-link-lib=static=z" and "cargo:rustc-link-lib=static=elf".

This would require more changes than just adding static to these commands.

When novendor is disabled (default), you build the vendored libbpf and tell rustc to link it statically here.

Right, I get how it works without novendor, but I'm confused about how it ever could have worked with novendor enabled.

You haven’t noticed it because it’s not covered in the CI job and apparently no one has actually used this feature until now (or just didn’t report it).

Oh right, maybe that's the answer to my confusion: this feature never worked to begin with?

Before I broke novendor, were we linking statically or dynamically?

Statically.

Well,  guess if this feature was broken, then we weren't linking at all :)

Or, rather, I guess my real question is: should this be "cargo:rustc-link-lib=bpf" or "cargo:rustc-link-lib=static=bpf"?

The former when novendor is enabled (i.e. linking against system-provided libbpf), the latter when novendor is disabled (i.e. statically linking vendored libbpf).

If we should be trying to statically link, then we probably also need to output "cargo:rustc-link-lib=static=z" and "cargo:rustc-link-lib=static=elf".

This would require more changes than just adding static to these commands.

To clarify: do we care about supporting the case where the system-provided libbpf is static? If so, and if we aren't using pkgconfig, then I think we'd have to manually link in libz and libelf, for it to work, since libbpf transitively depends on them.
But, if we don't care about the case where there's a static system-provided libbpf, then this PR looks fine as-is.

To clarify: do we care about supporting the case where the system-provided libbpf is static?

Ah, I understand what you mean now, I overlooked library_prefix() before. Fixed now.

To clarify: do we care about supporting the case where the system-provided libbpf is static?

This would actually require more changes. And I would start by rewriting it to use pkg-config. However, to be honest, I’ve already spent too much time on this.

I think it worked at one point. pkgs.org reports a novendor version being shipped in fedora: https://pkgs.org/search/?q=libbpf-sys
I also seem to recall dynamic linking with libbpf working at some point (at least when I developed the patch).


Sync Fast Crash

Context

Version: v1.9.0-rc3
Network: Testnet
Node: Docker
Additional Arguments: --sync=fast

Issue
Using Testnet Docker with --sync=fast, the container will crash after 30k - 50k Frequency blocks.
Logs
These were the last logs, but may don't show any real errors
2023-11-22 12:14:08.266 DEBUG tokio-runtime-worker runtime::system: [Relaychain] [48116] length: 13751 (normal 0%, op: 0%, mandatory 0%) / normal weight: 0 (0%) / op weight 0 (0%) / mandatory weight<PHONE_NUMBER>00 (0%)
2023-11-22 12:14:08.271 DEBUG tokio-runtime-worker runtime::inclusion-inherent: [Relaychain] [enter_inner] parent_header=0x5e4bddefd4c9a4cdcbcfeb93d40bf42d0785d8466837fbef70f996cbf75a2014 bitfields.len(): 97, backed_candidates.len(): 4, disputes.len(): 0
2023-11-22 12:14:08.285 DEBUG tokio-runtime-worker runtime::system: [Relaychain] [48117] length: 10641 (normal 0%, op: 0%, mandatory 0%) / normal weight: 0 (0%) / op weight 0 (0%) / mandatory weight<PHONE_NUMBER>00 (0%)
2023-11-22 12:14:08.290 DEBUG tokio-runtime-worker runtime::inclusion-inherent: [Relaychain] [enter_inner] parent_header=0xc6626e0cff97ca09beaa1fb60e1dcab9dab156ecbd0eb014affd753aa72e19d9 bitfields.len(): 97, backed_candidates.len(): 6, disputes.len(): 0

Update: After more investigation, this was due to a low memory issue.
Added task to update recommended system specs in the docs.


MogoDB query with special fiter returns 406

I have collection with an object.
I do a query to find objects with a special key:
{
    "filter": {
        "accounts": {
            "$has": "aSearchValue"
        }
    },
    "token": "…"
}

With SQLite as DB the call works.
With mongoDB it returns a 406 error code with this body:
{"error":true,"message":"Oooops, something went wrong."}

Let me know if you need more info to reproduce

This is a different implementation between MonongoDB and MongoLite.
MongoDB doesn't have a $has operator. Instead you just do "accounts":"aSearchValue" this will do also a ✌does accounts contains "aSearchValue"✌check if the accounts field is an array.
Long story short, I adjusted the MongoLite Query builder: https://github.com/agentejo/cockpit/commit/cda8813968fe7ed26cfbcdb47185a25733681793
so the following query should work now with mongodb and sqlite as datasource:
{
    "filter": {
        "accounts": "aSearchValue"
    },
    "token": "…"
}

That solved the issue!
Thanks a lot @aheinze for the quick fix. Really helpful

other queries work like a charm. Didn't encounter any other problems


Make $trusted facts work with apache/unicorn or nginx/unicorn

via X-SSL-Client-Cert variable
See PUP-6366
Also see #PR4997 that is for/against Puppet 3.x branch.

CLA signed by all contributors.

It looks like some of the linting for this pull request failed; the Travis CI test at (https://travis-ci.org/puppetlabs/puppet/jobs/136823269) indicates that the commit message needs to be reformatted for consistency.

@buzzdeee We're still waiting on the commit message format to be fixed up before we can merge this. It would also be cool if you could figure out how to write tests for it (although not a deal-breaker if you don't, since we consider this code deprecated)

damnit, @branan ,thanks for the ping. I somehow missed that earlier comment, would have fixed that much earlier.

Closing this one in favor of #5169 which has the reformatted commit message


Find new versions by parsing json

@SuperQ one attempt at fixing: https://github.com/prometheus/golang-builder/issues/216
This should keep the current functionality as far as my testing goes. Now just getting the versions from the said json file.
What do you think?

Does this need any other work, or is it good to merge?

@SuperQ this could be merged if there is no need for more changes


Chore/integrate hound ci

What does this PR do?
Adds Hound CI to our project
How should this be manually tested?
Hound commented on this pull request, that means everything works fine. Check .hound.yml file to check if Hound is configured correctly
Screenshot

@Avuidrauxs I merged the main branch into this one, so now it should be ok


fix: powerbi-docs/developer/embed-service-principal.md

Update closed br tags

@nschonni : Thanks for your contribution! The author, @markingmyname, has been notified to review your proposed change.

@nschonni Not going to make the change on this as it works as expected.
Thank you.
Please close this PR.

A standalone closing </br> isn't valid HTML/Markdown, can you explain how it works as expected?

@mgblythe : Thanks for your contribution! The author, @markingmyname, has been notified to review your proposed change.

@mgblythe : Thanks for your contribution! The author, @markingmyname, has been notified to review your proposed change.


1_activation.yml

Steps to reproduce
1
Actual results
best
Logs

Logs

<!-- Paste your logs here -->

Flutter Doctor output

Doctor output

<!-- Paste your output here -->

Hello @msaalehi
When opening an issue, please try to provide all or some of the information indicated in the template so that we can address this issue properly.
More specifically, please provide the information indicated below:
A completed and minimal reproducible code sample
The output of flutter doctor -v
Reproduction steps
I am closing this issue since little or no information has been provided. Once you update the issue with more information, please write in the comments and I will re-open this for further discussion. Thanks!


Add ModifySpacing message handling to SmartPacing and SmartSpacingWit…

…hEdge
Description
I want to be able to dynamically change the spacing between window with smartSpacing so here is my pull request.

Please update CHANGES.md and then I'll do a review.  Thanks.

@pjones Sorry, I have just updated the CHANGES.md

🆙

@strokyl This PR is in the review queue.  Thanks!

Looks good to me, thanks!

Just for the record, this was already possible with multi-toggle.
As an example, see my config:
https://github.com/IvanMalison/dotfiles/blob/fabc451ceafc612ab13e1193367b1d5136b13c32/dotfiles/xmonad/xmonad.hs#L224


etcd test is flaky for test_blocking_rename_self

running 1 test
  2023-09-12T12:36:31.357430Z DEBUG opendal::services: service=etcd operation=blocking_write path=81ae3294-1e21-47f9-af79-0703033bc7d8 -> started
    at core/src/layers/logging.rs:726

  2023-09-12T12:36:31.357626Z DEBUG opendal::services: service=etcd operation=blocking_write path=81ae3294-1e21-47f9-af79-0703033bc7d8 -> start writing
    at core/src/layers/logging.rs:737

  2023-09-12T12:36:31.569737Z ERROR opendal::services: service=etcd operation=BlockingWriter::close path=81ae3294-1e21-47f9-af79-0703033bc7d8 written=1485803B -> data close failed: Unexpected (temporary) at Writer::close => grpc request error: status: Unauthenticated, message: "etcdserver: invalid auth token", details: [], metadata: MetadataMap { headers: {"access-control-allow-headers": "accept, content-type, authorization", "access-control-allow-methods": "POST, GET, OPTIONS, PUT, DELETE", "access-control-allow-origin": "*", "content-type": "application/grpc", "trailer": "Grpc-Status", "trailer": "Grpc-Message", "trailer": "Grpc-Status-Details-Bin"} }

Context:
   service: etcd
   path: 81ae3294-1e21-47f9-af79-0703033bc7d8

Source:
   grpc request error: status: Unauthenticated, message: "etcdserver: invalid auth token", details: [], metadata: MetadataMap { headers: {"access-control-allow-headers": "accept, content-type, authorization", "access-control-allow-methods": "POST, GET, OPTIONS, PUT, DELETE", "access-control-allow-origin": "*", "content-type": "application/grpc", "trailer": "Grpc-Status", "trailer": "Grpc-Message", "trailer": "Grpc-Status-Details-Bin"} }

Backtrace:
   0: opendal::types::error::Error::new
             at ./src/types/error.rs:338:24
   1: opendal::services::etcd::backend::<impl core::convert::From<etcd_client::error::Error> for opendal::types::error::Error>::from
             at ./src/services/etcd/backend.rs:320:9
   2: <core::result::Result<T,F> as core::ops::try_trait::FromResidual<core::result::Result<core::convert::Infallible,E>>>::from_residual
             at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/core/src/result.rs:1961:27
   3: <opendal::services::etcd::backend::Adapter as opendal::raw::adapters::kv::api::Adapter>::set::{{closure}}
             at ./src/services/etcd/backend.rs:292:17
   4: <core::pin::Pin<P> as core::future::future::Future>::poll
             at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/core/src/future/future.rs:125:9
   5: <opendal::raw::adapters::kv::backend::KvWriter<S> as opendal::raw::oio::write::api::Write>::poll_close::{{closure}}
             at ./src/raw/adapters/kv/backend.rs:451:64
   6: <core::pin::Pin<P> as core::future::future::Future>::poll
             at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/core/src/future/future.rs:125:9
   7: futures_util::future::future::FutureExt::poll_unpin
             at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/futures-util-0.3.28/src/future/future/mod.rs:562:9
   8: <opendal::raw::adapters::kv::backend::KvWriter<S> as opendal::raw::oio::write::api::Write>::poll_close
             at ./src/raw/adapters/kv/backend.rs:439:28
   9: <opendal::layers::error_context::ErrorContextWrapper<T> as opendal::raw::oio::write::api::Write>::poll_close
             at ./src/layers/error_context.rs:423:9
  10: <opendal::layers::complete::CompleteWriter<W> as opendal::raw::oio::write::api::Write>::poll_close
             at ./src/layers/complete.rs:765:16
  11: <opendal::layers::blocking::BlockingWrapper<I> as opendal::raw::oio::write::api::BlockingWrite>::close::{{closure}}
             at ./src/layers/blocking.rs:207:36
  12: <futures_util::future::poll_fn::PollFn<F> as core::future::future::Future>::poll
             at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/futures-util-0.3.28/src/future/poll_fn.rs:56:9
  13: tokio::runtime::park::CachedParkThread::block_on::{{closure}}
             at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.29.1/src/runtime/park.rs:283:63
  14: tokio::runtime::coop::with_budget
             at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.29.1/src/runtime/coop.rs:107:5
  15: tokio::runtime::coop::budget
             at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.29.1/src/runtime/coop.rs:73:5
  16: tokio::runtime::park::CachedParkThread::block_on
             at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.29.1/src/runtime/park.rs:283:31
  17: tokio::runtime::context::blocking::BlockingRegionGuard::block_on
             at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.29.1/src/runtime/context/blocking.rs:66:9
  18: tokio::runtime::handle::Handle::block_on::{{closure}}
             at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.29.1/src/runtime/handle.rs:308:13
  19: tokio::runtime::context::runtime::enter_runtime
             at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.29.1/src/runtime/context/runtime.rs:65:16
  20: tokio::runtime::handle::Handle::block_on
             at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.29.1/src/runtime/handle.rs:307:9
  21: <opendal::layers::blocking::BlockingWrapper<I> as opendal::raw::oio::write::api::BlockingWrite>::close
             at ./src/layers/blocking.rs:206:9
  22: <opendal::layers::logging::LoggingWriter<W> as opendal::raw::oio::write::api::BlockingWrite>::close
             at ./src/layers/logging.rs:1389:15
  23: <opendal::layers::retry::RetryWrapper<R,I> as opendal::raw::oio::write::api::BlockingWrite>::close::{{closure}}
             at ./src/layers/retry.rs:1034:14
  24: backon::blocking_retry::BlockingRetry<B,T,E,F,RF,NF>::call
             at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/backon-0.4.1/src/blocking_retry.rs:175:26
  25: <opendal::layers::retry::RetryWrapper<R,I> as opendal::raw::oio::write::api::BlockingWrite>::close
             at ./src/layers/retry.rs:1034:9
  26: opendal::types::operator::blocking_operator::BlockingOperator::write_with::{{closure}}
             at ./src/types/operator/blocking_operator.rs:569:17
  27: core::ops::function::FnOnce::call_once
             at /rustc/5[680](https://github.com/apache/incubator-opendal/actions/runs/6159457461/job/16714336842#step:6:681)fa18feaa87f3ff04063800aec256c3d4b4be/library/core/src/ops/function.rs:250:5
  28: opendal::types::operator::operator_functions::OperatorFunction<T,R>::call
             at ./src/types/operator/operator_functions.rs:65:9
  29: opendal::types::operator::operator_functions::FunctionWrite::call
             at ./src/types/operator/operator_functions.rs:142:9
  30: opendal::types::operator::blocking_operator::BlockingOperator::write
             at ./src/types/operator/blocking_operator.rs:405:9
  31: behavior::blocking_rename::test_blocking_rename_self
             at ./tests/behavior/blocking_rename.rs:115:5
  32: core::ops::function::FnOnce::call_once
             at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/core/src/ops/function.rs:250:5
  33: behavior::utils::build_blocking_trial::{{closure}}
             at ./tests/behavior/utils.rs:170:9
  34: libtest_mimic::Trial::test::{{closure}}
             at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/libtest-mimic-0.6.1/src/lib.rs:112:54
  35: core::ops::function::FnOnce::call_once{{vtable.shim}}
             at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/core/src/ops/function.rs:250:5
  36: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
             at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/alloc/src/boxed.rs:1993:9
  37: libtest_mimic::run_single::{{closure}}
             at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/libtest-mimic-0.6.1/src/lib.rs:505:43
  38: <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
             at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/core/src/panic/unwind_safe.rs:271:9
  39: std::panicking::try::do_call
             at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/std/src/panicking.rs:500:40
  40: __rust_try
  41: std::panicking::try
             at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/std/src/panicking.rs:464:19
  42: std::panic::catch_unwind
             at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/std/src/panic.rs:142:14
  43: libtest_mimic::run_single
             at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/libtest-mimic-0.6.1/src/lib.rs:505:5
  44: libtest_mimic::run::{{closure}}
             at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/libtest-mimic-0.6.1/src/lib.rs:476:35
  45: <F as threadpool::FnBox>::call_box
             at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/threadpool-1.8.1/src/lib.rs:95:9
  46: threadpool::spawn_in_pool::{{closure}}
             at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/threadpool-1.8.1/src/lib.rs:769:17
  47: std::sys_common::backtrace::__rust_begin_short_backtrace
             at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/std/src/sys_common/backtrace.rs:135:18
  48: std::thread::Builder::spawn_unchecked_::{{closure}}::{{closure}}
             at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/std/src/thread/mod.rs:529:17
  49: <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
             at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/core/src/panic/unwind_safe.rs:271:9
  50: std::panicking::try::do_call
             at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/std/src/panicking.rs:500:40
  51: __rust_try
  52: std::panicking::try
             at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/std/src/panicking.rs:464:19
  53: std::panic::catch_unwind
             at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/std/src/panic.rs:142:14
  54: std::thread::Builder::spawn_unchecked_::{{closure}}
             at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/std/src/thread/mod.rs:528:30
  55: core::ops::function::FnOnce::call_once{{vtable.shim}}
             at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/core/src/ops/function.rs:250:5
  56: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
             at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/alloc/src/boxed.rs:1993:9
  57: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
             at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/alloc/src/boxed.rs:1993:9
  58: std::sys::unix::thread::Thread::new::thread_start
             at /rustc/5680fa18feaa87f3ff04063800aec256c3d4b4be/library/std/src/sys/unix/thread.rs:108:17
  59: <unknown>
  60: <unknown>

    at core/src/layers/logging.rs:1403

  2023-09-12T12:36:31.5[698](https://github.com/apache/incubator-opendal/actions/runs/6159457461/job/16714336842#step:6:699)85Z  WARN opendal::service: operation=BlockingWriter::close path=81ae3294-1e21-47f9-af79-0[703](https://github.com/apache/incubator-opendal/actions/runs/6159457461/job/16714336842#step:6:704)033bc7d8 -> retry after 1s: error=Unexpected (temporary) at Writer::close, context: { service: etcd, path: 81ae3294-1e21-47f9-af79-0703033bc7d8 } => grpc request error: status: Unauthenticated, message: "etcdserver: invalid auth token", details: [], metadata: MetadataMap { headers: {"access-control-allow-headers": "accept, content-type, authorization", "access-control-allow-methods": "POST, GET, OPTIONS, PUT, DELETE", "access-control-allow-origin": "*", "content-type": "application/grpc", "trailer": "Grpc-Status", "trailer": "Grpc-Message", "trailer": "Grpc-Status-Details-Bin"} }, source: grpc request error: status: Unauthenticated, message: "etcdserver: invalid auth token", details: [], metadata: MetadataMap { headers: {"access-control-allow-headers": "accept, content-type, authorization", "access-control-allow-methods": "POST, GET, OPTIONS, PUT, DELETE", "access-control-allow-origin": "*", "content-type": "application/grpc", "trailer": "Grpc-Status", "trailer": "Grpc-Message", "trailer": "Grpc-Status-Details-Bin"} }
    at core/src/layers/retry.rs:259

  2023-09-12T12:36:32.573783Z  WARN opendal::layers::complete: writer has not been closed or aborted, must be a bug
    at core/src/layers/complete.rs:[705](https://github.com/apache/incubator-opendal/actions/runs/6159457461/job/16714336842#step:6:706)

test services_etcd::test_blocking_rename_self ... FAILED

cc @G-XD, would you like to take a look? Thanks in advance.

Seems etcd-client doesn't do token refresh for us.

Well, the root cause is our kv API not implement correctly. But adding a connection pool is also a good idea :rofl:

which kv APi not implemented correctly?

The future state machine inside kv adapter:
https://github.com/apache/incubator-opendal/pull/3041/files#diff-e33ce9dc785c78f1663af0614d80c879d02da13f139918a5f95063df5836e0f4L439


IPv6 support

The cooklang.org domain lacks GitHub Pages' IPv6 addresses:
2606:50c0:8000::153
2606:50c0:8001::153
2606:50c0:8002::153
2606:50c0:8003::153

Thanks, I added these records.


Update README.md

Added Levi's
Adds the following events or companies:

Checklist

[] I have updated the event or company counts
[] I have put the most recent relevant date in the "Last Update" column
[] I have linked to the article about the change, not the company's website

Hey your PR seems to remove some other listings... could you rebase from master and resolve conflicts?

You can discard this. I will let someone else from the company handle this. Thanks for the website.


Bug: Support newer uuid version

Describe the bug
the current tagged version does not support newer uuid version. The commit that changed this is from January 30 but the last release was October 12 last year. Please create a new release tag to get this change into the latest version.
To Reproduce
Steps to reproduce the behavior:
add uuid >=4.1.0
then try to add matomo_tracker
Expected behavior
works

cc: @TesteurManiak

Quick workaround for now (since the fix is in main but not in any tag):
pubspec.yaml
matomo_tracker:
  git:
    url: git@github.com:Floating-Dartists/matomo-tracker.git
    ref: main

Closing this as solved by #136

this doesn't solve the issue since the fix is not released yet

It does, the fact that it is not on pub.dev doesn't mean that the issue is not fixed. The PR has been merged and I've already explained in this comment why we haven't already published a new release. Keeping this issue open is not needed.

I see. Makes sense. The part you mentioned in the comment was the missing piece here. :+1:


Possibility to use cloudfront

Does the plugin support invaliding a Cloudfront distribution by providing a cloud front id and possibly a matcher?

Hi @bjensen,
We don't natively support invalidating a Cloudflare distribution in this package but it's possible you could achieve that by using the onFinished callback which is invoked after the plugin has finished uploading the built assets.


adding scan number for merged spectra

adding for library export

[x] all usi of merged
[x] single spec type
[x] collision energies for merged spectra
[x] scan number for merged

New formats include:
mgf
# list of USI
USI=[mzspec:mzspec:PLACEHOLDER::20230404_pluskal_nih_05P_A7_id_positive:264, mzspec:mzspec:PLACEHOLDER::20230404_pluskal_nih_05P_A7_id_positive:265, mzspec:mzspec:PLACEHOLDER::20230404_pluskal_nih_05P_A7_id_positive:266]

# list of merged scan numbers follows mgf format
SCANS=151-193,530-579

# refers to the energies of all merged scans from last MSn level
COLLISION_ENERGY=[20.0, 40.0, 60.0]

# refers to the energies of all merged scans. Here 3 MS4 scans with [MS2, MS3, MS4] energies
MSn_collision_energies=[[15.0, 40.0, 20.0], [15.0, 40.0, 40.0], [15.0, 40.0, 60.0]]

json
# scan numbers
"scan_number":[416,417,418,419,420,421,422,423,424]

# collision energy either single value or list: all on the same MS level
"collision_energy":[20.0,15.0,60.0]

# MSn energies for MS2, MS3, MS4 ...
"msn_collision_energies":[15.0,40.0,60.0]

# USI
usi":["mzspec:mzspec:PLACEHOLDER::20230404_pluskal_nih_02P_A12_id_positive:450"]

not finished yet

What is the scan number for? I think currently it is set to -1 so it is clear that the spectrum is not a real/raw spectrum contained in the data file. If we set the scan number to something this assumption is not clear anymore, especially for external tools.

The idea is to have the source spectra. So if we merge two spectra, we know which spectra were used.

SCANS can point to multiple scans to highlight the source
https://www.matrixscience.com/help/data_file_help.html#:~:text=SCANS Anything from a single scan number to a complex list of ranges%2C e.g. SCANS%3D1278%2C1280-1284%2C1290-1294%2C1298. When there are multiple raw files%2C there can be multiple SCANS entries in a single query%2C each with a zero-based index that relates to a specific raw file%2C e.g. SCANS[3].

Ok, but is your plan to alter the Scan.getScanNumber() method to return a list/array? I don't know if that's good.
How about setting a list of USIs to the merged spectra?

Oh no its only about the export to libraries. Like setting the scan numbers to the mgf, json, etc.
Also setting USIs as well.
So Scan is untouched

I added a few things but all seems good from my side.
Maybe @SteffenHeu can check again.

Some example files. Had to change mgf format to .txt because thats what GH accepts
nih_lib.json
nih_lib.mgf.txt


[bug] Network switcher is hidden until a wallet is connected

Is there an existing issue for this?

[X] I have searched the existing issues

RainbowKit Version
1.02
wagmi Version
1.2.0
Current Behavior
The network switcher is currently hidden when no wallet is connected.
Expected Behavior
However, this doesn't align with the standard way of doing things. And one of the most important UX rules is to mimic the behaviors of the majority of UIs (Jakob's law).
Most multi-chains DApp allow their users to switch between networks even before a wallet is connected.
This allows users to easily browse data on each chain (e.g., yields).
Maybe showing/hiding the network switcher when a wallet is connected should be configurable through a showSwitcher: "always" | "connected" prop of the <ConnectButton/> component.
Steps To Reproduce
No response
Link to Minimal Reproducible Example (CodeSandbox, StackBlitz, etc.)
https://www.rainbowkit.com/
Anything else?
No response

I don't think RainbowKit or any other wallet connection library should be responsible for anything that happens when no wallets are connected.
You can build a simple dropdown for the networks on your own and show the page content based on the selected value. You won't need RainbowKit for that. You could also use just simple icons as in https://magiceden.io.

Will think about this! There have some improvements in WalletConnect v2 that makes this more feasible.

@adbario : I don't think RainbowKit or any other wallet connection library should be responsible for anything that happens when no wallets are connected.

I got your point, it makes sense thanks.
But by allowing users to switch between networks defined in the Wagmi config it seems that RainbowKit already goes beyond the wallet's scope. If RainbowKit wanted to fit in the wallet's scope it should only provide a way to access RPCs provided by wallets or shouldn't allow network management at all.
IMO RainbowKit is actually more a network + wallet manager.
Your network switcher is relevant with nowadays design trends, a bit customizable and so should fit for most project. However, as most multi-chain project will require being able to manage network before wallet connection, they will not being able to use yours.
A dropdown is not "simple" to code properly as it requires respecting a ton of accessibility measures, managing a list of chains icons, handling network change on click, etc. Not having to think about this and to code things from scratch is usually why developers are using libraries like RainbowKit.

@adbario : You can build a simple dropdown for the networks on your own and show the page content based on the selected value. You won't need RainbowKit for that. You could also use just simple icons as in https://magiceden.io/.

Sure using icons-based switching will fit for some projects to provide icons-based switching (like MagicEden or Beefy) but it wouldn't for many others. A good approach could be to let choice to developers by providing a component's prop as mentionned in my previous message.

@DanielSinclair : Will think about this! There have some improvements in WalletConnect v2 that makes this more feasible.

Great ! What makes it actually hard to realize ?

@LilaRest Just to catch back on this we're building this feature alongside wagmi v2. Can you take a look at the video in this PR and tell me if that would solve your problem ?
Let me know if you have any more questions 👍

We're starting to see this paradigm sunset with Uniswap's recent change, where network switching is decoupled from the connect step and is requested at the time of interaction. I'll close this out so that we can focus on adopting the recent EIPs for the multi-chain window provider to mitigate this need all together. https://x.com/Uniswap/status/1833871322352353569


Carrier/Interceptor quirks

When the carrier is moving, interceptors will remain outside and follow it around.
Interceptors below 10 shields will return inside the carrier to regenerate (not really, they're just hidden and invulnerable, otherwise the carrier will try to relaunch them). (as described on liquipedia)

I'm not sure of the best way to implement the "launched only if they have at least 20 health" part, I remember having issues where they would never heal above 20 health. Solvable with nested validators?
Behaviors are added through the Hangar ability to ensure that validators can reference the carrier as the caster.
I couldn't figure out the purpose of InterceptorSCBW@AB which tried to apply an unknown CarrierInterceptorBombs behavior so I removed it for clarity. The same goes for the unknown InterceptorFate.
Sorry if I messed up the data structure, but  I hope it should be simple enough to copy-paste/rename.

I think the AB effect was a leftoever from when i derived the effect from campaign mod. i intedned to clean them up eventually once i reviewed their purpose, but i forgot :P.

This has been implemented


feat: change styles of faq-card, add styles to training elements

What type of PR is this?

Uncomment one (or more) /kind <> lines:

/kind bug

/kind cleanup

/kind design

/kind user-interface
/kind content

/kind translation

Any specific area of the project related to this PR?

Uncomment one (or more) /area <> lines:

/area blog

/area documentation

/area videos

What this PR does / why we need it:
Adds styles to faq_card, remove redundant html with classes. Updates styles on tarining page. Adds links to contributors page.
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: bullet03
Once this PR has been reviewed and has the lgtm label, please assign leogr for approval. For more information see the Kubernetes Code Review Process.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: bullet03, Issif
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [Issif]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

LGTM label has been added.  Git tree hash: a0f696c3a5fec337789cba34450cf4dc08e1602f


pxToRem sometimes returning incorrect size

pxToRem is sometimes outputting incorrect values. It appears to sometimes use the wrong remSize in its calculations.
Observed:

Expected:

The results are consistent with using 16px as the HTML font-size, but in most cases the correct value of 14px is used.

acknowledging the problem - root cause is the fact that siteVariables are calculated before theme has provided any static styles, and, thus, before theme's html font size was applied - thus, for pxToRem calculations default 16px is used.
Currently see two options for us to address this issue:

remove static styles support from Stardust themes. In that case we might expect no changes to html font size being brought by loaded theme, so the problem will disappear. As an additional benefit, we will eliminate any possibility for global styles being leaked from loaded theme  and affecting the entire app's page
use lazy evaluation mechanism for some of the variables, something like the following one, in case of font sizes - and remove pxToRem from direct exports in Stardust:

export const fontSizes = ({ pxToRem }) => ({
  smaller: pxToRem(10),
  ..
  larger: pxToRem(24)
})

Both options imply deign changes, but I would rather vote for the first one, as it would result in generally simpler approach, with site variables remaining to be just plain objects. Please, folks, let me know about your thoughts on that.
Cc: @mnajdova, @miroslavstastny, @layershifter, @alinais, @Bugaa92, @levithomason

remove static styles support from Stardust themes.

Personally I vote for this, this will allow to get rid of this #960. But we will still need staticStyles like normalize.css.
Can we introduce a separate provider for them? StaticProvider? It will be not super-friendly, but will clarify the responsibilities.

We can't remove the static styles without consequence.  It would mean HTML font size wouldn't be set, normalize.css wouldn't be applied, and global styles such as font-family, box-sizing, body color, etc could not be set.
There is a third option, which I believe is the correct one, the pxToRem utility should get its html font-size value from the theme, where it is defined, not from querying the browser.


How to debug a wasm error?

Description:
I wrote a wasm filter in assemblyscript v 0.19.23 and using https://github.com/solo-io/proxy-runtime v 0.1.15 and it loads correctly but the http call is returning a result code 2 and proxy_on_http_call_response is never called.
These are the logs
[2022-11-17 19:42:08.870][1][trace][wasm] [source/extensions/common/wasm/wasm_vm.cc:39] [vm->host] env.proxy_http_call(33088, 12, 28816, 52, 33152, 0, 31904, 4, 1000, 32000)
[2022-11-17 19:42:08.872][1][trace][wasm] [source/extensions/common/wasm/wasm_vm.cc:39] [vm<-host] env.proxy_http_call return: 2

The proxy-runtime source code documents that result code as a BadArgument but I don't have a clue on which of the arguments could be wrong. This is how the http call looks like
let h: Headers = [];
    h.push(makeHeaderPair(":path", "/static/token"));
    h.push(makeHeaderPair(":method", "GET"));
    let cluster = this.getConfiguration();
    log(LogLevelValues.info, "singleton updateConfig! "+cluster);

    let result = this.httpCall(cluster,
      // provide the auth cluster our headers, so it can make an auth decision.
      h,
      // no need for body or trailers
      new ArrayBuffer(0), [],
      // 1 second timeout
      1000,
      // pass us, so that the callback receives us back.
      // once AssemblyScript supports closures, this will not be needed.
      this,
      // http callback: called when there's a response. if the request failed, headers will be 0
      (origin_context: BaseContext, headers: u32, body_size: usize, trailers: u32) => {
        log(LogLevelValues.info, "callback called!");
        let bytes = get_buffer_bytes(BufferTypeValues.HttpCallResponseBody, 0, body_size);
        log(LogLevelValues.info, "token" + String.UTF8.decode(bytes));
        set_shared_data("data", bytes);
      });

And it is almost identical to the example from the library.
I'm using envoy 1.20.

I removed the authority header because I didn't think it was needed and I thought I've tested putting it back and making no difference, but I've tested again putting the header back and now it is working.
Anyway the question still applies about how should I have debugged this "result 2" if I didn't have the example as a basis, for example where I could find that the authority header is required?

Another thing that I couldn't find documented is the semantic of the returned value proxy_action_t in many of the functions like proxy_on_http_request_headers.
The assemblyscript sdk has meaningful names for the different numeric values but it isn't clear the difference between the variants, e.g. StopIteration vs StopAllIterationAndBuffer vs StopAllIterationAndWatermark

for example where I could find that the authority header is required?

This is more like a conventional rule. :path, :authority, and :method are required headers for normal http call.

And If want debug result 2 (BadArgument), some backgrond knowledge of Envoy is necessary.
You can find WasmResult::BadArgument easily from envoy source code. Sometimes a quick grep can solve lots of problems.
For example:
  // Check that we were provided certain headers.
  if (message->headers().Path() == nullptr || message->headers().Method() == nullptr ||
      message->headers().Host() == nullptr) {
    return WasmResult::BadArgument;
  }

cc @PiotrSikora


instrumentation for mistralai 1.0

https://github.com/mistralai/client-python/blob/main/MIGRATION.md

I believe this is done


fix: Ensure all patch calls can conflict when resource version doesn't match

Fixes #1578
Description
This change ensures that calls to Patch that would fully replace portions of the spec like lists continue to conflict if the resource has changed since the controller first retrieved the resource.
This fixes the issue in #1578 where resource quantities are converted to different strings during deserialization and then re-serialization back by ensuring that the request that we send to the apiserver only represents the parts of the resource that we intend to change.
This allows us to keep the NodeClaim immutability checks that we have.
How was this change tested?
make presubmit
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>0
Details

51 of 70 (72.86%)  changed or added relevant lines in 15 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage increased (+0.07%) to 80.64%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

pkg/controllers/nodeclaim/termination/controller.go
4
5
80.0%

pkg/controllers/nodeclaim/lifecycle/controller.go
4
7
57.14%

pkg/controllers/node/termination/controller.go
7
12
58.33%

pkg/controllers/disruption/controller.go
1
11
9.09%

Files with Coverage Reduction
New Missed Lines
%

pkg/controllers/nodeclaim/termination/controller.go
1
68.75%

Totals

Change from base Build<PHONE_NUMBER>0:
0.07%

Covered Lines:
8414

Relevant Lines:
10434

💛  - Coveralls


Code review

Repository downloaded: 3/5/2018, 12:19 (UTC+3)
Your program is really advanced compared to what I have done in school until now; probably my comments won't prove extremely useful to you. One test failed, though, and in the end I wrote a suggestion to fix that.
Style
I really like your code's style. It's easy to read, very well documented and commented; even if this level is too advanced for me to understand everything, it was easy to get a grip of each class's function.
Your use of empty lines helps to understand the code's structure. For example in the MainNavigation class's constructor you used empty lines to separate groups of three equal operations, performed on three different buttons.
I also like that you don’t care about going over that vertical layout line, and you sometimes write very long lines (for example in ToolsView). After all the computer screen is quite large, so it makes sense to use it all (as long as a line fits into it and you can read everything without scrolling). I noticed that it's easier to make sense of the code structure if you don't break lines.
I like that you wrote some (final) variable names in all caps instead of using camel case; it highlights that those variables are final, and they actually have a function similar to enums.
Interfaces and inheritance
You used interfaces and inheritance very well. I like that Frontend is an interface, so you can easily implement another Frontend if you want, without changing the rest of the code (thanks to the State class).
Great examples of inheritance are the class Table, and all the classes that extend it.
Single responsibility principle
Your program has a lot of classes. It isn't only because it is quite complex, but also because you employed very well the single responsibility principle, making very specialized classes. In particular it was interesting to see how you implemented the DAO design pattern in a different way than what we saw in the tikape course. You made a class for each SQL table, and even a static class inside those classes, for the column names. And then you used methods to construct SQL statements/queries, instead of writing them manually (for example method TableSQLParser in class FileTable). I didn’t understand why you would need all that at first. But then I realized that it might be very useful; in case you want to change a column name, you'd only have to change that in one place. For the same reason there also many enums, like in Views and Settings.
Private constructors
I noticed that you wrote a private constructor for some classes (for example FileProcesses). These classes only contain information, like methods (for example FileProcesses) or final variables (for example style Strings in class Style); no instance of these classes is needed in the program. I don't know if hiding the constructor serves a practical purpose (security?), but at least it looks cool.
Your own exceptions
Many things were interesting and new for a beginner like me. For example, I was amused that you can create your own customized exceptions, like your BackendException. I also like that you explain in Javadoc why exceptions could occur in a given method.
Other cool stuff
I like that you often use functional style, like in ExceptionHandler, MainProcesses, FatalErrorScene and State. I've just finished a Haskell course, therefore I look forward to understanding how to integrate that magical stuff into non-functional languages like Java.
I also like that you utilized concurrency, creating a pool of 10 threads in Main. This way you can maintain the UI responsive even if some processes are doing heavy work in the background.
 It's Interesting that you made some methods specifically for testing (like some setters in Main). I had wondered myself, when writing tests for my app: does it make sense to write extra stuff into the source code only for testing? Like making new methods, or changing a variable from final to not final. Apparently it does make sense, especially if they are only small methods like getters and setters.
You also mocked dependencies very well. Like the rest of your code, this is well organized, since you put all the fake classes into a separate package, utils.fakeClasses.
MD5CheckSumTest failed!
This test was the only one that failed. I was almost happy because I had no idea how to suggest any improvement for your code otherwise.
You present two different hash values, one for Windows, and the other one for other operating systems. But I'm on Windows, and still I got the other value, so the test failed.
The hash value should be only one. According to this and other sources, the different hashes for text files might result from how different operating systems implement line changes (with different unicode characters). But in MD5CheckSum you use FileInputStream, which reads a file as a byte stream, so probably the outcome depends only on which system you created (or modified) the text file on.
So I think you should only include one hash in this test, and that wouldn't fail on any OS.

Thank you for the very throughout review, I appreciate the effort you've put into writing this.
Interfaces
I love interfaces! I just recently discovered what all you can do with them in Java.
Mainly the most interesting thing I find are Functional interfaces, because they can be used to abstract so many things into lambdas (() -> doStuff(); & state -> doStuffTo(state)) and method references (object::referencedMethod).
For example I realized that it is possible to give methods as parameters - Just like in JavaScript and python, albeit a bit more secure in terms of type. (This is done in this project via MethodReference-interfaces)
It's a whole new way of reducing copy-paste code with a slight reduction of performance, for example in FileProcesses passing a method to performSingleFolderOperation and performAnOperationOnFiles.
Previously the files for loop was present in all four methods
Another really useful way of using interfaces is to just write a new method in an interface, continue work on other code using the new method and worry about implementation of the new method later.
It reduces context switching a lot, so coding larger complexes requires less effort.
Single Responsibility Principle
Nice to know that the principle is applied in some of the codebase.
I read this quote once that has really helped write more maintainable code.

Don't write code that is easy to build onto, write code that is easy to delete.

I don't remember where I read it from but I think it was in Clean Code-book and that one really stuck with me.
It is easy to add and add, but then when you want to refactor something - "oh, removing this one bit causes changes in 45 different files and I can't keep them all in my head."
That happened to me once (not with this project) and it took a week to get the program to function again after the refactoring - I don't want it to happen again.
Private constructors
This is a bit odd, but I'm only doing it because SonarCloud bugs out every time there is a class with all static methods.
I find that it is an anti-pattern to write a lot of classes with a lot of static only methods. Since Java is Object-oriented it would make more sense to write objects that handle specific actions instead.
For example in an older project of mine I have a class called PlaylistFileManager, and it only has static methods. With a name like that you'd think it would be given a file in the constructor and then it would have methods to manipulate that single file, but now an outside object calls the methods with a specific file. It is not optimal.
TableSQLParser
This class is actually copied from another project of mine that supports both SQLite and MySQL.
The original purpose of the class was thus make it easier to read the create table statements since MySQL and SQLite have different syntax for defining primary keys. Now it just reduces the amount of raw SQL I need to write :3
Custom exceptions
Exception handling is still something am still I struggling with, but learning.
It's difficult to get proper error messages to the user - but alas! Custom exceptions come to the rescue, now a single catch clause can set a custom message for the user to see!
I've used non-runtime exceptions in the past (If you throw such exception you'll have to write throws to every method or catch it down the line - One example of these is IOException), but I find that this way the exceptions will be caught everywhere around the codebase, leaving try catch blocks all over the place & making it quite impossible to get all of them "fixed" in the eyes of a user.
runtime exceptions (For example IllegalStateException) seem like a really nice way of "stopping execution as soon as possible when error occurs" and it cleans up the code because there isn't a need for a bunch of try catch blocks every time you call a method. Hard part is actually remembering what methods might throw the runtime exceptions (It's why I write them in the Javadoc!).
Custom exceptions are also useful when using libraries that you might want to change later - Just wrap the library's exception to your own exception and then it can be changed later (Easy to delete). I've used this for the SQLDatabase, wrapping all SQLExceptions to a BackendException
Setters for tests
I think this is another anti-pattern, but I find it easier to do it this way than by setting the variable accessible and changing the value via reflection. It probably matters more in larger projects and ones where the methods are supposed to be used as an API (Like libraries).
It probably makes more sense having the variable be package-private and placing the tests in the same package - so that the variable can be set there. Thanks for bringing this up, I'll have to look into it.
MD5 test
This one is actually pretty tricky!
It indeed is caused by line breaks being different on different OS:es, and that causes the checksum to be different.
I'm guessing I should use a non-text file for the test instead. Thanks!
Summary
Thank you so much for your review. I found it very useful. (Sorry for rambling, but I like doing that sometimes)
I really recommend reading Clean Code book, it's free and you can read few pages every now and then. It drastically improved how I code. A lot of the stuff I mentioned here was learned from the book :)

Thanks a lot for all these tips! There's a lot to learn :D I'll check out the book.
Have a great summer!

Thanks!
Have a nice summer as well :)


[dall-e parser][3/n] Add basic tests for load and serialize

[dall-e parser][3/n] Add basic tests for load and serialize
Pretty simple, just adding in the tests which I already did manually to test the previous commits
Specifically I added tests for load() and serialize(). Found an error on serialize through this test (had to define function as async!
Should now be able to run tests by entering:
cd ~/Projects/aiconfig/python && pytest --disable-warnings -vv

Stack created with Sapling. Best reviewed with ReviewStack.

#301
#298
#297
-> #294

had to define function as async

The main model parser methods have to be async, the abstract class also defined this as async. Should this be documented somewhere?

lgtm, maybe a test for run(), mocking the api call, would be nice to have

I tried to do this in https://github.com/lastmile-ai/aiconfig/pull/301 but got blocked for API key issue. Left more details there


koord-scheduler: Pod updates should not update the timestamp

Ⅰ. Describe what this PR does
Pod updates should not update the timestamp in loadaware cache. This would cause pods that have been in the cache for a while to estimate resource during scheduling instead of using the actual resource reported on nodemetric. This discrepancy arises from the timestamp change without timely updating of nodemetric.
Ⅱ. Does this pull request fix one issue?
Ⅲ. Describe how to verify it
Ⅳ. Special notes for reviews
V. Checklist

[ ] I have written necessary docs and comments
[ ] I have added necessary unit tests and integration tests
[ ] All checks passed in make test

/approve


Add dynverse comparison + fix nation for Yvan Saeys

PS: great that you have a DOI https://github.com/dynverse/dynmethods#sources

Thanks, @zouter, for becoming a contributor. It is always good to get new comparative studies and methods.


[BUG]: Lesson 28 can't run cargo build

Issue/Experience
In Lesson 28:
cargo build-sbf --sbf-out-dir=../../dist/program
Geting:
error: not a directory: '/root/.local/share/solana/install/releases/1.14.2/solana-release/bin/sdk/bpf/dependencies/sbf-tools/rust/bin'
Output of running node tooling/camper-info.js from the workspace root
INFO:   Project:  learn-how-to-set-up-solana-by-building-a-hello-world-smart-contract
INFO:   Lesson Number:  1
INFO:   Curriculum Version:  0.1.1
INFO:   freeCodeCamp - Courses<EMAIL_ADDRESS>INFO:   Commit:  3484c47 fix(deps): update dependency @solana/web3.js to v1.66.2
INFO:   OS Info:
Architecture: x64
Platform: linux
Release: 5.4.72-microsoft-standard-WSL2
Type: Linux
What I've tried to resolve the issue:

upgrading to Solana 1.14.3
cleared ~/.cache/solana/
ran cargo-build-sbf vs cargo build-sbf

Hello there,
Please follow the issue guide by sharing the output of running node tooling/camper-info.js from the workspace root.

Updated the original issue.

Thank you 🙂
Your OS and architecture is the same as mine. So, I am not sure why you are encountering an issue. I am unable to reproduce any issue.
Share the output of:
ls -la ~/.rustup/toolchains/

Try running:
# ONLY IF YOU HAVE `1.14.2`
rustup toolchain link bpf ~/.local/share/solana/install/releases/1.14.2/solana-release/bin/sdk/bpf/dependencies/bpf-tools/rust
# I suspect this will also produce an error about bpf-tools/rust

ls -la ~/.rustup/toolchains/
drwxr-xr-x 3 root root 4096 Oct 24 11:18 .
drwxr-xr-x 6 root root 4096 Oct 24 11:18 ..
drwxr-xr-x 7 root root 4096 Oct 24 11:18 stable-x86_64-unknown-linux-gnu
rustup toolchain link bpf ~/.local/share/solana/install/releases/1.14.2/solana-release/bin/sdk/bpf/dependencies/bpf-tools/rust
error: not a directory: '/root/.local/share/solana/install/releases/1.14.2/solana-release/bin/sdk/bpf/dependencies/bpf-tools/rust/lib'

Thank you for trying that with me. Unfortunately, I am out of ideas, and can only suggest deleting the container, and rebuilding it from scratch.


Cannot run a project containing endpoints without parameter names in class files

When the project containing the endpoints is compiled without the parameters flag, ClassGraph always returns null as parameter name, whereas Java reflection generates argN placeholder names.
While it is recommended to add the compiler flag for readability, its absence should not break the application: we should generate the missing parameter names.

Even better would be to extract parameter names from JavaDocs in case it's not in the class files, but that's a separate step in addition to just making sure it still somehow works even without.


Governing Board Election 2024

The MapLibre Governing Board Election 2024 will take place at the end of August. This issue informs you about the deadlines and the process around the Election.
Dates and Timeline
Here are the most important dates for the election process:

Thursday, Aug 29th, 2024

Governing Board election poll ends

Thursday, Aug 22nd, 2024

Approval new Voting Members ends

Thursday, Aug 15th, 2024

Governing Board Candidate Registration ends
Voting Member Nomination ends

gantt
    title Governing Board Election Timeline
    dateFormat YYYY-MM-DD
    section Preparation
        Governing Board Candidate Registration                    :a1, 2024-07-15, 2024-08-15
        Voting Member Nomination                                          :a2, 2024-07-15, 2024-08-15
     section Approval
        Approval New Voting Members      :a3, 2024-07-15, 2024-08-22
     section Election
        Election Poll                                        :a4, 2024-08-22, 2024-08-29

Governing Board Candidate Registration
People who are interested to serve on the Governing Board have to register themselves for the election. This is done by simply posting your motivation to be a Governing Board member in this GitHub Discussion.
The Governing Board meets four times per year and discusses the long-term strategy of MapLibre, is involved in hiring decisions, and approves the budget. The Board meets also with larger donors of the MapLibre Sponsorship Program in the MapLibre Advisory Council four times per year.
Everybody can serve on the Governing Board - there are no requirements regarding Voting Membership or similar in the MapLibre Charter. However, at most one person can serve on the Governing Board per employer.
Voting Member Nomination
Voting Members are the people who can elect the MapLibre Governing Board and vote on changes to the MapLibre Charter, see VOTING_MEMBERS.md.
The Charter states that existing Voting Members can nominate new Voting Members up to two weeks prior to the Governing Board Election. The only requirement for a nomination is that the person contributed to MapLibre in a non-trivial way.
We use a Pull Request based workflow to nominate new Voting Members, read more here.
Approval New Voting Members
Existing Voting Members can approve or reject granting Voting Membership to someone who is nominated. For this we use a Pull Request based workflow, read more here.
Election Poll
The Governing Board Election Poll is sent out by email to all MapLibre Voting Members and is open for one week.
The Voting Members have to order all the candidates from first choice to last choice. Then, the Meek STV method is used to select the first 5 candidates who will form the next MapLibre Governing Board.
We use an online voting tool called OpaVote for the Governing Board Election Poll.

https://share-eu1.hsforms.com/1OcrNFreTRMqPRb0_PlOt3gfn2ab is the link for new Voting Member registration.


Fix output exchange flows mislabeled as resources

After noticing the red in the validate database in openLCA, ran a unit test against exchange flows that are outputs with 'resource' in their flow categories. This is what I found:
2024-03-01 18:20:49.465:WARNING:Found resource flow in output exchange! 'Water, fresh' in power plant construction - coal_const (ba733e1a-3d28-3bc7-8bcc-2d23982b6bf0)
2024-03-01 18:20:49.465:WARNING:Found resource flow in output exchange! 'Water, saline' in power plant construction - coal_const (ba733e1a-3d28-3bc7-8bcc-2d23982b6bf0)
2024-03-01 18:20:49.484:WARNING:Found resource flow in output exchange! 'Water, fresh' in power plant construction - ngcc_const (edb67176-ca7d-3370-aa8f-56d1c6f58c1c)
2024-03-01 18:20:49.484:WARNING:Found resource flow in output exchange! 'Water, saline' in power plant construction - ngcc_const (edb67176-ca7d-3370-aa8f-56d1c6f58c1c)

It appears fresh and saline water are labeled as resources but categorized as outputs.
The validation error notes these flows are found in both inputs and outputs.
They have positive values (I recall seeing negative emissions in renewable inventories to signify water use, rather than water discharge).
Should these be reclassified as emissions?

@m-jamieson

I think it's fine to classify them as output flows (e.g., Elementary flows/emission/water/water, fresh). I'm not aware of any "official" water use metrics using the fedelemflow systems that would be impacted by this type of change.

Just noting that we have two FEDEFL-inventory impact categories for water consumption, defined here, that capture total water resource use. I don't actually know off the top of my head how resource flows as outputs would be characterized with this method.

I tracked down the culprit to the last five lines in this CSV file:
https://github.com/USEPA/ElectricityLCI/blob/master/electricitylci/data/plant_construction_inventory.csv
For whatever reason, the compartment mapping dictionary found here:
https://github.com/USEPA/ElectricityLCI/blob/2232c41f2cb4fd333ad59c8710aa55906e6a7ed3/electricitylci/power_plant_construction.py#L56
creates two columns: 'Compartment_path' and 'Compartment'.
Compartment_path is correctly labeled as "resource" for both water flows, but "Compartment" is split between "resource" and "water," which might be what's throwing off the compartment mapping done here:
https://github.com/USEPA/ElectricityLCI/blob/2232c41f2cb4fd333ad59c8710aa55906e6a7ed3/electricitylci/combinator.py#L147
where "water" is mapped to emission, not resource.
Any ideas on what's going on in the "Compartment" labeling in power_plant_construction.py?

I believe the differences in approaches were just based on the limitations of the data at the time. Almost no resource flows were considered for Power plants as the data sources were all based on emissions - eGRID, AMPD, NEI, etc. I think this results in an emissions-focused mapping for combinator.py.
For power plant construction, that looks like it's in part trying to translate between openLCA reference flows and federal elementary flows, as well as trying to comply with previously established nomenclature for elci (a generic "resource" vs speicifc compartments for emissions).
This is all kind of speculation at this point. The construction pieces were some of the last added and I think the development timeline was such that I was just trying to get it working.
If it's easiest to revisit the whole mapping, I'd maybe suggest doing that - or changing the construction inventory to be natively in fedefl, so that we don't have to do any of this.


Set icon for OpenSim64.exe. Fix redist installer.

Partially addresses #628.
Fixes #809.
Brief summary of changes

We use ReplaceVistaIcon.exe (similar to Resource Hacker) to change the icon for OpenSim64.exe
The NSIS installer now creates start menu shortcuts.
The installation of the Visual C++ redistributable now occurs in a way wherein users are not likely to kill the installer (a separate installer pops up).
I added the ability to set the icon for the installer executable itself, but I commented this out because we do not have an icon that is appropriate for the installer executable (I don't want to use the OpenSim logo on its own, because then the installer could be confused with the application itself. Ideally we would have the modern OpenSim in a cardboard box; similar to OpenSimInstallerIcon.bmp).

Testing I've completed

Built the GUI and installer and ran the installer.
Ensured that the OpenSim desktop and start menu shortcuts work as intended, and that they have the correct icon (the OpenSim logo).
Ensured that the process of running the Visual C++ redistributable is less confusing.

CHANGELOG.md (choose one)

no need to update because...minor changes

Yes this is ready to be merged.


Something is wrong with the horizontal symmetry axis

import numpy as np
import abel

xx, yy = np.meshgrid(np.linspace(-256, 256, 512), np.linspace(-256, 256, 512))
r = np.sqrt(xx**2 + yy**2)

a = np.exp(-1/5000*r**2)

plt.imshow(a)
plt.colorbar()

t = abel.Transform(a, symmetry_axis=0).transform;

plt.figure()
plt.imshow(t)

This results in

which looks just fine.
Now keeping with the vertical axis of symmetry I move the gauss function along the y axis.
r = np.sqrt(xx**2 + (yy-80)**2). The result is as expected:

Now move the gauss along the x-axis  r = np.sqrt((xx-80)**2 + yy**2) and choose a horizontal axis of symmetry: t = abel.Transform(a, symmetry_axis=1).transform;. This should result in the same images, except transposed. But we get:

@leon-vv thanks for providing the code to illustrate this issue.
Your second case breaks cylindrical symmetry and so the Abel transform is invalid. See the docs, and the wine glass image figure.
In your example, specifying the symmetry origin facilitates the Abel transform. Passing the origin (centre of symmetry) parameter for the transform fixes this. Note, also, the image width should be an odd integer for PyAbel transforms.
xx, yy = np.meshgrid(np.linspace(-255, 255, 511), np.linspace(-255, 255, 511))
r = np.sqrt((xx-80)**2 + yy**2)

a = np.exp(-1/5000*r**2)

plt.imshow(a, extent=[-255, 255, -255, 255])
plt.colorbar()

t = abel.Transform(a, symmetry_axis=1, origin=(255, 255+80)).transform

plt.figure()
plt.imshow(t, extent=[-255, 255, -255, 255])

plt.show()

I think that @leon-vv is interpreting the symmetry_axis argument as a way to control the relevant axis for the Abel transform. Really, the Abel transform is always performed around the y-axis. I think that we should make this clear in the docs for abel.Transform. I'm noticing a few issues with the doc for our flagship user interface:

We should let users know that the Abel transform is performed around the y-axis. If their data is rotated the wrong way, they are going to need to use np.rot90.

In the description for "symmetry_axis", we should probably add a bit more info. At least we should say "see below", since we provide a better description for quadrants and symmetry below.

We should provide an usage example! (I know that we have one in the readme, maybe we just cut and paste it here.)

And now, a side note. @stggh said:

Note, also, the image width should be an odd integer for PyAbel transforms.

abel.Transform takes care of re-centering and can deal with even image widths. So, while the "odd image requirement" is true on a fundamental level for each transform method, abel.Transform takes care of this issue and allows both even and odd images to be used. So, we should simply encourage users to use abel.Transform and live a care-free life :).  (I'm thinking back to  https://github.com/PyAbel/PyAbel/issues/272, we had a user asking about the even/odd image situation, when really they were just looking for the centering + transform functionality of abel.Transform.)

abel.Transform takes care of re-centering and can deal with even image widths

Only when the origin parameter is specified.

We should let users know that the Abel transform is performed around the y-axis. If their data is rotated the wrong way, they are going to need to use np.rot90.

Or transpose before and after. May be faster or may be not, but at least (A.T).T == A.

Thanks all for your elaborate answers.

Your second case breaks cylindrical symmetry and so the Abel transform is invalid.

I think that @leon-vv is interpreting the symmetry_axis argument as a way to control the relevant axis for the Abel transform.

Yes this is the root of the problem. I thought the symmetry_axis determined the z-axis of the cylindrical coordinate system used for the abel transform.

Or transpose before and after. May be faster or may be not, but at least (A.T).T == A

This is what I have resorted to. np.rot90 uses a transpose under the hood, so directly using transpose will be faster.

We should let users know that the Abel transform is performed around the y-axis. If their data is rotated the wrong way, they are going to need to use np.rot90.
In the description for "symmetry_axis", we should probably add a bit more info. At least we should say "see below", since we provide a better description for quadrants and symmetry below.

Please see my pull request.

Should we close this issue, since the problem is already addressed in #288?

Yes, I think that this has been addressed. So I'll close this. (If someone considers this unresolved, please re-open.)
Thanks for pointing this out @leon-vv!


Gravatars are broken on pypi.org

Gravatars across PyPI are not loading because of HTTP 504s from https://warehouse-camo.cmh1.psfhosted.org.
To reproduce: Load a project page or user page, and look at the maintainers list or (lack of) profile picture.

I'm using Chrome 67.0.3396.48 (beta channel) on Ubuntu 16.04.4.
Example of part of the maintainers list for Flask:

Logs:

I can reproduce - in fact, I was just about to open a ticket for this.  Thanks for beating me to it @anowlcalledjosh :)

Thanks for report. Gonna look into the reasons why, but it appears that the TLS certificates for the service expired and were not renewed.
This is resolved for now.


IO.puts

I think it's a code smell for a library to do 'IO.puts' on errors, the errors should be reflected only in the function's output.
My opinion only so if you agree I could make the fix myself and submit a PR.

@joelfperion I agree. I'd love some other way to pas up the error. Perhaps a call to a logger or just pass it back?

It seems to me that most libraries in elixir don't log (httpoison, phoenix, dynamo, etc..) so maybe to conform to their best practice just pass it back?

sounds good. Merged the PR


Disabled logging in production builds

Hi there,
I've been using this addon for quite some time now, but in the last couple of months I've been using it more and more in addon demo pages. When I build my app in production mode and publish it on gh-pages, I still get logging (see screenshot) which I believe should be disabled.

We should update shouldLog to check for ENV vars, but for now you should be able to import ENV in your mirage/config.js, and if env is production, run this.logging = false.

👍  great! Thanks for the workaround


[Visualization question]: CPU versus GPU

I need a SVG graphics visualizing two processes. One takes an image as input, applies a Gaussian blur and produces a new imagw as output. All that happens on the CPU. The other process needs to transfer the data to GPU, applies the Gaussian blur there, and transfers the image back to the CPU. In the drawing, time goes from top to bottom and box heights represent time. While the Gaussian blur is faster on the GPU, the back and forth transfer together with the Gaussian blur takes longer than the Gaussian blur on the CPU. CPU and GPU are visualized as columns.
git-bob try to achieve this SVG graphics

Ok, git-bob try again with these modifications: make the boxes on the GPU side less high. Add boxes for input and output images. Represent them as data with a silo like shape.

Almost perfect! Just add arrows between the boxes as explained above!
git-bob try again


TextField multiline prop disables HTML5 form validation features

[x ] The issue is present in the latest release.
[x ] I have searched the issues of this repository and believe that this is not a duplicate.

Current Behavior 😯
The validation does not happen when I use the multiline prop. It turns out the multiline prop transforms TextField into textarea which cannot have a HTML5 type attribute.
Expected Behavior 🤔
I would expect type validation, when I use e. g. type="number" to allow the user to input only numbers even if using the multiline prop. Or at least a mention in documentation that the multiline prop disables the validation 😇

Steps to Reproduce 🕹
See example here:
https://codesandbox.io/s/icy-leaf-139fz?file=/src/App.js

Steps:

import TextField from '@material-ui/core/TextField';
compare <TextField type="number" multiline/> and <TextField type="number"/>

Context 🔦
I was building a form and did not expect this behavior.

  Output from `npx @material-ui/envinfo` goes here.

I'm closing as you have already explain why it can't be done. Thanks for the issue, it will probably be helpful for documentation purposes.


renaming table in table designer does not work if cursor is still in name field

Version: 1.36.0
Commit: 0704471e6b4a79f0c2c2425b22dc6bee60a1c2a8
Date: 2022-04-19T18:21:59.017Z
VS Code: 1.59.0
Electron: 13.6.6
Chrome: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Darwin x64 21.4.0
Steps to Reproduce:

open designer for an existing table
change the table name and leave cursor in the field
save - generate script with changes

the preview window shows no changes, yet the script editor shows the change

I've fixed the issue that when there are no changes user can still trigger the publish changes dialog by pressing CTRL+S.
In order to submit the changes, user has to move the focus out of the text box, this is currently by design. we can revisit it if we have a lot of users complaining about it.


Changing classes to the new implementation of Database Managing

In issue #163 I create a class that warped DBManager so we can mokc it.
This issue is about changing the classes that uses DBManager:

[x] - Driver
[x] - ParkingSlot
[ ] - Order
[ ] - ParkingSlotRequest

[ ] - Validation

@matityahuinba after you vication we need to go over the order class to change it, I dont completly understand you code to do it alone. But for now travis run only 6 min so it is ok

Begin to work on Order class :)

I finished my part :)
Order & OrderTest classes are ready!

@assaflu
We're done, aren't we?


chore(build): force using bash in Makefile to avoid incompatibilities

Release Note
NONE

Let's spare some check resource, not required by this change.


not seeing plot when i execute model.plot()

I would like to reproduce the results in figure 4 of the paper "Nested Variational Compression in Deep Gaussian Processes" from "Nested Deep GPs.ipynb" notebook but model.plot() does not show any figure. Please what am i doing wrong?

@mzwiessele is this associated with the changes of the plotting code for
GPy?
On Mon, Feb 29, 2016 at 9:48 PM, Mawul4j<EMAIL_ADDRESS>wrote:

I would like to reproduce the results in "Nested Deep GPs" notebook but
model.plot() does not show any figure. Please what am i doing wrong?
—
Reply to this email directly or view it on GitHub
https://github.com/SheffieldML/deepGPy/issues/5.

Could you provide a code snippet reproducing the error and your python version, so we can narrow it down? Also which GPy are you using?

On 01 Mar 2016, at 06:36, Neil Lawrence<EMAIL_ADDRESS>wrote:
@mzwiessele is this associated with the changes of the plotting code for
GPy?
On Mon, Feb 29, 2016 at 9:48 PM, Mawul4j<EMAIL_ADDRESS>wrote:

I would like to reproduce the results in "Nested Deep GPs" notebook but
model.plot() does not show any figure. Please what am i doing wrong?
—
Reply to this email directly or view it on GitHub
https://github.com/SheffieldML/deepGPy/issues/5.

—
Reply to this email directly or view it on GitHub.

Okay, i have GPy (0.8.8, /home/mawulolo/GPy_Devel/GPy) installed locally.
Basically, model.plot() produces no figure.
and
for layer in model.layers:
layer.plot()
produces the following:
ValueError                                Traceback (most recent call last)
 in ()
1 for layer in model.layers:
----> 2     layer.plot()
/home/mawulolo/Desktop/Masters_Project/Lab_Session/layers.pyc in plot(self)
329
330     def plot(self):
--> 331         plotting.plot_input_layer(self)
332
333
/home/mawulolo/Desktop/Masters_Project/Lab_Session/plotting.pyc in plot_input_layer(layer)
67         Xnew, xmin, xmax = x_frame1D(layer.Z, resolution=200)
68
---> 69         sausage_plot(layer, Xnew, ax1)
70         errorbars(layer, ax1)
71         plt.setp(ax1.get_xticklabels(), visible=False)
/home/mawulolo/Desktop/Masters_Project/Lab_Session/plotting.pyc in sausage_plot(layer, Xnew, ax)
8 def sausage_plot(layer, Xnew, ax):
9     mu, var = layer.predict(Xnew)
---> 10     gpplot(Xnew, mu, mu + 2np.sqrt(var), mu - 2np.sqrt(var), ax=ax)
11
12 def errorbars(layer, ax):
/home/mawulolo/GPy_Devel/GPy/GPy/plotting/matplot_dep/base_plots.pyc in gpplot(x, mu, lower, upper, edgecol, fillcol, ax, fignum, **kwargs)
33
34     #here's the mean
---> 35     plots.append(meanplot(x, mu, edgecol, axes))
36
37     #here's the box
/home/mawulolo/GPy_Devel/GPy/GPy/plotting/matplot_dep/base_plots.pyc in meanplot(x, mu, color, ax, fignum, linewidth, **kw)
20 def meanplot(x, mu, color='#3300FF', ax=None, fignum=None, linewidth=2,**kw):
21     _, axes = ax_default(fignum, ax)
---> 22     return axes.plot(x,mu,color=color,linewidth=linewidth,**kw)
23
24 def gpplot(x, mu, lower, upper, edgecol='#3300FF', fillcol='#33CCFF', ax=None, fignum=None, **kwargs):
/home/mawulolo/anaconda2/lib/python2.7/site-packages/matplotlib/init.pyc in inner(ax, *args, **kwargs)
1809                     warnings.warn(msg % (label_namer, func.name),
1810                                   RuntimeWarning, stacklevel=2)
-> 1811             return func(ax, *args, **kwargs)
1812         pre_doc = inner.doc
1813         if pre_doc is None:
/home/mawulolo/anaconda2/lib/python2.7/site-packages/matplotlib/axes/_axes.pyc in plot(self, *args, **kwargs)
1425             kwargs['color'] = c
1426
-> 1427         for line in self._get_lines(*args, **kwargs):
1428             self.add_line(line)
1429             lines.append(line)
/home/mawulolo/anaconda2/lib/python2.7/site-packages/matplotlib/axes/_base.pyc in _grab_next_args(self, *args, **kwargs)
384                 return
385             if len(remaining) <= 3:
--> 386                 for seg in self._plot_args(remaining, kwargs):
387                     yield seg
388                 return
/home/mawulolo/anaconda2/lib/python2.7/site-packages/matplotlib/axes/_base.pyc in _plot_args(self, tup, kwargs)
362             x, y = index_of(tup[-1])
363
--> 364         x, y = self._xy_from_xy(x, y)
365
366         if self.command == 'plot':
/home/mawulolo/anaconda2/lib/python2.7/site-packages/matplotlib/axes/_base.pyc in _xy_from_xy(self, x, y)
221         y = _check_1d(y)
222         if x.shape[0] != y.shape[0]:
--> 223             raise ValueError("x and y must have same first dimension")
224         if x.ndim > 2 or y.ndim > 2:
225             raise ValueError("x and y can be no greater than 2-D")
ValueError: x and y must have same first dimension

Please, is there anything i am doing wrong?

I have managed to upgrade GPy to version 0.9.4 but this issue persists.
Follow up: Is there any solution to this?

I don't think it has anything to do with you doing something wrong. I cannot be sure though. Could you give us a minimalist example of when it goes wrong? So we can run it on newer versions of GPy and see how it performs there? Also we might be able to find the problem, if there is one in DeepGP.
Thanks

On 02 Mar 2016, at 10:48, Mawul4j<EMAIL_ADDRESS>wrote:
I have managed to upgrade GPy to version 0.9.4 but this issue persists.
Follow up: Is there any solution to this?
—
Reply to this email directly or view it on GitHub.

Okay.
when i execute "model.plot()", basically it shows nothing
Also when i execute
for layer in model.layers:
----> layer.plot()
ValueError: x and y must have same first dimension
I don't know if that makes sense.

Do you have a piece of code, which we can run, which reproduces the error? That would be very helpful in order to see where the problem lies.
Thanks

On 02 Mar 2016, at 14:03, Mawul4j<EMAIL_ADDRESS>wrote:
Okay.
when i execute "model.plot()", basically it shows nothing
Also when i execute
for layer in model.layers:
----> layer.plot()
ValueError: x and y must have same first dimension
I don't know if that makes sense.
—
Reply to this email directly or view it on GitHub.

Nested.zip

Have you tried commenting out this? https://github.com/SheffieldML/deepGPy/blob/master/step_fn_demo.py#L4

Yes but it did not solve the problem for me. Did it work for you?

OK nevermind my previous comment as you were trying to run the notebook, not the step function demo script.
I couldn't replicate the problem you have on a mac with the latest GPy.

The plotting.py file contains code that only covers cases where input and output dimensions are ==1.
Could it be that the complete plotting.py file has not been uploaded here on github?
Any pointers on how to fix this myself?

Could it be that the complete plotting.py file has not been uploaded here
on github?

No, if it works for Thang, it's on github.
If your output dimension is larger than 1, I suspect that simply no plot
will appear.
James.
On 5 April 2016 at 22:44, Mawul4j<EMAIL_ADDRESS>wrote:

The plotting.py file contains code that only covers cases where input and
output dimensions are ==1.
Could it be that the complete plotting.py file has not been uploaded here
on github?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/SheffieldML/deepGPy/issues/5#issuecomment-205996021

@jameshensman  Basically, i want to reproduce figure 4 of the paper "Nested Variational Compression in Deep Gaussian Processes". So, I ran the example in the notebook on robot wireless data to get that result.
Maybe i am doing this wrong, but can you please show me how figure 4 of that paper was produced with DeepGPy?
I believe Thang was helping with the step function demo.


Read the docs

Codecov Report

Merging #30 (de82543) into main (987de79) will decrease coverage by 0.41%.
The diff coverage is 94.74%.

@@            Coverage Diff             @@
##             main      #30      +/-   ##
==========================================
- Coverage   96.98%   96.56%   -0.42%
==========================================
  Files          40       43       +3
  Lines        2285     2561     +276
==========================================
+ Hits         2216     2473     +257
- Misses         69       88      +19

Impacted Files
Coverage Δ

datagen/supplier/core/__init__.py
100.00% <ø> (ø)

datagen/supplier/core/select_list_subset.py
95.23% <ø> (-0.22%)
:arrow_down:

datagen/supplier/core/unicode_range.py
100.00% <ø> (ø)

datagen/supplier/core/refs.py
92.85% <50.00%> (-7.15%)
:arrow_down:

datagen/types.py
86.66% <70.00%> (-13.34%)
:arrow_down:

datagen/builder.py
95.85% <85.71%> (+0.33%)
:arrow_up:

datagen/supplier/core/uuid_handler.py
94.11% <87.50%> (-5.89%)
:arrow_down:

datagen/supplier/core/nested.py
97.87% <92.30%> (-2.13%)
:arrow_down:

datagen/casters.py
95.23% <92.72%> (-4.77%)
:arrow_down:

datagen/supplier/core/geo.py
96.49% <93.75%> (-0.29%)
:arrow_down:

... and 49 more

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 987de79...de82543. Read the comment docs.


analysis.setAnalysisRoots fails when provided a non-existent path.

If any of the paths provided to [analysis.setAnalysisRoots] (https://htmlpreview.github.io/?https://github.com/dart-lang/sdk/blob/master/pkg/analysis_server/doc/api.html#request_analysis.setAnalysisRoots)'s included list is a path to a file system entity that does not exist, no analysis roots are set, and the analysis server responds with the error UNSUPPORTED_FEATURE and the message $path is not a folder. Only support for folder analysis is implemented currently.
This is contrary to the API spec, which specifically says "if the client sets an analysis root before the root becomes visible to server in the filesystem, there is no error; once the server sees the root in the filesystem it will start analyzing it."
In IntelliJ, this bug manifests in the following way: if the user deletes the folder representing one of their analysis roots, and then restarts their IDE, IntelliJ will request a non-existent analysis root.  The analysis.setAnalysisRoots command will fail, so no files will be analyzed.  In effect, from the user's point of view, all analysis is broken, and remains broken until the user re-introduces the folder or deletes the bogus path from their project configuration.

I plan to fix this as part of reworking the context manager (#24133).

https://codereview.chromium.org/1316753003/

Note: filed #24305 as a reminder that we still need to ensure that once the folder comes into existence, the analysis server needs to begin analyzing it without prompting.


Unable to Query Invoices with Minor Version 16-23 and VendorCredits 12-23

The error is Exception appears in converting Response to XML.
Further investigation reveals the root cause being
object(RuntimeException) {
        [protected] message => 'Property FreeFormAddress does not exist. Class QuickBooksOnline\API\Data\IPPInvoice'
        [protected] code => (int) 0
        [protected] file => '/Users/challgren/Projects/ATX Liquor/website v1/Vendor/quickbooks/v3-php-sdk/src/XSD2PHP/src/com/mikebevz/xsd2php/Bind.php'
        [protected] line => (int) 135
}

Also the Developer Docs state that PHP SDK v4.0.4 supports Minor Version 23
My guess is the IPPSalesTransaction need to be updated to support SalesTransaction.FreeFormAddress that was added in Minor Version 21. I also looked and it appears that IPPVendorCredit needs to be updated to support VendorCredit.balance
My guess is no one has run the XSD2PHP since the project was started.

@challgren I really appreciate your pointing out. Thanks so much for your contribution. I will review the changes and merge ASAP.

This can be closed when its released.

Release 5.0.0


fix frame box aspectRatio handling

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


pepsyn translate should have an option on whether to include the stop codon

Closing because package is no longer actively maintained.


Update position of FAB and set limit of bounce effect of FAB for iOS

Widget is now platform aware, positioning FAB in right location for iOS and disable bounce on expanded height of SliverFab.

Hey man! Thanks for PR!


Test fix

cargo test --all used to fail on this test. I've also added --all to travis.

Coverage decreased (-0.03%) to 83.067% when pulling 41c80d17334143e763bc671d0725473942629509 on kornelski:vframetest into f3b1c5875505b81fc0af55e7ebc3447aac3ce678 on xiph:master.

Thank you, @Luni-4 maybe we could add it to the github actions as well.

Sure! I think it would be better to use --workspace option though because the --all one is deprecated.


listeners should return null to continue on (#21)

Listeners should return null if they want the event to continue propagating.

Thanks @edalzell!


feat: add cicle check icon

What kind of change does this PR introduce?
Adding icon
What is the new behavior?
Add animated circle-check
Demo
https://github.com/user-attachments/assets/181274f9-e520-4bd7-9667-6f9902d46a18
Additional context
You can increase the animation time by 0.1 second if you like.

I'm sorry, I've just seen that my linter has reordered the index.ts file.


Support broadcasting single wire operations and expectations to more than one wire

Currently, all quantum operations and expectation values in PennyLane act on a single wire; for example, if you wish to return Pauli-Z expectations for three wires, you would have to do
return qml.expval.PauliZ(0), qml.expval.PauliZ(1), qml.expval.PauliZ(2)

It would be useful to also allow local (single wire) operations and expectation values to apply to more than one wire, i.e.,
@qml.qnode(dev)
def circuit(x, y):
    qml.ops.Hadamard(wires=[0, 3])
    qml.ops.RX(x, wires='all')
    return qml.expval.PauliZ(wires=[0,2])

This should be a relatively simple modification. For example, the QNode.construct() method could be modified such that qml.expval(wires=[0, 2, 5]) automatically gets translated into the tuple qml.expval(wires=0), qml.expval(wires=2), qml.expval(wires=5). Similarly, when constructing the operator queue, a list of wires (or 'all') could be automatically 'broadcast' or expanded.

Okay, I dug a little deeper into this and discussed with @josh146. It seems that trying to support broadcasting to multi-wires leads to some ambiguity which might not be desirable in the long term.
E.g., if we take expval.PauliX(2) vs expval.PauliX([0, 2]), it seems that broadcasting is convenient. But what about a two or three qubit gate? Do we do expval.Toffoli([(1, 2, 3), (5, 6, 7) ]).
In the spirit of PEP20 - the Zen of Python, it seems that the current method is the most optimal. One can always do a list comprehension for multiple wires in case of both single and multi-qubit gates.
return qml.expval.PauliZ(wires = [0, 2])` vs `return [qml.expval.PauliZ(w) for w in wires]
Or,
return qml.expval.Toffoli(wires = [(0, 1, 2), (3, 4, 5)])` vs `return [qml.expval.Toffoli(w) for w in wires]
In any case, if we wish to implement this for other reasons such as parallel computation, I think we just need to change check_wires to identify such a case and then rewrite the expectation value computation in pennylane._device. Still not sure if it is worth doing all these changes just to get single qubit broadcasting to work when the alternative - list comprehension is the more pythonic way of doing it.

I tend to agree, single wire gate broadcasting would simply be a convenience for the user, and not introduce any new or additional functionality. At the same time, it has the chance to cause some confusion with multi-wire gates.
Taking into account #175, which would be a significant feature addition, my current thinking is to close this issue and treat list comprehension as the preferred method for 'broadcasting' single wire operations.


Topic/spickler unpickler subtyping

Add SPicklerUnpickler as a subclass of SPickler and Unpickler.
cc> @havocp @eed3si9n

Replaces #275

LGTM


issue with embedding static and dynamic packages in iOS using flutter

Our pod file contains
use_frameworks!
pod install fails when above property is set. if it is commented it installs fine but breaks our our code where there are dynamic packages.

@srinivasuk is it still an issue? do you try to add flutter to an existing app? Adding Flutter to an existing app is experimental and only available on the master channel.

We tried few months back and struggled a lot integrating with existing IOS
app
We are able to integrate without firebase, but when we tried to integrate
with firebase we got pod issue. We don't know if it is flutter issue or
firebase issue.
So finally we kept flutter project on hold because of this issue.
If issue is resolved we can try it again.
Thanks
On Wed, Oct 9, 2019, 5:24 PM Stanislav Bondarenko<EMAIL_ADDRESS>wrote:

@srinivasuk https://github.com/srinivasuk is it still an issue? do you
try to add flutter to an existing app? Adding Flutter to an existing app is
experimental and only available on the master channel.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/flutter/flutter/issues/33192?email_source=notifications&email_token=AAHUJ7SRIBL7IP2TZSI7M63QNZKYJA5CNFSM4HOVTU22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAZUELY#issuecomment-540230191,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAHUJ7X5GBYWJY6LOIJ45PLQNZKYJANCNFSM4HOVTU2Q
.

@srinivasuk Now it's hard to know what was the exact issue, it would be cool if you try and if it fails, then provide your flutter doctor -v output, pubspec.yaml, error logs.

Without additional information, we are unfortunately not sure how to resolve this issue. We are therefore reluctantly going to close this bug for now. Please don't hesitate to comment on the bug if you have any more information for us; we will reopen it right away!
Thanks for your contribution.


Depth image normalization seems to loose details

I am currently trying to capture both, the color image and the depth image. This is working, but the depth image looks really bad. The nearer areas are all blown out, sometimes the whole image is white.
The depth stream instead looks like how the death image should look like. I use the same method to convert the CVPixelBuffer into a grayscale image (the one you are using in the example).
I am missing something there, or why are these depth images not normalised the same way? I also tried to capture a depth image with the Halide App and they seem much better in depth resolution then the one I can capture / stream with lumina. Are there other ways to capture depth images or normalize them?
Here is the code I use to normalize the depth images:
func captured(stillImage: UIImage, livePhotoAt: URL?, depthData: Any?, from controller: LuminaViewController) {
	// save color image
	CustomPhotoAlbum.shared.save(image: stillImage)

	// save depth image if possible
	print("trying to save depth image")
	if #available(iOS 11.0, *) {
	    if var data = depthData as? AVDepthData {

	        // be sure its DisparityFloat32
	        if data.depthDataType != kCVPixelFormatType_DisparityFloat32 {
	            data = data.converting(toDepthDataType: kCVPixelFormatType_DisparityFloat32)
	        }

	        guard let depthImage = data.depthDataMap.normalizedImage(with: controller.position) else {
	            print("could not convert depth data")
	            return
	        }

	        ...

extension CVPixelBuffer {
    func normalizedImage(with position: CameraPosition) -> UIImage? {
        let ciImage = CIImage(cvPixelBuffer: self)
        let context = CIContext(options: nil)
        if let cgImage = context.createCGImage(ciImage, from: CGRect(x: 0, y: 0, width: CVPixelBufferGetWidth(self), height: CVPixelBufferGetHeight(self))) {
            return UIImage(cgImage: cgImage , scale: 1.0, orientation: getImageOrientation(with: position))
        } else {
            return nil
        }
    }

    private func getImageOrientation(with position: CameraPosition) -> UIImageOrientation {
        switch UIApplication.shared.statusBarOrientation {
        case .landscapeLeft:
            return position == .back ? .down : .upMirrored
        case .landscapeRight:
            return position == .back ? .up : .downMirrored
        case .portraitUpsideDown:
            return position == .back ? .left : .rightMirrored
        case .portrait:
            return position == .back ? .right : .leftMirrored
        case .unknown:
            return position == .back ? .right : .leftMirrored
        }
    }
}

Here are the three images:
Color Image

Depth Image from the captured method

Depth image from the streamed method

Ok, it seems that there is a difference between relative and absolute depth buffers. The relative one is only for foreground / background separation, while absolute is to measure real distances. Is it possible to tell lumina, which one I would like to get?

Hey @cansik just letting you know that I finally have some time to take a look at this - I'll be in Italy all week this week on vacation but I'll see what I can come up with on my flights!