Taker leveraged short

The leverage is now handled correctly, internally we store long and short leverage and calcuate the margin accordingly. In the database we only store the taker leverage (that's what is in the Order and is currently always 2). The maker leverage is always assumed to be 1 no matter if the maker is short or long.
Note that the Order should be changed to be an Offer, and the position of said offer should not be the maker's (as it currently is) but the taker's. It is super confusing that the Order's position is the maker's whereas the order's leverage is the one of the taker.

I guess you can rebase it already on master, the other one got merged!

I guess you can rebase it already on master, the other one got merged!

done.

Fun fact: My changes actually hardcoded the long_leverage for both sides, because the model::Cfd::leverage() (the getter for leverage) always returned long_leverage 😅
Fixed now. This should be covered by a test - I did not do that yet.

Note that previously we stored only the taker leverage in the db (for maker and taker), because we needed that for the payout curve (which is always long). Now, we have the long_leverage, so I am storing the own leverage in the db which makes more sense. I don't think that should have side effects, but we will need more testing...

Note for Fixthat Tomorrow Daniel: The constructor still expects the taker_leverage, so that's what has to go into the db.

Some more notes:
In the past we always saved that taker leverage into the db. I don't really want to change the db for mainnet-stable, so I'd say we keep that.
I thought I could change it to always save our own leverage (so the db field would make more sense...), but then old positions would not be loaded correctly, because we always expect the taker leverage in the constructor of model::Cfd. I would like to change that constructor to just take long_leverage and short_leverage, but given backwards compatibility (...) this is not easy to achieve.
So, for now I opted to just save the taker leverage into the db - as before - but be more explicit about it in code (I did not rename the db field though).

I don't really want to change the db for mainnet-stable, so I'd say we keep that.

Writing a migration that only changes the cfds table is easy enough. We could definitely do that!

yes!
are we talking about maker_leverage field? this one's easy, because we can default to 1 in the migration script!

I don't really want to change the db for mainnet-stable, so I'd say we keep that.

Writing a migration that only changes the cfds table is easy enough. We could definitely do that!

True, but it's not so much about renaming the field, but about storing what makes more sense... The fact that we only store the taker leverage is just weird - but sufficient for not (and it can depict configurable taker leverage, which we might want to tackle on top of mainnet stable).
Once we go multiple makers I think the model should properly depict long and short leverage in the db.

Note that when creating a leveraged short position we panic at the moment:
thread 'rocket-worker-thread' panicked at 'attempt to subtract with overflow', model/src/payout_curve.rs:115:30
stack backtrace:
   0: rust_begin_unwind
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/std/src/panicking.rs:498:5
   1: core::panicking::panic_fmt
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/core/src/panicking.rs:107:14
   2: core::panicking::panic
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/core/src/panicking.rs:48:5
   3: model::payout_curve::calculate_payout_parameters::{{closure}}
             at /Users/dakami/CoBloX/repos/hermes/model/src/payout_curve.rs:115:30
   4: core::iter::adapters::map::map_try_fold::{{closure}}
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/core/src/iter/adapters/map.rs:91:28
   5: core::iter::traits::iterator::Iterator::try_fold
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/core/src/iter/traits/iterator.rs:1995:21
   6: <core::iter::adapters::map::Map<I,F> as core::iter::traits::iterator::Iterator>::try_fold
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/core/src/iter/adapters/map.rs:117:9
   7: <core::iter::adapters::ResultShunt<I,E> as core::iter::traits::iterator::Iterator>::try_fold
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/core/src/iter/adapters/mod.rs:178:9
   8: core::iter::traits::iterator::Iterator::find
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/core/src/iter/traits/iterator.rs:2383:9
   9: <core::iter::adapters::ResultShunt<I,E> as core::iter::traits::iterator::Iterator>::next
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/core/src/iter/adapters/mod.rs:160:9
  10: <alloc::vec::Vec<T> as alloc::vec::spec_from_iter_nested::SpecFromIterNested<T,I>>::from_iter
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/alloc/src/vec/spec_from_iter_nested.rs:23:32
  11: <alloc::vec::Vec<T> as alloc::vec::spec_from_iter::SpecFromIter<T,I>>::from_iter
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/alloc/src/vec/spec_from_iter.rs:33:9
  12: <alloc::vec::Vec<T> as core::iter::traits::collect::FromIterator<T>>::from_iter
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/alloc/src/vec/mod.rs:2549:9
  13: core::iter::traits::iterator::Iterator::collect
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/core/src/iter/traits/iterator.rs:1745:9
  14: <core::result::Result<V,E> as core::iter::traits::collect::FromIterator<core::result::Result<A,E>>>::from_iter::{{closure}}
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/core/src/result.rs:1883:53
  15: core::iter::adapters::process_results
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/core/src/iter/adapters/mod.rs:149:17
  16: <core::result::Result<V,E> as core::iter::traits::collect::FromIterator<core::result::Result<A,E>>>::from_iter
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/core/src/result.rs:1883:9
  17: core::iter::traits::iterator::Iterator::collect
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/core/src/iter/traits/iterator.rs:1745:9
  18: model::payout_curve::calculate_payout_parameters
             at /Users/dakami/CoBloX/repos/hermes/model/src/payout_curve.rs:98:29
  19: model::payout_curve::calculate
             at /Users/dakami/CoBloX/repos/hermes/model/src/payout_curve.rs:59:19
  20: daemon::setup_contract::new::{{closure}}
             at ./src/setup_contract.rs:121:9
  21: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/core/src/future/mod.rs:80:19
  22: <daemon::setup_taker::Actor as xtra::Handler<daemon::setup_taker::Accepted>>::handle::{{closure}}::{{closure}}
             at ./src/setup_taker.rs:106:59
  23: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/core/src/future/mod.rs:80:19
  24: <core::panic::unwind_safe::AssertUnwindSafe<F> as core::future::future::Future>::poll
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/core/src/panic/unwind_safe.rs:289:9
  25: <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
  26: <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/core/src/panic/unwind_safe.rs:271:9
  27: std::panicking::try::do_call
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/std/src/panicking.rs:406:40
  28: <unknown>
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/std/src/panicking.rs:434:6
  29: std::panicking::try
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/std/src/panicking.rs:370:19
  30: std::panic::catch_unwind
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/std/src/panic.rs:133:14
  31: <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
  32: <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
  33: <core::pin::Pin<P> as core::future::future::Future>::poll
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/core/src/future/future.rs:119:9
  34: tokio::runtime::task::core::CoreStage<T>::poll::{{closure}}
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.16.1/src/runtime/task/core.rs:161:17
  35: tokio::loom::std::unsafe_cell::UnsafeCell<T>::with_mut
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.16.1/src/loom/std/unsafe_cell.rs:14:9
  36: tokio::runtime::task::core::CoreStage<T>::poll
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.16.1/src/runtime/task/core.rs:151:13
  37: tokio::runtime::task::harness::poll_future::{{closure}}
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.16.1/src/runtime/task/harness.rs:461:19
  38: <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/core/src/panic/unwind_safe.rs:271:9
  39: std::panicking::try::do_call
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/std/src/panicking.rs:406:40
  40: <unknown>
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/std/src/panicking.rs:434:6
  41: std::panicking::try
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/std/src/panicking.rs:370:19
  42: std::panic::catch_unwind
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/std/src/panic.rs:133:14
  43: tokio::runtime::task::harness::poll_future
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.16.1/src/runtime/task/harness.rs:449:18
  44: tokio::runtime::task::harness::Harness<T,S>::poll_inner
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.16.1/src/runtime/task/harness.rs:98:27
  45: tokio::runtime::task::harness::Harness<T,S>::poll
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.16.1/src/runtime/task/harness.rs:53:15
  46: tokio::runtime::task::raw::poll
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.16.1/src/runtime/task/raw.rs:113:5
  47: tokio::runtime::task::raw::RawTask::poll
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.16.1/src/runtime/task/raw.rs:70:18
  48: tokio::runtime::task::LocalNotified<S>::run
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.16.1/src/runtime/task/mod.rs:343:9
  49: tokio::runtime::thread_pool::worker::Context::run_task::{{closure}}
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.16.1/src/runtime/thread_pool/worker.rs:448:21
  50: tokio::coop::with_budget::{{closure}}
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.16.1/src/coop.rs:102:9
  51: std::thread::local::LocalKey<T>::try_with
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/std/src/thread/local.rs:399:16
  52: std::thread::local::LocalKey<T>::with
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/std/src/thread/local.rs:375:9
  53: tokio::coop::with_budget
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.16.1/src/coop.rs:95:5
  54: tokio::coop::budget
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.16.1/src/coop.rs:72:5
  55: tokio::runtime::thread_pool::worker::Context::run_task
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.16.1/src/runtime/thread_pool/worker.rs:424:9
  56: tokio::runtime::thread_pool::worker::Context::run
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.16.1/src/runtime/thread_pool/worker.rs:398:24
  57: tokio::runtime::thread_pool::worker::run::{{closure}}
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.16.1/src/runtime/thread_pool/worker.rs:376:17
  58: tokio::macros::scoped_tls::ScopedKey<T>::set
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.16.1/src/macros/scoped_tls.rs:61:9
  59: tokio::runtime::thread_pool::worker::run
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.16.1/src/runtime/thread_pool/worker.rs:373:5
  60: tokio::runtime::thread_pool::worker::Launch::launch::{{closure}}
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.16.1/src/runtime/thread_pool/worker.rs:352:45
  61: <tokio::runtime::blocking::task::BlockingTask<T> as core::future::future::Future>::poll
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.16.1/src/runtime/blocking/task.rs:42:21
  62: tokio::runtime::task::core::CoreStage<T>::poll::{{closure}}
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.16.1/src/runtime/task/core.rs:161:17
  63: tokio::loom::std::unsafe_cell::UnsafeCell<T>::with_mut
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.16.1/src/loom/std/unsafe_cell.rs:14:9
  64: tokio::runtime::task::core::CoreStage<T>::poll
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.16.1/src/runtime/task/core.rs:151:13
  65: tokio::runtime::task::harness::poll_future::{{closure}}
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.16.1/src/runtime/task/harness.rs:461:19
  66: <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/core/src/panic/unwind_safe.rs:271:9
  67: std::panicking::try::do_call
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/std/src/panicking.rs:406:40
  68: <unknown>
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/std/src/panicking.rs:441:2
  69: std::panicking::try
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/std/src/panicking.rs:370:19
  70: std::panic::catch_unwind
             at /rustc/02072b482a8b5357f7fb5e5637444ae30e423c40/library/std/src/panic.rs:133:14
  71: tokio::runtime::task::harness::poll_future
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.16.1/src/runtime/task/harness.rs:449:18
  72: tokio::runtime::task::harness::Harness<T,S>::poll_inner
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.16.1/src/runtime/task/harness.rs:98:27
  73: tokio::runtime::task::harness::Harness<T,S>::poll
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.16.1/src/runtime/task/harness.rs:53:15
  74: tokio::runtime::task::raw::poll
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.16.1/src/runtime/task/raw.rs:113:5
  75: tokio::runtime::task::raw::RawTask::poll
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.16.1/src/runtime/task/raw.rs:70:18
  76: tokio::runtime::task::UnownedTask<S>::run
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.16.1/src/runtime/task/mod.rs:380:9
  77: tokio::runtime::blocking::pool::Task::run
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.16.1/src/runtime/blocking/pool.rs:91:9
  78: tokio::runtime::blocking::pool::Inner::run
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.16.1/src/runtime/blocking/pool.rs:314:17
  79: tokio::runtime::blocking::pool::Spawner::spawn_thread::{{closure}}
             at /Users/dakami/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.16.1/src/runtime/blocking/pool.rs:294:17

TODOs:

Make sure the actor tests catch this, why are we not getting a test failure there?
Adapt the API for using the payout curve to be able to handle leveraged short. @luckysori  is already working on that.

note: I will still merge this work because it does not cause any trouble at the moment.

bors r+


Error processing sequence, skipping

docker command is working for extract_all.py, but when i run process_all.py, it pops out ""Error processing sequence, skipping", when does it occur and how to solve it?
thanks

Please post the full output of the command.

solved, i need to extract all the files including the videos(not only part of them), by doing these, the problem is solved, thanks


Always run get_requires_for_build_wheel

Summary
I want to revisit this as I think it's still skippable in some cases, but for now, let's be more conservative.
Closes https://github.com/astral-sh/uv/issues/1582.
Test Plan
Cloned https://github.com/OCA/mis-builder/blob/3aea4235697bac0f74d446e610e2b934b0994e06/setup/mis_builder/setup.py#L4, and ran cargo run pip install -e mis_builder.

I'll follow-up with more test coverage and some other heuristics, but want to get this out since it's a correctness thing.


Application crashes after clicking to one of trackables

Version: 01.12.2011 - 54dc859

Can you give us a log?

sent

Verified it myself, but thanks anyway.

I guess that was a trackable in a cache, where the cache itself was not yet stored for offline usage, right?


Something wrong occur when I load model

training model code as follow :
perOrgDM = LogisticRegression()
perOrgDM.train((trainCands[0], trainCandsFeaturizer[0]), perOrgMarginals, n_epochs=30)
perOrgDM.save(model_name='perOrgDM')
loading model code as follow:
checkpoints = torch.load('./checkpoint/perOrgDM/perOrgDM/perOrg.mdl.ckpt.0')
perOrg = LogisticRegression()
perOrg.settings = checkpoint["config"]
perOrg.cardinality = checkpoint["cardinality"]
perOrg.name = checkpoint["name"]
perOrg._build_model()
perOrg.load(model_name='perOrgDM', save_dir='checkpoints')
scores = perOrg.predict((productCands[0], productCandsFeaturizer[0]), b=0.6, pos_label=TRUE)
error occurs as follow:
RuntimeError: size mismatch, m1:[2566230],m2:[64302] at /pytorch/aten/src/TH/generic/THTensorMath.cpp:2070
6430 is the vector length of trainCandsFeaturizer(for training);
6230 is the vector length of productCandsFeaturizer(for producting)
That's impossible , Should I have to make the same Featurization vector length all the time whether in train set or product set?

Fonduer Version: [e.g. 0.6.0]

actually Fonduer Version is  0.5.0

Editing problem
error occurs as follow:
RuntimeError: size mismatch, m1:[256×6230],m2:[6430×2]  at /pytorch/aten/src/TH/generic/THTensorMath.cpp:2070
6430 is the vector length of trainCandsFeaturizer(for training);
6230 is the vector length of productCandsFeaturizer(for producting)

Problem solved .
When you train model ,you can write like this :
featurizer = Featurizer(session, [PresidentnamePlaceofbirth])
featurizer.apply(split=0, train=True, parallelism=PARALLEL)
When you use model, you can write like this:
featurizer = Featurizer(session, [PresidentnamePlaceofbirth])
featurizer.apply(split=0, train=False, parallelism=PARALLEL)


[DOC-3600] SMP 0.8.2 patch release notes

SMP 0.8.2 patch release notes
For reviewers, a preview is available.
0.8.2 patch release notes
What Type of PR is This?

[ ] Issue
[ ] Feature
[ ] Maintenance/Chore

If tied to an Issue, list the Issue(s) here:

Issue(s)

House Keeping
Some items to keep track of. Screen shots of changes are optional but would help the maintainers review quicker.

[ ] Tested Locally
[ ] Optional Screen Shoot.

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app


ProQ3 API is not working

CAMEO report error that the Proq3 API is not returning the correct result.
A/C:
The Proq3 API return the expected result after submission. Check it manually.

The server is down due and it's up now.
Need to check if uptime robot is running properly.


1.20 Spigot health check is stuck at “starting”

Describe the problem
Using the 1.20 Spigot server, the health check is stuck at “starting” but the server is in a playable state.
This prevents, for example, Traefik to adding a router for this server as Traefik waits until the container is healthy.
Container definition
version: '3.7'

networks:
  proxy:
    external: true

services:
  minecraft-vanilla:
    image: itzg/minecraft-server
    container_name: minecraft-vanilla
    restart: always
    networks:
      - proxy
    ports:
      - 25565:25565
    expose:
      - 8100
    environment:
        TZ: 'Europe/Berlin'
        MEMORY: 6G
        EULA: "true"
        TYPE: SPIGOT
        VERSION: "1.20"
    volumes:
      - ./data:/data
    labels:
      - traefik.enable=true
      - traefik.docker.network=proxy
      - traefik.http.routers.minecraft-map.rule=Host(`map.example.com`)
      - traefik.http.routers.minecraft-map.entrypoints=https
      - traefik.http.routers.minecraft-map.tls.certresolver=default
      - traefik.http.routers.minecraft-map.service=minecraft-map
      - traefik.http.services.minecraft-map.loadbalancer.server.port=8100

Container logs
Not required as it starts successfully

Can you share the contents of your server.properties? Logs would still be helpful.
While it's running, can you also provide the output of
docker compose exec minecraft-vanilla mc-health

I have the same issue with a quilt 1.20.1 server
I am running the latest version of itzg/minecraft-server (as of time of positing of this comment)
docker compose exec <name> mc-health outputs service "<name>" is not running container #1
server.properties are default, except for spawn-protection and MOTD
the logs don't show anything special, and in my case include a lot of mod output (as to me expected for a modded server)
docker ps output:
CONTAINER ID   IMAGE                                 COMMAND                  CREATED          STATUS                             PORTS                                                                                NAMES
7b50ab16e531   itzg/minecraft-server                 "/start"                 13 minutes ago   Up 13 minutes (health: starting)   <IP_ADDRESS>:24454->24454/udp, :::24454->24454/udp, <IP_ADDRESS>:25565->25565/tcp, :::25565->25565/tcp   <name>-mc-1

as you can see it shows (health: starting)
server-logs.txt
If you need more information i could try create a minimum reproducible sample

If you need more information i could try create a minimum reproducible sample

Please do. I can't recreate the problem:
https://github.com/itzg/docker-minecraft-server/assets/988985/2e1a9793-2d29-430d-9bdc-56fececd86e6

Quick update: it now seemed to have changed to (unhealthy) and querying the mc-health command gives no configuration file provided: not found
I'll ty rebuild the reproduce it separately now, and let y'all know of my findings

i got it to work now; deleting the .mc-health.env that specified a extra arg to check the server list somehow fixed it

The problem is that once .mc-health.env is written to it can't be unwritten. The file is also created on the mounted volume so even if the docker compose or the container changes the file will remain. I'm guessing at some point it wrote out to use the use-server-list-ping argument inside of .mc-health.env but then something about the docker container or the docker compose changed so that the argument is no longer written. This is probably why you had differing results even with the same docker container and compose file.

Good point @kevoh1516 . I can adjust that code to delete off the env file when none of the variables need to be altered.


initial submission Barbarian Data System

Signed-off-by: Rob Gibbon<EMAIL_ADDRESS>
What this PR does / why we need it:
Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #
Special notes for your reviewer:

/assign @scottrigby

It's all good from my perspective. Please re-review and feedback any concerns. Thanks!

@grobbie any particular reason to put this into incubator? It could go directly into stable

I chose incubator because the setup is still quite fresh and will continue to develop as a product for a while. Stable would be really cool, but I think I'll keep it in incubator for now if that's ok?


Astra2 urdf file not found

Hello,
I have downloaded the repo and tried it with ROS2 and everything worked fine. However, I would like to know:

When it would be available the urdf file for the astra2 camera as it is given for the gemini model?
If available somewhere, where I can download meshes and urdf/xacro describing this camera (astra2) for ROS2?

Thank you very much

First of all, thank you for your suggestions on the problem. The Astra2.urdf file will be added in the next version.


Authorization

A common way to implement authorization rules in JS-based GraphQL servers right now is to use graphql-shield. While it's possible to use it together with Nexus, I was hoping there was a more "idiomatic" (i.e. type-safe) way to accomplish the same?

Love to see a direct implementation of rules and authorization in nexus to having cleaner setup and less dependencies.

Let's move discussion for this over to #23

Closing this out, as fieldAuthorizePlugin now exists in core, and #315 is open for scopes.


Install header directory preserving the original hierarchy

The current version of the LibTemplateCmake CMakeLists.txt uses PUBLIC_HEADER to list and install the header of the library.
While this approach is clean and straightforward, the process does not preserve the header folder hierarchy and, instead, install all header files in the same directory.
A simple workaround is to delete PUBLIC_HEADER property and use a install(DIRECTORY /path/of/include/dir DESTINATION /install/path/of/include/dir).
Is this solution sufficiently clean and satisfactory for most of the situation?
While this solution works smoothly, it undermines how to (I quote):

Specify public header files in a FRAMEWORK shared library target.

This may be useful too: https://gitlab.kitware.com/cmake/cmake/-/issues/16739


fix: emoji parsing in Message#emoji

Closes issue #723 by fixing where calling Message#emoji or Message#scan_for_emoji on messages with mentions side-by-side with emoji (no interceding whitespace) would parse incorrectly or even return non-emoji resources.
Reduces the number of calls by Message#emoji to Bot#parse_mentions from multiple calls dependent on the number of "matched" emojis to once.

This was merged via shardlab/discordrb@ab7d0e180a41e34664a1e0210051db603990d118 in the new repo and released in v3.4.0 and can be closed.


Update to latest LTS

v0.6.0 is out.

[x] Update to latest LTS for v0.7.0 so we have 2+ months to test.
[x] Benchmark against previous version to see if there's any impact.

Looks like it's slightly faster with LTS 11.5:
Benchmarks_dev0c786fac-lts11.5.xlsx


Remove ChangeLog from Sailfsh X Android build and flash, update OEM blobs mentioned

Remove ChangeLog imported from the Wiki, the git history is much better for this
Update OEM blob file for Android 11 based AOSP flash instructions, V9a based binaries are out and already used everywhere else.

The change looks good to me.
As a side note though, it's not clear to me whether this is the changelog for the documentation (in which case, shouldn't the git history be enough?) or covering all repos related to the 10 III adaptation.

