Flaky Rollover test

I believe this is not the first time that I've seen the rollover test failing on CI so I thought I create this ticket:
https://github.com/itchysats/itchysats/runs/6978234506?check_suite_focus=true
https://github.com/itchysats/itchysats/runs/6978501105?check_suite_focus=true
logs:
2022-06-21T05:07:30.890106ZTRACEwire: Received msg_name="MakerToTaker::CurrentOffers"
thread 'rollover_an_open_cfd_maker_going_short' panicked at 'assertion failed: nanoseconds <= 0', /Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/time-0.3.10/src/duration.rs:205:13
2022-06-21T05:07:33.186718ZTRACEwire: measuring heartbeat pulse
2022-06-21T05:07:35.114795ZERRORdaemon::rollover::protocol: Rollover failed: End of stream while receiving rollover decision from maker order_id=039c4a12-7ae9-4c99-8077-b7bb99d7e7cc
2022-06-21T05:07:35.117854Z WARNmodel::cfd: Rollover failed: End of stream while receiving rollover decision from maker order_id=039c4a12-7ae9-4c99-8077-b7bb99d7e7cc
2022-06-21T05:07:35.581490ZTRACEwire: Sending taker_id=c3c2a220e6a527389bc81f42531a752033b1d9486f2342b6945629e92e329b5a msg_name="MakerToTaker::Heartbeat"
2022-06-21T05:07:35.582253ZTRACEwire: Received msg_name="MakerToTaker::Heartbeat"
2022-06-21T05:07:35.776453ZTRACEwire: measuring heartbeat pulse
2022-06-21T05:07:38.310996ZTRACEwire: measuring heartbeat pulse
2022-06-21T05:07:40.583780ZTRACEwire: Sending taker_id=c3c2a220e6a527389bc81f42531a752033b1d9486f2342b6945629e92e329b5a msg_name="MakerToTaker::Heartbeat"
2022-06-21T05:07:40.584497ZTRACEwire: Received msg_name="MakerToTaker::Heartbeat"
2022-06-21T05:07:40.875338ZTRACEwire: measuring heartbeat pulse
2022-06-21T05:07:43.495683ZTRACEwire: measuring heartbeat pulse
2022-06-21T05:07:45.655280ZTRACEwire: Sending taker_id=c3c2a220e6a527389bc81f42531a752033b1d9486f2342b6945629e92e329b5a msg_name="MakerToTaker::Heartbeat"
2022-06-21T05:07:45.656029ZTRACEwire: Received msg_name="MakerToTaker::Heartbeat"
2022-06-21T05:07:46.011020ZTRACEwire: measuring heartbeat pulse
2022-06-21T05:07:48.614530ZTRACEwire: measuring heartbeat pulse
2022-06-21T05:07:50.657671ZTRACEwire: Sending taker_id=c3c2a220e6a527389bc81f42531a752033b1d9486f2342b6945629e92e329b5a msg_name="MakerToTaker::Heartbeat"
2022-06-21T05:07:50.658498ZTRACEwire: Received msg_name="MakerToTaker::Heartbeat"
2022-06-21T05:07:51.175912ZTRACEwire: measuring heartbeat pulse
2022-06-21T05:07:53.734707ZTRACEwire: measuring heartbeat pulse
2022-06-21T05:07:55.709514ZTRACEwire: Sending taker_id=c3c2a220e6a527389bc81f42531a752033b1d9486f2342b6945629e92e329b5a msg_name="MakerToTaker::Heartbeat"
2022-06-21T05:07:55.710251ZTRACEwire: Received msg_name="MakerToTaker::Heartbeat"
2022-06-21T05:07:56.265887ZTRACEwire: measuring heartbeat pulse
2022-06-21T05:07:58.811785ZTRACEwire: measuring heartbeat pulse
2022-06-21T05:08:00.851667ZTRACEwire: Sending taker_id=c3c2a220e6a527389bc81f42531a752033b1d9486f2342b6945629e92e329b5a msg_name="MakerToTaker::Heartbeat"
2022-06-21T05:08:00.852488ZTRACEwire: Received msg_name="MakerToTaker::Heartbeat"
2022-06-21T05:08:01.312877ZTRACEwire: measuring heartbeat pulse
2022-06-21T05:08:03.870419ZTRACEwire: measuring heartbeat pulse
2022-06-21T05:08:05.875651ZTRACEwire: Sending taker_id=c3c2a220e6a527389bc81f42531a752033b1d9486f2342b6945629e92e329b5a msg_name="MakerToTaker::Heartbeat"
2022-06-21T05:08:05.876511ZTRACEwire: Received msg_name="MakerToTaker::Heartbeat"
2022-06-21T05:08:06.373971ZTRACEwire: measuring heartbeat pulse
2022-06-21T05:08:08.936527ZTRACEwire: measuring heartbeat pulse
2022-06-21T05:08:10.931388ZTRACEwire: Sending taker_id=c3c2a220e6a527389bc81f42531a752033b1d9486f2342b6945629e92e329b5a msg_name="MakerToTaker::Heartbeat"
2022-06-21T05:08:10.932520ZTRACEwire: Received msg_name="MakerToTaker::Heartbeat"
2022-06-21T05:08:11.535411ZTRACEwire: measuring heartbeat pulse
2022-06-21T05:08:14.082159ZTRACEwire: measuring heartbeat pulse
2022-06-21T05:08:16.019100ZTRACEwire: Sending taker_id=c3c2a220e6a527389bc81f42531a752033b1d9486f2342b6945629e92e329b5a msg_name="MakerToTaker::Heartbeat"
2022-06-21T05:08:16.019826ZTRACEwire: Received msg_name="MakerToTaker::Heartbeat"
2022-06-21T05:08:16.584303ZTRACEwire: measuring heartbeat pulse
2022-06-21T05:08:19.189022ZTRACEwire: measuring heartbeat pulse
2022-06-21T05:08:21.063304ZTRACEwire: Sending taker_id=c3c2a220e6a527389bc81f42531a752033b1d9486f2342b6945629e92e329b5a msg_name="MakerToTaker::Heartbeat"
2022-06-21T05:08:21.064147ZTRACEwire: Received msg_name="MakerToTaker::Heartbeat"
2022-06-21T05:08:21.812936ZTRACEwire: measuring heartbeat pulse
2022-06-21T05:08:24.393736ZTRACEwire: measuring heartbeat pulse
2022-06-21T05:08:26.206833ZTRACEwire: Sending taker_id=c3c2a220e6a527389bc81f42531a752033b1d9486f2342b6945629e92e329b5a msg_name="MakerToTaker::Heartbeat"
2022-06-21T05:08:26.207675ZTRACEwire: Received msg_name="MakerToTaker::Heartbeat"
2022-06-21T05:08:26.919567ZTRACEwire: measuring heartbeat pulse
2022-06-21T05:08:29.562996ZTRACEwire: measuring heartbeat pulse
thread 'rollover_an_open_cfd_maker_going_short' panicked at 'called `Result::unwrap()` on an `Err` value: Value channel did not satisfy predicate within 60 seconds

Maybe related to : https://github.com/itchysats/itchysats/issues/2263

Seems like we have hit this bug: https://github.com/time-rs/time/issues/481

With my branch rollover_refactor rebased on master I am able to (sometimes) reproduce this locally:
2022-06-21T22:32:31.404426Z TRACE wire: Sending taker_id=5f6147d246000364ed824a46ffd4b7e661cea0a066506e402213ced844578e53 msg_name="MakerToTaker::CurrentOffers"
2022-06-21T22:32:31.407120Z TRACE wire: Received msg_name="MakerToTaker::CurrentOffers"

called `Result::unwrap()` on an `Err` value: Value channel did not satisfy predicate within 60 seconds

Caused by:
    deadline has elapsed
thread 'double_rollover_an_open_cfd' panicked at 'assertion failed: nanoseconds <= 0', /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/time-0.3.10/src/duration.rs:205:13
stack backtrace:
   0: rust_begin_unwind
             at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
             at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/core/src/panicking.rs:143:14
   2: core::panicking::panic
             at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/core/src/panicking.rs:48:5
   3: time::duration::Duration::new_unchecked
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/time-0.3.10/src/duration.rs:205:13
   4: <time::time::Time as core::ops::arith::Sub>::sub
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/time-0.3.10/src/time.rs:751:9
   5: <time::primitive_date_time::PrimitiveDateTime as core::ops::arith::Sub>::sub
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/time-0.3.10/src/primitive_date_time.rs:933:34
   6: <time::offset_date_time::OffsetDateTime as core::ops::arith::Sub>::sub
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/time-0.3.10/src/offset_date_time.rs:1218:9
   7: model::cfd::Cfd::hours_to_extend_in_rollover_based_on_event
             at /Users/dakami/CoBloX/repos/hermes/model/src/cfd.rs:1531:26
   8: model::cfd::Cfd::accept_rollover_proposal
             at /Users/dakami/CoBloX/repos/hermes/model/src/cfd.rs:918:17
   9: <daemon::rollover::maker::Actor as xtra::Handler<daemon::rollover::maker::Accept>>::handle::{{closure}}::{{closure}}::{{closure}}
             at /Users/dakami/CoBloX/repos/hermes/daemon/src/rollover/maker.rs:174:83
  10: daemon::command::Executor::execute::{{closure}}
             at /Users/dakami/CoBloX/repos/hermes/daemon/src/command.rs:38:26
  11: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
             at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/core/src/future/mod.rs:84:19
  12: <daemon::rollover::maker::Actor as xtra::Handler<daemon::rollover::maker::Accept>>::handle::{{closure}}::{{closure}}
             at /Users/dakami/CoBloX/repos/hermes/daemon/src/rollover/maker.rs:182:27
  13: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
             at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/core/src/future/mod.rs:84:19
  14: tokio_tasks::tasks::Tasks::add_fallible::{{closure}}
             at /Users/dakami/CoBloX/repos/hermes/tokio-tasks/src/tasks.rs:35:20
  15: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
             at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/core/src/future/mod.rs:84:19
  16: <core::panic::unwind_safe::AssertUnwindSafe<F> as core::future::future::Future>::poll
             at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/core/src/panic/unwind_safe.rs:289:9
  17: <futures_util::future::future::catch_unwind::CatchUnwind<Fut> as core::future::future::Future>::poll::{{closure}}
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-util-0.3.21/src/future/future/catch_unwind.rs:36:42
  18: <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
             at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/core/src/panic/unwind_safe.rs:271:9
  19: std::panicking::try::do_call
             at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/panicking.rs:492:40
  20: ___rust_try
  21: std::panicking::try
             at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/panicking.rs:456:19
  22: std::panic::catch_unwind
             at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/panic.rs:137:14
  23: <futures_util::future::future::catch_unwind::CatchUnwind<Fut> as core::future::future::Future>::poll
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-util-0.3.21/src/future/future/catch_unwind.rs:36:9
  24: <futures_util::future::future::remote_handle::Remote<Fut> as core::future::future::Future>::poll
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-util-0.3.21/src/future/future/remote_handle.rs:105:29
  25: <core::pin::Pin<P> as core::future::future::Future>::poll
             at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/core/src/future/future.rs:123:9
  26: tokio::runtime::task::core::CoreStage<T>::poll::{{closure}}
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.14.1/src/runtime/task/core.rs:161:17
  27: tokio::loom::std::unsafe_cell::UnsafeCell<T>::with_mut
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.14.1/src/loom/std/unsafe_cell.rs:14:9
  28: tokio::runtime::task::core::CoreStage<T>::poll
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.14.1/src/runtime/task/core.rs:151:13
  29: tokio::runtime::task::harness::poll_future::{{closure}}
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.14.1/src/runtime/task/harness.rs:461:19
  30: <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
             at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/core/src/panic/unwind_safe.rs:271:9
  31: std::panicking::try::do_call
             at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/panicking.rs:492:40
  32: ___rust_try
  33: std::panicking::try
             at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/panicking.rs:456:19
  34: std::panic::catch_unwind
             at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/panic.rs:137:14
  35: tokio::runtime::task::harness::poll_future
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.14.1/src/runtime/task/harness.rs:449:18
  36: tokio::runtime::task::harness::Harness<T,S>::poll_inner
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.14.1/src/runtime/task/harness.rs:98:27
  37: tokio::runtime::task::harness::Harness<T,S>::poll
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.14.1/src/runtime/task/harness.rs:53:15
  38: tokio::runtime::task::raw::poll
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.14.1/src/runtime/task/raw.rs:113:5
  39: tokio::runtime::task::raw::RawTask::poll
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.14.1/src/runtime/task/raw.rs:70:18
  40: tokio::runtime::task::LocalNotified<S>::run
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.14.1/src/runtime/task/mod.rs:343:9
  41: tokio::runtime::basic_scheduler::Inner<P>::block_on::{{closure}}::{{closure}}
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.14.1/src/runtime/basic_scheduler.rs:297:52
  42: tokio::coop::with_budget::{{closure}}
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.14.1/src/coop.rs:106:9
  43: std::thread::local::LocalKey<T>::try_with
             at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/thread/local.rs:413:16
  44: std::thread::local::LocalKey<T>::with
             at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/thread/local.rs:389:9
  45: tokio::coop::with_budget
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.14.1/src/coop.rs:99:5
  46: tokio::coop::budget
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.14.1/src/coop.rs:76:5
  47: tokio::runtime::basic_scheduler::Inner<P>::block_on::{{closure}}
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.14.1/src/runtime/basic_scheduler.rs:297:29
  48: tokio::runtime::basic_scheduler::enter::{{closure}}
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.14.1/src/runtime/basic_scheduler.rs:349:29
  49: tokio::macros::scoped_tls::ScopedKey<T>::set
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.14.1/src/macros/scoped_tls.rs:61:9
  50: tokio::runtime::basic_scheduler::enter
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.14.1/src/runtime/basic_scheduler.rs:349:5
  51: tokio::runtime::basic_scheduler::Inner<P>::block_on
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.14.1/src/runtime/basic_scheduler.rs:230:9
  52: tokio::runtime::basic_scheduler::InnerGuard<P>::block_on
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.14.1/src/runtime/basic_scheduler.rs:501:9
  53: tokio::runtime::basic_scheduler::BasicScheduler<P>::block_on
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.14.1/src/runtime/basic_scheduler.rs:186:24
  54: tokio::runtime::Runtime::block_on
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.14.1/src/runtime/mod.rs:461:46
  55: happy_path::double_rollover_an_open_cfd
             at ./tests/happy_path.rs:412:5
  56: happy_path::double_rollover_an_open_cfd::{{closure}}
             at ./tests/happy_path.rs:408:7
  57: core::ops::function::FnOnce::call_once
             at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/core/src/ops/function.rs:227:5
  58: core::ops::function::FnOnce::call_once
             at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/core/src/ops/function.rs:227:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
