OPRF stall

Starting Helpers:
btsavage@btsavage-mbp raw-ipa % cargo run --release --no-default-features --features "cli web-app real-world-infra compact-gate stall-detection" --bin helper -- --identity 3 --network test_data/network.toml --port 3002 --disable-https

Running Script:
btsavage@btsavage-mbp raw-ipa % SIZE=1000000; cargo run --release --bin report_collector --features="clap cli test-fixture" -- gen-ipa-inputs -n $SIZE --max-breakdown-key 256 --report-filter all --max-trigger-value 7 --seed 123 > /tmp/events-${SIZE}.txt

Helper 1
2023-11-29T00:36:37.268350Z  WARN stall_detector{role=H1}: ipa_core::helpers::gateway::stall_detection::gateway: Helper is stalled sn=10657796 state=
{
"gate[11422]=binary_validator/row9/computed_capped_attributed_trigger_value_just_saturated_case", from=H3. Waiting to receive records ["[2163..3071]"].
"gate[11436]=prime_field_validator/modulus_convert_breakdown_key_bits_and_trigger_values/convert_bit0/xor2", from=H3. Waiting to receive records ["[18432..19455]"].
"gate[11444]=prime_field_validator/modulus_convert_breakdown_key_bits_and_trigger_values/convert_bit1/xor2", from=H3. Waiting to receive records ["[18432..19455]"].
"gate[11452]=prime_field_validator/modulus_convert_breakdown_key_bits_and_trigger_values/convert_bit10/xor2", from=H3. Waiting to receive records ["[18432..19455]"].
"gate[11461]=prime_field_validator/modulus_convert_breakdown_key_bits_and_trigger_values/convert_bit2/xor2", from=H3. Waiting to receive records ["[18432..19455]"].
"gate[11469]=prime_field_validator/modulus_convert_breakdown_key_bits_and_trigger_values/convert_bit3/xor2", from=H3. Waiting to receive records ["[18432..19455]"].
"gate[11477]=prime_field_validator/modulus_convert_breakdown_key_bits_and_trigger_values/convert_bit4/xor2", from=H3. Waiting to receive records ["[18432..19455]"].
"gate[11485]=prime_field_validator/modulus_convert_breakdown_key_bits_and_trigger_values/convert_bit5/xor2", from=H3. Waiting to receive records ["[18432..19455]"].
"gate[11493]=prime_field_validator/modulus_convert_breakdown_key_bits_and_trigger_values/convert_bit6/xor2", from=H3. Waiting to receive records ["[18432..19455]"].
"gate[11501]=prime_field_validator/modulus_convert_breakdown_key_bits_and_trigger_values/convert_bit7/xor2", from=H3. Waiting to receive records ["[18432..19455]"].
"gate[11509]=prime_field_validator/modulus_convert_breakdown_key_bits_and_trigger_values/convert_bit8/xor2", from=H3. Waiting to receive records ["[18432..19455]"].
"gate[11517]=prime_field_validator/modulus_convert_breakdown_key_bits_and_trigger_values/convert_bit9/xor2", from=H3. Waiting to receive records ["[18432..19455]"].
}

Helper 2
2023-11-29T00:36:37.270875Z  WARN stall_detector{role=H2}: ipa_core::helpers::gateway::stall_detection::gateway: Helper is stalled sn=10658252 state=
{
"gate[11423]=binary_validator/row9/computed_capped_attributed_trigger_value_not_saturated_case", from=H1. Waiting to receive records ["[2277..3071]"].
"gate[11781]=prime_field_validator/move_value_to_correct_breakdown/depth7/bit0", from=H1. Waiting to receive records ["[18432..19455]"].
}

Helper 3
2023-11-29T00:36:37.270916Z  WARN stall_detector{role=H3}: ipa_core::helpers::gateway::stall_detection::gateway: Helper is stalled sn=10635268 state=
{
"gate[11422]=binary_validator/row9/computed_capped_attributed_trigger_value_just_saturated_case", from=H2. Waiting to receive records ["[2048..3071]"].
}

Any clues as to the root cause @akoshelev ?

I haven't started looking into it. Planning to investigate once I am done with multi-threading

I am still seeing some weird chunk sizes being sent between helpers.
**grep "binary_validator/row9/computed_capped_attributed_trigger_value_just_saturated_case" /tmp/h2.log | grep "Sending next"
2023-12-05T19:30:34.186122Z  INFO send{to=H3 gate=gate[12072]=binary_validator/row9/computed_capped_attributed_trigger_value_just_saturated_case}: ipa_core::helpers::buffers::ordering_sender: Sending next 1024 bytes
2023-12-05T19:30:51.054940Z  INFO send{to=H3 gate=gate[12072]=binary_validator/row9/computed_capped_attributed_trigger_value_just_saturated_case}: ipa_core::helpers::buffers::ordering_sender: Sending next 1024 bytes
2023-12-05T19:31:06.968061Z  INFO send{to=H3 gate=gate[12072]=binary_validator/row9/computed_capped_attributed_trigger_value_just_saturated_case}: ipa_core::helpers::buffers::ordering_sender: Sending next 1024 bytes
2023-12-05T19:31:23.263925Z  INFO send{to=H3 gate=gate[12072]=binary_validator/row9/computed_capped_attributed_trigger_value_just_saturated_case}: ipa_core::helpers::buffers::ordering_sender: Sending next 1024 bytes
2023-12-05T19:31:39.858097Z  INFO send{to=H3 gate=gate[12072]=binary_validator/row9/computed_capped_attributed_trigger_value_just_saturated_case}: ipa_core::helpers::buffers::ordering_sender: Sending next 1024 bytes
2023-12-05T19:31:57.134318Z  INFO send{to=H3 gate=gate[12072]=binary_validator/row9/computed_capped_attributed_trigger_value_just_saturated_case}: ipa_core::helpers::buffers::ordering_sender: Sending next 1024 bytes
2023-12-05T19:32:13.442274Z  INFO send{to=H3 gate=gate[12072]=binary_validator/row9/computed_capped_attributed_trigger_value_just_saturated_case}: ipa_core::helpers::buffers::ordering_sender: Sending next 1024 bytes
2023-12-05T19:32:29.663746Z  INFO send{to=H3 gate=gate[12072]=binary_validator/row9/computed_capped_attributed_trigger_value_just_saturated_case}: ipa_core::helpers::buffers::ordering_sender: Sending next 1024 bytes
2023-12-05T19:32:44.689919Z  INFO send{to=H3 gate=gate[12072]=binary_validator/row9/computed_capped_attributed_trigger_value_just_saturated_case}: ipa_core::helpers::buffers::ordering_sender: Sending next 1024 bytes
2023-12-05T19:33:00.765225Z  INFO send{to=H3 gate=gate[12072]=binary_validator/row9/computed_capped_attributed_trigger_value_just_saturated_case}: ipa_core::helpers::buffers::ordering_sender: Sending next 1024 bytes
2023-12-05T19:33:17.144936Z  INFO send{to=H3 gate=gate[12072]=binary_validator/row9/computed_capped_attributed_trigger_value_just_saturated_case}: ipa_core::helpers::buffers::ordering_sender: Sending next 1024 bytes
2023-12-05T19:33:34.463893Z  INFO send{to=H3 gate=gate[12072]=binary_validator/row9/computed_capped_attributed_trigger_value_just_saturated_case}: ipa_core::helpers::buffers::ordering_sender: Sending next 1024 bytes
2023-12-05T19:33:51.497959Z  INFO send{to=H3 gate=gate[12072]=binary_validator/row9/computed_capped_attributed_trigger_value_just_saturated_case}: ipa_core::helpers::buffers::ordering_sender: Sending next 1024 bytes
2023-12-05T19:34:07.532171Z  INFO send{to=H3 gate=gate[12072]=binary_validator/row9/computed_capped_attributed_trigger_value_just_saturated_case}: ipa_core::helpers::buffers::ordering_sender: Sending next 1024 bytes
2023-12-05T19:34:24.251729Z  INFO send{to=H3 gate=gate[12072]=binary_validator/row9/computed_capped_attributed_trigger_value_just_saturated_case}: ipa_core::helpers::buffers::ordering_sender: Sending next 1024 bytes
2023-12-05T19:34:41.347484Z  INFO send{to=H3 gate=gate[12072]=binary_validator/row9/computed_capped_attributed_trigger_value_just_saturated_case}: ipa_core::helpers::buffers::ordering_sender: Sending next 1024 bytes
2023-12-05T19:34:56.487639Z  INFO send{to=H3 gate=gate[12072]=binary_validator/row9/computed_capped_attributed_trigger_value_just_saturated_case}: ipa_core::helpers::buffers::ordering_sender: Sending next 1024 bytes
2023-12-05T19:35:11.845600Z  INFO send{to=H3 gate=gate[12072]=binary_validator/row9/computed_capped_attributed_trigger_value_just_saturated_case}: ipa_core::helpers::buffers::ordering_sender: Sending next 519 bytes
2023-12-05T20:24:39.455490Z  INFO send{to=H3 gate=gate[12072]=binary_validator/row9/computed_capped_attributed_trigger_value_just_saturated_case}: ipa_core::helpers::buffers::ordering_sender: Sending next 1024 bytes
2023-12-05T20:24:55.148838Z  INFO send{to=H3 gate=gate[12072]=binary_validator/row9/computed_capped_attributed_trigger_value_just_saturated_case}: ipa_core::helpers::buffers::ordering_sender: Sending next 1024 bytes
2023-12-05T20:25:10.177275Z  INFO send{to=H3 gate=gate[12072]=binary_validator/row9/computed_capped_attributed_trigger_value_just_saturated_case}: ipa_core::helpers::buffers::ordering_sender: Sending next 1024 bytes
2023-12-05T20:25:27.272723Z  INFO send{to=H3 gate=gate[12072]=binary_validator/row9/computed_capped_attributed_trigger_value_just_saturated_case}: ipa_core::helpers::buffers::ordering_sender: Sending next 1024 bytes
2023-12-05T20:25:43.597640Z  INFO send{to=H3 gate=gate[12072]=binary_validator/row9/computed_capped_attributed_trigger_value_just_saturated_case}: ipa_core::helpers::buffers::ordering_sender: Sending next 1024 bytes
2023-12-05T20:26:01.167813Z  INFO send{to=H3 gate=gate[12072]=binary_validator/row9/computed_capped_attributed_trigger_value_just_saturated_case}: ipa_core::helpers::buffers::ordering_sender: Sending next 1024 bytes
2023-12-05T20:26:16.395990Z  INFO send{to=H3 gate=gate[12072]=binary_validator/row9/computed_capped_attributed_trigger_value_just_saturated_case}: ipa_core::helpers::buffers::ordering_sender: Sending next 1024 bytes
2023-12-05T20:26:31.531605Z  INFO send{to=H3 gate=gate[12072]=binary_validator/row9/computed_capped_attributed_trigger_value_just_saturated_case}: ipa_core::helpers::buffers::ordering_sender: Sending next 1024 bytes
2023-12-05T20:26:47.727183Z  INFO send{to=H3 gate=gate[12072]=binary_validator/row9/computed_capped_attributed_trigger_value_just_saturated_case}: ipa_core::helpers::buffers::ordering_sender: Sending next 1024 bytes
2023-12-05T20:27:05.346826Z  INFO send{to=H3 gate=gate[12072]=binary_validator/row9/computed_capped_attributed_trigger_value_just_saturated_case}: ipa_core::helpers::buffers::ordering_sender: Sending next 1024 bytes
2023-12-05T20:27:21.005066Z  INFO send{to=H3 gate=gate[12072]=binary_validator/row9/computed_capped_attributed_trigger_value_just_saturated_case}: ipa_core::helpers::buffers::ordering_sender: Sending next 1024 bytes
2023-12-05T20:27:38.361139Z  INFO send{to=H3 gate=gate[12072]=binary_validator/row9/computed_capped_attributed_trigger_value_just_saturated_case}: ipa_core::helpers::buffers::ordering_sender: Sending next 1024 bytes