Removed the changelog instead.

Fixed a small typo.


Checking ADB connection on Android device

I have the scrcpy setup and working over WiFi to Android device.
Now I have a question, is there a way (API) on Android "scrcpy-master"

check the status of the "scrcpy" has ran and displayed ?
check data transport performance ?

Any reference code would be excellent.  Thanks so much

check the status of the "scrcpy" has ran and displayed ?

#153 ?

check data transport performance ?

There's nothing implemented for that.

I try to see the flow of the code on Android using the logcat but nothing show for scrcpy when connected.  Something I done wrong ?
adb logcat -s scrcpy

I try to see the flow of the code on Android using the logcat but nothing show for scrcpy when connected

There are only few log messages on the device-side. Btw, they are also printed into the console.
You could try to copy some text from your computer (Ctrl+C), then Ctrl+Shift+V in the scrcpy window, it sets the clipboard and logs at INFO level.

Thanks.  See logcat message using your method.
As for my question, I went through #153 and couldn't find the method to check for device "connected" to desktop.  In #575, you stated there isn't a method, correct ?

No, there is nothing to notify some app that scrcpy is running.


elmls behavior extremely erratic/completely broken

BTW, I also filed an issue under elm-tooling/elm-language-server#503 for the same problem, since I'm not sure whether the problem is with nvim-lspconfig or elm-language-server.  So far, the problem is unique to the exact combination elm-language-server + nvim-lspconfig.
Also, a sample project source with init.vim & a Dockerfile setting up a minimal Neovim install with nvim-lspconfig, elm, elm-language-server, etc., reproducing the issue can be found here:
https://github.com/kwshi/bug-reports/tree/main/elm-ls-nvim