2022-06-21T22:32:32.388208Z TRACE wire: measuring heartbeat pulse
2022-06-21T22:32:34.843965Z ERROR daemon::rollover::protocol: Rollover failed: End of stream while receiving rollover decision from maker order_id=aa0ee60b-6ea3-4101-afc4-4614d8ce3463
2022-06-21T22:32:34.849558Z  WARN model::cfd: Rollover failed: End of stream while receiving rollover decision from maker order_id=aa0ee60b-6ea3-4101-afc4-4614d8ce3463
2022-06-21T22:32:34.883705Z TRACE wire: Sending taker_id=5f6147d246000364ed824a46ffd4b7e661cea0a066506e402213ced844578e53 msg_name="MakerToTaker::Heartbeat"

It does look like we run into the debug_assert in time, but I am not sure that it was this bump https://github.com/itchysats/itchysats/pull/2267 that is causing this...?

time panics when creating the resulting Duration at the subtraction in this line:
https://github.com/itchysats/itchysats/blob/2f31cd76ab51c88ade8bb88aea9eda6b252fa736/model/src/cfd.rs#L1531
This is bad 😅

I can confirm that pinning the time version to =0.3.9 fixes the problem on my branch.

let hours_left = current_settlement_time - now;

can you deterministicly reproduce this? If so, what are the values for current_settlement_time and now?


[mount]Fix copy file range

What problem are we solving?
#4405
How are we solving the problem?
Remove duplicate locks.
How is the PR tested?
local call copy_file_range.
Checks

[ ] I have added unit tests if possible.
[ ] I will add related wiki document changes and link to this PR after merging.

Glad to see this getting attention, but FWIW you can still get a deadlock if the same goroutine acquires a read-lock twice, if some other process calls Lock() in between. See https://pkg.go.dev/sync#RWMutex:

If a goroutine holds a RWMutex for reading and another goroutine might call Lock, no goroutine should expect to be able to acquire a read lock until the initial read lock is released. In particular, this prohibits recursive read locking. This is to ensure that the lock eventually becomes available; a blocked Lock call excludes new readers from acquiring the lock.
In the terminology of the Go memory model, the n'th call to Unlock “synchronizes before” the m'th call to Lock for any n < m, just as for Mutex. For any call to RLock, there exists an n such that the n'th call to Unlock “synchronizes before” that call to RLock, and the corresponding call to RUnlock “synchronizes before” the n+1'th call to Lock.

Glad to see this getting attention, but FWIW you can still get a deadlock if the same goroutine acquires a read-lock twice, if some other process calls Lock() in between. See https://pkg.go.dev/sync#RWMutex:

If a goroutine holds a RWMutex for reading and another goroutine might call Lock, no goroutine should expect to be able to acquire a read lock until the initial read lock is released. In particular, this prohibits recursive read locking. This is to ensure that the lock eventually becomes available; a blocked Lock call excludes new readers from acquiring the lock.
In the terminology of the Go memory model, the n'th call to Unlock “synchronizes before” the m'th call to Lock for any n < m, just as for Mutex. For any call to RLock, there exists an n such that the n'th call to Unlock “synchronizes before” that call to RLock, and the corresponding call to RUnlock “synchronizes before” the n+1'th call to Lock.

This merge request has deleted the second lock on entryLock in the same goroutine

Glad to see this getting attention, but FWIW you can still get a deadlock if the same goroutine acquires a read-lock twice, if some other process calls Lock() in between. See https://pkg.go.dev/sync#RWMutex:

If a goroutine holds a RWMutex for reading and another goroutine might call Lock, no goroutine should expect to be able to acquire a read lock until the initial read lock is released. In particular, this prohibits recursive read locking. This is to ensure that the lock eventually becomes available; a blocked Lock call excludes new readers from acquiring the lock.
In the terminology of the Go memory model, the n'th call to Unlock “synchronizes before” the m'th call to Lock for any n < m, just as for Mutex. For any call to RLock, there exists an n such that the n'th call to Unlock “synchronizes before” that call to RLock, and the corresponding call to RUnlock “synchronizes before” the n+1'th call to Lock.

This merge request has deleted the second lock on entryLock in the same goroutine

Ah, my mistake – I see that the one left is the lock on the file itself, whereas filehandle_read locks the entryLock.


Support parsing APC, DPS, PM and other generic C1 sequences

This adds support for some of the lesser known C1 control codes.
Even xterm only offers limited support here:
http://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-Controls-beginning-with-ESC
This is technically a BC break with the current unstable master, as unsupported control codes no longer end up in the data stream.
Closes #4
Closes #5
Closes #6
Closes #7

Supporting 8 byte C1 codes has been left out intentionally here, see #11.


Inconsistent resource ARN syntax, breaks IAM policy

Describe the bug
Was attempting to create an IAM policy to grant console access to developers who can trigger builds via GitHub commits, found that the resource ARN patterns for Amplify resources are inconsistently applied.
To Reproduce

Using the IAM policy generator, create a policy which grants all Amplify actions on any amplify resource. Produces the following:
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "amplify:CreateApp",
                "amplify:ListApps"
            ],
            "Resource": "*"
        },
        {
            "Sid": "VisualEditor1",
            "Effect": "Allow",
            "Action": "amplify:*",
            "Resource": "arn:aws:amplify:*:*:apps/*/branches/*"
        },
        {
            "Sid": "VisualEditor2",
            "Effect": "Allow",
            "Action": "amplify:*",
            "Resource": [
                "arn:aws:amplify:*:*:apps/*/domains/*",
                "arn:aws:amplify:*:*:apps/*/branches/*/jobs/*"
            ]
        },
        {
            "Sid": "VisualEditor3",
            "Effect": "Allow",
            "Action": "amplify:*",
            "Resource": "arn:aws:amplify:*:*:apps/*"
        }
    ]
}

Create an account role, attach the previously created policy.

Assume the role and load the Amplify console.

Click into an Amplify application. Nothing loads in the list of branches.

Open the browser's JS console and look for 403s, which will look like:
...does not have amplify:ListDomainAssociations on resource: arn:aws:amplify:<REGION>:<ACCOUNT_ID>:/apps/<APP_HASH>/domains

...does not have amplify:ListWebhooks on resource: arn:aws:amplify:<REGION>:<ACCOUNT_ID>:/apps/<APP_HASH>/webhooks

Note the ARN pattern difference (slash prepended to apps):

In the IAM statement, the resource ARNs are arn:aws:amplify:*:*:apps/...
In the 403 message, the resource ARNs are arn:aws:amplify:<REGION>:<ACCOUNT_ID>:/apps/...

Return to primary role

Alter the IAM policy statement to prepend a slash to apps in all resource ARN patterns

Reassume the test role using the policy

Reload the Amplify console. Some items load, but not all.