it seems to be happening once per step but size varies from 519 to 300
2023-12-05T19:54:52.267215Z  INFO send{to=H1 gate=gate[12086]=prime_field_validator/modulus_convert_breakdown_key_bits_and_trigger_values/convert_bit0/xor2}: ipa_core::helpers::buffers::ordering_sender: Sending next 4096 bytes
2023-12-05T19:54:53.041703Z  INFO send{to=H1 gate=gate[12086]=prime_field_validator/modulus_convert_breakdown_key_bits_and_trigger_values/convert_bit0/xor2}: ipa_core::helpers::buffers::ordering_sender: Sending next 300 bytes
2023-12-05T20:24:39.494548Z  INFO send{to=H1 gate=gate[12086]=prime_field_validator/modulus_convert_breakdown_key_bits_and_trigger_values/convert_bit0/xor2}: ipa_core::helpers::buffers::ordering_sender: Sending next 4096 bytes
2023-12-05T20:24:40.552093Z  INFO send{to=H1 gate=gate[12086]=prime_field_validator/modulus_convert_breakdown_key_bits_and_trigger_values/convert_bit0/xor2}: ipa_core::helpers::buffers::ordering_sender: Sending next 4096 bytes

Another observation - it happens right before a large pause in execution for this step (19:54 ->20:24)