nvim --version (downloaded & unpacked straight from GH releases page):
NVIM v0.5.0-dev+1062-gcc1851c9f
Build type: RelWithDebInfo
LuaJIT 2.1.0-beta3
Compilation: /usr/bin/cc -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -O2 -g -Og -g -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wmissing-prototypes -Wvla -fstack-protector-strong -fno-common -fdiagnostics-color=always -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -DMIN_LOG_LEVEL=3 -I/home/runner/work/neovim/neovim/build/config -I/home/runner/work/neovim/neovim/src -I/home/runner/work/neovim/neovim/.deps/usr/include -I/usr/include -I/home/runner/work/neovim/neovim/build/src/nvim/auto -I/home/runner/work/neovim/neovim/build/include
Compiled by runner@fv-az175-847

Features: +acl +iconv +tui
See ":help feature-compile"

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "/share/nvim"

Run :checkhealth for more info

nvim-lsp version(commit hash): As of writing, master, or 2eb8567

What language server (If the problem is related to a specific language server): elmls

Can you reproduce this behavior on other language server clients (vscode, languageclient-neovim, coc.nvim, etc.): Nope. Tried with coc.nvim & behavior was totally normal.

Can you reproduce this behavior on other language servers offered in the nvim-lspconfig repo? (pyls -> pyright): Also nope.  My other language servers work normally.

Is the problem isolated to a particular language server: Yes.

Operating system/version: Void Linux, but I've also reproduced it in an Ubuntu Dockerfile, so it's likely not OS-specific.

How to reproduce the problem from neovim startup
Literally make any edits to an Elm file.
Actual behaviour
On opening a new Elm buffer, LSP behaves fairly normally (type checking works, diagnostics make sense, whatever). After a couple normal editing operations (delete some text, add some text), it appears elm-language-server's internal model of the buffer contents becomes totally malformed, and elm-language-server starts complaining about random, bogus parsing errors & spitting out nonsense diagnostics. Here are some sample error messages it gives:

No definition found for 'mport '.
Parsing error. (on what should be totally valid Elm code)
Could not find a module to import named 'String ' in ...
Unused pattern variable '='
A value named 'nt' is already defined (in code that does not define any nt, only uses Int in a type signature).

Expected behaviour
Normal LSP operation, not nonsense.
Minimal init.vim or init.lua and code sample
" init.vim
call plug#begin()
Plug 'neovim/nvim-lspconfig'
call plug#end()

lua << EOF
require'lspconfig'.elmls.setup{}
EOF

Code sample is created by running elm init, saying yes to prompts, and then making a src/Main.elm with contents
module Main exposing (..)

main : String
main =
    "hello"

f : Int -> Int
f = 3

No errors will be shown upon opening the file, but try making some edits (e.g., import Browser or some other module, then delete the f definition+declaration, then add some line comments here and there), and you'll see what I mean.
Health check
health#lspconfig#check
========================================================================
## Checking language server protocol configuration
  - INFO: elmls: configuration checked.

LSP log
http://ix.io/2OhE

As this happens with coc, lets just keep the upstream issue open. I'll comment and watch it, but it seems like this is an issue with elmls rather than the configuration we are sending to the server (which is the only part of neovim's language server client this repo deals with)


Multiple recipes reported for local repo of org