In the JS console, find 403 messages like:
...does not have amplify:ListBranches on resource: arn:aws:amplify:<REGION>:<ACCOUNT_ID>:apps/<APP_HASH>/branches/*

...does not have arn:aws:amplify:<REGION>:<ACCOUNT_ID>:apps/<APP_HASH>/branches/*

Return to primary role, alter IAM policy to be as follows:
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "amplify:CreateApp",
                "amplify:ListApps"
            ],
            "Resource": "*"
        },
        {
            "Sid": "VisualEditor1",
            "Effect": "Allow",
            "Action": "amplify:*",
            "Resource": [
                "arn:aws:amplify:*:*:/apps/*/branches/*",
                "arn:aws:amplify:*:*:apps/*/branches/*"
            ]
        },
        {
            "Sid": "VisualEditor2",
            "Effect": "Allow",
            "Action": "amplify:*",
            "Resource": [
                "arn:aws:amplify:*:*:/apps/*",
                "arn:aws:amplify:*:*:apps/*"
            ]
        },
        {
            "Sid": "VisualEditor3",
            "Effect": "Allow",
            "Action": "amplify:*",
            "Resource": [
                "arn:aws:amplify:*:*:/apps/*/domains/*",
                "arn:aws:amplify:*:*:apps/*/domains/*",
                "arn:aws:amplify:*:*:/apps/*/branches/*/jobs/*",
                "arn:aws:amplify:*:*:apps/*/branches/*/jobs/*"
            ]
        }
    ]
}

Reassume test role, reload Amplify console--all features appear to be loading.

Expected behavior
Expected the IAM policy creation wizard to produce a policy capable of granting access to all Amplify actions and resources.
Additional context
Looks like there are some inconsistent resource ARN patterns in the codebase or in IAM, no idea how that all shakes out. Presumably need to standardize on whether or not to use a leading slash before apps in the pattern.
Sample code
I think it's pretty clear from the repro, but @ me if you need info.

Thanks for reporting the bug. The fix is on the way

What's the canonical pattern for the ARNs? /app or app?

arn:aws:amplify::<ACCOUNT_ID>:apps/* is the valid Arn format for our service

@nballenger we have pushed a fix. Can you please verify?

Created a new policy via the policy wizard to enable all Amplify actions
Attached to a testing role with no other permissions
Assumed the role and viewed the Amplify console

Looks like the policy gives access to everything. Thanks for the fix, I've updated my existing roles / groups to use the new policy. Leaving the issue open because I don't want to interfere with whatever your internal process is, but feel free to close--nothing further needed on my end.


Handle intermittent Wi-Fi connection in weather.py

I find that the program will run for a long period - several hours - and then get stuck trying to get more data.  I think it loses its Wi-Fi connection (for whatever reason) and doesn't recover.  After waking up, could it check for its connection and try to reconnect if required?
Thanks,
David

Are there any warning messages displayed on the screen?
I had experienced intermittent failures which were due to the script failing to handle missing data which sometimes get pushed through the API. The current version of the code should correct this. Could you @gm8arv confirm if you are working with the most recent version?

I'm using the version from 8-July-2023 nd I'm unsure what may have changed.  I have modified it to add the NTP code, and display the most recent check for update time.  I added a led-on/led-off pair around the get_data()..get_data_airquality() sequence,   When the program stops, it's with the LED lit.  OK, that's not much use, but it's something.  I'll attach my version.
main.py.txt
David

I also meant to mention that in the NTP code I changed the timeout from 1 second to 4 seconds, which seemed more reasonable to me.  But I could not find a way to change the timeout for the urequests.get().

Someone suggested that I could add a timeout this way:
r = urequests.get(URL, timeout=5)

Tested and the program seems less likely to hang.  The default timeout is infinite (I was told) so the program would hang indefinitely in the case of an Internet or Wi-Fi issue.  With the timeout the program continues and displays older data.  The "Updated" field (and my NTP "Run at" field)  show the program activity.
David

I'm running v0.02 but had the same issue as David with all versions when running on battery power (I hadn't noticed the same issue on USB power...but that might be because I didn't run it for an extended period via USB).
Visual symptoms seem variable, but a couple of example screenshots are attached. The longest I could run the app was for about 4 hours. At first I thought it might be the supplied AAA batteries, but after putting in Energizer Lithium Ultras in, I noticed voltage levels were at 3.6V so maybe it's not battery related. I then made a couple of changes to the code (sadly concurrently) and it's now been running for over 14 hours without a problem. I'm not sure whether some of the changes were spurious...but something is making it behave more stably after recovering from its deep sleep. The changes are:

I added a line to set the CPU speed after the import statements
badger2040.system_speed(badger2040.SYSTEM_TURBO)

Added a wait at the start of get_data() (you need to import time as well at the start of the code)
    time.sleep(5)

Added a sleep statement after connecting to WiFi

print("connecting")
display.connect()

time.sleep(1)
get_data()
get_data_airquality()

So I got a 'WiFi client failed' error message after 17 hours. Better than before...but still not right!

I'm seeing better results now, still not perfect, but I noticed that a Galleon LiPo battery I had velcroed to the back of the Badger was obscuring the Wi_Fi antenna located opposite the USB end of the Pico - the apparently "blank" area on the PCB.  Since removing that battery (I'm powering off USB for now) things have been better, but not 100% reliable.
David


Issue with Flux Training, Tensor Size Mismatch

Flux .toml config:

# Output path for training runs. Each training run makes a new directory in here.
output_dir = '/workspace/ComfyUI/models/loras/flux'

# Dataset config file.
dataset = 'examples/dataset.toml'
# You can have separate eval datasets. Give them a name for Tensorboard metrics.
# eval_datasets = [
#     {name = 'something', config = 'path/to/eval_dataset.toml'},
# ]

# training settings

# I usually set this to a really high value because I don't know how long I want to train.
epochs = 1000
# Batch size of a single forward/backward pass for one GPU.
micro_batch_size_per_gpu = 1
# Pipeline parallelism degree. A single instance of the model is divided across this many GPUs.
pipeline_stages = 1
# Number of micro-batches sent through the pipeline for each training step.
# If pipeline_stages > 1, a higher GAS means better GPU utilization due to smaller pipeline bubbles (where GPUs aren't overlapping computation).
gradient_accumulation_steps = 4
# Grad norm clipping.
gradient_clipping = 1.0
# Learning rate warmup.
warmup_steps = 100

# eval settings

eval_every_n_epochs = 1
eval_before_first_step = true
# Might want to set these lower for eval so that less images get dropped (eval dataset size is usually much smaller than training set).
# Each size bucket of images/videos is rounded down to the nearest multiple of the global batch size, so higher global batch size means
# more dropped images. Usually doesn't matter for training but the eval set is much smaller so it can matter.
eval_micro_batch_size_per_gpu = 1
eval_gradient_accumulation_steps = 1

# misc settings

# Probably want to set this a bit higher if you have a smaller dataset so you don't end up with a million saved models.
save_every_n_epochs = 1
# Can checkpoint the training state every n number of epochs or minutes. Set only one of these. You can resume from checkpoints using the --resume_from_checkpoint flag.
#checkpoint_every_n_epochs = 1
checkpoint_every_n_minutes = 120
# Always set to true unless you have a huge amount of VRAM.
activation_checkpointing = true
# Controls how Deepspeed decides how to divide layers across GPUs. Probably don't change this.
partition_method = 'parameters'
# dtype for saving the LoRA or model, if different from training dtype
save_dtype = 'bfloat16'
# Batch size for caching latents and text embeddings. Increasing can lead to higher GPU utilization during caching phase but uses more memory.
caching_batch_size = 1
# How often deepspeed logs to console.
steps_per_print = 1
# How to extract video clips for training from a single input video file.
# The video file is first assigned to one of the configured frame buckets, but then we must extract one or more clips of exactly the right
# number of frames for that bucket.
# single_beginning: one clip starting at the beginning of the video
# single_middle: one clip from the middle of the video (cutting off the start and end equally)
# multiple_overlapping: extract the minimum number of clips to cover the full range of the video. They might overlap some.
# default is single_middle
video_clip_mode = 'single_middle'

# [model]
# # flux, ltx-video, or hunyuan-video
# type = 'hunyuan-video'
# # Can load Hunyuan Video entirely from the ckpt path set up for the official inference scripts.
# #ckpt_path = '/home/anon/HunyuanVideo/ckpts'
# # Or you can load it by pointing to all the ComfyUI files.
# transformer_path = '/data2/imagegen_models/hunyuan_video_comfyui/hunyuan_video_720_cfgdistill_fp8_e4m3fn.safetensors'
# vae_path = '/data2/imagegen_models/hunyuan_video_comfyui/hunyuan_video_vae_bf16.safetensors'
# llm_path = '/data2/imagegen_models/hunyuan_video_comfyui/llava-llama-3-8b-text-encoder-tokenizer'
# clip_path = '/data2/imagegen_models/hunyuan_video_comfyui/clip-vit-large-patch14'
# # Base dtype used for all models.
# dtype = 'bfloat16'
# # Hunyuan Video supports fp8 for the transformer when training LoRA.
# transformer_dtype = 'float8'
# # How to sample timesteps to train on. Can be logit_normal or uniform.
# timestep_sample_method = 'logit_normal'

# flux example
[model]
type = 'flux'
# Path to Huggingface Diffusers directory for Flux
diffusers_path = '/workspace/diffusion-pipe/FLUX.1-dev'
# You can override the transformer from a BFL format checkpoint.
transformer = '/workspace/diffusion-pipe/FLUX.1-dev/flux1-dev.safetensors'
dtype = 'bfloat16'
flux_shift = true

# LTV-Video example
# [model]
# type = 'ltx-video'
# diffusers_path = '/data2/imagegen_models/LTX-Video'
# dtype = 'bfloat16'
# timestep_sample_method = 'logit_normal'

[adapter]
type = 'lora'
rank = 32
# Dtype for the LoRA weights you are training.
dtype = 'bfloat16'
# You can initialize the lora weights from a previously trained lora.
#init_from_existing = '/data/diffusion_pipe_training_runs/something/epoch50'

[optimizer]
# AdamW from the optimi library is a good default since it automatically uses Kahan summation when training bfloat16 weights.
# Look at train.py for other options. You could also easily edit the file and add your own.
type = 'adamw8bit'
lr = 1e-4
betas = [0.9, 0.99]
weight_decay = 0.01
eps = 1e-8

_________________________________________________________________________________________________

Error Log:
[2024-12-28 14:23:45,277] [INFO] [config.py:1003:print]   zero_config .................. stage=0 contiguous_gradients=True reduce_scatter=True reduce_bucket_size=500000000 use_multi_rank_bucket_allreduce=True allgather_partitions=True allgather_bucket_size=500000000 overlap_comm=False load_from_fp32_weights=True elastic_checkpoint=False offload_param=None offload_optimizer=None sub_group_size=1000000000 cpu_offload_param=None cpu_offload_use_pin_memory=None cpu_offload=None prefetch_bucket_size=50000000 param_persistence_threshold=100000 model_persistence_threshold=9223372036854775807 max_live_parameters=1000000000 max_reuse_distance=1000000000 gather_16bit_weights_on_model_save=False module_granularity_threshold=0 use_all_reduce_for_fetch_params=False stage3_gather_fp16_weights_on_model_save=False ignore_unused_parameters=True legacy_stage1=False round_robin_gradients=False zero_hpz_partition_size=1 zero_quantized_weights=False zero_quantized_nontrainable_weights=False zero_quantized_gradients=False zeropp_loco_param=None mics_shard_size=-1 mics_hierarchical_params_gather=False memory_efficient_linear=True pipeline_loading_checkpoint=False override_module_apply=True
[2024-12-28 14:23:45,277] [INFO] [config.py:1003:print]   zero_enabled ................. False
[2024-12-28 14:23:45,277] [INFO] [config.py:1003:print]   zero_force_ds_cpu_optimizer .. True
[2024-12-28 14:23:45,277] [INFO] [config.py:1003:print]   zero_optimization_stage ...... 0
[2024-12-28 14:23:45,277] [INFO] [config.py:989:print_user_config]   json = {
    "train_micro_batch_size_per_gpu": 1,
    "gradient_accumulation_steps": 4,
    "gradient_clipping": 1.0,
    "steps_per_print": 1
}
[2024-12-28 14:23:45,277] [INFO] [engine.py:105:__init__] CONFIG: micro_batches=4 micro_batch_size=1
[2024-12-28 14:23:45,277] [INFO] [engine.py:146:__init__] is_pipe_partitioned= False is_grad_partitioned= False
[2024-12-28 14:23:45,324] [INFO] [engine.py:165:__init__] RANK=0 STAGE=0 LAYERS=60 [0, 60) STAGE_PARAMS=171935744 (171.936M) TOTAL_PARAMS=171935744 (171.936M) UNIQUE_PARAMS=171935744 (171.936M)
[rank0]: Traceback (most recent call last):
[rank0]:   File "/workspace/diffusion-pipe/train.py", line 458, in <module>
[rank0]:     loss = model_engine.train_batch().item()
[rank0]:            ^^^^^^^^^^^^^^^^^^^^^^^^^^
[rank0]:   File "/workspace/diffusion-pipe/venv/lib/python3.11/site-packages/deepspeed/runtime/pipe/engine.py", line 389, in train_batch
[rank0]:     self._exec_schedule(sched)
[rank0]:   File "/workspace/diffusion-pipe/venv/lib/python3.11/site-packages/deepspeed/runtime/pipe/engine.py", line 1422, in _exec_schedule
[rank0]:     self._exec_instr(**cmd.kwargs)
[rank0]:   File "/workspace/diffusion-pipe/venv/lib/python3.11/site-packages/deepspeed/runtime/pipe/engine.py", line 735, in _exec_forward_pass
[rank0]:     outputs = super().forward(inputs)
[rank0]:               ^^^^^^^^^^^^^^^^^^^^^^^
[rank0]:   File "/workspace/diffusion-pipe/venv/lib/python3.11/site-packages/deepspeed/utils/nvtx.py", line 18, in wrapped_fn
[rank0]:     ret_val = func(*args, **kwargs)
[rank0]:               ^^^^^^^^^^^^^^^^^^^^^
[rank0]:   File "/workspace/diffusion-pipe/venv/lib/python3.11/site-packages/deepspeed/runtime/engine.py", line 1914, in forward
[rank0]:     loss = self.module(*inputs, **kwargs)
[rank0]:            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[rank0]:   File "/workspace/diffusion-pipe/venv/lib/python3.11/site-packages/torch/nn/modules/module.py", line 1553, in _wrapped_call_impl
[rank0]:     return self._call_impl(*args, **kwargs)
[rank0]:            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[rank0]:   File "/workspace/diffusion-pipe/venv/lib/python3.11/site-packages/torch/nn/modules/module.py", line 1562, in _call_impl
[rank0]:     return forward_call(*args, **kwargs)
[rank0]:            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[rank0]:   File "/workspace/diffusion-pipe/venv/lib/python3.11/site-packages/deepspeed/runtime/pipe/module.py", line 386, in forward
[rank0]:     x = self.activation_checkpoint_func(exec_range_func(start_idx, end_idx), *x)
[rank0]:         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[rank0]:   File "/workspace/diffusion-pipe/venv/lib/python3.11/site-packages/torch/_dynamo/eval_frame.py", line 600, in _fn
[rank0]:     return fn(*args, **kwargs)
[rank0]:            ^^^^^^^^^^^^^^^^^^^
[rank0]:   File "/workspace/diffusion-pipe/venv/lib/python3.11/site-packages/deepspeed/runtime/activation_checkpointing/checkpointing.py", line 953, in checkpoint
[rank0]:     CheckpointFunction.apply(function, all_outputs, *args)
[rank0]:   File "/workspace/diffusion-pipe/venv/lib/python3.11/site-packages/torch/autograd/function.py", line 574, in apply
[rank0]:     return super().apply(*args, **kwargs)  # type: ignore[misc]
[rank0]:            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[rank0]:   File "/workspace/diffusion-pipe/venv/lib/python3.11/site-packages/deepspeed/runtime/activation_checkpointing/checkpointing.py", line 544, in forward
[rank0]:     outputs = run_function(*inputs_cuda)
[rank0]:               ^^^^^^^^^^^^^^^^^^^^^^^^^^
[rank0]:   File "/workspace/diffusion-pipe/venv/lib/python3.11/site-packages/deepspeed/runtime/pipe/module.py", line 363, in exec_func
[rank0]:     inputs = layer(inputs)
[rank0]:              ^^^^^^^^^^^^^
[rank0]:   File "/workspace/diffusion-pipe/venv/lib/python3.11/site-packages/torch/nn/modules/module.py", line 1553, in _wrapped_call_impl
[rank0]:     return self._call_impl(*args, **kwargs)
[rank0]:            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[rank0]:   File "/workspace/diffusion-pipe/venv/lib/python3.11/site-packages/torch/nn/modules/module.py", line 1562, in _call_impl
[rank0]:     return forward_call(*args, **kwargs)
[rank0]:            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[rank0]:   File "/workspace/diffusion-pipe/venv/lib/python3.11/site-packages/torch/amp/autocast_mode.py", line 43, in decorate_autocast
[rank0]:     return func(*args, **kwargs)
[rank0]:            ^^^^^^^^^^^^^^^^^^^^^
[rank0]:   File "/workspace/diffusion-pipe/models/flux.py", line 321, in forward
[rank0]:     encoder_hidden_states, hidden_states = self.block(
[rank0]:                                            ^^^^^^^^^^^
[rank0]:   File "/workspace/diffusion-pipe/venv/lib/python3.11/site-packages/torch/nn/modules/module.py", line 1553, in _wrapped_call_impl
[rank0]:     return self._call_impl(*args, **kwargs)
[rank0]:            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[rank0]:   File "/workspace/diffusion-pipe/venv/lib/python3.11/site-packages/torch/nn/modules/module.py", line 1562, in _call_impl
[rank0]:     return forward_call(*args, **kwargs)
[rank0]:            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[rank0]:   File "/workspace/diffusion-pipe/venv/lib/python3.11/site-packages/diffusers/models/transformers/transformer_flux.py", line 180, in forward
[rank0]:     attention_outputs = self.attn(
[rank0]:                         ^^^^^^^^^^
[rank0]:   File "/workspace/diffusion-pipe/venv/lib/python3.11/site-packages/torch/nn/modules/module.py", line 1553, in _wrapped_call_impl
[rank0]:     return self._call_impl(*args, **kwargs)
[rank0]:            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[rank0]:   File "/workspace/diffusion-pipe/venv/lib/python3.11/site-packages/torch/nn/modules/module.py", line 1562, in _call_impl
[rank0]:     return forward_call(*args, **kwargs)
[rank0]:            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[rank0]:   File "/workspace/diffusion-pipe/venv/lib/python3.11/site-packages/diffusers/models/attention_processor.py", line 588, in forward
[rank0]:     return self.processor(
[rank0]:            ^^^^^^^^^^^^^^^
[rank0]:   File "/workspace/diffusion-pipe/venv/lib/python3.11/site-packages/diffusers/models/attention_processor.py", line 2318, in __call__
[rank0]:     query = apply_rotary_emb(query, image_rotary_emb)
[rank0]:             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[rank0]:   File "/workspace/diffusion-pipe/venv/lib/python3.11/site-packages/diffusers/models/embeddings.py", line 1208, in apply_rotary_emb
[rank0]:     out = (x.float() * cos + x_rotated.float() * sin).to(x.dtype)
[rank0]:            ~~~~~~~~~~^~~~~
[rank0]: RuntimeError: The size of tensor a (4608) must match the size of tensor b (16896) at non-singleton dimension 2
[2024-12-28 14:23:58,874] [INFO] [launch.py:319:sigkill_handler] Killing subprocess 7470
[2024-12-28 14:23:58,875] [ERROR] [launch.py:325:sigkill_handler] ['/workspace/diffusion-pipe/venv/bin/python', '-u', 'train.py', '--local_rank=0', '--deepspeed', '--config', 'examples/hunyuan_video.toml'] exits with return code = 1

Should be fixed by 5b9c0be.

Confirmed it's working, thanks! Amazing tool, appreciate all your work.


⚠ ESPN has degraded performance

In c27d7f8, ESPN (https://espn.com) experienced degraded performance:

HTTP code: 200
Response time: 811 ms

Resolved: ESPN performance has improved in 42bc1b4.


Fix defaults for Blackfriday

fixes #866

It doesn't work.
I still have to add fractions = true to get fractions.

Hi @bep (oh, new GitHub handle!),
Actually, even before @naoina's refactoring, the old code
viper.SetDefault("Blackfriday", map[string]bool{
    "angledQuotes": false,
    "fractions": true,
    "plainIdAnchors": false})

as found in eb686352b1785844778e1cba8c69b85079e3044f did not work for me either,
and that is why I had to push a follow-up commit f6c0b472e9f54fa3e0d2695a8cffe343f9112244 to workaround that, but I do feel that it was a kludge and not the real solution.
Apparently, for some reasons, viper.SetDefault() isn't working for "Blackfriday"... not working for maps, perhaps?

Aha, I see. OK.
(yes, new GitHub handle - bep is my initials and my first choice for usernames. It was taken back then, it was taken now -- but was a dusty account with no activity, so I asked GitHub to delete that account).


Hello World fails

Hello. Great library!
All other examples work (osx x64), but vips.Image.text fails.
-- make a new image with some text rendered on it
image = vips.Image.text("Hello World!", {dpi = 300})
error: 'no such operation
VipsOperation: class "text" not found
'
./configure --prefix=/Users/pasi/installed/C/vips/build --disable-dependency-tracking --enable-shared --disable-static --without-python --without-pangoft2 --without-libwebp --without-radiance --without-matio --without-openslide --without-poppler --without-OpenEXR --without-magick --without-gsf
--with-giflib-includes=/usr/local/Cellar/giflib/5.1.4/include --with-giflib-libraries=/usr/local/Cellar/giflib/5.1.4/lib
--with-jpeg-includes=/usr/local/Cellar/jpeg/8d/include --with-jpeg-libraries=/usr/local/Cellar/jpeg/8d/lib

Hello, vips uses pangoft2 to render text, so you need to enable that.
The brew vips should work, I think.

Thanks, I realized that too.
Tool to change loader paths (huge job by hand): https://github.com/auriamg/macdylibbundler

I changed Settings.cpp #63 to std::string inside_path_str = "@loader_path/";

You shouldn't need to change loader paths. I tried here and it all works fine:
brew install lua
brew install luajit
brew install vips
luarocks --local install lua-vips
eval `luarocks path`

Then:
$ luajit
LuaJIT 2.0.5 -- Copyright (C) 2005-2017 Mike Pall. http://luajit.org/
JIT: ON CMOV SSE2 SSE3 SSE4.1 fold cse dce fwd dse narrow loop abc sink fuse
>  vips = require "vips"
> x = vips.Image.text("hello world")
> x:write_to_file("x.png")
> ^D
$ open x.png

And I can see a "hello world" image.

I don't use luarocks for client installation. I have all libs in my own folder (mac32/64 + linux64/arm + win 32/64). Would be nice to have 32 bit win libraries, compiling them in paiful and non-productive work.

There are some old win32 builds here:
http://www.vips.ecs.soton.ac.uk/supported/8.1/win32/
But they might be too old.
Did you get it working with luajit on win64? I've not tried that myself.


Commenting solution

Hello!
I know this goes somewhat against the philosophy of Chronoblog, still I need a commenting solution for posts.
After looking at various solutions, I tried Disqus with no success.
Did try:

Gatsby Plugin Disqus
disqus-react
And this solution from Janosh

Seems that there are no easy solutions to implement Disqus on Markdown pages/posts.
I could use another commenting system if that could work with Chronoblog.
Any ideas?
François Meehan

Hi.
I recently made an example of how it is possible to use Disqus in Chronoblog: https://github.com/Chronoblog/gatsby-starter-chronoblog-disqus
An example post with comments: https://chronoblog-disqus.now.sh/small-blog-post
Description of how this works in the documentation: https://github.com/Chronoblog/gatsby-theme-chronoblog#get-post-data-in-post-footer
I do not use commenting systems, because of this, maybe I missed something, or something may not work as it should. Try these solutions and write whether it turned out.
All this will work only in the version of Chronoblog v0.18.0 or higher.

Thanks Ivan!
Did the update to v0.18.0 and applied changes to post-footer.mdx and gatsby-config.js.
Gatsby starts without error until trying to open a post at which point I get:
> TypeError: Cannot read property 'fields' of undefined MDXContent
> src/gatsby-theme-chronoblog/post-footer.mdx:28
>   25 | <AuthorBanner mdxType="AuthorBanner"></AuthorBanner>
>   26 | <p> </p>
>   27 | <Disqus config={{
> > 28 |   url: props.siteMetadata.siteUrl + props.postData.fields.slug,
>   29 |   title: props.postData.frontmatter.title,
>   30 |   id: props.postData.id
>   31 | }} mdxType="Disqus" />

Any ideas?
Thanks in advance,
François

Where do you get the Disqus component? Is this a plugin https://github.com/tterb/gatsby-plugin-disqus?
And I don’t really understand what mdxType = "Disqus" does.

Hi,
That is the one that I installed.
I have installed gatsby-starter-chronoblog-disqus  on a separate instance and it works perfectly.
For now I will move over my content and config to the new starter, that will give me the chance to do a good spring cleaning.
And for the record, I was using Justcomments. Unfortunately this solutions is not viable anymore as the developer sent this message:

JustComments does not accept new customers. JustComments will shut down by the end of 2020. Read more in our blog.

Thanks for the prompt response, I hope everything health wise is ok for you and family in Moscow.
All the best!
François


Run the converted tests as part of automated builds

Run the tests (from https://github.com/application-stacks/runtime-component-operator/issues/178) as part of the automated Travis builds

Travis (new location): https://app.travis-ci.com/github/application-stacks/runtime-component-operator/branches


#132 #133

Appears to solve these issues and needs further testing by reporters.
Also adds fast load in console.

Although this says it passed the AppVeyor test, it failed miserably. Back to the drawing board.


[Bug] 申请证书失败

[2024-10-25 15:24:22]
开始检查
[2024-10-25 15:24:22]
获取记录成功
[2024-10-25 15:24:22]
检查通过
[2024-10-25 15:24:22]
开始申请
[2024-10-25 15:24:23]
申请证书失败
get directory at 'https://acme-v02.api.letsencrypt.org/directory': Get "https://acme-v02.api.letsencrypt.org/directory": tls: failed to verify certificate: x509: certificate signed by unknown authority

https://github.com/go-acme/lego/issues/239
和这个是同一个问题，可参考一下

@usual2970 非常感谢，已处理


Dropped cheggaaa/pb for muesli/goprogressbar

I hope this doesn't come across as me having a bit of an NIH-syndrome.
I do find the original pb implementation a bit overly complicated and lacking though. I would encourage everyone to give this version a spin and compare the looks / behaviour of the two different progress-bars.
The only downside is goprogressbar assuming ANSI support on Windows, which only recently returned in Windows 10. pb is supposed to behave a bit nicer there, but I ran into various issues with it there, too (this may or may not be fixed by now, I don't have a Windows machine to test this right now). I will promise to look into this in the next few days, though.

I've also introduced a bit of consistency in the audit's output's lingo.

I can rebase / squash that if you want - unless you're already on it. Just let me know!

@muesli Please rebase.

@dominikschulz Done!

@dominikschulz Now we're good to merge!

Awesome, thank you.


Rework detection of gear source/origin

Shortcommings of current system (marked = solved):

[x] relies on item name and is dependent on english client
[x] some items are not detected correctly (635 SCH weapon for example)
[x] needs manual work on game updates
[x] can become inconsistent with other curated data

Done in 7152ee0528e1a04bc120bd82132760d0de9efaf7


Banner about the upcoming TLS 1.2 enforcement

Added variable with the background color and put it in all places the verbatim value was used.

https://devblogs.microsoft.com/nuget/nuget-org-will-permanently-remove-support-for-tls-1-0-and-1-1-on-june-15th/
Let's align with the blog: "NuGet.org will permanently remove support for TLS 1.0 and 1.1 on June 15th. Please ensure that your systems use TLS 1.2."

@skofman1, done.


nav-bar-buttons not working properly sometimes when switching between states

when I switch between different states, the ng-click actions on the nav-bar-buttons sometimes dont get associated with the respective functions in the state scope.
I am suspecting that this is happening because the ion-nav-bar buttons are outside of the ion-view.
inside the view all the click handlers are associated without problems, but the nav-bar-buttons are dead.
is this a known bug?

Greetings @Freundschaft!
My sensors indicate that you need to update your issue through our custom issue form. We are now requiring all issues to be submitted this way, to ensure that we have all of the information necessary to fix them as quickly as possible.
Click Here To Update Your Issue
I will have no choice but to close this issue if it is not resubmitted through the form. Please fill out the rest of the form, so that I may use my friendly robot powers to assist you.
Thank you!


Dockerfile: upgrade docker/dockerfile to 1.4

Upgrade docker/dockerfile to 1.4.

https://github.com/moby/buildkit/releases/tag/dockerfile%2F1.4.0

cc: @lambdalisue

Thanks a lot 🎉


Cannot authenticate

I'm attempting to set this up in Windows using WSL on Traktor 3.10. I am able to stand up the project using the provided docker image, and get the expected JSON response when navigating to https://api.beatport.com/v4/catalog/genres/ in the browser (other endpoints that don't require some dynamic id also work), as suggested in the README. I've also added the generated cert to the Windows cert store, edited the hosts file and have verified that there are no SSL issues/warnings:

However, when I attempt to authenticate in Traktor (this is after flushing DNS and even a restart), I get this error:

and here are the associated logs as output by docker compose:
traktor-streaming-proxy-traktor-1  | 392767 [eventLoopGroupProxy-4-13] INFO ktor.application  - 302 Found: GET - /v4/auth/o/authorize/ in 0ms -> traktor://bp_oauth?code=foo
traktor-streaming-proxy-traktor-1  | 397384 [eventLoopGroupProxy-4-14] INFO ktor.application  - 200 OK: GET - /v4/auth/logout/ in 0ms

Using fiddler, I see these requests:
GET https://api.beatport.com/v4/auth/o/authorize/?client_id=bNGKE97x70L0C5hyv5gsnpQHo9EYR5aA2RQPlbsL&response_type=code&redirect_uri=traktor://bp_oauth
302 Redirect to traktor://bp_oauth?code=foo

GET https://api.beatport.com/v4/auth/logout/
200 OK ()

matching the logs. I cleared all cookies from my browser (Firefox) just in case, with the same result.
Here is my docker-compose.yml:
services:
  traktor:
    image: ghcr.io/0xf4b1/traktor-streaming-proxy:v0.3-amd64
    build:
      context: .
      dockerfile: Dockerfile
    volumes:
      - ./server.crt:/app/cert/server.crt
      - ./server.key:/app/cert/server.key
      - ./config.properties:/app/config.properties
      - ./license:/app/license
    ports:
      - "443:443"
    init: true

and config.properties:
#
#Fri Sep 29 03:37:37 GMT 2023
beatport.accountId=1337338
spotify.password=<redacted>
spotify.username=<redacted>
tidal.countryCode=foo
tidal.userId=1337
tidal.clientId=foo
tidal.accessToken=foo
tidal.refreshToken=foo

Other things I've tried:

logging in with my actual Beatport subscription, the editing my hosts file, and then attempting to connect. In that case I can see Beatport in the Traktor interface, but I could not get a listing of any of the categories despite the endpoint being accessible as shown above.
rebuilding the image locally with all Tidal related features scrubbed, which I figured I'd try after having some issues (see #12) with Tidal, despite the fact that your solution there worked (this is why it's not listed in the screenshot above, but results were the same with the pre-built image)

Thanks again for putting this out there, and again awesome project! I've never developed anything with Kotlin but it seems like a great choice for this based on the terseness of the code. Please let me know if I can provide any other details. My hunch is that either I'm doing something wrong (likely!) or maybe the fairly recent Traktor 3.10 update has changed the auth flow in some way.

Hey, I've tried to set it up on Windows, but also couldn't get it to work yet. I think there might be a problem with trusting the certificate. When trying to curl  https://api.beatport.com/v4/catalog/genres/ with having added the root CA certificate ca.pem to the trust store, the following error occurs:
curl: (35) schannel: next InitializeSecurityContext failed: Unknown error (0x80092012) - The revocation function was unable to check revocation for the certificate.
But it works fine in the browser, so when trying to login, Traktor opens the browser to /v4/auth/o/authorize/ and gets the redirect, as we see in the log. But then Traktor itself should send the post /v4/auth/o/token/, but we don't see this in the logs, so I think the connection cannot be established most likely because of the cert error. Then it only fails with the logout, again via the browser.
I tried to address this check for revocation of the certificate but couldn't find a solution yet.

I made some partial progress by tweaking gen-cert.sh to generate a standalone cert that I imported in Windows into "Trusted Root Certification Authorities" instead of "Personal".
Here's the modified script:
#!/bin/bash

set -e

openssl req -x509 -new -nodes -newkey rsa:4096 -keyout server.key -out server.crt -days 365 -subj "/CN=api.beatport.com" -extensions SAN -config <(cat << EOF
[req]
distinguished_name=req
[SAN]
subjectAltName=DNS:api.beatport.com
EOF
)

New error:

New logs:
traktor-streaming-proxy-traktor-1  | 276066 [eventLoopGroupProxy-4-9] INFO ktor.application  - 302 Found: GET - /v4/auth/o/authorize/ in 1ms -> traktor://bp_oauth?code=foo
traktor-streaming-proxy-traktor-1  | 276284 [eventLoopGroupProxy-4-10] INFO ktor.application  - 200 OK: POST - /v4/auth/o/token/ in 0ms
traktor-streaming-proxy-traktor-1  | 276297 [eventLoopGroupProxy-4-11] INFO ktor.application  - 200 OK: GET - /v4/my/account/ in 1ms
traktor-streaming-proxy-traktor-1  | 276310 [eventLoopGroupProxy-4-12] INFO ktor.application  - 200 OK: GET - /v4/my/license/ in 0ms
traktor-streaming-proxy-traktor-1  | 277833 [eventLoopGroupProxy-4-13] INFO ktor.application  - 200 OK: GET - /v4/auth/logout/ in 0ms

Thanks for finding out the trick with the cert, now I also got to the license error. It seems Traktor on macOS and Windows uses different client ids and client certificates, that's why the signature verification fails. The license file is generated for the application public key from the macOS version:
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA5otUtjLv5LJmLK+Lw+TI
UzrX0j3UP493K8T2dzqE/tLMVvOvNOwUDvzomX0VpTZrXesLFpCrztdMG5p2I4M0
jTVTl6cpU8SD68WUjqlvLUYCHIGub4okQK57f5d4iTagU9FjyB2VwfA3nuuhhEpj
4ioQuYR8ENhMiMNMydITsXCFEbRgxpDRvIj24+/QthsOETtu2Ooq4U+pvidQPu5l
rcZdgemPUFPtTn4GqQ0/wZpaD2mzMlLUi4xlqcGo0LsCtTkPtAhSWxWrl+ReKj+k
9zJCK8qzeYUPf/fuA5I7owuyRrfN6ReiFdU/UF38Ou6pSrRCvVkQkmpTmv8kEnvn
RwIDAQAB
-----END PUBLIC KEY-----

and windows uses this key:
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAozFFb+t0RSB1AdDBwap+
dZ/8AH/FseqpSkG8oW3rzonQ/jEMtsY6AJogv+HfFclnrVlx1aYyJvQXIwIBx+Sk
E5J+YTdUKYlLX62xL44TQLDOw1varMnxWfCX4ih5taXDWacu1HemI+peRtsi8r9m
FVCBMFuFVOCv9vGL8H4L/12GTO0+rIIpBZr11pQ/K44WFyr9GOVx/GTeDH52Ktlx
CgOMADfgdH9hjLryS+EN/LL/yg1bw7OF9UmpZGzUaTjn1qYErlq5bqlDcBFSdo6v
b5v74acNV8Qjbov8okSoUd13A6JJkJp4Sxi/Ve07DTvPZHGIZn01nVpLX9tkDRcT
2wIDAQAB
-----END PUBLIC KEY-----

To forge a proper windows license, we need to dump the private key from the binary.
As a quick workaround, I've generated another license.txt file, this contains the payload encrypted with the public key of the windows binary and is signed with the key of the macOS binary. When patching the windows binary with e.g. hxd and replacing the above public key with the public key of the macOS binary, it passes the signature check and successfully decrypts the payload with the private key of the windows binary. This way I got it working on windows now :)

Nice! I've been able to replicate your steps, thank you!

Fyi, this is probably separate but I can't list playlists with the spotify source. I'm guessing that this isn't implemented since logs show requests to /v4/my/playlists/, which doesn't have a handler.
Thanks again!

Happy to hear that it works now :)
Yeah that's right, playlists are not yet handled, but this will be added soon. At the moment, saved tracks, release radar and searching should work.

Hi!!! Can you help me with a tutorial for WIN10? I love your project!!! I search info to modify something of your project with no exit. :)

Hey, you can try to follow the steps provided in the readme. If you have docker on your system, the differences are you need the certificate generated as stated here and trusted on your system, and unfortunately the Traktor binary modified with the other public key and use the license file as written in this issue.


Socket sending half JSON

When subscribed to stream sources the JSONAPI is sending objects over multiple socket messages (packages?). This leads to JSON.parse freaking out and throwing errors.
this._socket.on("data", val => {
      let arr = val.toString().trim().split("\r\n");
      // log entry...

      arr.forEach((json, i) => {
          // log i/arr.length

          try{
              let data = JSON.parse(json);
          }catch(err){
              // log error
          }
      })
})

This is expected because it is a normal TCP socket. You will need to gather all received messages in a buffer and look for \r\n. That is how you know a complete message has been received. Multiple messages can also come concatenated in one TCP packet, so you will also need to expect that.
If you don't want to handle all this yourself, it's probably easier to connect to the WebSocket, which handles all of this for you using its protocol.


How to set empty key of social links and only show label icons on sidebar (如何设置侧边栏不显示社交链接名, 只显示图标)

How to show only social icons without the name of the social link on the sidebar, e.g., only show Facebook icon, without the name "Facebook" on the sidebar? (How to set empty key value for social links name?)
如何设置侧边栏上不显示社交链接网站的名字, 只要图标, 比如只要 Facebook 的图标, 而不要显示 "Facebook" +  Facebook 图标?

you can change  sidebar.swig
 {{ name }}

to

Need to add switch option here.

@zhuzhuyule Then how to set the _config.yml?

@wendingp for now with standart metods it is not possible. You may use decision by @zhuzhuyule and it must work fine.

@wendingp alright, check PART 3 in #1697 pull, there is needed by you option.

@wendingp if you modify  the sidebar.swig file, don't about _config.yml.
Suggest:

revert sidebar.swig
then  update theme 'NexT'
Modify _config.yml

social_icons:
  enable: true
  icons_only: true
  transition: false

like PART 3 in  #1697 pull


fix(failover): prevent double failover in case of lost connectivity

This patch ensures the operator does not trigger two failovers when a primary Pod loses connectivity and fails to recognize its role change from primary to replica.
Previously, the first failover occurred when the operator detected that the primary Pod was no longer ready or present. A second failover could be triggered if the old primary Pod recovered before the Kubelet timeout, with the operator potentially promoting it to primary again based on the Pod list.
With this patch, the operator will wait for the recovered Pod to acknowledge its new role before taking further action, preventing unnecessary failovers.
Closes: #2513
Release notes
Prevent double failover in case of lost connectivity

EE: https://github.com/EnterpriseDB/cloudnative-pg/actions/runs/11329017284

/ok-to-merge


fix: correct separators in git log rename handling

Solve issues with separators in git log rename handling
Solves https://github.com/angular-architects/detective/issues/26
BEFORE
Portrays issue 26
AFTER
Correctly deals with separators in git log rename handling
Checklist for PR

[x] PR is only about one and only one concern
[x] Description contains a short title, an optional description, and the sections BEFORE and AFTER
[x] (A) new short test(s) show(s) that the PR is working; extended existing test-data to show this

Big thanks!


[ csi-controller ] -- failed to provision volume with StorageClass

Used By:       mcamel-common-es-cluster-masters-es-data-1
Events:
  Type     Reason                Age                  From                                                                                Message
  ----     ------                ----                 ----                                                                                -------
  Normal   WaitForFirstConsumer  54m                  persistentvolume-controller                                                                                waiting for first consumer to be created before binding
  Warning  ProvisioningFailed    54m (x6 over 54m)    lvm.hwameistor.io_hwameistor-local-storage-csi-controller-57668bdc5-ldpcx_07f0ebaa-70fe-42a2-9caa-dca0bc68a32a  failed to provision volume with StorageClass "hwameistor-storage-lvm-hdd": rpc error: code = Unknown desc = requireNode g-master1 is not ready
  Normal   Provisioning          53m (x7 over 54m)    lvm.hwameistor.io_hwameistor-local-storage-csi-controller-57668bdc5-ldpcx_07f0ebaa-70fe-42a2-9caa-dca0bc68a32a  External provisioner is provisioning volume for claim "mcamel-system/elasticsearch-data-mcamel-common-es-cluster-masters-es-data-1"
  Warning  ProvisioningFailed    53m                  lvm.hwameistor.io_hwameistor-local-storage-csi-controller-57668bdc5-ldpcx_07f0ebaa-70fe-42a2-9caa-dca0bc68a32a  failed to provision volume with StorageClass "hwameistor-storage-lvm-hdd": error generating accessibility requirements: no topology key found on CSINode g-master1
  Warning  ProvisioningFailed    53m (x2 over 53m)    lvm.hwameistor.io_hwameistor-local-storage-csi-controller-57668bdc5-ldpcx_fd63fcb0-2e08-4ecb-a45b-94dfae3dae03  failed to provision volume with StorageClass "hwameistor-storage-lvm-hdd": error generating accessibility requirements: no topology key found on CSINode g-master1
  Normal   ExternalProvisioning  19m (x142 over 54m)  persistentvolume-controller                                                                                waiting for a volume to be created, either by external provisioner "lvm.hwameistor.io" or manually created by system administrator
  Normal   Provisioning          19m (x15 over 53m)   lvm.hwameistor.io_hwameistor-local-storage-csi-controller-57668bdc5-ldpcx_fd63fcb0-2e08-4ecb-a45b-94dfae3dae03  External provisioner is provisioning volume for claim "mcamel-system/elasticsearch-data-mcamel-common-es-cluster-masters-es-data-1"
  Warning  ProvisioningFailed    19m (x13 over 53m)   lvm.hwameistor.io_hwameistor-local-storage-csi-controller-57668bdc5-ldpcx_fd63fcb0-2e08-4ecb-a45b-94dfae3dae03  failed to provision volume with StorageClass "hwameistor-storage-lvm-hdd": rpc error: code = Unknown desc = requireNode g-master1 is not ready
  Normal   ExternalProvisioning  60s (x61 over 16m)   persistentvolume-controller                                                                                waiting for a volume to be created, either by external provisioner "lvm.hwameistor.io" or manually created by system administrator
  Normal   Provisioning          47s (x11 over 15m)   lvm.hwameistor.io_hwameistor-local-storage-csi-controller-57668bdc5-fcdnx_274fcaf8-b0e4-43c1-aefe-356bc95d68ed  External provisioner is provisioning volume for claim "mcamel-system/elasticsearch-data-mcamel-common-es-cluster-masters-es-data-1"
  Warning  ProvisioningFailed    37s (x11 over 15m)   lvm.hwameistor.io_hwameistor-local-storage-csi-controller-57668bdc5-fcdnx_274fcaf8-b0e4-43c1-aefe-356bc95d68ed  failed to provision volume with StorageClass "hwameistor-storage-lvm-hdd": rpc error: code = DeadlineExceeded desc = context deadline exceeded

Is there any logs of local-storage pod which running at the same node with local-storage-csi-controller pod?

this issue happened during DCE cluster upgrade, evict pod, volume migration


Expect to use @throws in lib/*.d.ts to mark which methods may throw err

Suggestion

Use @throws to mark the corresponding error on the method in the .d.ts file in the lib directory
🔍 Search Terms
@throws jsdoc comments
✅ Viability Checklist
My suggestion meets these guidelines:

[x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
[x] This wouldn't change the runtime behavior of existing JavaScript code
[x] This could be implemented without emitting different JS based on the types of the expressions
[x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
[x] This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion
Use @throws to mark the corresponding error on the method in the .d.ts file in the lib directory
📃 Motivating Example
/**
 * Converts a JavaScript Object Notation (JSON) string into an object.
 * @param text A valid JSON string.
 * @param reviver A function that transforms the results. This function is called for each member of the object.
+* @throws {SyntaxError} if the string to parse is not valid JSON.
 * If a member contains nested objects, the nested objects are transformed before the parent object is.
 */
 parse(text: string, reviver?: (this: any, key: string, value: any) => any): any;