OrderingSender generates `Sending next" message when the stream is ready
        if let Poll::Ready(v) = b.take(cx) {
            self.waiting.wake(self.next.load(Acquire));
            tracing::info!("Sending next {} bytes", v.len());
            Poll::Ready(Some(v))
        } else if b.closed {
         ...
       }

b.take() returns Poll::Ready  iff there are bytes written and either buffer - spare < written or stream is closed.
        if self.written > 0 && (self.written + self.spare.get() >= self.buf.len() || self.closed) {
            let v = self.buf[..self.written].to_vec();
            self.written = 0;

            Self::wake(&mut self.write_ready);
            Poll::Ready(v)
        } else {
            Self::save_waker(&mut self.stream_ready, cx);
            Poll::Pending
        }

Given that spare is constant (64 bytes) and each message is 1 or 4 bytes long (making buffer capacity either 1024 or 4096), the only plausible explanation that I have is that stream is considered closed.

Scratch the previous correspondence, these were two separate runs

Current theory: something is broken inside UnorderedReceiver.
Here is some evidence for that.
H2 is stalled
"gate[12073]=binary_validator/row9/computed_capped_attributed_trigger_value_not_saturated_case", from=H1. Waiting to receive records ["[229..1023]"].

Protocol is moving as expected, submitting first 1024 multiplications (sends complete, receives blocked waiting for data from H1
2023-12-06T17:12:59.854353Z TRACE oprf_ipa_query{sz=100000}:attribute_cap_aggregate:per_user_attribution{rows=10}:send{i=1022 total=1796 to=H3 gate="binary_validator/row9/computed_capped_attributed_trigger_value_not_saturated_case"}: ipa_core::helpers::gateway::send: new
2023-12-06T17:12:59.854360Z TRACE oprf_ipa_query{sz=100000}:attribute_cap_aggregate:per_user_attribution{rows=10}:send{i=1022 total=1796 to=H3 gate="binary_validator/row9/computed_capped_attributed_trigger_value_not_saturated_case"}: ipa_core::helpers::gateway::send: close time.busy=3.30µs time.idle=3.52µs
2023-12-06T17:12:59.854364Z TRACE oprf_ipa_query{sz=100000}:attribute_cap_aggregate:per_user_attribution{rows=10}:receive{i=1022 from=H1 gate="binary_validator/row9/computed_capped_attributed_trigger_value_not_saturated_case"}: ipa_core::helpers::gateway::receive: new
2023-12-06T17:12:59.854375Z TRACE oprf_ipa_query{sz=100000}:attribute_cap_aggregate:per_user_attribution{rows=10}:send{i=1023 total=1796 to=H3 gate="binary_validator/row9/computed_capped_attributed_trigger_value_not_saturated_case"}: ipa_core::helpers::gateway::send: new
2023-12-06T17:12:59.854382Z TRACE oprf_ipa_query{sz=100000}:attribute_cap_aggregate:per_user_attribution{rows=10}:send{i=1023 total=1796 to=H3 gate="binary_validator/row9/computed_capped_attributed_trigger_value_not_saturated_case"}: ipa_core::helpers::gateway::send: close time.busy=3.81µs time.idle=3.52µs
2023-12-06T17:12:59.854386Z TRACE oprf_ipa_query{sz=100000}:attribute_cap_aggregate:per_user_attribution{rows=10}:receive{i=1023 from=H1 gate="binary_validator/row9/computed_capped_attributed_trigger_value_not_saturated_case"}: ipa_core::helpers::gateway::receive: new

Later (pay attention to timestamps), a batch of records arrived from H1
2023-12-06T17:12:59.917502Z TRACE oprf_ipa_query{sz=100000}:attribute_cap_aggregate:per_user_attribution{rows=10}:receive{i=0 from=H1 gate="binary_validator/row9/computed_capped_attributed_trigger_value_not_saturated_case"}: ipa_core::helpers::buffers::unordered_receiver: Received next 1024 bytes
2023-12-06T17:12:59.917507Z TRACE oprf_ipa_query{sz=100000}:attribute_cap_aggregate:per_user_attribution{rows=10}:receive{i=0 from=H1 gate="binary_validator/row9/computed_capped_attributed_trigger_value_not_saturated_case"}: ipa_core::helpers::gateway::receive: close time.busy=39.7µs time.idle=87.1ms
2023-12-06T17:12:59.917643Z TRACE oprf_ipa_query{sz=100000}:attribute_cap_aggregate:per_user_attribution{rows=10}:receive{i=1 from=H1 gate="binary_validator/row9/computed_capped_attributed_trigger_value_not_saturated_case"}: ipa_core::helpers::gateway::receive: close time.busy=1.30µs time.idle=87.2ms

However, only first 227 receive requests were resolved
2023-12-06T17:13:00.343228Z TRACE oprf_ipa_query{sz=100000}:attribute_cap_aggregate:per_user_attribution{rows=10}:receive{i=223 from=H1 gate="binary_validator/row9/computed_capped_attributed_trigger_value_not_saturated_case"}: ipa_core::helpers::gateway::receive: close time.busy=762ns time.idle=508ms
2023-12-06T17:13:00.343555Z TRACE oprf_ipa_query{sz=100000}:attribute_cap_aggregate:per_user_attribution{rows=10}:receive{i=224 from=H1 gate="binary_validator/row9/computed_capped_attributed_trigger_value_not_saturated_case"}: ipa_core::helpers::gateway::receive: close time.busy=848ns time.idle=508ms
2023-12-06T17:13:00.343882Z TRACE oprf_ipa_query{sz=100000}:attribute_cap_aggregate:per_user_attribution{rows=10}:receive{i=225 from=H1 gate="binary_validator/row9/computed_capped_attributed_trigger_value_not_saturated_case"}: ipa_core::helpers::gateway::receive: close time.busy=706ns time.idle=508ms
2023-12-06T17:13:00.344221Z TRACE oprf_ipa_query{sz=100000}:attribute_cap_aggregate:per_user_attribution{rows=10}:receive{i=226 from=H1 gate="binary_validator/row9/computed_capped_attributed_trigger_value_not_saturated_case"}: ipa_core::helpers::gateway::receive: close time.busy=750ns time.idle=508ms
2023-12-06T17:13:00.344570Z TRACE oprf_ipa_query{sz=100000}:attribute_cap_aggregate:per_user_attribution{rows=10}:receive{i=227 from=H1 gate="binary_validator/row9/computed_capped_attributed_trigger_value_not_saturated_case"}: ipa_core::helpers::gateway::receive: close time.busy=799ns time.idle=509ms
<nothing after>

Given that we have 1024 receive requests in flight, the issue seems to be UnorderedReceiver not waking up next receiver request in-flight and the whole pipeline is stalled

Not sure if it is relevant, but record 227 was the last one for some PRF
2023-12-06T17:13:00.344589Z TRACE oprf_ipa_query{sz=100000}:attribute_cap_aggregate:per_user_attribution{rows=10}:receive{i=227 from=H1 gate="binary_validator/row9/computed_capped_attributed_trigger_value_just_saturated_case"}: ipa_core::helpers::gateway::receive: new
2023-12-06T17:13:00.344593Z TRACE oprf_ipa_query{sz=100000}:attribute_cap_aggregate:per_user_attribution{rows=10}:receive{i=227 from=H1 gate="binary_validator/row9/computed_capped_attributed_trigger_value_just_saturated_case"}: ipa_core::helpers::gateway::receive: close time.busy=276ns time.idle=3.19µs
2023-12-06T17:13:00.344596Z  INFO oprf_ipa_query{sz=100000}:attribute_cap_aggregate:per_user_attribution{rows=10}: ipa_core::protocol::ipa_prf::prf_sharding: close time.busy=5.99ms time.idle=6.08s

so it means that we couldn't cross the boundary between two user-specific attribution circuits

It does seem that the waker is missing.
at $t_0$ request to receive 114 is executed
2023-12-06T19:34:38.407207Z TRACE oprf_ipa_query{sz=100000}:attribute_cap_aggregate:per_user_attribution{rows=10 prf=4511667418102543736}:receive{i=114 from=H2 gate="binary_validator/row9/computed_capped_attributed_trigger_value_not_saturated_case"}: ipa_core::helpers::gateway::receive: new

at $t_1 \gt t_0$ request for record 113 is resolved but it can't find the waker to wake up.
2023-12-06T19:34:38.490185Z TRACE oprf_ipa_query{sz=100000}:attribute_cap_aggregate:per_user_attribution{rows=10 prf=14044988332725311749}:receive{i=113 from=H2 gate="binary_validator/row9/computed_capped_attributed_trigger_value_just_saturated_case"}: ipa_core::helpers::buffers::unordered_receiver: No waker for 114

this is the code that I used inside wake_next
        if let Some(w) = self.wakers[index].take() {
            w.wake();
        } else {
            tracing::trace!("No waker for {}", self.next)
        }

I don't anticipate this waker to be in overflow wakers because of the record number. 114 is well below 1024 (capacity), so this waker should've landed to the wakers vector.

yea I added more logs and it seems waker management is fine
H1 is stalled waiting for records 228...1023 from H3
binary_validator/row9/computed_capped_attributed_trigger_value_not_saturated_case", from=H3. Waiting to receive records ["[228..1023]"].

it submitted receive requests for all records
2023-12-07T18:39:35.174132Z TRACE ThreadId(15) oprf_ipa_query{sz=100000}:attribute_cap_aggregate:per_user_attribution{rows=10 prf=5291388962843137553}:receive{i=1 from=H3 gate="binary_validator/row9/computed_capped_attributed_trigger_value_not_saturated_case"}: ipa_core::helpers::gateway::receive: new
2023-12-07T18:39:35.174135Z TRACE ThreadId(15) oprf_ipa_query{sz=100000}:attribute_cap_aggregate:per_user_attribution{rows=10 prf=5291388962843137553}:receive{i=1 from=H3 gate="binary_validator/row9/computed_capped_attributed_trigger_value_not_saturated_case"}: ipa_core::helpers::buffers::unordered_receiver: Receiver::poll i=1
2023-12-07T18:39:35.174137Z TRACE ThreadId(15) oprf_ipa_query{sz=100000}:attribute_cap_aggregate:per_user_attribution{rows=10 prf=5291388962843137553}:receive{i=1 from=H3 gate="binary_validator/row9/computed_capped_attributed_trigger_value_not_saturated_case"}: ipa_core::helpers::buffers::unordered_receiver: Save waker for i = 1: Waker { data: 0x7f25a8205700, vtable: 0x562aff2bc2f8 }
...
2023-12-07T18:39:35.243608Z TRACE ThreadId(27) oprf_ipa_query{sz=100000}:attribute_cap_aggregate:per_user_attribution{rows=10 prf=2446537651109142584}:receive{i=1023 from=H3 gate="binary_validator/row9/computed_capped_attributed_trigger_value_not_saturated_case"}: ipa_core::helpers::buffers::unordered_receiver: Receiver::poll i=1023
2023-12-07T18:39:35.243610Z TRACE ThreadId(27) oprf_ipa_query{sz=100000}:attribute_cap_aggregate:per_user_attribution{rows=10 prf=2446537651109142584}:receive{i=1023 from=H3 gate="binary_validator/row9/computed_capped_attributed_trigger_value_not_saturated_case"}: ipa_core::helpers::buffers::unordered_receiver: Save waker for i = 1023: Waker { data: 0x7f25a8205700, vtable: 0x562aff2bc2f8 }

it received the whole batch of 1024 records from H3 and started waking up the executor
2023-12-07T18:39:35.288687Z TRACE ThreadId(29) oprf_ipa_query{sz=100000}:attribute_cap_aggregate:per_user_attribution{rows=10 prf=8042757424229509893}:receive{i=0 from=H3 gate="binary_validator/row9/computed_capped_attributed_trigger_value_not_saturated_case"}: ipa_core::helpers::buffers::unordered_receiver: Received next 1024 bytes
2023-12-07T18:39:35.288690Z TRACE ThreadId(29) oprf_ipa_query{sz=100000}:attribute_cap_aggregate:per_user_attribution{rows=10 prf=8042757424229509893}:receive{i=0 from=H3 gate="binary_validator/row9/computed_capped_attributed_trigger_value_not_saturated_case"}: ipa_core::helpers::buffers::unordered_receiver: Waking up next in line: 1
2023-12-07T18:39:35.288699Z TRACE ThreadId(29) oprf_ipa_query{sz=100000}:attribute_cap_aggregate:per_user_attribution{rows=10 prf=8042757424229509893}:receive{i=0 from=H3 gate="binary_validator/row9/computed_capped_attributed_trigger_value_not_saturated_case"}: ipa_core::helpers::buffers::unordered_receiver: Wake waker for i = 1: Waker { data: 0x7f25a8205700, vtable: 0x562aff2bc2f8 }

completing receive request for record 127 caused UR to wake the waker. Note that waker is the same for all records because the giant future is polled by a single task only
2023-12-07T18:39:35.684330Z TRACE ThreadId(26) oprf_ipa_query{sz=100000}:attribute_cap_aggregate:per_user_attribution{rows=10 prf=14909736342162320554}:receive{i=227 from=H3 gate="binary_validator/row9/computed_capped_attributed_trigger_value_not_saturated_case"}: ipa_core::helpers::buffers::unordered_receiver: Receiver::poll i=227
2023-12-07T18:39:35.684332Z TRACE ThreadId(26) oprf_ipa_query{sz=100000}:attribute_cap_aggregate:per_user_attribution{rows=10 prf=14909736342162320554}:receive{i=227 from=H3 gate="binary_validator/row9/computed_capped_attributed_trigger_value_not_saturated_case"}: ipa_core::helpers::buffers::unordered_receiver: Waking up next in line: 228
2023-12-07T18:39:35.684334Z TRACE ThreadId(26) oprf_ipa_query{sz=100000}:attribute_cap_aggregate:per_user_attribution{rows=10 prf=14909736342162320554}:receive{i=227 from=H3 gate="binary_validator/row9/computed_capped_attributed_trigger_value_not_saturated_case"}: ipa_core::helpers::buffers::unordered_receiver: Wake waker for i = 228: Waker { data: 0x7f25a8205700, vtable: 0x562aff2bc2f8 }

It does seem that waker was called correctly, but because it is not unique for this specific receive request, it could've caused a wake that got stuck before we had a chance to get to this specific receive request. I don't understand the whole mechanic for it yet though...

I think I figured what is going on. This is quite convoluted issue and tl;ldr is: flattening the stream causes all sorts of unpredictable behavior when multiple layers of seq_join is used. Random decisions made by the task scheduler make this issue revealing itself only on some occasions.
so for concreteness, here is an example of helpers stuck on OPRF IPA
H1
binary_validator/row9/computed_capped_attributed_trigger_value_just_saturated_case", from=H3. Waiting to receive records ["[0..1023]"].

H2
2023-12-12T15:52:24.454804Z  WARN ThreadId(15) stall_detector{role=H2}: ipa_core::helpers::gateway::stall_detection::gateway: Helper is stalled sn=103369316 state=
{
"gate[12072]=binary_validator/row9/computed_capped_attributed_trigger_value_just_saturated_case", from=H1. Waiting to receive records ["[115..1023]"].
"gate[12085]=prime_field_validator/modulus_convert_breakdown_key_bits_and_trigger_values/convert_bit0/xor1", from=H1. Waiting to receive records ["[0..1023]"].
"gate[12093]=prime_field_validator/modulus_convert_breakdown_key_bits_and_trigger_values/convert_bit1/xor1", from=H1. Waiting to receive records ["[0..1023]"].
"gate[12101]=prime_field_validator/modulus_convert_breakdown_key_bits_and_trigger_values/convert_bit10/xor1", from=H1. Waiting to receive records ["[0..1023]"].
"gate[12110]=prime_field_validator/modulus_convert_breakdown_key_bits_and_trigger_values/convert_bit2/xor1", from=H1. Waiting to receive records ["[0..1023]"].
"gate[12118]=prime_field_validator/modulus_convert_breakdown_key_bits_and_trigger_values/convert_bit3/xor1", from=H1. Waiting to receive records ["[0..1023]"].
"gate[12126]=prime_field_validator/modulus_convert_breakdown_key_bits_and_trigger_values/convert_bit4/xor1", from=H1. Waiting to receive records ["[0..1023]"].
"gate[12134]=prime_field_validator/modulus_convert_breakdown_key_bits_and_trigger_values/convert_bit5/xor1", from=H1. Waiting to receive records ["[0..1023]"].
"gate[12142]=prime_field_validator/modulus_convert_breakdown_key_bits_and_trigger_values/convert_bit6/xor1", from=H1. Waiting to receive records ["[0..1023]"].
"gate[12150]=prime_field_validator/modulus_convert_breakdown_key_bits_and_trigger_values/convert_bit7/xor1", from=H1. Waiting to receive records ["[0..1023]"].
"gate[12158]=prime_field_validator/modulus_convert_breakdown_key_bits_and_trigger_values/convert_bit8/xor1", from=H1. Waiting to receive records ["[0..1023]"].
"gate[12166]=prime_field_validator/modulus_convert_breakdown_key_bits_and_trigger_values/convert_bit9/xor1", from=H1. Waiting to receive records ["[0..1023]"].
}

H3
2023-12-12T15:52:24.441428Z  WARN ThreadId(16) stall_detector{role=H3}: ipa_core::helpers::gateway::stall_detection::gateway: Helper is stalled sn=103378760 state=
{
"gate[12073]=binary_validator/row9/computed_capped_attributed_trigger_value_not_saturated_case", from=H2. Waiting to receive records ["[115..1023]"].
"gate[12086]=prime_field_validator/modulus_convert_breakdown_key_bits_and_trigger_values/convert_bit0/xor2", from=H2. Waiting to receive records ["[0..1023]"].
"gate[12094]=prime_field_validator/modulus_convert_breakdown_key_bits_and_trigger_values/convert_bit1/xor2", from=H2. Waiting to receive records ["[0..1023]"].
"gate[12102]=prime_field_validator/modulus_convert_breakdown_key_bits_and_trigger_values/convert_bit10/xor2", from=H2. Waiting to receive records ["[0..1023]"].
"gate[12111]=prime_field_validator/modulus_convert_breakdown_key_bits_and_trigger_values/convert_bit2/xor2", from=H2. Waiting to receive records ["[0..1023]"].
"gate[12119]=prime_field_validator/modulus_convert_breakdown_key_bits_and_trigger_values/convert_bit3/xor2", from=H2. Waiting to receive records ["[0..1023]"].
"gate[12127]=prime_field_validator/modulus_convert_breakdown_key_bits_and_trigger_values/convert_bit4/xor2", from=H2. Waiting to receive records ["[0..1023]"].
"gate[12135]=prime_field_validator/modulus_convert_breakdown_key_bits_and_trigger_values/convert_bit5/xor2", from=H2. Waiting to receive records ["[0..1023]"].
"gate[12143]=prime_field_validator/modulus_convert_breakdown_key_bits_and_trigger_values/convert_bit6/xor2", from=H2. Waiting to receive records ["[0..1023]"].
"gate[12151]=prime_field_validator/modulus_convert_breakdown_key_bits_and_trigger_values/convert_bit7/xor2", from=H2. Waiting to receive records ["[0..1023]"].
"gate[12159]=prime_field_validator/modulus_convert_breakdown_key_bits_and_trigger_values/convert_bit8/xor2", from=H2. Waiting to receive records ["[0..1023]"].
"gate[12167]=prime_field_validator/modulus_convert_breakdown_key_bits_and_trigger_values/convert_bit9/xor2", from=H2. Waiting to receive records ["[0..1023]"].
}

New attribution circuit looks like as follows.

                                      ┌─────────────────────────────────────────────┐
                                      │                                             │
                                      │                                             │
                                      │                                             │
              User circuit            │      sequential join (1024 active items)    │
                                      │                                             │
                                      │                                             │
                                      │                                             │
                                      └──────────────────────┬──────────────────────┘
                                                             │
                                                             │
                                                             │
                                                             │
                                                             │
                                                             │
                                                             ▼
                                      ┌────┬────┬────┬────┬────┬────┬────┬────┬─────┐
                                      │    │    │    │    │    │    │    │    │     │
              Capped values           │    │    │    │    │    │    │    │    │     │
                                      └────┴────┴────┴────┴────┴────┴────┴────┴─────┘

                                                          ┌────┐
                                            capped value  │    │
                                                          │    │
                                                          └────┘

                                                          ┌────┐
                                            capped value  │    │
                                                          │    │
                                                          └────┘

                                                          ┌────┐
                                            capped value  │    │
                                                          │    │
                                                          └────┘

                                                          ┌────┐
                                                          │    │
                                            capped value  │    │
                                                          └────┘

                                     ┌───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
                                     │                                                                                │
                                     │                                                                                │
            modulus conversion       │                                            sequential join (1024 active items)                                                    │
                                     │                                                                                │
                                     │                                                                                │
                                     └───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

                                     ┌───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
                                     │                                                                                │
                                     │                                                                                │
             aggregation             │                                             sequential join (1024 active items)                                                   │
                                     │                                                                                │
                                     │                                                                                │
                                     └───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

The issue is that 1024 active user circuits can produce more than 1024 items for modulus conversion. In fact, our test circuit starts processing the largest user circuits (10 rows) first, so around ~100 finished circuits can fill up the buffer for modulus conversion.
Here is how the failure case looks like.
On helper 1

Tokio polls the resulting stream (aggregation), which polls modulus conversion stream which, in turn, polls per user attribution circuit. First 1024 attribution circuits starts executing.
All helpers reach the step computed_capped_attributed_trigger_value_just_saturated_case. This means that all communications required for computed_capped_attributed_trigger_value_not_saturated_case has finished.
First 120 per-user attribution circuit futures resolve and produce 120 vectors with ~9 items each, totalling ~1024 capped values to be converted to prime field. They generate a wake notification to the executor.
Tokio executor makes a random decision to poll modulus conversion circuit, rather than per-user attribution stream. This moves 1024 capped values and modulus conversion produces 1024 multiplications and 1024 receive requests.
At this point it can't move forward because modulus conversion stream does not poll per-user attribution stream anymore and will not let the remaining circuits to complete. Receive requests remain outstanding. This is what we're seeing on one of the helpers

"gate[12073]=binary_validator/row9/computed_capped_attributed_trigger_value_not_saturated_case", from=H2. Waiting to receive records ["[115..1023]"].
"gate[12086]=prime_field_validator/modulus_convert_breakdown_key_bits_and_trigger_values/convert_bit0/xor2", from=H2. Waiting to receive records ["[0..1023]"].
...

On helper 2
At step 4, tokio executor makes a different decision and continues polling the sequential futures for per-user attribution circuit. This drives all receive requests for step computed_capped_attributed_trigger_value_just_saturated_case to complete and this helper moves to computed_capped_attributed_trigger_value_just_saturated_case. This is what is shown in the logs too:
Note the step is computed_capped_attributed_trigger_value_just_saturated_case and not computed_capped_attributed_trigger_value_not_saturated_case
"gate[12072]=binary_validator/row9/computed_capped_attributed_trigger_value_just_saturated_case", from=H1. Waiting to receive records ["[115..1023]"].
"gate[12085]=prime_field_validator/modulus_convert_breakdown_key_bits_and_trigger_values/convert_bit0/xor1", from=H1. Waiting to receive records ["[0..1023]"].

On helper 3, executor decided to keep polling the per-user attribution circuit and got stuck at the computed_capped_attributed_trigger_value_just_saturated_case step, while sending all the data required to the helper #2
2023-12-12T15:50:24.483444Z  WARN ThreadId(10) stall_detector{role=H1}: ipa_core::helpers::gateway::stall_detection::gateway: Helper is stalled sn=103458052 state=
{
"gate[12072]=binary_validator/row9/computed_capped_attributed_trigger_value_just_saturated_case", from=H3. Waiting to receive records ["[0..1023]"].
}

Now helpers are in a broken state. Two of them completed 114 per user attribution circuits and started doing modulus conversion. The third one completed 0 circuits because the other one got stuck at computed_capped_attributed_trigger_value_not_saturated_case and never sent it the data required to advance.
❯ grep "prf_sharding: close" h1.log | grep "per_user_attribution" | wc -l
       0

❯ grep "prf_sharding: close" h2.log | grep "per_user_attribution" | wc -l
     114

❯ grep "prf_sharding: close" h3.log | grep "per_user_attribution" | wc -l
     114

I believe the root cause of this issue is the misalignment of the flow control for two streams. Per-user attribution circuit with flow control enabled for 1024 user circuits can produce more than 1024 items for the downstream consumer.

Can we work around this by changing the protocol to not have one future generate multiple child futures?
I had a similar type of thing going on with quicksort, but I took a different approach. I used flat_map to map to a flattened list of inputs, which I mapped to async futures. We can probably do something similar.
https://github.com/private-attribution/ipa/pull/892

@benjaminsavage I haven't looked closely into quicksort implementation, but it seems it uses only one seq_join which is fine for later flattening the stream. When we have multiple combinations of them inside one protocol, we will be having this spiritual failures.
Currently my thinking is that we could fix it by removing backpressure from the user circuits (drive them in parallel). It won't be free, but it will fix the issue I think.
Long term I am less and less optimistic about concurrency control at infra layer. There are just too many things that can go wrong and that are invisible to the protocols which make those issues hard to reproduce and debug. I think we should invest in vectorization that will be applied at the circuit layer where you as an author can precisely control how much data you want to put on the wire. You could also control CPU parallelism - that will cost us something in terms of code, but benefits as I see them now outweight the cons.
Maybe @martinthomson and @andyleiserson who is working on vectorization can express their opinions too

I pushed a branch that seems to help with this. However, I believe it only reduces the chance that things get scheduled in a way that deadlocks, not eliminates it, at least if you allow for pathological scheduling of futures.
Also, judging by at least three discussions of deadlocks in the google results for "rust buffered stream", we're not the only ones to have trouble like this.

https://blog.polybdenum.com/2022/07/24/fixing-the-next-thousand-deadlocks-why-buffered-streams-are-broken-and-how-to-make-them-safer.html
https://tmandry.gitlab.io/blog/posts/for-await-buffered-streams/
https://rust-lang.github.io/wg-async/vision/submitted_stories/status_quo/barbara_battles_buffered_streams.html

There are a few changes I am contemplating that might be a more complete fix:

Modify things so that the seq_join after attribution can be eliminated, meaning there would be only one seq_join at the end of the protocol. I think doing this is non-trivial because of the way modulus conversion currently works with streams of values (not streams of futures). Even with that change, since there is a throughput mismatch between attribution and aggregation, the work unit for one or the other would need to be scaled (or, we would need to keep a buffer after attribution, to enable it to complete a work unit).
Or, modify seq_join to include the functionality in my BufferedStream, with some additional scheduling enforcement to guarantee the fix always works.
Modify seq_join to consume an iterator over futures rather than a stream of futures (i.e. remove the ability for the thing that produces the futures to block). Possibly that's the scheduling enforcement mentioned in the previous bullet. This might require changes to protocols (like not using streams of items in modulus conversion). I'm not sure if this is a fix, or if it just discourages patterns (the intermediate seq_join) that are likely to be problematic.
Make the use of record IDs more regular to eliminate the throughput mismatch. However, I'm not sure that's a fix without also doing some of the other things mentioned here.
Spawn portions of the protocol as independent tasks, so that they make progress even if not actively polled by something downstream.

things get scheduled in a way that deadlocks, not eliminates it

You mean "reduces deadlocks, not eliminates them", I assume.

Modify things so that the seq_join after attribution can be eliminated

This might help, but all signs point to this not helping.

include the functionality in my BufferedStream

I agree with you that the underlying problem is such that you reduce, not eliminate, at this point.

consume an iterator over futures

I can pretty much guarantee that consuming an iterator of futures is not going to make this better, based on my reading of those postings.  Maybe not at all.

Make the use of record IDs more regular

This falls under the "JuSt Be MoRe CaReFuL" strategy.  Maybe we can do that here, but I'm skeptical.

Spawn portions of the protocol as independent tasks

This is starting to sound better and better as things develop.  However, this whole async lifetime nonsense is a real drag.  I don't want to move to Arc over &, but it is starting to get more and more appealing.

My understanding of the buffered stream problem is that it comes down to something relatively simple.  Futures are only polled at the consumer, so that when you have an aggregation (like seq_join) you can create a situation where futures do not get polled when they need to.
Imagine a case where you have a collection of futures, where each future resolves from two (or more) underlying actions, each requiring independent driving.  Let's say that we have modulus conversion, which has two multiply operations: xor1 and xor2.  If you have 1k operations outstanding, you need to ensure that the xor1 operation is polled for the data to be sent or received.  But it could be that the 1k is not woken because xor2 is not making progress.  (More likely the roles of these two are inverted, but you get the idea.)
Most of the discussion talks about how to ensure that the delayed xor1 operations get polled.  Spawning does seem to be the answer that most people reach for here.  I don't know if we can guarantee that this will work for us, but I think that is what we should look to investigate.

consume an iterator over futures

I can pretty much guarantee that consuming an iterator of futures is not going to make this better, [...]

OK, maybe I got that part wrong.  Still, I think that we'd end up with more calls to .try_collect() than is ideal.

I think the problem and solution can be stated more simply than I was thinking the other day:
The problem occurs when processing of a completed work unit gets split up. Going back to the case Alex analyzed: one helper inevitably must be the first to receive 1,024 records of MPC data for the last gate in the attribution stage. At this point the seq_join for the aggregation stage begins pulling futures from its input stream. Because each item output from the attribution stage corresponds to multiple aggregation stage records, only ~120 attribution output records need to be consumed for the aggregation stage to reach a full active work unit of 1,024 futures. Once it does so, the aggregation seq_join will no longer pull additional futures from its input stream, which means that the futures that would have flushed data for the last of the 1,024 attribution records to other helpers can be left pending. (While the futures that flush the outbound data for the last of the 1,024 attribution records could have been scheduled previously, there is no reason they have to be.)
Viewed in light of that description, the fix is easier to justify: don't give any futures to the aggregation stage, until a full set of futures in the attribution stage has been driven to completion. Which is roughly what the fix was doing, but it can be made more precise by counting records in and out of the buffer. Each time a multiple of 1,024 records in is crossed, advance the number of records eligible to be output by 1,024.
I agree that changing the way seq_join accepts its input futures is irrelevant. On Saturday I was worried about a deadlock with the attribution and aggregation stages at arbitrary record IDs (e.g. aggregation at 9,000; attribution at 4,000 -- aggregation would need to run ahead to 40,000 to start pulling the data where attribution stopped). If that were the case, it might have been desirable to change things such that each aggregation stage future can independently couple with the attribution stage futures producing relevant data. But I don't think states like that are reachable, and I don't think that changing the coupling between the stages eliminates the fundamental problem of needing to tune the work unit carefully.
One other note -- maybe this is obvious, but it helped me in thinking about how the deadlocks happen -- the scheduler on helper A doesn't know when there is a future Y on helper B that is pending on data that will be sent by future X on helper A. This means that we're inherently reliant on future X getting scheduled for some other reason, in order to make progress. This would be a problem for our system even with a runtime like Javascript that always drives futures to completion.

I don't think that vectorization will fix this, at least not directly.

My thought was that if we give more control to the protocol code to control the width of execution. In extreme case, our channels can be configured with capacity 1, so each send actually triggers a network communication and vectorization techniques ensure we have enough data on the wire.
This could eliminate the delays and the need for seq_join.

Spawn portions of the protocol as independent tasks

This is starting to sound better and better as things develop. However, this whole async lifetime nonsense is a real drag. I don't want to move to Arc over &, but it is starting to get more and more appealing.

#873 should help with it. If futures spawned by seq_join are polled by the executor directly, OPRF IPA seems to be working fine. Not sure how sustainable it is to rely on that though.

Viewed in light of that description, the fix is easier to justify: don't give any futures to the aggregation stage, until a full set of futures in the attribution stage has been driven to completion. Which is roughly what the fix was doing, but it can be made more precise by counting records in and out of the buffer. Each time a multiple of 1,024 records in is crossed, advance the number of records eligible to be output by 1,024.

@andyleiserson I wonder if the fix needs to be put explicitly on the protocol side or we need another combinator in addition to seq_join. In the latter case, I worry a bit about complexity of this.

One other note -- maybe this is obvious, but it helped me in thinking about how the deadlocks happen -- the scheduler on helper A doesn't know when there is a future Y on helper B that is pending on data that will be sent by future X on helper A. This means that we're inherently reliant on future X getting scheduled for some other reason, in order to make progress. This would be a problem for our system even with a runtime like Javascript that always drives futures to completion.

this is interesting - I had an impression that runtimes like Javascript/Java always immediately schedule futures for execution. In what circumstances you think having such runtimes  can lead to a similar deadlock?

My thought was that if we give more control to the protocol code to control the width of execution. In extreme case, our channels can be configured with capacity 1, so each send actually triggers a network communication and vectorization techniques ensure we have enough data on the wire.

You're right... when I wrote that comment, I was thinking this was an issue of the helpers taking divergent execution paths, which I think could still happen with vectorization. But it's really a work unit problem, and if we can always set the work unit to 1 with vectorization, it shouldn't be an issue. (However, vectorization will introduce a different kind of work unit problem, since you need to collect a certain number of records to be packed into a vector.)

https://github.com/private-attribution/ipa/pull/873 should help with it. If futures spawned by seq_join are polled by the executor directly, OPRF IPA seems to be working fine. Not sure how sustainable it is to rely on that though.

I think it is as a good a fix as what BufferedStream does (performance win aside) -- it has the same effect, that completion of attribution futures necessary to make forward progress isn't dependent on the aggregation stage polling them.

@andyleiserson I wonder if the fix needs to be put explicitly on the protocol side or we need another combinator in addition to seq_join. In the latter case, I worry a bit about complexity of this.

I think the BufferedStream functionality could be integrated with seq_join, if we thought that made things simpler for protocol authors.

this is interesting - I had an impression that runtimes like Javascript/Java always immediately schedule futures for execution. In what circumstances you think having such runtimes can lead to a similar deadlock?

Yeah, that's my understanding too. The point about having issues even with different runtime behavior doesn't make sense. Problems arise because we don't construct all our futures eagerly (which we intentionally stopped doing, because it was inefficient). No runtime will execute futures that don't exist.
The issue is really that it's hard to know when a particular future needs to be created in order to make forward progress. And even given a solution that is 100% correct in applying local knowledge to create necessary futures, there is still remote knowledge (other helper needs X piece of data) that isn't available.


三台机器搭建双节点，max版本，各服务怎么分布，或者有没有搭建文档

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

可参考一下文档，https://fisco-bcos-doc.readthedocs.io/zh_CN/latest/docs/tutorial/pro/installation.html#tars


Move this to the organization Gorgonia

This package should be moved to https://github.com/Gorgonia when 1.0 is nearing. This is the result of the thinking that arose from #91.
The purpose of this is to move Gorgonia away from being just a personal project - it's not a personal project since last year, with great contributors like @NDari and @kabaka0 . I'm increasingly worried about the bus factor of this repo. Moving this repo to an organization would allow someone else to step up as main maintainer should you know, I get hit by a bus.
Once the move to the org is done, there are some further things that can be done:

The tensor package should be split out as well. (from github.com/chewxy/gorgonia/tensor to github.com/Gorgonia/tensor)
An additional horny package (the analogue of Keras) could be added. It's a personal package for now, with a bunch of structs that define a neural network layer. But it's highly opinionated. Still thinking about it.

Additional details please?

This package should be moved to https://github.com/Gorgonia when 1.0 is nearing.
The tensor package should be split out as well.
An additional horny package (the analogue of Keras) would be added, but I'm in two minds about it because it's quite opinionated -  significantly more so than Keras

This may be a side point, but I think before going in that direction, maybe we need to add a bit more.. professionalism to the packages ;) for example, remove all the curse words in the comments, and maybe rename horny to something... different. I enjoy the comments, but I think it is worth making this package a bit less colorful since this is a serious package. If this is something we want to do, I can take point on it.

I'll keep this in mind as I work on the pro-oriented doc site as well.

I agree with @ndari. And horny is the name of my personal package that I use personally (it's a reference Keras, which means horn). I mean I get weird looks from people who review my CV and say "you created a package called sexp"...
it'll all be cleaned up

Thats not as bad as sextractor.

Updated the main post again, as it's time to start putting some serious work into this issue

Added TODO list as this seems to be a lot more concrete now

Thank you all. @kabaka0 @NDari . This package now lives in the Gorgonia org which you are owners of.


LCA of a Binary tree

Description
Lowest Common Ancestor of a binary tree using cpp
Domain
Data Structure
Type of Contribution
Documentation
Code of Conduct

[X] I follow Contributing Guidelines & Code of conduct of LearnCPP.

I would like to work on this issue under GSSOC'22

Greetings!
As the issue has not yet been worked upon, I would like to work on it. Kindly assign this issue to me under GSSOC 2022.

??


Support criteo/dlrm operations with cpu-backed Dataset

Establishes CPU support for all operations used in Criteo/DLRM example (i.e. Categorify, LogOp, FillMissing, Clip, Normalize).  Note that this contributes to the work requested in #534

It's amazing how small these changes are. Super cool!


Add BaseMetric

Codecov Report
Attention: Patch coverage is 0% with 26 lines in your changes missing coverage. Please review.

Project coverage is 98.94%. Comparing base (ec8565f) to head (992c3f7).

Files
Patch %
Lines

src/karbonn/metric/base.py
0.00%
23 Missing :warning:

src/karbonn/metric/__init__.py
0.00%
3 Missing :warning:

Additional details and impacted files
@@             Coverage Diff             @@
##              main     #225      +/-   ##
===========================================
- Coverage   100.00%   98.94%   -1.06%
===========================================
  Files           79       81       +2
  Lines         2433     2459      +26
  Branches       301      305       +4
===========================================
  Hits          2433     2433
- Misses           0       26      +26

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Is there any pre-trained RETRO model released yet?

I don't have resources to train a large model myself, but I'm wondering if anyone has used this repo to release a model that I can play with.
Thanks!

+1

+1 for pre-trained model!

@lucidrains if there's a pretrained model (even the encoder part), please let us know?

@lucidrains if there's a pretrained model (even the encoder part), please let us know?

My team is trying to do this, so if you are interested, check out this project : https://github.com/Langboat/mengzi-retrieval-lm


Update 6.5 docs

Before 6.5.10:

[ ] new domain?
[ ] add link to 7.0
[ ] ensure that pipelines are ok

Closing in favor of #775


UAA logout.do does not logout of all webapps

We tried using the logout.do API in UAA in order to logout of all the webapps as stated in
"The UAA can act as a Single Sign On server for the Cloud Foundry platform (and possibly user apps as well), so if a user logs out he logs out of all the apps."
However the user is not actually logged out. When I access one of the webapps then user is not logged out.
Thanks

/logout.do will trigger a local logout in the UAA but does not inform applications about a logout as UAA does not keep track of sessions in the applications.
As OAuth2 server, UAA issues tokens which usually have a longer validity than the UAA user sessions.
Some approaches for implementing single logout from a technal perspective (I have not yet tested against UAA)

Move to the SAML2 protocol as UAA now implements the SAML2 IdP role
revoke tokens and use online token validation against the UAA check_token endpoint

In regards to
"2) revoke tokens and use online token validation against the UAA check_token endpoint"
Does not /logout.do or /logout invalidate the UAA token? Does it have to be done by apps?

no, the issued tokens have a longer lifetime than the UAA user session (by intent). This is standard OAuth2 behaviour.

Investigating the single sign out question myself, could we add a new attribute under 'clients' to hold the logout-url of the client application. For each client that has this attribute specified the logout.do will create an iframe with the logout url. It has been mentioned that uaa would need to know which client you are logged into, but if you call the logout url on a client you are not logged into would this not fail silently? This still might have a scale-ability issue, but could be a feature that can be used with said warning.
There maybe a scenario or a technical issue that means that this is not possible, but I think it is worth exploring.

Closing this issue as we have started work on the iframe/post message format as part of the OpenID Connect session management spec implementation. Please follow this epic https://www.pivotaltracker.com/epic/show/2869233


remove magic 12, add XmlTest

add XmlTest, & fixes #128

sorry, this add test currently would fail.
I will soon fix.


Using with angular 4

guys, we are trying to use rangy with angular 4 core and systemJs transpiler, but we faced lots of challenges:
-First: i installed the lib with npm install rangy
-Second: i have added the core-js to systemJs bundler    'rangy': 'node_modules/:rangy/lib/rangy-core.js'
-Third: i have installed necessary typings

Finally: when acquiring the library:
rangy.getSelection().saveCharacterRanges(this.currentElement)
always getting cannot read undefined function saveCharacterRanges

Have you solved the issue?

Yes it was systemJs acquiring issue, any way we migrate to webpack instead of ugly systemJs support 😊

@RamyEl-basyouni How to properly import Rangy in Angular 7 app?

Sorry for the late response,
Just install rangy using npm and then import to your component:
import * as rangy from 'rangy'
Now you can use rangy variable

@Greatshock as mentioned above

Hey @joistick11 @RamyEl-basyouni
Do you have any thoughts on how to use not only core of rangy but other stuff as rangy-highlighter or rangy-classapplier with Angular?
import * as rangy from 'rangy' or import rangy from 'rangy' (doesn't matter) - open the door only to core methods and properties. But unfortunately it's impossible to use i.e. rangy.createClassApplier method.
Thanks in advance for your tips!

But unfortunately it's impossible to use i.e. rangy.createClassApplier method.

I'm maintaining an old project had the same issue today. This is how I got it working:
import rangy from 'rangy/lib/rangy-core';
import 'rangy/lib/rangy-classapplier';
import 'rangy/lib/rangy-textrange';

Then you can use rangy.createClassApplier and rangy.getSelection().saveCharacterRanges.


add-unit-testing-to-rhtap

This pr adds unit testing to rhtap for rekor. I've created my own version of rekor in rhtap in my own workspace and have tested both fail and success scenarios for both.
Comments
I only went with that image as its the same used in the Docker files, if it needs to be changed let me know :+1:
Gonna work on the e2e tests next

If you can access the links you can see them passing, you can also view the logs to confirm

https://console.redhat.com/preview/application-pipeline/workspaces/securesign/applications/rekor/pipelineruns/backfill-redis-on-pull-request-hpxt5
https://console.redhat.com/preview/application-pipeline/workspaces/securesign/applications/rekor/pipelineruns/rekor-cli-on-pull-request-gdwhn
https://console.redhat.com/preview/application-pipeline/workspaces/securesign/applications/rekor/pipelineruns/rekor-server-on-pull-request-9n5m2


Not working for .Slim files

Does highlight or give any intellisense for a slim files. Slim files are treated as plaintext

Have you installed this extension: https://marketplace.visualstudio.com/items?itemName=sianglim.slim

Is this step mentioned in its instructions somewhere?
I only installed https://marketplace.visualstudio.com/items?itemName=gencer.html-slim-scss-css-class-completion.  and reading "Supported Language Modes" : "Slim" makes me think that it will make autocomplete and highlight work for slim files.

Sorry for misleading. This extension will not work without that extension.
I will clearly state this in README.

I've go ahead and added requires note to the slim.
Closing this issue favor on this change.


[Doom - Downgrade] Prevent using documents and datasources after downgrade if they are over the free plan limits

Related design doc
Tasks:

Add logic that if a datasource has more docs than the limits, it’s not usable by api or custom assistants (incl. error message for api and notification for CAs)
Add logic that if there are more datasources than the limits, static datasources are not usable by api or CAs (incl. err msgs / notification)

This turns out to require tradeoffs. Below, framing

Datasource limits for users who downgraded: the case where the user had more datasources (or documents) than the new downgraded plan allows
Enforcing the limit = err on the retrieval, and alert the user that they have to remove datasources / documents to get it to work again
Context
A. Currently, this case only affects users who canceled their subscription, and switched back to a free plan
B. in the future, it might affect users who switch from a plan to another where limits change
C. This is only about the case where there is a decrease in the user allowed limits. Other cases not discussed here:

Enforcing limits when the user hasn't yet reached them, and tries to add datasources / documents from the app => already handled;
The case in which they try to add datasources using the API => PR incoming;

Solutions
Performing counts on the datasources and documents might be costly. We have 2 options:

solve only for case A (present) => run the count directly in runRetrieval

run the counts only on free plan for rag agents based on static DS => this can then be done live during the RAG action, since it concerns few users who have churned anyways and probably don't evem have messages left in their free plan.

solve for case B (possible future in which people change their max DS/documents limit)=> then we need to find solutions

ability to mark datasources as unavailable, or limits as reached, somewhere easily available by api (but needs to be synced e.g. the user can remove datasources)
have dedicated cached queries for counts on datasources / documents
other ideas?

Conclusion

I favor solution A, I can ship in ~15' if agreed on (so I'm biased, thus checking for agreement), PR is already half there.
I think the possible future is not definite, and dealing with those hypothetical future cases is not a priority--as long as we can clearly know if and when we hit them in the future so they don't take us by surprise
=> I will throw a loud exception, with a link to this issue, if the code ends up trying to enforce a datasource limit for a non-free plan.

@spolu r? Or maybe there is a fast solution I missed?
@aric mentionning you too since you were on the PR

Following IRL discussion with @spolu & @lasryaric, current situtation does not warrant our time to handle: solution AA => we let the user run messages on agents that have static datasources. Very edge-casy anyways
However, avoiding keeping large static datasources for indefinite periods of time is important; therefore:

for now: ops email when user downgrades will be updated to check there is no large static datasource, and otherwise to contact the user and tell them they will be removed in 7 days
future: we will have a retention policy of 30 days for free users => untouched datasources will be scrapped after a month

A runbook will be created + the downgrade faq will be updated to reflect that

Thank you!


Getting task-begin and task-create callbacks from Intel runtime for initial task

Have previously noted that Intel runtime gives task-create and task-enter callbacks for initial task, while LLVM does not. Thought I'd fixed this.
Noticed when running BOTS fib that trace includes these events when invoked with Intel runtime. Results in duplicate task nodes for the initial task, which is not intended.

Have tried and failed to reproduce this, closing for now until I can do so.

Have been able to duplicate this by invoking an icc-compiled app and clang-compiled Otter - the issue happens because the code that skips the inital-task-create event is only present when compiling Otter under Intel. Remove the #ifdef and all should work as expected.


PaymentSheet doesn't set in Customer the selected card

Describe the bug
If the user has multiple cards added via PaymentSheet, there isn't anywhere in the API that says what is the selected card.
Also, in https://stripe.com/docs/payments/save-and-reuse?platform=react-native&ui=payment-sheet#charge-saved-payment-method, it says to use stripe.paymentMethods.list to get the user payment methods. Ok, but if there are multiple methods, how do I know the one that the user has selected? This seems to be a major flaw in Stripe.
If I make my own way to set the default card, it will just be ambiguous to the user what really is the selected card, as in PaymentSheet it may has another card selected. What is the point of selecting another card in PaymentSheet and pressing Set Up and waiting for its loading if it doesn't do anything at all?
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

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.

closing as a duplicate of https://github.com/stripe/stripe-react-native/issues/716


dapr status -k parses image tag / version name incorrectly

Expected Behavior
When using a custom image for the dashboard k3d-registry:5555/dashboard:dashfix-linux-arm64 I found that dapr status -k shows the image name as 5555/dashboard:dashfix-linux-arm64.
Instead of the first :, the last : should be used to identify the version / image tag.

Is this related to https://github.com/dapr/cli/pull/1116, /cc @pravinpushkar?

right.. Should be fixed in this release. @berndverst

@berndverst Can you verify that the intended fix is there in place? Then this issue can be closed,

@mukundansundar Is this still open?

@shivam-51 It should have been fixed already.


Automated Package Upgrade

:tada: This PR is included in version 7.7.3 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Return pkttag with network list objects

Bug Fix: Return pkttag with network list objects
Manual testing: add network with VLAN id, list networks, verify VLAN id
Fixes-Jira: CNTV-175

can you add unit test?

@amccormi this change looks fine, but notice that the file you're editing is under the vendor directory... that means it's coming from another repo.
The file you really want to edit is here:  https://github.com/contiv/contivmodel/blob/21d55827df093ccf432760d0ff375dbec276cc9b/contivModel.go#L3515
However, that file is codegen'd from another repo:  https://github.com/contiv/modelgen/blob/6e594250ebafdcc9b4cc932b91411ae6ceee4174/generators/templates.go#L938
Making this change is going to require a minimum of 3 PRs, and the final PR on netplugin will just be updating the "contivmodel" dependency in Godeps.


Update deprecated npm packages

Using node 16, building generates these warnings. We should upgrade to more recent versions of these packages.

npm WARN deprecated<EMAIL_ADDRESS>this library is no longer supported
npm WARN deprecated<EMAIL_ADDRESS>Please upgrade  to version 7 or higher.  Older versions may use Math.random() in certain circumstances, which is known to be problematic.  See https://v8.dev/blog/math-random for details.
npm WARN deprecated<EMAIL_ADDRESS>Use mz or fs-extra^3.0 with Promise Support
npm WARN deprecated<EMAIL_ADDRESS>request has been deprecated, see https://github.com/request/request/issues/3142
npm WARN deprecated<EMAIL_ADDRESS>cross-spawn no longer requires a build toolchain, use it instead
npm WARN deprecated<EMAIL_ADDRESS>Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
npm WARN deprecated<EMAIL_ADDRESS><EMAIL_ADDRESS>is no longer maintained and not recommended for usage due to the number of issues. Because of the V8 engine whims, feature detection in old core-js versions could cause a slowdown up to 100x even if nothing is polyfilled. Please, upgrade your dependencies to the actual version of core-js.
npm WARN deprecated<EMAIL_ADDRESS><EMAIL_ADDRESS>is no longer maintained and not recommended for usage due to the number of issues. Because of the V8 engine whims, feature detection in old core-js versions could cause a slowdown up to 100x even if nothing is polyfilled. Please, upgrade your dependencies to the actual version of core-js.

(This output is from gear icon on the righthand side in the GitHub Actions tab, and selecting View Raw Logs of one of the build actions)

Will look into this more after finishing the connect button and the 5 second pinging. I will re-assign myself once I'm finished with the other issues if this has not been resolved yet.


Can not pair my 310XT

Hi.
I am trying this tool on my Garmin 310XT (latest firmware).
I get stuck here:
Driver available: [<class ant.base.driver.SerialDriver at 0x7f06036298d8>, <class ant.base.driver.USB2Driver at 0x7f0603629f58>, <class ant.base.driver.USB3Driver at 0x7f06033db050>]
 - Using: ant.base.driver.SerialDriver
Serial information:
name:             /dev/ttyUSB1
port:             /dev/ttyUSB1
baudrate:         115200
bytesize:         8
parity:           N
stopbits:         1
timeout:          None
writeTimeout:     None
xonxoff:          False
rtscts:           False
dsrdtr:           False
interCharTimeout: None
Request basic information...
  Capabilities:  array('B', [4, 3, 0, 3])
Starting system...
Key done...
Searching...
Authenticating with Forerunner 310XT<PHONE_NUMBER>)
 - Pairing:

I don't get any pair prompt on my device. I have data transfer and pairing turned on on the garmin.
What can I do, any ideas?

It looks like it is using the SerialDriver, which is not that functional at the moment. That probably means you have an older USB1-Wireless USB Stick. I know it is not a good solution, but it is possible to buy the newer one from Garmin or other manufacturer. Issue #47 is the main bug for this. Someone had success using a Suunto Movestick Mini in #92 as well.


🐛 [PLUGIN_NAME_HERE] Your issue title here

I have migrated to firebase_messaging: ^8.0.0-dev.14
however i started receiving error that .configure is missing in
FirebaseMessaging.instance.configure(
      onMessage: (Map<String, dynamic> message) async

configure() was removed from 8.0.0-dev.14.
You can now directly listen to changes using
FirebaseMessaging.onMessage.listen((RemoteMessage message) { }); FirebaseMessaging.onMessageOpenedApp.listen((RemoteMessage message) { });

I have migrated to firebase_messaging: ^8.0.0-dev.14
however i started receiving error that .configure is missing in
FirebaseMessaging.instance.configure(
      onMessage: (Map<String, dynamic> message) async

yes i have figured this out.
I have 2 more questions because documentation i smissing:

Code taken from your example - is it nessecarry? f yes how to create chanel?

  /// Create an Android Notification Channel.
  ///
  /// We use this channel in the `AndroidManifest.xml` file to override the
  /// default FCM channel to enable heads up notifications.
  await flutterLocalNotificationsPlugin
      .resolvePlatformSpecificImplementation<
          AndroidFlutterLocalNotificationsPlugin>()
      ?.createNotificationChannel(channel);

How to show image on the left side of the notification? Because if i attach image in payload it displays at the bottom of th image as big as it is

This is not necessary, it is just used for local notifications, as mentioned in the comment
Not sure but that is platform-specific (see https://pub.dev/packages/flutter_local_notifications). firebase_messaging is only responsible for communicating with Firebase Cloud Messaging to register the device and be able to use all of the functionality to receive and read the data of notifications from different app states.

 You can even do this yourself with some dart code to create a widget that interprets the RemoteMessage received in onMessage and shows it in a way that you would like.
Closing this for now since it isn't really an issue with the plugin or the documentation.

Thanks,
in comments heads up notification is mentioned but not local notification
On Tue, 2 Feb 2021 at 14:56, Markus Aksli<EMAIL_ADDRESS>wrote:

This is not necessary, it is just used for local notifications, as
mentioned in the comment
Not sure but that is platform-specific (see
https://pub.dev/packages/flutter_local_notifications).
firebase_messaging is only responsible for communicating with Firebase
Cloud Messaging to register the device and be able to use all of the
functionality to receive and read the data of notifications from different
app states.

 You can even do this yourself with some dart code
to create a widget that interprets the RemoteMessage received in onMessage
and shows it in a way that you would like.
Closing this for now since it isn't really an issue with the plugin or the
documentation.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/FirebaseExtended/flutterfire/issues/4918#issuecomment-771650924,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA54ZF4MFVUCXCLSIPTV5FDS4777FANCNFSM4W6UBRTQ
.

--
Pagarbiai,
Vytautas Pranskunas


Update bazel-toolchains mirror URL warning

What
Change the bazel-toolchains mirror URL to use the release archive format instead of the commit archive format.
Why
According to @smukherj1 from the bazel project in bazelbuild/bazel-toolchains#891 the GitHub commit archive URL is no longer mirrored by mirror.bazel.build. Instead the GitHub release archive URL is mirrored. This incorrect URL is causing bazel to output the following warning during build:
$ git clone https://github.com/google/tink
$ git checkout 23ce810c979b1105fe6a657a5667a7275764b411
$ cd tink/tools/tinkey
$ bazel build tinkey
WARNING: Download from https://mirror.bazel.build/github.com/bazelbuild/bazel-toolchains/archive/3.2.0.tar.gz failed: class com.google.devtools.build.lib.bazel.repository.downloader.UnrecoverableHttpException GET returned 404 Not Found
...

Thanks, working on merging this.


Delete workitem

[1] Provide the ability to delete workitem(s)
[2] Space owner and workitem creator can delete workitem
[3] It is a soft delete
[4] When a workitem is deleted, all links associated with it are deleted
User Story:
https://openshift.io/openshiftio/Openshift_io/plan/detail/76

Fixed via https://github.com/fabric8-services/fabric8-wit/pull/2305


Reproducible random numbers for filling tensors

Currently, our numerical tests generate random numbers in a non-reproducible way.
Using this PR, a new call was added to the runtime helpers to either print the seed that will be used, or read the seed from an env variable. For example:
root@1250b049ac2b:~/onnx-mlir/build# Debug/bin/TestMatMul2D
Model can reuse the current seed by exporting "TEST_SEED=1097851945"
...

ran without the TEST_SEED being defined, so a new random seed was selected. If we were to run the same test again but exporting TEST_SEED=1097851945, then that seed would be used, thus enabling us to re-run the same experiment with the same random numbers.
The call to handle the random seeds is here.
**
 * omDefineSeed.
 * When called, the random number generator for omTensorCreateWithRandomData
 * will be seeded exactly once. The seed is randomly generated when ignoreSeed
 * is nonnull; otherwise the input seedValue is used.
 *
 * @param seed input seed.
 * @param ignoreSeed when nonzero, ths function define its own random seed.
 * @return return the seed that was used.
 *
 */
unsigned int omDefineSeed(unsigned int seed, unsigned int ignoreSeed);

The handling of an env variable is done by a static function in ModelLibBuilder top class:
  // Set the random number generator seed to the value passed by the environment
  // variable; if not found, use a random seed. Optional call to enable
  // reproducible random numbers.
  static void setRandomNumberGeneratorSeed(const std::string &envVar);

Jenkins Linux s390x Build #5132 [push] Reproducible random numb... started at 11:32

Jenkins Linux ppc64le Build #4253 [push] Reproducible random numb... started at 11:35

Jenkins Linux amd64 Build #5116 [push] Reproducible random numb... started at 10:32

Jenkins Linux ppc64le Build #4253 [push] Reproducible random numb... failed after 39 min

Jenkins Linux s390x Build #5132 [push] Reproducible random numb... passed after 1 hr 0 min

Jenkins Linux amd64 Build #5116 [push] Reproducible random numb... passed after 1 hr 12 min


HoloLens 2 - MRTK - Unity UI Interaction - direct manipulation doesn't work

Description:
Direct manipulation of Unity UI Interaction in MRTK doesn't work.
Steps to reproduce the behavior:

Go to MRTK
Try far field (hand rays) interaction to manipulate Button, Toggle Button, Slide Bar and Drop down Menu.
Confirm far field interaction works.
Try near field (direct manipulation) interactions to manipulate Button, Toggle Button, Slide Bar and Drop down Menu.
Confirm near field interaction doesn't work.

Setup

MRTK Version [2<IP_ADDRESS>]

Target Platform

HoloLens 2

could be related to https://github.com/Microsoft/MixedRealityToolkit-Unity/pull/3749

@vijiang, can you see if this repros on latest mrtk_development? The MRTK version being used there is super old (i.e. 10 months now) and there's been significant churn since then.


Improve README formatting and link to HttpListener

Pull Request Creation Checklist

[x] Useful title (i.e. Fix #XXX: Description / Feature #XXX: Description / RFC #XXX: Description)
[x] Description of the changes you are making

LGTM, thanks!


Support model for Summit (and beyond)

This section needs to be re-thought for Summit:
https://rh-aiservices-bu.github.io/insurance-claim-processing/modules/02-01-getting-connected.html#_getting_support_during_rh1_in_person_labs
because

It's not RH1
we can't use slack

this has been done


Make StateKey stateKey

No need to expose this outside the package.
But maybe clients want it because they need to know what to Query for?

StateKey is not a required interface function of plugin. Within paytovote StateKey isn't even used, individual keys for each issue are generated using IssueKey, which IS in fact called by the paytovote CLI extension commands for the paytovote-query command... so It does need to be exposed in this example. Makes sense generally to allow for other plugins to query right out of the state? Even if StateKey isn't used in the example plugins within basecoin I imagine most complex plugins will want access for CLI extendibility

Frey had included this as a TODO in his edits to the docs. I pulled it out into an issue, but I don't even think it is one because clients might need the state key to provide custom query commands

@rigelrozanski @ebuchman Can this be closed, since it seems we want to expose it?

Sure. Closing...


Watermark in scenes after the latest update

After updating to the latest version there is a watermark in every scene generated. This is with either models mm_sd_v14 and mm_sd_v15.
See also included gif as an example;

When checking out revision 8849369ce0839dc9a3ee563e56aef9e451e9c421 this problem is no longer present and generated without any watermark.

Probably is related to this continue-revolution/sd-webui-animatediff/issues/31

I guest I'll revert the change until the original author identifies the root cause.

I played around with both version and found that the watermark only present in some models, not always.

Old revision
New revision

As mentioned in the issue thread, it seems to be due to the training dataset. The new version is the correct implementation and produces smoother GIFs compared to the older version. However, I've brought back the old method and also created a new node with the new method, so you can try both to find the best fit for each model.


[Urgent!!!] When I use my own datasets, after I run the sheet "train_blending_gan.py", the command line seems to be stuck and no any errors!

When I use my own datasets, after I run the sheet "train_blending_gan.py", the command line seems to be stuck like this:
Input arguments:
        nef: 64
        ngf: 64
        nc: 3
        nBottleneck: 4000
        ndf: 64
        lr_d: 0.0002
        lr_g: 0.002
        beta1: 0.5
        l2_weight: 0.999
        gpu: 1
        n_epoch: 25
        data_root: steel_plates
        load_size: 64
        image_size: 64
        ratio: 0.5
        val_ratio: 0.05
        d_iters: 5
        clamp_lower: -0.01
        clamp_upper: 0.01
        experiment: encoder_decoder_blending_result
        test_folder: samples
        workers: 4
        batch_size: 64
        test_size: 64
        train_samples: 150000
        test_samples: 256
        manual_seed: 5
        resume:
        snapshot_interval: 1
        print_interval: 1
        plot_interval: 10

Create & Init models ...
        Init G network ...
        Init D network ...
        Copy models to gpu 1 ...
Init models done ...

Load images from steel_plates ...
        21 folders in total, 1 val folders ...
        Trainset contains 150000 image files
        Valset contains 256 image files

Saving samples to encoder_decoder_blending_result/samples ...

And, when I kill this script, the command line shown like this:
^CTraceback (most recent call last):
  File "train_blending_gan.py", line 183, in <module>
    main()
  File "train_blending_gan.py", line 164, in main
    train_batch = [trainset[idx][0] for idx in range(args.test_size)]
  File "train_blending_gan.py", line 164, in <listcomp>
    train_batch = [trainset[idx][0] for idx in range(args.test_size)]
  File "/home/wyy/anaconda3/envs/python36/lib/python3.6/site-packages/chainer/dataset/dataset_mixin.py", line 67, in __getitem__
    return self.get_example(index)
  File "/ssd3/wyy/projects/GP-GAN/dataset.py", line 84, in get_example
    obj_croped = self._crop(obj, rw, rh, sx, sy)
  File "/ssd3/wyy/projects/GP-GAN/dataset.py", line 66, in _crop
    im = resize(im, (rw, rh), order=1, preserve_range=False, mode='constant')
  File "/home/wyy/anaconda3/envs/python36/lib/python3.6/site-packages/skimage/transform/_warps.py", line 148, in resize
    cval=cval, mode=ndi_mode)
  File "/home/wyy/anaconda3/envs/python36/lib/python3.6/site-packages/scipy/ndimage/filters.py", line 299, in gaussian_filter
    mode, cval, truncate)
  File "/home/wyy/anaconda3/envs/python36/lib/python3.6/site-packages/scipy/ndimage/filters.py", line 217, in gaussian_filter1d
    return correlate1d(input, weights, axis, output, mode, cval, 0)
  File "/home/wyy/anaconda3/envs/python36/lib/python3.6/site-packages/scipy/ndimage/filters.py", line 95, in correlate1d
    origin)
KeyboardInterrupt

Is the size of the image in my dataset (5000x3000) too large? Or is it something else? I look forward to your reply and would appreciate it.

It's too large. Can you try smaller size, see 64x64?

However, I scaled the original 5000x3000 to 64x64 while training, and the problem I described above occurred. @wuhuikai


What is the recommended way of using vcpy with boto3?

I created a bunch of tests using vcrpy with boto3 without really looking under the hood at what was going on and just enjoying the magic.
Now I see that the requests are based on the settings in my environment (ex: region, credentials). If any of those change (which they have) the tests break.
I also just noticed the uri has changed for some boto calls which are breaking tests.
Example:
vcrpy is trying to match:
<Request (POST) https://cloudfront.amazonaws.com/2017-03-25/origin-access-identity/cloudfront>
while the cassette contains:
https://cloudfront.amazonaws.com/2016-11-25/origin-access-identity/cloudfront
What is the recommended way to use this with boto3 so that it ignores these changing elements?
Update: modifying the cassettes to use the new cloudfront uri fixed the tests affected by the uri issue, but is there a better way than find/replace?
Thanks

You can filter that information from the request: http://vcrpy.readthedocs.io/en/latest/advanced.html#filter-sensitive-data-from-the-request
Then it will not be stored in the cassette so it shouldn't be used for matching.

What about matching the cloudfront requests? Do I have to create a custom matcher so that in the future when they update their url again it doesn't break my tests? I imagine I'm not the only one using vcrpy with boto3. This along with any other issues that I'm probably not covering must be resolved already by someone.

Yup you could do that with a custom matcher.  Not aware of a more "universal" technique.

Ok thanks.


Don't process IPs if there are none

This attempts to avoid an error message when using this plugin with vagrant files that do not use goodhosts.
Currently untested

I tested it and seems works.


bump to akka 2.4-M3 in 2.12.x

See https://github.com/akka/akka/pull/18009
That will enable removal of scala.concurrent.util.Unsafe.

after which https://issues.scala-lang.org/browse/SI-9381 can be closed

akka PR was merge

I'll get back on this as soon as the regular 2.12.x build is green again.

2.12.x is green again. now running a community build with src/library/scala/concurrent/util/Unsafe.java removed at https://scala-ci.typesafe.com/view/scala-2.12.x/job/scala-2.12.x-integrate-community-build/146/consoleFull

fixed in #129


Links do not respect Azure AD tenant

Bot often adds links to Azure resources, such as the action group in this example:

Tom Kerkhove linked action group '{redacted} (Development)' (resource group: {redacted}, webhook: MicrosoftTeams_AzureApp_UTC_Apr_08_2020_071256) to this channel to receive notifications from subscription '{redacted}'.

However, it does not respect the Azure AD tenant in which the linked subscription lives.
When I click the link it goes to my companies' tenant, and not the one of my customer.

Apologies this is a known issue, it browses to the default tenant and you have to change to the right tenant in the browser.

Sounds fair, I presume this will be changed for public preview?


Drag-and-drop support in 3D view

Need to investigate what it takes to support dropping .osim, .mot files in embedded browser.

At least investigate implementing before the public beta.

I don't believe this issue has been fixed.  Using this build OpenSim-dd7dc47b-2018-02-11 when #514 was merged. Dragging the leg6dof9mus.osim model yields:

Closing the Visualizer Window and dragging into the blank space does load the model. Closing the model and dragging into the Visualizer Window yields:

Dragging into the Models - properties panel also loads the model but not the Navigator, which
shows the do not enter sign.

I think we should be able to drag directly into the Navigator as well and get the  do not enter sign when dragging into the Visualizer Window (if it cannot be supported) rather than a cryptic message. It is definitely confusing to say we do not support .osim files!
Also the curso changes from Copy+ to Move->  and both of these seem incorrect. It should be "Open" or "Load".

Let me explain the change in behavior to see if we can find reasonable consensus:

In 3.3 users had to drop .osim, .mot, .sto files into 3D window (drag handle displayed +Copy)
In 4.0 users can drop files into toolbar, Properties Window, Coordinates Window (drag handle displayed +Move)
Depending on whether graphics window is open, either you get the xml file to edit or a message that .osim files are not supported.
I just clarified the message in the second case to state that OpenSim files need to be Dropped into Toolbar. I can block dropping altogether in the Browser window though that may prevent the possibility of dragging geometry into the scene and users may miss that they can drop into Toolbar or other windows. Let me know what you think @aseth1 @chrisdembia @tkuchida

One solution is for the graphics window to be open when you first launch the GUI.

Thanks @chrisdembia but the reason we didn't do that (open gfx window on launch) in the first place is that the application GUI comes up before the server is ready to accept connections leading to Error/page-not-found misleading message in some cases.

I vaguely remember that, but perhaps there is some way to get a callback when the GUI is done loading.

@aymanhab I think the error window/message with the host address and "Unsupported file format (.osim)" should be removed. In its place we should block users from dragging into any region we do not want them too (or cannot support) by changing the cursor into a "do-not-enter" symbol and where it can be opened or loaded it should say "Load" or "Open" not Move or Copy since this is not the action being performed. I don't think the behavior of 3.3 is very relevant here especially if we are concerned with improving the interface. What we have now (OpenSim c596914-2018-02-24) isn't acceptable.

That's exactly what I implemented already, please verify when the build is
posted.
On Feb 25, 2018 11:24 AM, "Ajay Seth"<EMAIL_ADDRESS>wrote:

@aymanhab https://github.com/aymanhab I think the error window/message
with the host address and "Unsupported file format (.osim)" should be
removed. In its place we should block users from dragging into any region
we do not want them too (or cannot support) by changing the cursor into a
"do-not-enter" symbol and where it can be opened or loaded it should say
"Load" or "Open" not Move or Copy since this is not the action being
performed. I don't think the behavior of 3.3 is very relevant here
especially if we are concerned with improving the interface. What we have
now (OpenSim c596914
https://github.com/opensim-org/opensim-gui/commit/c5969142098827599030e27fc1be2a075c235d74-2018-02-24)
isn't acceptable.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/opensim-org/opensim-gui/issues/422#issuecomment-368336708,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADyccMX91r-yP4QsYvehqd9tD4rqe1rMks5tYbNZgaJpZM4P7SME
.

Great. I verified that this is now the case on Windows with build OpenSim-2416f17a-2018-02-25.
Is there a reason we cannot drag onto the Navigator? That seems to be the most natural place to drag to.

Thanks for verifying. The reason dropping of files into trees and lists is
blocked by default is that there's built in support for drag and drop
within these widgets e.g. to reorder that we don't want to hijack and could
be useful to utilize in the future.
On Feb 25, 2018 6:16 PM, "Ajay Seth"<EMAIL_ADDRESS>wrote:

Great. I verified that this is now the case on Windows with build
OpenSim-2416f17a-2018-02-25.
Is there a reason we cannot drag onto the Navigator? That seems to be the
most natural place to drag to.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/opensim-org/opensim-gui/issues/422#issuecomment-368371033,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADyccKA1RmEMSWsd9kE8IIQ9X1Ll6R2Sks5tYhPigaJpZM4P7SME
.

This does not work for me on my Mac. @aymanhab Is that expected?

Dropping into toolbar (and some other windows) should work, dropping into 3D view or navigator should not work for the reason mentioned above. It should be documented though since users may have been used to it from previous releases.

OK, the behavior works on Mac as you describe, although this does seem to be a downgrade from 3.3. The navigator and the 3D window are where I would try to drop a model. So I think most people will think the feature is no longer supported. Are there any other options?

That being said, I almost never use drag and drop on any application. 🦋  I think I may be the exception though.

I usually don't use drag and drop but I'm learning that it is pretty handy. I think @aseth1 uses it extensively.

In tools e.g. VisualStudio, you can drop anywhere, but dropping in navigator/tree has specific meaning (e.g. add to project). Eventually we want to leverage that and allow drag and drop in navigator between models/submodels etc. If we allow drop in Navigator now we may open a big can of new issues.


docs: add state transition function handbook

Motivation

Create an implementation handbook for new contributors to fully grasp what they are building, how to do it and why they are doing it.
Also adding a comprehensive visual representation of the state_transition function functional dependency tree.

@mpaulucci Do you have other comments or are there comments that i need to address before merging ?


[FORMATTING] MySQL TRUNCATE function not supported

SELECT TRUNCATE(88.244, 2),ROUND(88.2446,3)
Version: v10+

Thanks for reporting.
This currently happens because of the formatter doesn't properly distinguish between TRUNCATE [TABLE] statement and TRUNCATE function., which is part of a larger problem in the formatter.


fix(fix/doc-scripts):  build docs first

restore building the docs

:tada: This PR is included in version 2.10.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Implement Transact-SQL IF ELSE Statement Control Flows.

Fixes #1273 except for Blocks.

Coverage decreased (-0.09%) to 88.599% when pulling<PHONE_NUMBER>30733683cfc6bcca2e5156db94302f on manticore-projects:IfElseStatement into f85b4b630008d9ecbf707b534336460784ed6ea6 on JSQLParser:master.

Please correct conflicts.


finally - migration is complete :)

Added an example where one parameter depends on multiple ones in an older version
These two variables are sumed to form the new one.
The migrate method of the TestClass is a bit more complicated that when the one_to_one_mapping method is used.
I may add one more helper method to simplify this, but for now, it works.
There are still tons of debug messages which I will remove, when perhaps some more test-cases are thought of.
Could you come up with some siuations where the migration will be used. So far, only toy examples have been tested.

One very relevant example is the SVM code which has C1 and C2 currently but should rather have a vector C that could either contain just 1 variable (C is the same for all examples), two variables (one for negative class and one for positive) or as many entries as there are examples.
I don't recall if this is already supported in the x-validation (setting vectors instead of scalars) but I recall that it is annoying having to set C1 and C2 despite the most frequent use is C1==C2 :)


ERROR  Unexpected token (Note that you need plugins to import files that are not JavaScript)

Hi,
Another issue was recently reported in Nuxt-Security : https://github.com/Baroshem/nuxt-security/discussions/343
OP is using the following syntax:
false && console.log('.....')

Which results in ERROR  Unexpected token (Note that you need plugins to import files that are not JavaScript)
I guess removing the console.log('.....') part results in invalid JavaScript:
false &&

Suggestion: instead of removing the console.log('.....') part, you could maybe replace it with a noop such as (() => {})()

yep, I'll consider it.

Yeah, I think it could make sense to have it as it wouldn't break the code then for users that may utilise this approach.
Let us know @Talljack if we can do anything to help you :)

yep, I'll consider it.

Or, if you don’t want to insert many times the same code snippet, you could override console.log with the same function

fixed #17

Thanks @Talljack
I will bump the package in Nuxt Security and see how it works there :)

Yep. Go ahead
Jakub Andrzejewski @.***>于2024年1月19日 周五16:35写道：

Thanks @Talljack https://github.com/Talljack
I will bump the package in Nuxt Security and see how it works there :)
—
Reply to this email directly, view it on GitHub
https://github.com/Talljack/unplugin-remove/issues/8#issuecomment-1899978008,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AIGYDZFBSAYNBRMO3CIZ7JLYPIV6PAVCNFSM6AAAAABB62OBYOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJZHE3TQMBQHA
.
You are receiving this because you were mentioned.Message ID:
@.***>


Improve Login page

Currently User can see both mobile and otp fields and both allowing alphabets which should be restricted as well as otp field should only get displayed after otp has been send successfully. Add Alerts or toast to Notify if user has given wrong inputs

@codervivek5 Iam  willing to solve this bug, please assign it to me


fix: use relative url for submodule definition (#264)

Uses relative url for submodule so to enable users to clone from mirror site with --recurse-submodules.
Tested in  a site without GitHub access, using a mirror site
Tested with a normal configuration, using https://github.com as usual
Uses 2 levels of indirection (../../stevearc/nvim_doc_tools) instead of one (../nvim_doc_tools) so that people who fork aerial are not also forced to fork nvim_doc_tools.

Thanks for the PR!