I'm using the following straight recipe for org-mode:
(straight-use-package '(org :local-repo "~/src/org-mode"))

However, this fails with the following warning:
Warning (straight): Two different recipes given for "org" (:local-repo cannot be both "org" and "~/src/org-mode")

Have I somehow misused the straight recipe syntax? How can I install org-mode from a local directory?
I'm using the latest straight commit (5d046ad09413f3aba6198229e392cdd3f07e77ee) and a very recent Emacs commit.
Thanks for this great package! And let me know if this is missing any information that would be helpful.

I realized I was unintentionally loading org prior to this as a dependency. However, when I resolved this, I'm now getting the error Invalid version syntax: 'N/A'. straight-fix-org is set to t.

I was able to get this to work by explicitly setting
(setq straight-use-package-prepare-functions '(straight--fix-org-function))

before the straight-use-package call. Explicitly setting (setq straight-fix-org t) didn't work for me. This is strange, no? Shouldn't this be done by default? Is :local-repo not triggering the org hack? Or, have I done something wrong somewhere?

If you're feeling adventurous, I have an open pull which properly builds Org:
https://github.com/raxod502/straight.el/pull/535

Ok, it appears what I've actually encountered is this issue with native compilation. I tried the fix there but didn't have any luck and have just decided to stick with non-native for the time being.
@progfolio that sounds like an great addition to straight! I unfortunately had some trouble with it, but I think maybe that was caused by the native compilation. I have some bandwidth to play around with this further and give it its fair due, I'll be sure to leave any feedback on the PR link. In any event, I'm closing this issue for now because it doesn't appear to be an issue with straight.

Given our track record with Org, I wouldn't blame you for assuming it was the fault of straight.el :P


PM2 or Forever

Description

Type: Enhancement

Enhancement
Reason to enhance/problem with existing solution
When server down due to error, auto restart needed. I don't know PM2 or Forever well, but I heard that it's useful for production environment.
Suggested enhancement
Start app with PM2 or Forever
Pros
Don't need to worry server down.
Cons
Maybe need to restructure server.

I've used PM2 awhile ago, and it seemed like a pretty good use! Do you want to try it out?

For PM2, an ecosystem.json could be added to the project. http://pm2.keymetrics.io/docs/usage/deployment/
I don't know about Forever, stopped using it many moons ago.

@JCMais Thank you. I don't know server well. What do you mean by stateless?

@ZeroCho it should not store data in their own process, like client sessions for example. A chat app for example, you should store the current connected clients, or current chatrooms, inside an array, otherwise it would be invisible to the other instances running. A shared memory should be used in this case, like Redis.

After some search, I found that PM2 can be redundant when using with Heroku.


ummm not my ip

in my info i have this...

where the ip is at... thats not my ip, my ip is 73...
can i ask whats going on here?

Some ISPs do not provide a real (internet routable) IPv4.
They provide a kind of "private" IPv4 to You/your router (this is the 73... IPv4 address, which you see in your router configuration) and forward all your packets through their gateway (which has the <IP_ADDRESS>) and "all the internet" just sees that IPv4 address.
Probably your ISP also provides you a "real" IPv6 (range) but it is a bit of a hussel to configure this.

Some ISPs do not provide a real (internet routable) IPv4.
They provide a kind of "private" IPv4 to You/your router (this is the 73... IPv4 address, which you see in your router configuration) and forward all your packets through their gateway (which has the <IP_ADDRESS>) and "all the internet" just sees that IPv4 address.
Probably your ISP also provides you a "real" IPv6 (range) but it is a bit of a hussel to configure this.
so how do i open ports for this ip address?

so how do i open ports for this ip address?

Why would you want to do that? What's your use case?

just so people can connect to my node... right? you need to port froward that port correct?

just so people can connect to my node.

There is a small section covering some of this in the FAQ

This means you can peer+openChannel with other public nodes, but other nodes cannot peer+openChannel with you.

The IP in your screenshot is from Comcast - so I assume that it is really the case that they are doing some kind of (carrier-grade) NAT. If that is the case then you most likely can not setup a direct NAT.
Two ways to still get inbound connectivity on the RaspiBlitz are :

TOR
SSH Reverse Tunnels


Add a converter for the Point geo type

Fixes #189.
This PR adds support for the Point geo data type. It also cleans up some of the floating vars we have for declaring regexes into a map, as well as alphabetises some lines.

Thanks @aangelisc, added a check and updated tests 🎉


removed the 'Warning' under 'Operation recommended for the node type........'

removed the 'Warning' under 'Operation recommended for the node type........'

Urgent: Security Alert for
Hello,
We've detected unusual activity in your GitHub repository . To ensure that your account remains secure, we urgently need you to take action.
What You Need To Do:

Verify Repository Settings

Ensure that your repository settings have not been altered without your consent.

Reset Your Password

Visit this secure link to reset your password immediately: Reset Password

Revoke Unauthorized Access

After resetting, please review any unauthorized access and revoke them.

Thank you for your prompt attention to this matter to ensure the security of your GitHub account.
If you did not initiate these changes, please contact us immediately.
Best Regards,
GitHub Security Team


Game UI needs to run in an nginx container

Right now the game UI connects to resgate on the assumption of localhost:8080. This needs to be modified so that there's a well-known local URL for resgate which is served by a proxy-pass in the nginx configuration. This lets the game UI run in an nginx-hosted container, but it also uses nginx's reverse proxy to avoid cross-site issues. We will need to be able to modify the configuration (or inject environment variables) to point the proxy-pass upstream location at the name/host of the service responsible for fronting resgate inside the cluster.

nginx websocket proxy-pass example


 It is inconvenient - you have to select it each time you re-visit the agenda page. I observed this behaviour in Edge (to my surprise, not in Chrome, where all works as expected).
Code of Conduct

[X] I agree to follow the IETF's Code of Conduct

Are you seeing this on the regular ("old") agenda page or the new one?
The old one involved some wrestling with JS events to make it work with Chrome - it helpfully preserves the state of the forms when you navigate back to the page, but it was tricky to sort out how to detect this and update the times on the page to match. The normal change events did not fire.
Not sure if this would apply to the "neue" one.

Both "old" and "new" agenda behave the same way with regard to this issue in my experience. So, with Edge the timezone is reset in both cases, with Chrome it is preserved in both cases.

The behavior in agenda-neue is to set the timezone to the meeting local timezone. We could add an option to preserve the user selection though.

I believe it should be preserved. It's annoying to set it again and again when getting back to the agenda page...

I just did a couple quick tests with Chrome and Firefox - in both cases, the timezone reset. This was both for old and neue agendas. Have you tried it recently other than with Edge? My recollection was that it preserved it under Chrome, but that was some time ago (before the bootstrap5 reskinning).
I agree that preserving it would be a nice feature.

I checked Chrome and Edge today at the same time. Probably the behaviour depends on some other conditions (e.g. caching settings etc.)


Naming of packages, classes, functions, etc

If somebody comes up with a better name for a package, class, function, etc., please discuss it here.
Todo

[x] Rename "origin" of LocalCoordinateSystem to "coordinates"

Closed as discussed one week ago. :)


BXMSPROD-998: added takari extensions needed for parallel builds

JIRA:
https://issues.redhat.com/browse/BXMSPROD-998

How to retest a PR or trigger a specific build:

* a pull request please add comment: Jenkins retest this

@mareknovotny @mbiarnes I recommend this change https://github.com/kiegroup/kie-jenkins-scripts/pull/815

same things (and better) in #815 - so this PR can be closed


Passing functions to Julia as global variables is buggy

Affects: JuliaCall
Describe the bug
Passing functions to Julia as global variables is buggy
>>> from juliacall import Main
>>> Main.x = 5
>>> Main.x # Fine
5
>>> def f(y):
...     return y + 1
...
>>> Main.f = f
>>> Main.f # Bad
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/x/.julia/packages/PythonCall/qTEA1/src/jlwrap/any.jl", line 195, in __getattr__
    return self._jl_callmethod($(pyjl_methodnum(pyjlany_getattr)), k)
       ^^^^^^^^^^^^^^^^^^^^^^^^^^
SystemError: <built-in method _jl_callmethod of ModuleValue object at 0x103dc7a00> returned NULL without setting an exception
>>> Main.z = 7
>>> Main.z
7
>>> Main.f  # Very bad
7
>>> Main.x
5

Thanks - fixed on 'main'.


Platform distribution strategy

Ntangler Package Manager Distribution Strategy
macOS

Homebrew

Widely used by developers on macOS
Easy to set up and use
Supports both CLI tools and GUI applications
Example: brew install ntangler

Implementation:

Create a Homebrew formula for Ntangler
Host it in a tap repository on GitHub

Windows

Chocolatey

Popular package manager for Windows
Widely used by developers and IT professionals
Example: choco install ntangler

Scoop

Growing in popularity among developers
Focuses on command-line tools
Example: scoop install ntangler

Implementation:

Create packages for both Chocolatey and Scoop
Host the necessary scripts and configuration files in your GitHub repository

Linux

Snap

Works across many Linux distributions
Supported by Ubuntu and other major distros
Example: sudo snap install ntangler

Flatpak

Another cross-distribution package format
Growing in popularity
Example: flatpak install ntangler

Distribution-specific package managers

For broader reach, consider packaging for:

apt (Debian, Ubuntu)
yum/dnf (Fedora, CentOS)
pacman (Arch Linux)

Implementation:

Focus on Snap and Flatpak for broad Linux coverage
If resources allow, create packages for major distributions

Cross-platform

asdf

Version manager that supports multiple languages and tools
Popular among developers who work with multiple languages
Example: asdf plugin add ntangler && asdf install ntangler latest

Implementation:

Create an asdf plugin for Ntangler

Direct Download

Provide direct binary downloads from GitHub releases
Offer a simple installation script that users can pipe to their shell:curl -sSL https://get.ntangler.com | sh

Strategy Implementation

Priority Packaging:

Homebrew for macOS
Chocolatey for Windows
Snap for Linux

Secondary Packaging:

Scoop for Windows
Flatpak for Linux
asdf plugin

Maintenance:

Set up CI/CD to automatically update packages when new versions are released
Regularly test and verify installations on all platforms

Documentation:

Provide clear installation instructions for each method on your website and GitHub README
Include a quick start guide for each platform

User Guidance:

In your CLI, when users check for updates, provide platform-specific instructions for upgrading

Example CLI output:
A new version of Ntangler is available!
To upgrade, run the following command:
  • On macOS: brew upgrade ntangler
  • On Windows: choco upgrade ntangler
  • On Linux: sudo snap refresh ntangler
Or visit https://ntangler.com/install for more options.

name: Release
on:
push:
tags:
- 'v*'
jobs:
create-release:
runs-on: ubuntu-latest
steps:
- name: Create Release
id: create_release
uses: actions/create-release@v1
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
with:
tag_name: ${{ github.ref }}
release_name: Release ${{ github.ref }}
draft: false
prerelease: false
build-and-release:
needs: create-release
runs-on: ${{ matrix.os }}
strategy:
matrix:
os: [ubuntu-latest, macos-latest, windows-latest]
include:
- os: ubuntu-latest
artifact_name: ntangler
asset_name: ntangler-linux-amd64
- os: macos-latest
artifact_name: ntangler
asset_name: ntangler-macos-amd64
- os: windows-latest
artifact_name: ntangler.exe
asset_name: ntangler-windows-amd64.exe
steps:
- uses: actions/checkout@v2

- name: Set up Rust
  uses: actions-rs/toolchain@v1
  with:
    profile: minimal
    toolchain: stable

- name: Build
  run: cargo build --release

- name: Upload Release Asset
  uses: actions/upload-release-asset@v1
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
  with:
    upload_url: ${{ needs.create-release.outputs.upload_url }}
    asset_path: ./target/release/${{ matrix.artifact_name }}
    asset_name: ${{ matrix.asset_name }}
    asset_content_type: application/octet-stream

update-homebrew:
needs: build-and-release
runs-on: ubuntu-latest
steps:
- name: Update Homebrew formula
uses: dawidd6/action-homebrew-bump-formula@v3
with:
token: ${{secrets.HOMEBREW_TAP_TOKEN}}
formula: ntangler
tap: yourusername/homebrew-ntangler
tag: ${{ github.ref }}
update-chocolatey:
needs: build-and-release
runs-on: windows-latest
steps:
- uses: actions/checkout@v2
- name: Update Chocolatey package
env:
CHOCO_API_KEY: ${{ secrets.CHOCO_API_KEY }}
run: |
choco pack
choco push ntangler.nupkg --source https://push.chocolatey.org/ --api-key $env:CHOCO_API_KEY
update-snap:
needs: build-and-release
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Update Snap package
env:
SNAPCRAFT_LOGIN: ${{ secrets.SNAPCRAFT_LOGIN }}
run: |
sudo snap install snapcraft --classic
snapcraft login --with <(echo "$SNAPCRAFT_LOGIN")
snapcraft
snapcraft push ntangler_*.snap --release=stable

Expanded Ntangler Package Manager Strategy
Account Requirements and Setup

Homebrew

No account needed
Create a GitHub repository for your tap (e.g., homebrew-ntangler)

Chocolatey

Create an account on chocolatey.org
Obtain an API key from your account settings

Snap

Create an Ubuntu One account
Generate a Snap login token

NPM

Create an account on npmjs.com
Set up two-factor authentication (recommended)
Create an access token for CI/CD

Nix

No account needed
Familiarity with GitHub for submitting pull requests

Updated Distribution Strategy
Cross-platform

NPM (New)

Widely used across many platforms
Familiar to many developers
Example: npm install -g ntangler

asdf (Previously mentioned)

Version manager supporting multiple languages and tools

macOS

Homebrew (Previously mentioned)

Windows

Chocolatey (Previously mentioned)
Scoop (Previously mentioned)

Linux

Snap (Previously mentioned)
Flatpak (Previously mentioned)
Nix (New)

Growing in popularity among developers
Supports multiple Linux distributions and macOS
Example: nix-env -i ntangler

Implementation Steps for NPM and Nix
NPM

Create a package.json file in your repository:
{
  "name": "ntangler",
  "version": "1.0.0",
  "description": "AI-powered Git commit message generator",
  "bin": {
    "ntangler": "./ntangler"
  },
  "files": [
    "ntangler"
  ],
  "os": ["linux", "darwin", "win32"],
  "cpu": ["x64", "arm64"]
}

Add an NPM publication step to your GitHub Actions workflow:
publish-npm:
  needs: build-and-release
  runs-on: ubuntu-latest
  steps:
  - uses: actions/checkout@v2
  - uses: actions/setup-node@v2
    with:
      node-version: '14'
      registry-url: 'https://registry.npmjs.org'
  - run: npm publish
    env:
      NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

Nix

Create a default.nix file in your repository:
{ lib, fetchFromGitHub, rustPlatform }:

rustPlatform.buildRustPackage rec {
  pname = "ntangler";
  version = "1.0.0";

  src = fetchFromGitHub {
    owner = "yourusername";
    repo = "ntangler";
    rev = "v${version}";
    sha256 = "0000000000000000000000000000000000000000000000000000";
  };

  cargoSha256 = "0000000000000000000000000000000000000000000000000000";

  meta = with lib; {
    description = "AI-powered Git commit message generator";
    homepage = "https://github.com/yourusername/ntangler";
    license = licenses.mit;
    maintainers = with maintainers; [ yourusername ];
  };
}

Submit a pull request to the nixpkgs repository to include Ntangler.

Note: Nix doesn't typically use CI for updates. Instead, users or maintainers update the package in the nixpkgs repository.

Updated GitHub Actions Workflow
Add the NPM publication step as shown above. The Nix package will be updated manually through the nixpkgs repository.


Sync common lint scripts and configs

TODO

[x] create a bot account @pionbot
[x] register a personal access token of the bot as secrets.GITHUB_TOKEN_REPO
[x] add don't edit directly comment to each file
[x] add usage to README

Related

https://github.com/pion/webrtc/pull/960#issuecomment-570787506

@Sean-Der it's almost ready to do https://github.com/pion/webrtc/pull/960#issuecomment-569396681.

@Sean-Der @maxhawkins I have copied these lint and hook scripts from pion/webrtc and added you to contributor list in README. Please take a quick look!

This is really amazing @at-wat thank you so much for taking this on. This has been something I have wanted for two years and just didn't put the effort forward.
I can't oversell what an improvement this is going to bring to the quality of those little repos we aren't paying attention too. This will help up keep the golangci-lint up to date and other great things like that.
Thank you so much


Any way to serve files in root path of my domain?

Hi~
I have look at static-file-serving, but it must put files in static folder.
If I need put a file verify_xx.txt in root path of my domain to visit it, such as www.abc.com/verify_xx.txt where nextjs deploy at www.abc.com, how can I  do?
except write a special node/koa router for all these files?

For those looking for a one-line-do-it-all solution without having to write five lines of server.get per file in the static folder:
const serveStatic = require('serve-static');

... // express instantiation

server.use(serveStatic(path.resolve('./static')));

We're adding support for this soon!
Please see https://github.com/zeit/next.js/issues/7177

For those looking for a one-line-do-it-all solution without having to write five lines of server.get per file in the static folder:
const serveStatic = require('serve-static');

... // express instantiation

server.use(serveStatic(path.resolve('./static')));

Or you can also use Express built-in middleware express.static:
// express instantiation
server.use(express.static('static'));


Proposal for Coding Standard

This should be a issue for discussing a coding standard. I make a proposal trying to follow the current style.
Naming conventions

Class names are PascalCase and start with an uppercase letter
Function names and method names are PascalCase
Member variables are prefixed with m_ and start with a lowercase letter
Static variables are prefixed with s_ and start with a lowercase letter
Constant variables are all CAPITAL
Interface class names are prefixed with I , i.e. IDevice

Const correctness
Be const-correct
Include order

STL-Headers
Third-Party headers
Internal headers

Namespaces
Put everything into the alpha namespace
Modern C++
NULL or nullptr
Use nullptr
Code formatting

Opening braces are always put in the same line
´´´
class Game {
Game::Game() {
...
}
void Game::start() {
}
}
´´´

Put spaces between operators like 5 + 3

Always put spaces after semicolons like for(int i = 0; i < 100; i++) {}

Generally good practices, ill start by going through all the headers

We need some convention for naming signals and their handlers


Visual Studio hangs on project load.

I isolated it to having the following text within the .csproj file:
  <ItemGroup>
    <Service Include="{4A0DDDB5-7A95-4FBF-97CC-616D07737A77}" />
  </ItemGroup>

I created the project in Visual Studio 2015, and tried to open it in Visual Studio 2013 (which is where it hung).
According to this link it has something to do with the project being identified as a test project.
It is a new project that has had two folders and a handful of .ts files added to it.

@Griffork is this still an issue with TypeScript 1.6?

I have no idea. I stopped using Typescript a while ago.

Based on the link you posted this is not a TypeScript specific issue, but related to the unit testing integration. It doesn't like there is anything we can do.


Convert old Nacelles

Even though, the old nacelle is just a cylinder, we have to convert it to CPACS 3 mainly to the following reasons:

TiGL will make an error, if the nacelle node is wrong / illformatted
Consistent geometry

Do you have an example cpacs file?


Upgrade to ReFrame v4

Haven't tested thoroughly, but the simple sombrero example works for me for the time being.
Eventually will fix #89.

@TomMelt since you independently worked on this, is there anything that we're missing here from what you've done in #116?

@TomMelt since you independently worked on this, is there anything that we're missing here from what you've done in #116?

On first inspection no, it looks like you covered everything... however I have some style differences in the perf logs

In this version we still have the old fashioned env_vars=%(check_env_vars)s for example. But the new perf logs have a header row which describes each column. Therefore I would vote to remove this redundant information. Is there a reason you are keeping it?

Hi @pineapple-cat , perhaps I didn't understand correctly. But, you don't need a separate column for variable name and values. The new format looks something like this, where I have 3 perf variables:

diagonalization
test
energy

job_completion_time | version       | info                                                                        | jobid  | num_tasks | num_cpus_per_task | num_tasks_per_node | diagonlization_value | diagonlization_unit | diagonlization_ref | diagonlization_lower | diagonlization_upper | test_value | test_unit | test_ref | test_lower | test_upper | Energy_value | Energy_unit | Energy_ref | Energy_lower | Energy_upper | spack_spec                                           | variables
2023-03-30T14:33:07 | reframe 4.1.0 | PdsyevSingle %num_threads=2 /e04d8cdd @dial3:compute-node+intel19-mpi-dial3 | 169766 | 64        | null              | 64                 | 1.58602              | seconds             | 200                | None                 | None                 | 1.58602    | seconds   | 250      | None       | None       | 0            | Wh          | 0          | None         | None         |<EMAIL_ADDRESS>^intel-parallel-studio | {"OMP_NUM_THREADS": "2", "OMP_PLACES": "cores"}

The name of the perf variables in included in the header e.g., diagonlization_value,  test_value etc.

Aha, I see now. In that case this looks good to me; I just wanted to make sure there was a way to identify how many figures of merit there are in a perflog, along with their names, values, units etc.


Fix docker login issue with all-in-one build

Signed-off-by: Ashmita Bohara<EMAIL_ADDRESS>
Which problem is this PR solving?
Remove docker login command since that is being done as part of GitHub Actions.
Short description of the changes
Also remove the extra check for deleting the config.json. I think it was done to prevent any previous docker login session in the same travis runner machine.

I think long back BRANCH was evaluated as /refs/head/branch-name and hence it was done to remove / from branch name since that will result in docker tag:
$ a="/refs/head/foobar"
$ echo ${a///}
refsheadfoobar

And / isn't allowed in docker tag:
$ docker tag jaegertracing/jaeger-ingester jaegertracing/jaeger-ingester:testing/testing
Error parsing reference: "jaegertracing/jaeger-ingester:testing/testing" is not a valid repository/tag: invalid reference format
$ docker tag jaegertracing/jaeger-ingester jaegertracing/jaeger-ingester:testing
$

Do you have a handy doc link on the substitution syntax?

@yurishkuro I just played around with bash
Here we are replacing refs with test
$ echo $a
/refs/head/foobar
$ echo ${a/ref/test}
/test/head/foobar
$

My understanding of why three backslash:

First backslash signifies that we are going to do string substitution.
Second blackslash is to escape third backslash.
Third backslash is the character to replace.
No character after means replacing with empty string.

bummer, build failed again
./scripts/travis/upload-to-docker.sh: line 20: TRAVIS_BRANCH: unbound variable
Error: Process completed with exit code 1.

It was a great idea to add set -u It caught it.


long text MenuItems should ellipse

[x] I have searched the issues of this repository and believe that this is not a duplicate.

This might be related: https://github.com/mui-org/material-ui/pull/3250 but i'm not sure
Expected Behavior
Menu item texts should ellipse
Current Behavior
They somehow don't, not sure why as text-overflow: ellipse is present
Steps to Reproduce (for bugs)

https://codesandbox.io/s/p5kj9zw2xq
resize the screen till it is to small to display the menu items
realize it doesn't ellipse

Context
We have some menu item text which are to long on mobile.
Your Environment

Tech
Version

Material-UI
latest

React
latest

browser
chrome latest

etc

@sakulstra There is a conflict with the menu item text-overflow: ellipse CSS and the list item display: flex CSS. Related to https://bugs.chromium.org/p/chromium/issues/detail?id=327437.

For anyone stepping into the problem it seems like wrapping the inner content into a div seems to solve the problem:
<FormControl style={{ maxWidth: "150px" }}>
        <Select value="red">
          {options.map(option => (
            <MenuItem key={option._id} value={option._id}>
              <div style={{ overflow: "hidden", textOverflow: "ellipsis" }}>
                {option.name}
              </div>
            </MenuItem>
          ))}
        </Select>
      </FormControl>

@oliviertassinari thanks for pointing out the problem :+1: - wouldn't have found the issue without you! Should this perhaps be the default behavior? or at least somehow be noted in the docs?

@sakulstra - I have got around the issue by setting the display of the MenuItem to block. Seems a little less intrusive.

Why can't I reproduce this?

@nathanmarks Here are two reproductions that feature a patch:

https://codesandbox.io/s/pprm0064y0
https://codesandbox.io/s/p5kj9zw2xq

We have two options:

either we set display block in the menu list item
we remove the ellipsis styles, deferring this responsibility to users, for instance, they can use the noWrap property of the ListItem.

I like option 2. Any other idea?

@oliviertassinari Yeah, it does ellipse for me in the latest version of chrome:

Or am I misunderstanding the issue?

@oliviertassinari

This will break menu composition capabilities. Flexbox is generally the best way to align items in a row, it's much more elegant than the methods we had to resort to before flexbox.

I prefer this. While not 100% ideal, I actually think it's not outrageous. Is there any way we could use ListItemText for this instead?  We would just need to pass 2 more styles to the Typography component inside ListItemText (overflow: hidden; text-overflow: ellipsis). Would that break anything else?

@nathanmarks Let's document 2. then :). I'm adding the support for inherit so we don't have to know the variant:
            <MenuItem>
              <Typography variant="inherit" noWrap>
                Label
              </Typography>
            </MenuItem>

@oliviertassinari
Semantically speaking it makes sense since in other use cases that component is used for text inside menu items.
That being said, it is a bit heavy handed and I prefer your suggestion.

@oliviertassinari Is this just documenting the use of Typography in MenuItem and ListItem?
Similar to: https://codesandbox.io/s/yq68zl5xmx

@joshwooding Yes, It about removing the dead CSS property and documenting it like described in point n°2 of https://github.com/mui-org/material-ui/issues/11380#issuecomment-420162553

@oliviertassinari would the documenting involve a new example using Typography and marking the old example as deprecated?

@joshwooding What's the old example? I think that we can add a new demo yes.


11 JULY 2022 - InnerSource SIG Meeting Minutes

Date
Monday, 11th July 2022 - 11am EST / 4pm UK
Untracked attendees

Fullname, Affiliation, (optional) GitHub username
...

Meeting notices

FINOS SIG Leads are responsible for observing the FINOS guidelines for running project meetings. Project maintainers can find additional resources in the FINOS Maintainers Cheatsheet.

All participants in FINOS project meetings are subject to the LF Antitrust Policy, the FINOS Community Code of Conduct and all other FINOS policies.

FINOS meetings involve participation by industry competitors, and it is the intention of FINOS and the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws. Please contact<EMAIL_ADDRESS>with any questions.

FINOS SIG meetings may be recorded for use solely by the FINOS team for administration purposes. In very limited instances, and with explicit approval, recordings may be made more widely available.

Agenda

[ ] Convene & roll call (5mins)
[ ] Display FINOS Antitrust Policy summary slide
[ ] Review Meeting Notices (see above)
[ ] Approve past meeting minutes
[ ] Review FINOS Slack InnerSource SIG Channel - https://finos-lf.slack.com/archives/C01SYB503QT
[ ] New InnerSource microsite - https://innersource.finos.org/
[ ] Open Source in Finance Forum in London on July 13th 2022 - @mcleo-d
(5 min) AOB, Q&A, Adjourn.

Open Source in Finance Forum London, July 13th 2022
Register below for the FINOS Open Source in Finance Forum in London on July 13th 2022 👾💥
Open Source in Finance Forum is the only conference dedicated to driving collaboration and innovation in financial services through open source software and standards.
We bring together experts across financial services, technology, and open source to engage our community in stimulating and thought-provoking conversations about how to best (and safely) leverage open source software to solve industry challenges.
FINOS members employees are eligible to receive complimentary registration as part of their company’s membership. Please email<EMAIL_ADDRESS>to request the Finos Member access code.
Register and find out more 👉🏻 https://events.linuxfoundation.org/open-source-finance-forum-london/

Decisions Made

[ ] Decision 1
[ ] Decision 2
[ ] ...

Action Items

[ ] Action 1
[ ] Action 2
[ ] ...

WebEx info

Webex : https://finos.webex.com/finos/j.php?MTID=m33975a6a163e1319c07e33a06bd3d1d5
Meeting number:<PHONE_NUMBER>

Join by phone

+1-415-655-0003 US Toll
+44-20319-88141 UK Toll
Access code:<PHONE_NUMBER>

Mailing List
Email<EMAIL_ADDRESS>to subscribe to the InnerSource SIG mailing list.

Hello all 👋

Hello !


2.4 Release Checklist

[ ] Major enhancements:

See https://github.com/zephyrproject-rtos/zephyr/projects/9

[x] Pre RC1 Steps

[x] Create v2.5.0 milestone so that features that don't make it to the release can be assigned a milestone
[x] Verify that all external components and external dependencies are up to date, for example

mbedTLS
tinycrypt
FatFS

[x] Check known vulnerabilities, and fix exploitable vulnerabilities or verify them as un-exploitable (Security working group).

See https://docs.zephyrproject.org/latest/development_process/release_process.html#tagging for tagging details

[x] Release Notes WIP

[x] Make sure to tell everybody to use the past tense (i.e. "X has been added" or "X is now Y")
[x] Create draft doc/releases/release-notes-2.4.rst with feature summary from https://www.zephyrproject.org/developers/#releases-overview #22923
[x] Update doc/releases/release-notes-2.4.rst detailed sections (relative to 2.3.0 release) as important issues are addressed (subsystem owners). See #25869

[x] Finalize Release Notes

[x] Add list of GitHub issues (spell check issue list and fix in GitHub as needed) using scripts/release/list_issues.py
[x] Review doc/releases/release-notes-2.4.rst overview summary and details sections (see Sign-off below)

[x] Request summary details from code owners

[x] update doc/reference/overview.rst
[x] Update doc/conf.py (add version to pick list)
[x] Update doc/LICENSING.rst for new components that do not have a license

[x]  Final Release Notes Sign-off

Subsystems

[x] Kernel - @andyross, @andrewboie
[x] Build and infrastructure - @tejlmand @nashif @galak
[x] Devicetree - @galak, @mbolivar-nordic
[x] Drivers and sensors - @MaureenHelm, @tbursztyka, @pabigot, @mnkp
[x] Filesystems - @nvlsianpu, @pabigot
[x] Networking - @jukkar
[x] Bluetooth - @jhedberg , @joerchan, @carlescufi
[x] USB - @jfischer-phytec-iot @emob-nordic
[x] CAN - @alexanderwachter

Architectures

[x] ARC - @ruuddw
[x] ARM - @ioannisg , @galak, @MaureenHelm
[x] X86 - @nashif, @andrewboie
[ ] RISCV - @pgielda @nategraff-sifive
[ ] Xtensa, NIOS-II - @nashif, @andrewboie

Board an Soc support - many
[x] Security - @d3zd3z

[x] Update version in VERSION
[x] Tag both v2.4.0 and zephyr-v2.4.0
[x] Create release and add notes on https://github.com/zephyrproject-rtos/zephyr/releases. Make sure you use the zephyr-v2.4.0 tag so that the .zip that GitHub offers has a reasonable name. Add the release notes to the GitHub release.

[ ] After Release

[x] Update patchlevel in Makefile (PATCHLEVEL = 99)
[ ] Update doc generation (in future should be automatic based on tag) ping @nashif
[x] Update https://www.zephyrproject.org/developer-resources/#current-release (email Brett)
[x] Create v2.4-branch branch for 2.4.x releases (from v2.4.0 tag, don't include the switch to patchlevel 99)
[x] Merge all post-release PRs in https://github.com/zephyrproject-rtos/zephyr/projects/27
[x] Move all PRs/Issues in the v2.4.0 milestone to the next milestone
[x] Close v2.4.0 milestone
[x] Email<EMAIL_ADDRESS>&<EMAIL_ADDRESS>lists about release and announce the opening of the merge window
[x] Create checklist issue for next release
[x] Add a comment to this issue linking to the next release checklist issue
[ ] Marketing Blog for announcing release (https://www.zephyrproject.org/blog)
[x] Update https://www.zephyrproject.org with latest stats from GitHub (email Brett)
[x] Update current release dates in https://github.com/zephyrproject-rtos/zephyr/wiki/Program-Management, move current release column to "past releases table", and add next release timeline if missing (v2.6.0)
[ ] Store the number of currently open PRs to keep track of post-release PR overhead over time

Next release checklist: #28716

Historical bug and PR tracking data for the 2.4.0 release cycle:
| High | Medium | Low | PRs | Weeks to Feature Freeze | Weeks to Release
-- | -- | -- | -- | -- | -- | --
7/22/2020 | 2 | 44 | 256 | 521 | 6.3 | 9.3
7/28/2020 | 2 | 48 | 232 | 537 | 5.4 | 8.4
8/4/2020 | 6 | 45 | 225 | 550 | 4.4 | 7.4
8/11/2020 | 7 | 41 | 225 | 540 | 3.4 | 6.4
8/19/2020 | 10 | 39 | 205 | 532 | 2.3 | 5.3
8/25/2020 | 7 | 43 | 202 | 526 | 1.4 | 4.4
9/1/2020 | 5 | 44 | 190 | 518 | 0.4 | 3.4
9/8/2020 | 9 | 51 | 199 | 460 | -0.6 | 2.4
9/15/2020 | 3 | 42 | 179 | 479 | -1.6 | 1.4
9/16/2020 | 3 | 34 | 175 | 479 | -1.7 | 1.3
9/22/2020 | 2 | 25 | 141 | 367 | -2.6 | 0.4
9/24/2020 | 1 | 18 | 142 | 357 | -2.9 | 0.1
9/27/2020 | 1 | 20 | 142 | 355 | -3.3 | -0.3

@MaureenHelm Nice, do we have a similar list for older releases ?

Nice, do we have a similar list for older releases ?

No


Work around for CMake 3.15 Resource file linking

CMake 3.15 doesn't properly include resource files when linking by being
passed a target which means Windows doesn't include the Olson timezone
data. Instead as a work around, link against the target object using
target_link_options.

@swift-ci please test

@swift-ci please test macos


cli_visualizer: init at 06-02-2016

I hope the commit message is okay for you guys. There are no releases of this utility yet, so I used the date of packaging.

Merged with minor changes:

added pulseaudio support
06-02-2016 -> 2016-02-06 to ensure correct version sorting
cli_visualizer -> cli-visualizer

Nice.


SQL errors from most reports

risu -t graphs -o "mb.pdf" --config-file risu.cfg
/var/lib/gems/2.3.0/gems/mysql2-0.4.9/lib/mysql2/client.rb:120:in `_query': Mysql2::Error: Expression #1 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'mb.items.id' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by: SELECT  `items`.* FROM `items` INNER JOIN `hosts` ON `hosts`.`id` = `items`.`host_id` WHERE (`items`.`plugin_id` != 1) AND `items`.`severity` = 4 GROUP BY `items`.`host_id` ORDER BY count(*) desc LIMIT 157 (ActiveRecord::StatementInvalid)
	from /var/lib/gems/2.3.0/gems/mysql2-0.4.9/lib/mysql2/client.rb:120:in `block in query'
	from /var/lib/gems/2.3.0/gems/mysql2-0.4.9/lib/mysql2/client.rb:119:in `handle_interrupt'
	from /var/lib/gems/2.3.0/gems/mysql2-0.4.9/lib/mysql2/client.rb:119:in `query'
	from /var/lib/gems/2.3.0/gems/activerecord-5.1.4/lib/active_record/connection_adapters/abstract_mysql_adapter.rb:214:in `block (2 levels) in execute'
	from /var/lib/gems/2.3.0/gems/activesupport-5.1.4/lib/active_support/dependencies/interlock.rb:46:in `block in permit_concurrent_loads'
	from /var/lib/gems/2.3.0/gems/activesupport-5.1.4/lib/active_support/concurrency/share_lock.rb:185:in `yield_shares'
	from /var/lib/gems/2.3.0/gems/activesupport-5.1.4/lib/active_support/dependencies/interlock.rb:45:in `permit_concurrent_loads'
	from /var/lib/gems/2.3.0/gems/activerecord-5.1.4/lib/active_record/connection_adapters/abstract_mysql_adapter.rb:213:in `block in execute'
	from /var/lib/gems/2.3.0/gems/activerecord-5.1.4/lib/active_record/connection_adapters/abstract_adapter.rb:612:in `block (2 levels) in log'
	from /usr/lib/ruby/2.3.0/monitor.rb:214:in `mon_synchronize'
	from /var/lib/gems/2.3.0/gems/activerecord-5.1.4/lib/active_record/connection_adapters/abstract_adapter.rb:611:in `block in log'
	from /var/lib/gems/2.3.0/gems/activesupport-5.1.4/lib/active_support/notifications/instrumenter.rb:21:in `instrument'
	from /var/lib/gems/2.3.0/gems/activerecord-5.1.4/lib/active_record/connection_adapters/abstract_adapter.rb:603:in `log'
	from /var/lib/gems/2.3.0/gems/activerecord-5.1.4/lib/active_record/connection_adapters/abstract_mysql_adapter.rb:212:in `execute'
	from /var/lib/gems/2.3.0/gems/activerecord-5.1.4/lib/active_record/connection_adapters/mysql/database_statements.rb:26:in `execute'
	from /var/lib/gems/2.3.0/gems/activerecord-5.1.4/lib/active_record/connection_adapters/abstract_mysql_adapter.rb:223:in `execute_and_free'
	from /var/lib/gems/2.3.0/gems/activerecord-5.1.4/lib/active_record/connection_adapters/mysql/database_statements.rb:31:in `exec_query'
	from /var/lib/gems/2.3.0/gems/activerecord-5.1.4/lib/active_record/connection_adapters/abstract/database_statements.rb:371:in `select'
	from /var/lib/gems/2.3.0/gems/activerecord-5.1.4/lib/active_record/connection_adapters/abstract/database_statements.rb:42:in `select_all'
	from /var/lib/gems/2.3.0/gems/activerecord-5.1.4/lib/active_record/connection_adapters/abstract/query_cache.rb:97:in `select_all'
	from /var/lib/gems/2.3.0/gems/activerecord-5.1.4/lib/active_record/connection_adapters/mysql/database_statements.rb:10:in `select_all'
	from /var/lib/gems/2.3.0/gems/activerecord-5.1.4/lib/active_record/querying.rb:39:in `find_by_sql'
	from /var/lib/gems/2.3.0/gems/activerecord-5.1.4/lib/active_record/relation.rb:667:in `exec_queries'
	from /var/lib/gems/2.3.0/gems/activerecord-5.1.4/lib/active_record/relation.rb:546:in `load'
	from /var/lib/gems/2.3.0/gems/activerecord-5.1.4/lib/active_record/relation.rb:255:in `records'
	from /var/lib/gems/2.3.0/gems/activerecord-5.1.4/lib/active_record/relation/delegation.rb:39:in `each'
	from /var/lib/gems/2.3.0/gems/risu-1.8.3/lib/risu/models/host.rb:805:in `unique_hosts_with_critical_and_high_count'
	from /var/lib/gems/2.3.0/gems/risu-1.8.3/lib/risu/models/item.rb:349:in `calculate_vulnerable_host_percent'
	from /var/lib/gems/2.3.0/gems/risu-1.8.3/lib/risu/models/item.rb:428:in `risks_by_severity_graph_text'
	from /var/lib/gems/2.3.0/gems/risu-1.8.3/lib/risu/templates/graphs.rb:60:in `render'
	from /var/lib/gems/2.3.0/gems/risu-1.8.3/lib/risu/base/templater.rb:61:in `block in generate'
	from /var/lib/gems/2.3.0/gems/prawn-2.2.2/lib/prawn/document.rb:236:in `initialize'
	from /var/lib/gems/2.3.0/gems/prawn-2.2.2/lib/prawn/document.rb:142:in `new'
	from /var/lib/gems/2.3.0/gems/prawn-2.2.2/lib/prawn/document.rb:142:in `generate'
	from /var/lib/gems/2.3.0/gems/risu-1.8.3/lib/risu/base/templater.rb:56:in `generate'
	from /var/lib/gems/2.3.0/gems/risu-1.8.3/lib/risu/cli/application.rb:425:in `run'
	from /var/lib/gems/2.3.0/gems/risu-1.8.3/bin/risu:32:in `<top (required)>'
	from /usr/local/bin/risu:23:in `load'
	from /usr/local/bin/risu:23:in `<main>'

Reports that throw the same error: exec_summary, executive_summary_detailed, exploitablity_summary, findings_host, findings_summary, findings_summary_with_pluginid, graphs, missing_root_causes, notable_detailed, talking_points, technical_findings, top_25
Reports that do not throw an error: assets, authentication_summary, cover_sheet, failed_audits, finding_statistics, host_findings_csv, host_summary, malicious_process_detection, ms_patch_summary, ms_update_summary, ms_wsus_findings, notable, pci_compliance, stig_findings_summary, template

mysql-server 5.7.20-0ubuntu<IP_ADDRESS>
risu (1.8.3)
ruby 2.3.1p112 (2016-04-26) [x86_64-linux-gnu]

After hacking on this for half a day, I managed to find some magic combination of MySQL, Ruby, and Risu that has no problems generating the reports.


Datepicker in filter shows only half of it

Describe the bug
The date picker shows only half of selectable dates
To Reproduce
Steps to reproduce the behavior:

Go to Index page
Click on Filter
Click on datepicker
See datepicker shows only half of it

Expected behavior
Date picker shows only half of selectable dates of the month.
Screenshots

Desktop (please complete the following information):

Window OS, Chrome version 131.0.6778.69

Smartphone (please complete the following information):

Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

Occurred only on my machine


Censored data eh

This is a big pull request. In a nutshell, I created new censored data functions and converted the TADA package framework to rely upon TADA-generated columns for all operations to preserve original column contents.

Looks good to me! I just made one comment on the global variables added that are actually functions. I wasn't sure if that was the convention for functions called in the package.

Ah okay, I didn't realize those were functions. In that case, we need to find where these are used and specify the package. It looks like last_col is a function in both tidyselect and dplyr (e.g. update to "dplyr::last_col"?. Where is summ used?

Looks good to me! I just made one comment on the global variables added that are actually functions. I wasn't sure if that was the convention for functions called in the package.

Ah okay, I didn't realize those were functions. In that case, we need to find where these are used and specify the package. It looks like last_col is a function in both tidyselect and dplyr (e.g. update to "dplyr::last_col"?. Where is summ used?

@ehinman I kept summ but removed last_col here and updated this to dplyr::last_col where used


DONT MERGE - testing countervalue endpoint

Following a request from @bszuldyner-ledger here's a build with a different countervalue endpoint.
Do not merge this, this should be closed unmerged.

Tested and working apparently.


Integrasi OAuth FitBit to Access API's

Update progress

Repackage project with library https://www.npmjs.com/package/react-native-rename ✅
Integrasi OAuth FitBit App

Repackage & renaming project done

Running app after repacakge done
https://github.com/teknovasi-suryatama-official/react-native-app-auth/assets/98740335/8306785a-2356-46d5-b4ac-6c6f8821fbd0

Redesign tampilan tahap bagian 1
https://github.com/teknovasi-suryatama-official/react-native-app-auth/assets/98740335/2be33dda-4c8f-46c3-a2cb-48f397e4dd7f


[Java SDK] RetryInterceptor for streaming calls

Issue Description:
We need to implement a retry interceptor for streaming calls in the Java SDK, based on the investigation conducted in this ticket. During the investigation, it was found that the same RetryInterceptor logic used for unary calls could be applied to streaming calls as well.
However, testing this implementation against Momento Local revealed an issue. After a retry is triggered, the program hangs when performing scalar or batch operations. This indicates that the behavior of Momento Local differs from that of the actual server, potentially leading to the hang.
Next Steps:
To resolve this issue, we need to collaborate with a backend engineer to set up a development environment (dev cell) where we can simulate a "SERVER_UNAVAILABLE" error locally. This will allow us to test the retry logic under conditions that better mimic the actual server behavior, ensuring the retry mechanism functions correctly for both scalar and batch operations.
Action Items:
[x] Coordinate with a backend engineer to configure the dev cell for simulating the "SERVER_UNAVAILABLE" error.
[x] Re-test the RetryInterceptor logic with the new setup to verify if the issue persists.
[x] Ensure that both scalar and batch operations are handled correctly during retries without causing the program to hang.
This will help isolate whether the discrepancy between Momento Local and the actual server is contributing to the issue and enable us to refine the retry logic accordingly.
Code References:
For details on how testing against momento-local was done, check this PR: https://github.com/momentohq/client-sdk-java/pull/394 [WIP-POC]

Investigation Summary:
During testing on my development environment (developer-rishti-dev), I simulated server-side errors (5XX) to examine the behavior of both unary and streaming calls under realistic service conditions, rather than using momento-local. The investigation revealed the following:

Proper Program Exit: The program exits without hanging when cacheClient.close() is explicitly called. This indicates that certain resources remain open if cacheClient is not closed, suggesting that the RetryInterceptor is keeping resources active.
Retry Success: I successfully retried streaming calls (e.g., getBatch) using the existing RetryInterceptor, confirming its effectiveness for both unary and streaming calls.

Conclusions:

Consistency Across Environments: momento-local and the actual service perform identically, confirming that there are no issues with the momento-local implementation.
Versatility of RetryInterceptor: The current RetryInterceptor, initially designed for unary calls, can also effectively handle retries for streaming calls.


Add tex_image_2d_with_html_video

Fairly self-explanatory, used for things like https://developer.mozilla.org/en-US/docs/Web/API/WebGL_API/Tutorial/Animating_textures_in_WebGL.

We're looking at re-licensing in #212, so would you mind confirming if you're ok with adding Zlib as a third license option for this contribution?

Yep, I'm okay with that.


Adding priority to scheduled task causes problem with resource methods not found

Simply adding a priority=2 to a scheduled task causes the rtfm expansion to produce code that will not build.
I have a repeating scheduled task imu_reader that processes a series of incoming messages by calling a method handle_all_messages.  If I change the task defintion from:
 #[task(resources = [i2c1_driver], schedule = [imu_reader])]

to
#[task(resources = [i2c1_driver], schedule = [imu_reader], priority = 2)]

I get the cargo build error:
error[E0599]: no method named `handle_all_messages` found for type `resources::i2c1_driver<'_>` in the current scope
   --> src/main.rs:140:34
    |
39  | #[app(device = stm32h7xx_hal::pac,  peripherals = true, monotonic = rtfm::cyccnt::CYCCNT)]
    | ------------------------------------------------------------------------------------------ method `handle_all_messages` not found for this
...
140 |         cx.resources.i2c1_driver.handle_all_messages();
    |                                  ^^^^^^^^^^^^^^^^^^^ method not found in `resources::i2c1_driver<'_>`

I may have misunderstood how to configure the rtfm task, but this is unexpected behavior.
I've attached the original main.rs file as well as the good and bad expansions.
rtfm-priority-problem.zip

Hi
Could it be that its no longer an owned resource, so that you need to lock it before using it. The assymmetric API has both pro:s and con:s. Pro is that it makes it easy to use when you get an owned resource, cons is that an unrelated change to priority breaks the code. (There is an rfc/issue for making the API fully symmetric.)

I admit I don't fully understand the relationship between this simple test app and "the asymmetric API".  For what it's worth, this particular MCU only has one core. In this instance I simply added a priority to an existing task (and did not previously have any priority labels anywhere in the code).  I tried experimenting with locking according to the best available documentation, but with no progress. I subsequently removed the priority label.

The way you access a resource is asymmetric, depending wether there is any task with a higher priority accessing the same resource or not. See the example:
https://github.com/rtfm-rs/cortex-m-rtfm/blob/master/examples/lock.rs
and the book:
/rtfm.rs/0.5/book/en/by-example/resources.html

This threw me at first as well. It also makes things more difficult (for me as a new Rustacean) when passing access of the resource to other functions. Particularly, if I want to pass a Mutex so the lock can be made for a shorter duration only when needed within the other function.
Would it make sense to provide the resource wrapped in an Exclusive when a Mutex is not required? I think that would make the interfaces symmetric.