💻 Use Cases
want to be able to write code when you know that you need to beware of these unpredictable behavior

I like this idea, but it seems much more useful if this information could be propagated by typescript, so that a function which calls something annotated with @throws and doesn't catch is also considered as throwing.

Something like typescript-eslint/no-floating-promises would be interesting. In this rule unhandled promises shows an error on vscode.

Throw types are the one thing I still find myself wanting in TypeScript. Sometimes the types can get a little unwieldy, but there are very few things these days that you just outright can't express in the latest TypeScript versions. The types might be complicated, but almost anything is possible. Really makes the lack of throw/catch typings feel like a pretty big hole.
function getFriend(name: string): Friend, throws ReferenceError {
    const friend = friends.get(name);
    if (!friend) throw new ReferenceError("I don't know them!");
    return friend;
}

try {
    getFriend("partheseas")
} catch (error) {
    // typeof error would be inferred as ReferenceError
}

@throws looks like a Decorator
So I would like to see something more like a type, for example: Throws<ErrorType = any>
In this way intellisense will help me know that a function can also throw an error.
(This is my use case for wanting to have this type; so I know that I need to wrap it in a try catche.)
Currently typescript provides the type never, which also is an indication that the function will throw an error (or maybe has an infinite loop?). Maybe should never type start being generic so we also can indicate the type of thrown error?

Are you aware of TSDoc and its definition of the TSDoc @throws tag?
Better support and tooling for TSDoc (e.g. eslint TypeScript rules that consider TSDoc tags as defined in the standard) could resolve or at least mitigate this problem.


Unable to build an UWP app with Flutter 2.5.0-1.0-pre

Hello,
I have exactly the same issue as #82967, and it seems it's not fixed.
Here is the error log :
flutter run -d winuwp
Launching lib\main.dart on Windows (UWP) in debug mode...
LINK : warning LNK4075: ' /INCREMENTAL' ignoré à cause de la spécification '/OPT:ICF' [C:\Users\anima\StudioProjects\untitled\build\winuwp\runner_uwp\app.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VisualStudio\v16.0\AppxPackage\Microsoft.AppXPackage.Targets(3327,5): warning : APPX4
001: Build property AppxBundlePlatforms is not explicitly set and is calculated based on currently building architecture. Use 'Create App Package' wizard or edit pro
ject file to set it. [C:\Users\anima\StudioProjects\untitled\build\winuwp\runner_uwp\app.vcxproj]
Building Windows UWP application...
Failed to install file:///C:/Users/anima/StudioProjects/untitled/build/winuwp/runner_uwp/AppPackages/app/app_<IP_ADDRESS>_Debug_Test/app_<IP_ADDRESS>_x64_Debug.msixbundle
Failed to install app package
Error launching application on Windows (UWP).

Here is my flutter doctor:
>flutter doctor
Doctor summary (to see all details, run flutter doctor -v):
[√] Flutter (Channel dev, 2.5.0-1.0.pre, on Microsoft Windows [version 10.0.19042.1151], locale fr-FR)
[√] Android toolchain - develop for Android devices (Android SDK version 31.0.0)
[√] Chrome - develop for the web
[√] Visual Studio - develop for Windows (Visual Studio Community 2019 16.10.4)
[√] Android Studio (version 2020.3)
[√] VS Code (version 1.58.2)
[√] Connected device (5 available)

What should I do to fix this?

I have exactly the same issue as #82967

I'm not sure how you reached this conclusion, but your error doesn't appear to be at all related to that one. That was a specific compile failure which doesn't show up anywhere in your log. Your issue is:

Failed to install file:///C:/Users/anima/StudioProjects/untitled/build/winuwp/runner_uwp/AppPackages/app/app_<IP_ADDRESS>_Debug_Test/app_<IP_ADDRESS>_x64_Debug.msixbundle
Failed to install app package

Hi @g123k
Currently, when we rerun the app, we run to this issue
If you uninstall uwp app from Start, it should run again
This is a duplicate of https://github.com/flutter/flutter/issues/86996


Issue #284 Error Handling for JSON

Attempted to write a function adding to error log, list parameters that should be inputed

@lesliepu doesn't look like this one has any of the new stuff in it


N950

Hi, I just wanted to let you know I have tested and run on Samsung N950 Soundbar too. Perfect.
May I suggest that you clarify that you need to restart HA after the three files been downloaded and then the configuration.yaml will be valid when testing it before 2nd restart.

Thanks! Documentation updated


Can't get out of container network mode

Bug description
If a container is configured to use another container's network, it can't be reverted back to using any other mode using Duplicate/Edit.
For example if I have a container B using container A's network, and I want container B to now be in bridge mode, then the error is that bridge:A doesn't exist. It looks like the container field even though it's not showing in the UI anymore is still filled with the previous value.
Expected behavior
Be able to stop using another container's network.
Portainer Logs
Nothing relevant at the time of the error in the portainer logs.
Steps to reproduce the issue:

Create two containers and set one to use the other's network mode
Try to change it back to any other mode

Technical details:

Portainer version: 2.6.1
Docker version : 20.10.7
Platform : Linux (debian)
Command used to start Portainer : docker run -p 9000:9000 portainer/portainer
Browser: Firefox
Use Case : home
Have you reviewed our technical documentation and knowledge base? Haven't found anything about this but I may have missed it.

@Ulrar
I'm unable to reproduce this behaviour. I'm able to change the network to bridge in my case.
Can you try again and post some screenshots.

@samdulam I just reproduced it (standalone Docker) by:

make a network called internal
create container aaa using the internal network
create container bbb using the container(aaa) network.
goto recreate/redeploy bbb, select the unnamed bridge network, and hit deploy.
get the red "network bridge:aaa does not exist"

looks like the  selector is not cleared when the user changes from container network to something else (but its hidden)
I'm guessing its easier to fix, than it was to reproduce ;)

My current workaround is to activate the Select a container-option, by removing hidden and disabled in the DOM:
<option disabled="" value="" class="" selected="selected" hidden="">Select a container</option>


typeof frozen object property is generic, not literal type

In using frozen objects to create enums, it seems the literal value is not inferred to the type of that object's property.
In the following example, when using the $Values utility we get a union of the values, as expected ('THING' | 'THING_TWO'), but when using typeof to get the type of one of these properties, we get a type of string. I'd expect to get the string literal type instead.
const ENUM = Object.freeze({
    THING: 'THING',
    THING_TWO: 'THING_TWO',
});

const notAThing: typeof ENUM.THING = 'NOT_A_THING' // no error

const isAThing: $Values<typeof ENUM> = 'IS_A_THING' // Cannot assign `'IS_A_THING'` to `isAThing` because string [1] is incompatible with enum [2].

Try Flow
Of course, typing each property individually works, but I'd expect Object.freeze() to produce the same output. Is there another way around this?

Fixed as of v0.238


Added documentation for expected columns selection input per chart type

Code Flow:
http://codeflow/extensions/launcher.html?server=https:%2F%2Fmseng.visualstudio.com%2F&projectId=96a62c4a-58c2-4dbb-94b6-5979ebc7f2af&reviewId=537193&projectshortname=AppInsights

Do we want to add the expected behavior when wrong columns\types are used?


Added event handlers and a Redux store for cooperation

Refactored components by Single Responsibility Principle & added event handlers
The components have been refactored to follow to the SRP and decoupling the storage logic from presentation logic that makes the components to be reusable across different contexts. The refactored approach can be viewed via the following link: https://excalidraw.com/#json=HlRzYrei5UAlm1lbJhfDe,F79VZcZt6OpKfNRdFoF7dQ

[ PR #2061 ]
Implemented ability to change the availability status in 'My Cooperations' and store this information in the Redux store
Now, all changes to the availability status of resources on ResourceItems are persisted in the store:

When the publish type is set to 'Open manually', the availability of all resources is automatically changed to 'Closed', and these changes are persisted in the store:

Additionally, logic has been implemented to store the sort order of resources as individual items within each section. Previously, sorting was only implemented by group type, specifically for attachments, lessons, and quizzes, which only sorted groups but not the resources within them:

Breaking changes:

New changes broke the functionality of adding resources and all related logic in the CreateCourse component. [ Already implemented and fixed in Issue #2070 and PR #2316 ]

[ PR #2168 ]
Combined lessons, quizzes, and attachments into activities array in the cooperation store
Changed the cooperation store to combine the logic of storing attachments (lessons, quizzes, and attachments) into a single variable - activities. Also removed the order field:

[ PR #2290 ]
Refactored Cooperation & Course by Applying Main Requested Changes
Changed the name of the array activities to resources and the type of resources from [lessons, quizzes, attachments, questions] to [lesson, quiz, attachment, question]. Current structure Cooperation and Course:

[ PR #2303 ]
Fixed date serialization and mask input issues in DatePicker component

[x] Ensured availability.date is properly serialized to ISO string before dispatching actions:
A non-serializable value (Date object) was detected in the state, specifically in the path: cooperations.sections.0.resources.0.resource.availability.date. This warning is raised because Redux state should only contain plain serializable objects, arrays, and primitives. The reducer handling this action type is cooperationsSlice/updateResource.
[x] Adjusted props for DatePicker component to use fixed-length date parts to resolve mask input warning.

[ PR #2316 ]
Replaced functionality of create course in order to use new handlers
Updated the create course functionality to utilize the new handlers developed in PR #2061 after refactoring. The changes ensure that the course creation process works correctly when adding resources with the required entity data structure, as specified in PR #2290.
[ PR #2334 ]
Fixed [Error 409 (Conflict)] when saving cooperation with empty title or description
Resolved an issue where saving a cooperation with a section that has an empty title or description resulted in an Axios error with the message 'Request failed with status code 409'. After changes, it now shows a proper error popup message.
Tests Coverage for New Code:

🟣 Merged PRs:

[x] PR #2168
[x] PR #2189
[x] PR #2190
[ ] PR #2290
[ ] PR #2303
[ ] PR #2316
[ ] PR #2334

🟢 Closed Issues:
Based on this epic Epic: Rewrite cooperation activities #1921, the following issues were implemented:

[x]  Close Issue #1925
[x]  Close Issue #1926
[x]  Close Issue #1922
[x]  Close Issue #1919
[x]  Close Issue #2085
[x]  Close Issue #2270
[x]  Close Issue #2070
[x]  Close Issue #2103
[x]  Close Issue #2327
[x]  Close Issue #2073
[x]  Close Issue #2075
[x]  Close Issue #2071
[x]  Close Issue #2072
[x]  Close Issue #2323

Great work!


Bump to kokkos4.4

This is a fixed PR request to replace #589, which was trying to merge main into bump_to_kokkos4.4 rather than the other way around.

This should probably be bumped to 4.4.01? Just released on the 13th: https://github.com/kokkos/kokkos/releases/tag/4.4.01


Configure Azure Pipelines

This pipeline configuration builds the application and produces a build for the Release configuration.

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


Try state in context

Resolves: https://github.com/reakit/reakit/issues/745
The code is experimental. There are many TS linter errors. More like a proof-of-concept = this is possible in the core!
Benefits

Less code, no need to spread those states everywhere
Better performance, less rerenders

Goals

100% backward compatibility. It should work with every existing component without any changes. This isn't proved yet but I'll include tests later on.
Should be easy to enable this new feature for existing and upcoming components

How this works in the userland?
See https://github.com/reakit/reakit/issues/745
Is there anything we need to do to enable this feature for components?
Yes

We need to add a context and isContextProvider prop to parent components. (Like ComboboxPopover)
We need to add context prop to children components. (LikeComboboxOption)

How it works under the hood?
Based on @diegohaz 's awesome work: https://twitter.com/diegohaz/status/1307299869200191490
Components can be registered to use a specific Context and/or be a context provider. This is possible with the createComponent function. Two new properties are context and isContextProvider. Context providers are providing context for components that are created with the same context property. See ComboboxPopover as a context provider example. And see ComboboxOption as a context consumer example.
There is an internal pub-sub system between providers are consumers on top of the context. To avoid many rerenders of changing the value of the context we use this pub-sub system.
Consumers are wrapped with StateContextHoc HOC. This takes care of the receiving of the state updates from the pub-sub system. Applies the new state if applicable.
How to test?

npm run storybook
Open Combobox -> Combobox Non Context Vs Context

Does this PR introduce breaking changes?
The goal is 100% backward compatibility. Not sure yet 😄

@david-szabo97 Whoa! I was already hopeless that this would be possible in v1 (without a huge refactor), but again you come up with a very clever solution. ❤


Improve fast travel information and order

Improving information given to the user on fast travel time.
Now gives an approximate time of arrival.
Also re-ordered waiting time, due to an issue where passengers would teleport almost instantly and only the teleporting user would be stuck. The other way round is more preferable to avoid this cheat.

Thanks! I will include it

Hi! I included it "by hand" as the lines of code should be in another part. Currently testing.

Well, if you want to dig in the code to help me discover some misteries:

Bunkers moving on persistent load: Very strange as I use the same getters and setters for bunker positions, but they slightly move everytime the player loads them.
The biggest mistery: sometimes when you lose undercover and have AI in your group they dont get all their gear. This is present since like 2 years with unknown reason.
Any kind of better UI, better looking things as you did, is very welcome.


Folders in TOC always default to closed after clearing search results.

As the user types into the Search Bar, the folders in the TOC automatically expand to show the ItemTypes that match the search. After a user clears the search, the TOC resets and all of the folders will default to being closed even if some of them were open before the user started searching.
When the user then clicks to expand the folder, the folder still thinks it's open and will automatically close itself. This means that a user has to click any folder that was open before typing in the search bar twice to get it to open after clearing the search bar.

This was fixed in a pull request.


Introduce GitHub markdown editor, keep EasyMDE as fallback

The first step of the plan

#23290

Thanks to @silverwind for the first try in #15394 . Close #10729 and a lot of related issues.
The EasyMDE is not removed, now it works as a fallback, users can switch between these two editors.
Editor list:

Issue / PR comment
Issue / PR comment edit
Issue / PR comment quote reply
PR diff view, inline comment
PR diff view, inline comment edit
PR diff view, inline comment quote reply
Release editor
Wiki editor

Some editors have attached dropzone
Screenshots:

The EasyMDE is not removed, now it works as a fallback, users can switch between these two editors.

I'd say we should remove it eventually, maybe not initially but I see no benefit in keeping this buggy editor around any longer.

The EasyMDE is not removed, now it works as a fallback, users can switch between these two editors.

I'd say we should remove it, maybe not initially but I see no benefit in keeping this buggy editor around any longer, so I'd nuke it with this PR.

I also agree that the EasyMDE should be removed in the end, while I think maybe we can leave more time for it.
My opinions are: maybe there are some users who really like the EasyMDE (not everyone user is affected by its bug). If we remove it quickly, these users will be hurt.
Now, the EasyMDE is only the second choice, and there is almost no technical debit of it, I guess this PR's approach could satisfy most users. To remove the EasyMDE feature gracefully, maybe we could do these steps:

Show textarea by default, but if a user swiches to EasyMDE, then remember the choice, next time show EasyMDE first.

That's my next PR, to "remember" the referred editor (by LocalStorage)

Always show textarea by default, no remember.
Only use textarea by default, but if any user really needs the EasyMDE, provide a backdoor to get it back.
Remove the EasyMDE completely if no user complains

Once this is in, we should go through open issues. I estimate we can probably close 30+ issues with this.

One visual change that I would do is move the toolbar to right side of the tabs like I did in my original PR. Maybe put them on separate line when screen space becomes too small.

Conflicts are resolved, and fix some bugs during my test.


POST to CA fails using TLS

Hello i'm facing a issue using requests lib to post to a CA with self-signed certificate Everything goes well when I POST from curl:
curl --cacert "./ca-cert.pem" https://ca.goledger.com:7054/api/v1/cainfo -X POST
I get my response with CAChain
If I try using requests lib it fails
Expected Result
A response containing CAChain from CA at ca.goledger.com
Actual Result
The command fails throwing a strange SSLError (BAD_ECC_CERT)
 Traceback (most recent call last):
    File "/usr/local/lib/python3.5/dist-packages/urllib3-1.22-py3.5.egg/urllib3/connectionpool.py", line 601, in urlopen
        chunked=chunked)
    File "/usr/local/lib/python3.5/dist-packages/urllib3-1.22-py3.5.egg/urllib3/connectionpool.py", line 346, in _make_request
        self._validate_conn(conn)
    File "/usr/local/lib/python3.5/dist-packages/urllib3-1.22-py3.5.egg/urllib3/connectionpool.py", line 850, in _validate_conn
        conn.connect()
    File "/usr/local/lib/python3.5/dist-packages/urllib3-1.22-py3.5.egg/urllib3/connection.py", line 326, in connect
        ssl_context=context)
    File "/usr/local/lib/python3.5/dist-packages/urllib3-1.22-py3.5.egg/urllib3/util/ssl_.py", line 329, in ssl_wrap_socket
        return context.wrap_socket(sock, server_hostname=server_hostname)
    File "/usr/lib/python3.5/ssl.py", line 377, in wrap_socket
        _context=self)
    File "/usr/lib/python3.5/ssl.py", line 752, in __init__
        self.do_handshake()
    File "/usr/lib/python3.5/ssl.py", line 988, in do_handshake
        self._sslobj.do_handshake()
    File "/usr/lib/python3.5/ssl.py", line 633, in do_handshake
        self._sslobj.do_handshake()
    ssl.SSLError: [SSL: BAD_ECC_CERT] bad ecc cert (_ssl.c:645)

    During handling of the above exception, another exception occurred:

    Traceback (most recent call last):
    File "/usr/local/lib/python3.5/dist-packages/requests-2.18.4-py3.5.egg/requests/adapters.py", line 440, in send
        timeout=timeout
    File "/usr/local/lib/python3.5/dist-packages/urllib3-1.22-py3.5.egg/urllib3/connectionpool.py", line 639, in urlopen
        _stacktrace=sys.exc_info()[2])
    File "/usr/local/lib/python3.5/dist-packages/urllib3-1.22-py3.5.egg/urllib3/util/retry.py", line 388, in increment
        raise MaxRetryError(_pool, url, error or ResponseError(cause))
    urllib3.exceptions.MaxRetryError: HTTPSConnectionPool(host='ca.goledger.com', port=7054): Max retries exceeded with url: /api/v1/cainfo (Caused by SSLError(SSLError(1, '[SSL: BAD_ECC_CERT] bad ecc cert (_ssl.c:645)'),))

    During handling of the above exception, another exception occurred:

    Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    File "/usr/local/lib/python3.5/dist-packages/requests-2.18.4-py3.5.egg/requests/api.py", line 112, in post
        return request('post', url, data=data, json=json, **kwargs)
    File "/usr/local/lib/python3.5/dist-packages/requests-2.18.4-py3.5.egg/requests/api.py", line 58, in request
        return session.request(method=method, url=url, **kwargs)
    File "/usr/local/lib/python3.5/dist-packages/requests-2.18.4-py3.5.egg/requests/sessions.py", line 508, in request
        resp = self.send(prep, **send_kwargs)
    File "/usr/local/lib/python3.5/dist-packages/requests-2.18.4-py3.5.egg/requests/sessions.py", line 618, in send
        r = adapter.send(request, **kwargs)
    File "/usr/local/lib/python3.5/dist-packages/requests-2.18.4-py3.5.egg/requests/adapters.py", line 506, in send
        raise SSLError(e, request=request)
    requests.exceptions.SSLError: HTTPSConnectionPool(host='ca.goledger.com', port=7054): Max retries exceeded with url: /api/v1/cainfo (Caused by SSLError(SSLError(1, '[SSL: BAD_ECC_CERT] bad ecc cert (_ssl.c:645)'),))

Reproduction Steps
import requests
requests.post(url='https://ca.goledger.com:7054/api/v1/cainfo', verify='./ca-cert.pem')

System Information
{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": ""
  },
  "idna": {
    "version": "2.6"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.5.2"
  },
  "platform": {
    "release": "4.10.0-38-generic",
    "system": "Linux"
  },
  "pyOpenSSL": {
    "openssl_version": "",
    "version": null
  },
  "requests": {
    "version": "2.18.4"
  },
  "system_ssl": {
    "version": "1000207f"
  },
  "urllib3": {
    "version": "1.22"
  },
  "using_pyopenssl": false
}

Just got the same issue by using requests with the fabric-sdk-py from hyperledger fabric too.
Sorry, it is clearly not related to requests, but @vieiramanoel did you find the solution to the problem? Can you point me out to a referenced issue?
I'd really appreciate that. Thanks

Anyone has some clue of the root cause?
If pycurl/curl can work, but requests lib cannot work, then means something wrong in the requests lib?

@yeasy, this is an issue with openssl and the certificate chain being used. The reason pycurl works is because it has an additional dependency on libcurl-openssl-dev which is allowing cert resolution. We don't have an good way to support this behavior in Requests and as @sigmavirus24 stated can't support everything that curl does.

This issue specifically related to hyperledger has been determined.
The X509v3 extensions are not correctly generated when creating the certificate.
You can read the whole thread here: https://jira.hyperledger.org/browse/FABP-68


Convert to TypeScript

What type of PR is this? (check all applicable)

[x] ♻ Refactor
[ ] ✨ Feature
[ ] 🐛 Bug Fix
[ ] 👷 Optimization
[ ] 📝 Documentation Update
[ ] 🚩 Other

Description
Initial conversation to TS.
Related Tickets & Documents
Closes #60
Added to documentation?

[ ] 📜 readme
[ ] 🙅 no documentation needed

[optional] What gif best describes this PR or how it makes you feel?

 Why is this marked in progress? We don't need to make everything idiomatic in this PR. Getting the build system updated is most important. Everything else can be piecemeal.

If this compiles and works, I'm inclined to say merge and increment.

 Why is this marked in progress? We don't need to make everything idiomatic in this PR. Getting the build system updated is most important. Everything else can be piecemeal.

There is one bug that the integration tests caught:
| ✔  Schema registered!  Subject: mz_datagen_comments-value, ID: 4
|
| /app/node_modules/@kafkajs/confluent-schema-registry/dist/SchemaRegistry.js:153
|             throw new errors_1.ConfluentSchemaRegistryArgumentError(`Invalid registryId: ${JSON.stringify(registryId)}`);
|                   ^
|
| ConfluentSchemaRegistryArgumentError: Invalid registryId: undefined
|     at SchemaRegistry.encode (/app/node_modules/@kafkajs/confluent-schema-registry/dist/SchemaRegistry.js:153:19)
|     at file:///app/dist/src/schemas/schemaRegistry.js:65:44

Wanted to fix that first before merging

That but and a couple of others are fixed in my open PR. Maybe we can merge that one first?

That bug (I think) and a couple of others are fixed in my open PR. Maybe we can merge that one first?

Ok sounds good, let's merge #62 and then I'll rebase and go from there!

Ok done!

Just pushed the changes from main. Seems like we are still hitting that error:
| ✔  Registering Avro schema...
|
| file:///app/dist/src/schemas/schemaRegistry.js:17
|         schema.name = `name${i++}`;
|                     ^
|
| TypeError: Cannot create property 'name' on string 'string'

That looks like a new error

That looks like a new error

Ah yes, no that was actually the initial error, before I started debugging and trying out stuff


Don't see any prediction with rs serve

I am running the test Flask server on my GPU server, and it launches successfully but when I pan around, I don't get any results. This is supposed to be live prediction right? Or have I misunderstood?
I loaded my model checkpoint onto the server and then ran the server like this:
./rs serve --model vineyards/config/model-unet.toml --dataset vineyards/config/model-unet.toml --url<EMAIL_ADDRESS>--checkpoint ../checkpoint-00012-of-00100.pth --host=<IP_ADDRESS>
I have exported my mapbox token before this and have double-checked the paths to my model and dataset. But when I go to the page, I just see the satellite tiles and no prediction on top. Any ideas?
I don't even see any activity in the console output from Flask, nor any GPU activity from nvidia-smi when panning around.
I do notice however that the request is made in the browser to <IP_ADDRESS>, but this would be pointing to my own local machine where I have the browser open, is there a way to get it to put to the source server itself?

Here are the two files you need to look at

https://github.com/mapbox/robosat/blob/cbb1c73328183afd2d6351b7bfa3f430b73103ea/robosat/tools/templates/map.html
https://github.com/mapbox/robosat/blob/cbb1c73328183afd2d6351b7bfa3f430b73103ea/robosat/tools/serve.py

The browser makes requests to localhost here
https://github.com/mapbox/robosat/blob/cbb1c73328183afd2d6351b7bfa3f430b73103ea/robosat/tools/templates/map.html#L74
If you run the serve tool on your gpu rig and change the line above to the gpu rig's ip it should work. As long as the html and the tiles are served from the same origin (host & port) you will be fine re. CORS, otherwise you probably need to add some CORS headers.
Also check the note in the readme please :bow:
https://github.com/mapbox/robosat/blob/cbb1c73328183afd2d6351b7bfa3f430b73103ea/README.md

@daniel-j-h Thanks for the tip, I didn't realize it was baked into the index.html. I was able to get it running.
RE: the note - just wondering what you meant by that, do you mean to say to not expect consistent support with issues on this github anymore?

Glad you got it running! :tada:
Exactly, this project is outdated by now for years and the Mapbox folks don't maintain it :crying_cat_face: Just want to be clear about this before folks put their time and effort into an abandoned project.

Ok, understood. I have my own hacked fork specifically for my purposes anyway. Is there a new project for the same purpose? Mapbox-affiliated or not. I saw that there was Robosat.pink but it seems that the creator actually passed away and nobody has maintained it since then.

Yes, sadly https://github.com/mapbox/robosat/issues/184
I'm not keeping track of the current state wrt. open source solutions in the robosat domain, sorry.
I do work on my own machine learning projects and can say with confidence that robosat by now could be orders of magnitude faster, cheaper to train/predict, and more accurate, with all the recent advances, tho.
Best,
Daniel
On April 13, 2021 11:25:53 AM UTC, Isaac Boates @.***> wrote:

Ok, understood. I have my own hacked fork specifically for my purposes
anyway. Is there a new project for the same purpose? Mapbox-affiliated
or not. I saw that there was Robosat.pink but it seems that the creator
actually passed away and nobody has maintained it since then.


Allow returning to be used with oracle update

https://github.com/tgriesser/knex/issues/1249

Could you please update the docs to show that returning is supported by Oracle also?

@wubzz Absolutely! I updated the index.html


Modified the wording of the 2nd test in the "Chain Middleware to Create a Time Server" challenge.

The modification of the 2nd test wording in the "Chain Middleware to Create a Time Server" challenge was necessary. Otherwise, a test taker could interpret the test differently and implement a setTimeout() in his/her solution.
Checklist:

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the main branch of freeCodeCamp.
[x] I have tested these changes either locally on my machine, or GitPod.

Closes #46941

@VictorVoda can you apply Naomi suggestions, so we can merge your pull request?

@VictorVoda Thank you for trying to clear the issue, but to clear the issue I have opened a pull request with the requirement.
Thank you again 🙂


Separates project build and db updates.

What's this PR do?

Introduces new ds build --no-db argument
Introduces new ds updb command
Separates project build and db updates

What are the relevant tickets?

Ref DoSomething/dosomething-deploy#30
Ref DoSomething/dosomething-deploy#23

:100:

Fixes #5844. @angaither Thanks for the find.

Works! https://jenkins.dosomething.org/job/Deploy-Staging/314/console