Readd grpclb fallback

This is a continuation of #12187.
Issues I need to fix:

@sreecha Test times out. This should be fixed by avoiding multiple fallback timers.
@dgquintas Memory leakage: https://gist.github.com/dgquintas/42b4d0c7e639d5eea22f7b2ebea030b6.
@summerxyt Integration test failure. Fallback address update is not working where backends are restarted.

This change is

[trickle] No significant performance differences

This PR is in progress, right? If so, please add the "do not merge" and "work in progress" labels, to indicate us when we can start reviewing.

Yes. Just added the labels.  It happens about 1/1000.
FAILED: bins/opt/grpclb_end2end_test --gtest_filter=SingleBalancerTest.FallbackUpdate  GRPC_POLL_STRATEGY=epoll1 [ret=-6, pid=189863]

I0925 16:27:11.936582061    1231 ev_epoll1_linux.c:93]       grpc epoll fd: 3
D0925 16:27:11.936629270    1231 ev_posix.c:107]             Using polling engine: epoll1
D0925 16:27:11.936648500    1231 dns_resolver.c:301]         Using native dns resolver
D0925 16:27:11.936680510    1231 test_config.c:388]          test slowdown factor: sanitizer=1, fixture=1, poller=1, total=1
Note: Google Test filter = SingleBalancerTest.FallbackUpdate
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from SingleBalancerTest
[ RUN      ] SingleBalancerTest.FallbackUpdate
I0925 16:27:11.938828392    1231 grpclb_end2end_test.cc:525] starting backend server on port 2241
I0925 16:27:11.938985336    1264 server_builder.cc:269]      Synchronous server. Num CQs: 1, Min pollers: 1, Max Pollers: 2, CQ timeout (msec): 10000
I0925 16:27:11.940071604    1231 grpclb_end2end_test.cc:530] backend server startup complete
I0925 16:27:11.942032965    1231 grpclb_end2end_test.cc:525] starting backend server on port 1116
I0925 16:27:11.942095100    1287 server_builder.cc:269]      Synchronous server. Num CQs: 1, Min pollers: 1, Max Pollers: 2, CQ timeout (msec): 10000
I0925 16:27:11.943220799    1231 grpclb_end2end_test.cc:530] backend server startup complete
I0925 16:27:11.944276360    1231 grpclb_end2end_test.cc:525] starting backend server on port 7487
I0925 16:27:11.944349386    1298 server_builder.cc:269]      Synchronous server. Num CQs: 1, Min pollers: 1, Max Pollers: 2, CQ timeout (msec): 10000
I0925 16:27:11.945420614    1231 grpclb_end2end_test.cc:530] backend server startup complete
I0925 16:27:11.946173295    1231 grpclb_end2end_test.cc:525] starting backend server on port 14855
I0925 16:27:11.946219698    1311 server_builder.cc:269]      Synchronous server. Num CQs: 1, Min pollers: 1, Max Pollers: 2, CQ timeout (msec): 10000
I0925 16:27:11.947494103    1231 grpclb_end2end_test.cc:530] backend server startup complete
I0925 16:27:11.948205623    1231 grpclb_end2end_test.cc:525] starting balancer server on port 13202
I0925 16:27:11.948262070    1317 server_builder.cc:269]      Synchronous server. Num CQs: 1, Min pollers: 1, Max Pollers: 2, CQ timeout (msec): 10000
I0925 16:27:11.948995609    1231 grpclb_end2end_test.cc:530] balancer server startup complete
I0925 16:27:11.949422822    1321 grpclb_end2end_test.cc:188] LB[0x1a3f2e0]: BalanceLoad
I0925 16:27:11.949554969    1321 grpclb_end2end_test.cc:192] LB[0x1a3f2e0]: recv msg 'initial_request {
  name: "servername_not_used"
}
'
I0925 16:27:11.949563022    1321 grpclb_end2end_test.cc:304] LB[0x1a3f2e0]: sleeping for 1000 ms...
 Sending response 'server_list {
  servers {
    ip_address: "\177\000\000\001"
    port: 7487
  }
  servers {
    ip_address: "\177\000\000\001"
    port: 14855
  }
}
'
I0925 16:27:12.949737264    1441 grpclb.c:539]               Missing LB token for backend address 'ipv4:<IP_ADDRESS>:7487'. The empty token will be used instead
I0925 16:27:12.949754861    1441 grpclb.c:539]               Missing LB token for backend address 'ipv4:<IP_ADDRESS>:14855'. The empty token will be used instead
I0925 16:27:12.950866925    1231 grpclb_end2end_test.cc:789] ========= BEFORE THIRD BATCH ==========
I0925 16:27:12.951448621    1231 grpclb_end2end_test.cc:792] ========= DONE WITH THIRD BATCH ==========
I0925 16:27:12.951465234    1231 grpclb_end2end_test.cc:141] Backend: shut down
I0925 16:27:12.951471213    1231 grpclb_end2end_test.cc:549] backend about to shutdown
I0925 16:27:12.951552713    1231 grpclb_end2end_test.cc:552] backend shutdown completed
I0925 16:27:12.951568898    1231 grpclb_end2end_test.cc:141] Backend: shut down
I0925 16:27:12.951573802    1231 grpclb_end2end_test.cc:549] backend about to shutdown
I0925 16:27:12.951663653    1231 grpclb_end2end_test.cc:552] backend shutdown completed
I0925 16:27:12.951669885    1231 grpclb_end2end_test.cc:141] Backend: shut down
I0925 16:27:12.951672281    1231 grpclb_end2end_test.cc:549] backend about to shutdown
I0925 16:27:12.951833650    1231 grpclb_end2end_test.cc:552] backend shutdown completed
I0925 16:27:12.951840506    1231 grpclb_end2end_test.cc:141] Backend: shut down
I0925 16:27:12.951842867    1231 grpclb_end2end_test.cc:549] backend about to shutdown
I0925 16:27:12.951968292    1231 grpclb_end2end_test.cc:552] backend shutdown completed
I0925 16:27:12.951975099    1231 grpclb_end2end_test.cc:265] LB[0x1a3f2e0]: shut down
I0925 16:27:12.951977462    1231 grpclb_end2end_test.cc:549] balancer about to shutdown
E0925 16:27:12.952106550    2135 grpclb.c:1876]              assertion failed: glb_policy->lb_call == NULL

*******************************
Caught signal SIGABRT
I0925 16:27:12.952132151    1321 grpclb_end2end_test.cc:250] LB[0x1a3f2e0]: done
bins/opt/grpclb_end2end_test[0x5901ee]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7f74535e1330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7f7452805c37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f7452809028]
bins/opt/grpclb_end2end_test[0x4cbea0]
bins/opt/grpclb_end2end_test[0x44f726]
bins/opt/grpclb_end2end_test[0x451c78]
bins/opt/grpclb_end2end_test[0x462fdc]
bins/opt/grpclb_end2end_test[0x48d294]
bins/opt/grpclb_end2end_test[0x48d72b]
bins/opt/grpclb_end2end_test[0x4707a8]
bins/opt/grpclb_end2end_test[0x476e5d]
bins/opt/grpclb_end2end_test[0x47d3a5]
bins/opt/grpclb_end2end_test[0x47d4cc]
/usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0xb1a60)[0x7f7453165a60]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7f74535d9184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f74528ccffd]

It only happens in SingleBalancerTest.FallbackUpdate, also the pre-existing UpdatesTest.UpdateBalancersRepeated has the same flake stacktrace, so I think they have the same root cause. @dgquintas can check.
Otherwise, I don't see directly-related issues to fix.

[trickle] No significant performance differences

Corrupt JSON data (indicates timeout or crash):
    bm_fullstack_streaming_ping_pong.BM_StreamingPingPongWithCoalescingApi_MinInProcessCHTTP2_NoOpMutator_NoOpMutator__2M_2_0.opt.old: 1

[microbenchmarks] Performance differences noted:
Benchmark                                                                                atm_cas_per_iteration    cpu_time    real_time
-----------------------------------------------------------------------------------------------------------  -----------------------  ----------  -----------
BM_CreateDestroyPollset                                                                                +6%         +6%
BM_ErrorStringOnNewError<SimpleError>                                                                                +6%         +6%
BM_HpackEncoderEncodeHeader<EmptyBatch>/0/16k                                                                                +4%
BM_HpackEncoderEncodeHeader<SingleInternedBinaryElem<1, false>>/0/16k                                                                 +6%         +6%
BM_HpackEncoderEncodeHeader<SingleNonInternedBinaryElem<100, false>>/0/16k                                                            +4%         +4%
BM_HpackParserParseHeader<IndexedSingleStaticElem>                                                                                +6%         +6%
BM_Pluck1Core                                                                                +5%         +6%
BM_PumpStreamClientToServer<InProcessCHTTP2>/32k                                                                                +8%         +8%
BM_PumpStreamClientToServer<SockPair>/512                                                                                +5%
BM_PumpStreamServerToClient<InProcess>/0                                                                                +4%
BM_PumpStreamServerToClient<SockPair>/64                                                                                +7%
BM_StreamingPingPong<InProcessCHTTP2, NoOpMutator, NoOpMutator>/512/1                                                                 +7%         +7%
BM_StreamingPingPong<MinInProcessCHTTP2, NoOpMutator, NoOpMutator>/64/1                                                               +18%        +17%
BM_StreamingPingPong<TCP, NoOpMutator, NoOpMutator>/0/1                                                                               +7%         +7%
BM_StreamingPingPongWithCoalescingApi<InProcess, NoOpMutator, NoOpMutator>/4k/2/1                                                     +12%        +12%
BM_StreamingPingPongWithCoalescingApi<InProcess, NoOpMutator, NoOpMutator>/512/2/0                                                    +5%         +6%
BM_StreamingPingPongWithCoalescingApi<InProcess, NoOpMutator, NoOpMutator>/8/2/1                                                      +14%        +14%
BM_StreamingPingPongWithCoalescingApi<MinInProcess, NoOpMutator, NoOpMutator>/32k/1/1                                                 +4%         +4%
BM_StreamingPingPongWithCoalescingApi<MinInProcess, NoOpMutator, NoOpMutator>/4k/2/1                                                  +4%         +4%
BM_StreamingPingPongWithCoalescingApi<MinInProcess, NoOpMutator, NoOpMutator>/512/2/0                                                 +9%         +9%
BM_UnaryPingPong<InProcess, Client_AddMetadata<RandomBinaryMetadata<10>, 2>, NoOpMutator>/0/0                                         +5%         +5%
BM_UnaryPingPong<InProcess, NoOpMutator, NoOpMutator>/0/0                                                                             +8%         +8%
BM_UnaryPingPong<InProcess, NoOpMutator, NoOpMutator>/0/2M                                                   +5%
BM_UnaryPingPong<InProcess, NoOpMutator, NoOpMutator>/512/0                                                                           +10%        +9%
BM_UnaryPingPong<InProcess, NoOpMutator, NoOpMutator>/512/512                                                                         +5%         +5%
BM_UnaryPingPong<InProcess, NoOpMutator, Server_AddInitialMetadata<RandomAsciiMetadata<100>, 1>>/0/0                                  +5%         +5%
BM_UnaryPingPong<InProcessCHTTP2, Client_AddMetadata<RandomBinaryMetadata<31>, 1>, NoOpMutator>/0/0                                   +4%         +4%
BM_UnaryPingPong<InProcessCHTTP2, NoOpMutator, NoOpMutator>/4k/4k                                                                     +15%        +15%
BM_UnaryPingPong<InProcessCHTTP2, NoOpMutator, NoOpMutator>/512/0                                                                     +4%         +4%
BM_UnaryPingPong<InProcessCHTTP2, NoOpMutator, Server_AddInitialMetadata<RandomAsciiMetadata<10>, 100>>/0/0                           +4%         +4%
BM_UnaryPingPong<MinInProcessCHTTP2, NoOpMutator, NoOpMutator>/0/4k                                                                   +4%         +5%
BM_UnaryPingPong<MinInProcessCHTTP2, NoOpMutator, NoOpMutator>/0/8                                                                    +7%         +7%
BM_UnaryPingPong<MinInProcessCHTTP2, NoOpMutator, NoOpMutator>/1/1                                                                    +5%         +5%
BM_UnaryPingPong<TCP, NoOpMutator, NoOpMutator>/4k/0                                                                                +5%         +5%

Does the flake you're seeing still happen in UpdatesTest.UpdateBalancersRepeated even without this PR?  If so, then I agree that it's probably unrelated to this PR, but @dgquintas should verify.
Overall, the code looks good.  My comments are mostly minor.

Reviewed 5 of 7 files at r1, 1 of 1 files at r5, 1 of 1 files at r6.
Review status: all files reviewed at latest revision, 8 unresolved discussions, some commit checks broke.

src/core/ext/filters/client_channel/lb_policy/grpclb/grpclb.c, line 1678 at r6 (raw file):

   * actually runs, don't do anything. */
  if (glb_policy->serverlist != NULL) {
    GRPC_LB_POLICY_WEAK_UNREF(exec_ctx, &glb_policy->base,

This unref already happens at the end of the function, so we could eliminate the duplication by inverting the conditional and moving the rest of the function inside of it:
if (glb_policy->serverlist == NULL) {
  // ... the existing code from lines 1683-1691 ...
}
GRPC_LB_POLICY_WEAK_UNREF(exec_ctx, &glb_policy->base,
                          "grpclb_fallback_timer");

src/core/ext/filters/client_channel/lb_policy/grpclb/grpclb.c, line 1682 at r6 (raw file):

    return;
  }
  glb_policy->fallback_timer_active = false;

Shouldn't we do this even if glb_policy->serverlist is null?  Might want to move this above the preceding conditional.

src/core/ext/filters/client_channel/lb_policy/grpclb/grpclb.c, line 1750 at r6 (raw file):

const grpc_arg *arg =
grpc_channel_args_find(args->args, GRPC_ARG_LB_ADDRESSES);
if (arg == NULL || arg->type != GRPC_ARG_POINTER) {
return;
}
const grpc_lb_addresses *addresses =
(const grpc_lb_addresses *)arg->value.pointer.p;

This code duplicates what already exists in glb_update_locked().  To avoid this duplication, I suggest the following:

Move the code from lines 1798-1818 to the top of glb_update_locked(), so that we have already constructed the grpc_lb_addresses object before we call this function.
Pass in the grpc_lb_addresses object as a parameter to this function.

src/core/ext/filters/client_channel/lb_policy/grpclb/grpclb.c, line 1761 at r6 (raw file):

  glb_policy->fallback_backend_addresses =
      extract_backend_addresses_locked(exec_ctx, addresses);
  if (glb_policy->lb_fallback_timeout_ms > 0 &&

This was originally if (glb_policy->rr_policy != NULL).  Why change it?  What was wrong with the original condition?

src/core/ext/filters/client_channel/lb_policy/grpclb/grpclb.c, line 1776 at r6 (raw file):

  }

  if (glb_policy->updating_lb_channel && glb_policy->serverlist != NULL) {

This could just be:
else if (glb_policy->updating_lb_channel)

test/cpp/end2end/grpclb_end2end_test.cc, line 684 at r6 (raw file):

  }

  // Wait until the serverlist reception has been processed.

...and all backends are reachable.

test/cpp/end2end/grpclb_end2end_test.cc, line 759 at r6 (raw file):

  SetNextResolution(addresses);

  // Wait until the resolution update has been processed.

...and all backends are reachable.

test/cpp/end2end/grpclb_end2end_test.cc, line 784 at r6 (raw file):

  }

  // Wait until the serverlist reception has been processed.

...and all backends are reachable.

Comments from Reviewable

[trickle] No significant performance differences

Yes, the flake in UpdatesTest.UpdateBalancersRepeated happens at the master branch too, with similar flakiness.

Review status: all files reviewed at latest revision, 8 unresolved discussions, some commit checks broke.

src/core/ext/filters/client_channel/lb_policy/grpclb/grpclb.c, line 1678 at r6 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
This unref already happens at the end of the function, so we could eliminate the duplication by inverting the conditional and moving the rest of the function inside of it:
if (glb_policy->serverlist == NULL) {
  // ... the existing code from lines 1683-1691 ...
}
GRPC_LB_POLICY_WEAK_UNREF(exec_ctx, &glb_policy->base,
                          "grpclb_fallback_timer");

Done.

src/core/ext/filters/client_channel/lb_policy/grpclb/grpclb.c, line 1682 at r6 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
Shouldn't we do this even if glb_policy->serverlist is null?  Might want to move this above the preceding conditional.

Done.

src/core/ext/filters/client_channel/lb_policy/grpclb/grpclb.c, line 1750 at r6 (raw file):
Previously, markdroth (Mark D. Roth) wrote…

const grpc_arg *arg =
grpc_channel_args_find(args->args, GRPC_ARG_LB_ADDRESSES);
if (arg == NULL || arg->type != GRPC_ARG_POINTER) {
return;
}
const grpc_lb_addresses *addresses =
(const grpc_lb_addresses *)arg->value.pointer.p;

This code duplicates what already exists in glb_update_locked().  To avoid this duplication, I suggest the following:

Move the code from lines 1798-1818 to the top of glb_update_locked(), so that we have already constructed the grpc_lb_addresses object before we call this function.
Pass in the grpc_lb_addresses object as a parameter to this function.

Done.

src/core/ext/filters/client_channel/lb_policy/grpclb/grpclb.c, line 1761 at r6 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
This was originally if (glb_policy->rr_policy != NULL).  Why change it?  What was wrong with the original condition?

The problem of the previous code is that it doesn't include the case when glb_policy->rr_policy == NULL and we do want to propagate the update. For example, the fallback backends are restarted so there is a period without valid rr_policy. We saw this situation in our integration test.

src/core/ext/filters/client_channel/lb_policy/grpclb/grpclb.c, line 1776 at r6 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
This could just be:
else if (glb_policy->updating_lb_channel)

Done.
BTW, && glb_policy->serverlist != NULL is added in this line to overwrite the bogus balancer update which takes forever in the integration test.

test/cpp/end2end/grpclb_end2end_test.cc, line 684 at r6 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
...and all backends are reachable.

Actually, if I add WaitForAllBackends() at the beginning of this test just like other tests in this file, this test always fails because it waits until the serverlist is received. That's why I separated all the waiting mutual-exclusively.
But now I wonder why WaitForAllBackends() can finish in the fallback related test cases..
I wanted to change the waiting into a incremental way. All the increments don't introduce problems (which looks strange to me now..) except the serverlist reception part in FallbackUpdate test.

test/cpp/end2end/grpclb_end2end_test.cc, line 759 at r6 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
...and all backends are reachable.

The same as above (line 684).

test/cpp/end2end/grpclb_end2end_test.cc, line 784 at r6 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
...and all backends are reachable.

The same as above (line 684).

Comments from Reviewable

I'm having a look at the preexisting flake in UpdatesTest.UpdateBalancersRepeated

Corrupt JSON data (indicates timeout or crash):
    bm_fullstack_streaming_ping_pong.BM_StreamingPingPongWithCoalescingApi_MinInProcessCHTTP2_NoOpMutator_NoOpMutator__2M_2_0.counters.old: 1

[microbenchmarks] Performance differences noted:
Benchmark                                                                             cpu_time    locks_per_iteration    nows_per_iteration    real_time
------------------------------------------------------------------------------------  ----------  ---------------------  --------------------  -----------
BM_HpackEncoderEncodeHeader<SingleNonInternedBinaryElem<100, true>>/0/16k             +8%                                                      +9%
BM_PumpStreamClientToServer<InProcess>/512                                            +6%                                                      +6%
BM_PumpStreamServerToClient<UDS>/512                                                                                +5%
BM_SliceInternEqualToStaticMetadata                                                   +4%                                                      +4%
BM_StreamingPingPongMsgs<InProcess, NoOpMutator, NoOpMutator>/512                     +5%                                                      +5%
BM_StreamingPingPongMsgs<InProcess, NoOpMutator, NoOpMutator>/64                                                                               +4%
BM_StreamingPingPongWithCoalescingApi<MinInProcess, NoOpMutator, NoOpMutator>/64/2/1  +4%                                                      +4%
BM_TransportStreamRecv/8                                                              +4%                                                      +4%
BM_UnaryPingPong<MinInProcess, NoOpMutator, NoOpMutator>/128M/0                                   +6%                    +6%
BM_UnaryPingPong<MinInProcessCHTTP2, NoOpMutator, NoOpMutator>/4k/4k                  +12%                                                     +13%

test/cpp/end2end/grpclb_end2end_test.cc, line 684 at r6 (raw file):
Previously, AspirinSJL (Juanli Shen) wrote…
Actually, if I add WaitForAllBackends() at the beginning of this test just like other tests in this file, this test always fails because it waits until the serverlist is received. That's why I separated all the waiting mutual-exclusively.
But now I wonder why WaitForAllBackends() can finish in the fallback related test cases..
I wanted to change the waiting into a incremental way. All the increments don't introduce problems (which looks strange to me now..) except the serverlist reception part in FallbackUpdate test.

WaitForAllBackends() simply waits until all backends have serviced a request, it knows nothing about serverlists. Because in the fallback case you are hitting the backends directly, it's able to make progress. In the general case (without fallback active), it's true that a serverlist is a prerequisite, but only because that's the only way grpclb has to find what the backends are.

Comments from Reviewable

Review status: 6 of 7 files reviewed at latest revision, 8 unresolved discussions, some commit checks broke.

test/cpp/end2end/grpclb_end2end_test.cc, line 684 at r6 (raw file):
Previously, dgquintas (David G. Quintas) wrote…
WaitForAllBackends() simply waits until all backends have serviced a request, it knows nothing about serverlists. Because in the fallback case you are hitting the backends directly, it's able to make progress. In the general case (without fallback active), it's true that a serverlist is a prerequisite, but only because that's the only way grpclb has to find what the backends are.

I see. I just realized that I didn't reset the counters after each batch..  Then all of it makes sense to me now.. I feel this PR is mergable soon!!!

Comments from Reviewable

Review status: 6 of 7 files reviewed at latest revision, 8 unresolved discussions, some commit checks broke.

test/cpp/end2end/grpclb_end2end_test.cc, line 684 at r6 (raw file):
Previously, AspirinSJL (Juanli Shen) wrote…
I see. I just realized that I didn't reset the counters after each batch..  Then all of it makes sense to me now.. I feel this PR is mergable soon!!!

I think we should use the previous comments, because WaitForBackend() works in a customer view instead of infrastructure view. If WaitForBackend(i) finishes, it only means backend i is reachable (from the client).

Comments from Reviewable

Reviewed 1 of 1 files at r7.
Review status: all files reviewed at latest revision, 9 unresolved discussions, some commit checks broke.

src/core/ext/filters/client_channel/lb_policy/grpclb/grpclb.c, line 1761 at r6 (raw file):
Previously, AspirinSJL (Juanli Shen) wrote…
The problem of the previous code is that it doesn't include the case when glb_policy->rr_policy == NULL and we do want to propagate the update. For example, the fallback backends are restarted so there is a period without valid rr_policy. We saw this situation in our integration test.

Ah, so this happens in the case where the RR policy shuts down?  Okay, then this is fine for now.  Eventually, we will want to change the RR policy not to shut down when all of its subchannels go bad, in which case this change would not be necessary.  But this alternative expression should work fine.

src/core/ext/filters/client_channel/lb_policy/grpclb/grpclb.c, line 1776 at r6 (raw file):
Previously, AspirinSJL (Juanli Shen) wrote…
Done.
BTW, && glb_policy->serverlist != NULL is added in this line to overwrite the bogus balancer update which takes forever in the integration test.

Hmm... This is interesting.  I'm actually a little surprised that this works, because in principle it is not necessarily safe to abort an in-progress update.  But I don't see anything in the code that prevents this.
Actually, looking at the current code, I'm not sure why we bother to track pending updates here at all.  We should be able to just send the updated addresses to the LB channel via the fake resolver unconditionally, and let the pick_first code in the LB channel handle the updates itself.  But we can make that change in a separate PR, so let's not worry about it for now.

src/core/ext/filters/client_channel/lb_policy/grpclb/grpclb.c, line 1785 at r7 (raw file):

    // If a non-empty serverlist hasn't been received from the balancer,
    // propagate
    // the update to fallback_backend_addresses.

Nit: This can move to the previous line.

test/cpp/end2end/grpclb_end2end_test.cc, line 684 at r6 (raw file):
Previously, AspirinSJL (Juanli Shen) wrote…
I think we should use the previous comments, because WaitForBackend() works in a customer view instead of infrastructure view. If WaitForBackend(i) finishes, it only means backend i is reachable (from the client).

What I mean here is that the goal of this loop is to ensure that all of the backends that we should have (not all of the entries in backend_servers_) are actually ready.  If the initial address list contains more than one backend and we check only the first of them, then we know that the address list was processed but we don't know that all of the backends are actually connected.  What we are checking here is both (a) that the address list is being used and (b) that the backends are connected.  The comment should reflect that.

test/cpp/end2end/grpclb_end2end_test.cc, line 759 at r6 (raw file):
Previously, AspirinSJL (Juanli Shen) wrote…
The same as above (line 684).

See above.

test/cpp/end2end/grpclb_end2end_test.cc, line 784 at r6 (raw file):
Previously, AspirinSJL (Juanli Shen) wrote…
The same as above (line 684).

See above.

Comments from Reviewable

Review status: all files reviewed at latest revision, 7 unresolved discussions, some commit checks broke.

src/core/ext/filters/client_channel/lb_policy/grpclb/grpclb.c, line 1761 at r6 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
Ah, so this happens in the case where the RR policy shuts down?  Okay, then this is fine for now.  Eventually, we will want to change the RR policy not to shut down when all of its subchannels go bad, in which case this change would not be necessary.  But this alternative expression should work fine.

I see.

src/core/ext/filters/client_channel/lb_policy/grpclb/grpclb.c, line 1776 at r6 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
Hmm... This is interesting.  I'm actually a little surprised that this works, because in principle it is not necessarily safe to abort an in-progress update.  But I don't see anything in the code that prevents this.
Actually, looking at the current code, I'm not sure why we bother to track pending updates here at all.  We should be able to just send the updated addresses to the LB channel via the fake resolver unconditionally, and let the pick_first code in the LB channel handle the updates itself.  But we can make that change in a separate PR, so let's not worry about it for now.

Yes, the PF policy should be able to handle this itself.

src/core/ext/filters/client_channel/lb_policy/grpclb/grpclb.c, line 1785 at r7 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
Nit: This can move to the previous line.

Done. Sorry about that.

test/cpp/end2end/grpclb_end2end_test.cc, line 684 at r6 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
What I mean here is that the goal of this loop is to ensure that all of the backends that we should have (not all of the entries in backend_servers_) are actually ready.  If the initial address list contains more than one backend and we check only the first of them, then we know that the address list was processed but we don't know that all of the backends are actually connected.  What we are checking here is both (a) that the address list is being used and (b) that the backends are connected.  The comment should reflect that.

Ah, I see. That's also why I changed the previous code into a for loop over each subset.
Changed the comment.

test/cpp/end2end/grpclb_end2end_test.cc, line 759 at r6 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
See above.

Done.

test/cpp/end2end/grpclb_end2end_test.cc, line 784 at r6 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
See above.

Done.

Comments from Reviewable

[trickle] No significant performance differences

I filed the "issue" about propagating update in #12727.

Corrupt JSON data (indicates timeout or crash):
    bm_fullstack_trickle.BM_PumpStreamServerToClient_Trickle_2M_32k.opt.new: 1

[trickle] No significant performance differences

Corrupt JSON data (indicates timeout or crash):
    bm_fullstack_streaming_ping_pong.BM_StreamingPingPongWithCoalescingApi_MinInProcessCHTTP2_NoOpMutator_NoOpMutator__2M_2_0.opt.new: 1

[microbenchmarks] Performance differences noted:
Benchmark                                                                                allocs_per_iteration    atm_add_per_iteration    cpu_time    nows_per_iteration    real_time
---------------------------------------------------------------------------------------------------------  ----------------------  -----------------------  ----------  --------------------  -----------
BM_HpackEncoderEncodeHeader<SingleInternedBinaryElem<1, true>>/0/16k                                                                                +4%                               +4%
BM_HpackEncoderEncodeHeader<SingleInternedBinaryElem<100, false>>/0/16k                                                                                +9%                               +9%
BM_HpackEncoderEncodeHeader<SingleNonInternedElem>/0/16k                                                                                +4%                               +5%
BM_HpackParserParseHeader<RepresentativeServerInitialMetadata>                                                                                +4%
BM_PumpStreamServerToClient<InProcess>/64                                                                                +4%                               +4%
BM_PumpStreamServerToClient<TCP>/256k                                                                                +5%
BM_StreamingPingPong<InProcess, NoOpMutator, NoOpMutator>/8/2                                                                                +16%                              +17%
BM_StreamingPingPong<MinTCP, NoOpMutator, NoOpMutator>/512/1                                                                                +6%                               +6%
BM_StreamingPingPongWithCoalescingApi<InProcess, NoOpMutator, NoOpMutator>/512/2/0                                                                          +6%                               +6%
BM_StreamingPingPongWithCoalescingApi<InProcessCHTTP2, NoOpMutator, NoOpMutator>/1/1/1                                                                      +4%
BM_StreamingPingPongWithCoalescingApi<MinInProcess, NoOpMutator, NoOpMutator>/64/2/1                                                                        +4%                               +4%
BM_StreamingPingPongWithCoalescingApi<MinInProcessCHTTP2, NoOpMutator, NoOpMutator>/4k/1/1                                                                  +8%                               +8%
BM_TransportStreamSend/32k                                                                                +13%                              +13%
BM_UnaryPingPong<InProcess, Client_AddMetadata<RandomAsciiMetadata<10>, 1>, NoOpMutator>/0/0                                                                +7%                               +7%
BM_UnaryPingPong<InProcess, Client_AddMetadata<RandomAsciiMetadata<31>, 1>, NoOpMutator>/0/0                                                                +5%                               +5%
BM_UnaryPingPong<InProcess, NoOpMutator, Server_AddInitialMetadata<RandomBinaryMetadata<100>, 1>>/0/0                                                       +8%                               +8%
BM_UnaryPingPong<InProcessCHTTP2, NoOpMutator, NoOpMutator>/64/0                                                                                +5%                               +5%
BM_UnaryPingPong<InProcessCHTTP2, NoOpMutator, Server_AddInitialMetadata<RandomAsciiMetadata<31>, 1>>/0/0                                                   +8%                               +8%
BM_UnaryPingPong<MinInProcess, NoOpMutator, NoOpMutator>/0/512                                                                                +5%                               +5%
BM_UnaryPingPong<MinInProcessCHTTP2, NoOpMutator, NoOpMutator>/0/16M                                                                                -6%
BM_UnaryPingPong<MinInProcessCHTTP2, NoOpMutator, NoOpMutator>/512/512                                                                                +4%                               +4%
BM_UnaryPingPong<MinTCP, NoOpMutator, NoOpMutator>/2M/2M                                                                           -4%                                  -4%
BM_UnaryPingPong<TCP, NoOpMutator, NoOpMutator>/128M/128M                                                  -11%                    -10%

Basic Tests C++ Linux [dbg] (internal CI): #12510
Basic Tests C++ Linux [opt] (internal CI): #12313
Basic Tests MacOS [dbg] (internal CI): #12138
Basic Tests MacOS [opt] (internal CI): #12138
Basic Tests Windows [dbg] (internal CI): #12595
Basic Tests Windows [opt] (internal CI): #12595
Interop Cloud-to-Cloud Tests (internal CI): #12723
Interop Cloud-to-Prod Tests (internal CI): #12260
Tsan C (internal CI) — Internal CI build failed: #12741

[microbenchmarks] No significant performance differences


Add Bullet Point and Numbered List Formatting to Tiptap Editor

Description
Implement the ability to format selected text as a bullet point list or a numbered list in the Tiptap editor. The user should be able to toggle between list types and apply the formatting to the selected text.
Requirements

Bullet Point List Formatting:

When the bullet point list option is chosen, the selected text should be formatted as a bullet point list.

Numbered List Formatting:

When the numbered list option is chosen, the selected text should be formatted as a numbered list.

Menu Integration:

Add options to the editor's bubble menu or toolbar to format selected text as a bullet point list or numbered list.

Done ✅
https://github.com/user-attachments/assets/bdc74ea5-b5bd-48a0-a507-bcbbf1896ccd


Developing Wireframes

Description: Design wireframes for the main screens of the LambdaChess application, including the main menu, game screen, profile page, and settings.

Create wireframes for:

Main Menu
Game Screen
Profile Page
Settings

Acceptance Criteria:

Wireframes are created using Balsamiq or a similar tool.
All key elements are included: navigation, buttons, user interactions.
Wireframes are uploaded to the GitHub repository.

https://www.figma.com/proto/RZ43FtW6K6b01xlkOOs4je/Untitled?node-id=0-1&node-type=canvas&t=rSq5uG59EFATb6Hf-0&scaling=scale-down&content-scaling=fixed&page-id=0%3A1&starting-point-node-id=10%3A155


Error finding modules import with an alias and extensions resolve in Webpack

While running jsdoc command, the error 'Error: Cannot find module 'components/base/header/Header' is thrown because I'm using the "@" alias and the rules of resolve extentions of my Webpack config. So I import the child components with that kind of pattern in my Vue components :
import Header from '@/components/base/header/Header'
Is it expected that you will consider such rules in the future ?
Thank you for this plugin
Error: Cannot find module 'components/base/header/Header'     at Function.Module._resolveFilename (module.js:469:15)     at Function.Module._load (module.js:417:25)     at Module.require (module.js:497:17)     at evalmachine.<anonymous>:11:15     at ContextifyScript.Script.runInContext (vm.js:35:29)     at module.exports (/Users/myrmel/Documents/LocalDev/webv2/node_modules/jsdoc-vuejs/lib/vueComponentPrototypeExtractor.js:20:10)     at beforeParse (/Users/myrmel/Documents/LocalDev/webv2/node_modules/jsdoc-vuejs/index.js:20:47)     at emitOne (events.js:96:13)     at emit (events.js:188:7)     at Parser._parseSourceCode (/Users/myrmel/Documents/LocalDev/webv2/node_modules/jsdoc/lib/jsdoc/src/parser.js:248:14)     at Parser.parse (/Users/myrmel/Documents/LocalDev/webv2/node_modules/jsdoc/lib/jsdoc/src/parser.js:179:18)     at Object.module.exports.cli.parseFiles (/Users/myrmel/Documents/LocalDev/webv2/node_modules/jsdoc/cli.js:370:42)     at module.exports.cli.main (/Users/myrmel/Documents/LocalDev/webv2/node_modules/jsdoc/cli.js:239:14)     at Object.module.exports.cli.runCommand (/Users/myrmel/Documents/LocalDev/webv2/node_modules/jsdoc/cli.js:189:5)     at /Users/myrmel/Documents/LocalDev/webv2/node_modules/jsdoc/jsdoc.js:105:9     at Object.<anonymous> (/Users/myrmel/Documents/LocalDev/webv2/node_modules/jsdoc/jsdoc.js:106:3)

Hi,
Unfortunately, the plugin doesn't use webpack config file, so the plugin doesn't know what is an alias or not, and so it's failing for your usage case.
Also, i don't want to make webpack running on VueJS project, because I will probably lost jsdoc comment and I will be unable to run JSDoc on it...
I'm thinking about it!

Is it possible to at least make it optional whether this plugin will follow the import paths? Can you just treat them like a black box and document the code that is actually present in the .vue file?

Mmmh yea why not.
I see something like that for JSDoc config:
{
  "plugins": [
    "node_modules/jsdoc-vuejs"
  ],
  "vuejs": {
    "followRequire": false,
   },
  "source": {
    "includePattern": "\\.(vue|js)$"
    // or
    "include": [
       "foo.vue",
       "bar/test.vue'
    ]
  }
}

Also, I need to modify lib/vueComponentPrototypeExtractor.js.
I will work on that this week-end I think

Check the new 1.0.11 version, you can choose to follow imports or not (https://github.com/Kocal/jsdoc-vuejs#usage)

Thank you so much, this is great, very usefull !


Fixing an ie/edge error

"Object doesn't support property or method 'Symbol.iterator'" error is fixed

Thanks)


Fix computation with erase_mfix when assuming well-formedness

We were getting stuck on the destruction in the obligation when computing within coq and assuming well-formedness of the environment.

Good catch!


Bug 1908068: Enable DownwardAPIHugePages feature gate

This adds the DownwardAPIHugePages to the enabled-by-default feature gate flags.
Signed-off-by: Billy McFall<EMAIL_ADDRESS>

"DownwardAPIHugePages" an alpha feature. The effect of enabling the feature gate is to allow the existing resource "request" and "limit" fields of "hugepages-1Gi" and "hugepages-2Mi" to be exposed to a container via the Downward API. From an API stability point of view, based on the hugepages KEP, it's clear that it's only "alpha" because new features have to start out as alpha, but it seems very clearly guaranteed that it's going to go to GA. There is minimal chance that this behaviour will change as the feature moves to beta and GA upstream. There's no real danger that we're going to get stuck supporting some dropped or deprecated API as a result of enabling this feature gate now.
From a code-untestedness point of view, the effect of enabling the feature gate is also small. Currently the SR-IOV DP Admission Controller (mutating webhook) is the only controller using this feature. If it sees that secondary interfaces are being requested, and the container has also requested hugepages, then it will inject requests for these fields to be included via Downward API. Downward API is already being used to pass annotations to the container, so this is just 2 more fields being requested.

/retest

/bugzilla refresh

/bugzilla refresh

/assign @derekwaynecarr
This is not ready to merge, waiting on Kubelet to be bumped to 1.20 in OCP. Once that completes, I'll remove the WIP. But wanted to get some eyes on this sooner than later.
Related code:
https://github.com/openshift/sriov-dp-admission-controller/commit/e554764ff28ca980cbbafd9615df00aafbab0755
https://github.com/openshift/sriov-dp-admission-controller/commit/ecea1a8bb0beeaedc07dc83cd616f2b9d36da71b
cc @knobunc

Removing WIP, latest CI builds now have kubelet 1.20

@deads2k can you take a look at this please?  I'm not sure if @derekwaynecarr will get a chance.  Thanks

@deads2k @derekwaynecarr @knobunc PTAL
Let me know if you need more information on this PR. Need to wrap up this feature now the kubelet 1.20 is in OCP 4.7.

@deads2k @derekwaynecarr @knobunc PTAL
Let me know if you need more information on this PR. Need to wrap up this feature now the kubelet 1.20 is in OCP 4.7.

/lgtm

/approved

/approve


Out of context example code

Hi, there's a snippet of sample code on your page referencing a _userManager variable. This is really hard to understand because you give no context as to where that is supposed to go. Please explain context/destination for all code snippets otherwise other readers will have the same question as me: "where am I meant to put this, then?".
Otherwise many thanks of course for the docs. Simon
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: d0da2144-3730-f8ef-1d16-a89f11fd6198
Version Independent ID: 6d8f5bc8-8f5c-ba13-b7f2-0366eac46f81
Content: Authentication and authorization in ASP.NET Core SignalR
Content Source: aspnetcore/signalr/authn-and-authz.md
Product: aspnet-core
Technology: aspnetcore-signalr
GitHub Login: @bradygaster
Microsoft Alias: bradyg

Hello @simonziegler ... Yes, it can be mentioned in text and/or more code can be shown. In general tho when there's a sample app available and the code in the topic is linked from it, you can look at the sample app, which is linked at the top of the topic. In this case ...
https://github.com/dotnet/AspNetCore.Docs/blob/master/aspnetcore/signalr/authn-and-authz/sample/Pages/Account/Register.cshtml.cs#L23

Thanks - I’ll do that

You can see it when you scaffold Identity. It's shown in https://docs.microsoft.com/en-us/aspnet/core/security/authentication/identity


Email validation regex is wrong

[The email validation regex is incorrect. it excludes emails like<EMAIL_ADDRESS>If you look at the actual policy pack it has another regex that works RFC522]

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 105d323b-2017-72e9-3d26-dc32aa095439
Version Independent ID: b13a29a5-52af-d768-5191-86c20c9433ab
Content: Localize the user interface of your app with a custom policy
Content Source: articles/active-directory-b2c/custom-policy-localization.md
Service: active-directory
Sub-service: b2c
GitHub Login: @msmimart
Microsoft Alias: mimart

@villyg
Thanks for your feedback!
I just to confirm, you want us to add the excluded emails into the doc? Or do you have a doc specific feedback/enhancement request?

Hi,
Sorry I wasn't more detailed in the feedback.
I think this line ....
^[a-zA-Z0-9.!#$%&''+/=?^_`{|}~-]+@[a-zA-Z0-9-]+(?:.[a-zA-Z0-9-]+)$
... should have this regex instead ^[a-zA-Z0-9.!#$%&'^_`{}~-]+@[a-zA-Z0-9-]+(?:.[a-zA-Z0-9-]+)*$
the regex I'm proposing actually came from here:
https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack/blob/b6b78182a105b2503f476b2e59e88398ba18f56c/LocalAccounts/TrustFrameworkBase.xml#L188
the one in the localization string will not let users sign in with something like this<EMAIL_ADDRESS>but the one in the policy example will.
Let me know if you need anything else.

@villyg
Thank you for the detailed feedback!
I have assigned this issue to the author of this doc to review/update as appropriate.

@villyg thanks for this feedback! Resolved via https://github.com/MicrosoftDocs/azure-docs/issues/57902.
#please-close


Rethink TextInput props

Rohan mentioned in https://github.com/primer/components/issues/334 that some of the TextInput props could be taken care of by the Layout system props

This is no longer relevant!


in _unsigned16     return self._input_registers_values_list[addr]

I'm getting this error. can you help?
Traceback (most recent call last):
File "/home/pi/programacao/working/ler_rs485.py", line 15, in
inverter_ac_power = s.read("grid_power")[0]
^^^^^^^^^^^^^^^^^^^^
File "/home/pi/energy_diverter/lib/python3.11/site-packages/solaxx3/rs485.py", line 143, in read
value = self.read_register(register_info)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/pi/energy_diverter/lib/python3.11/site-packages/solaxx3/rs485.py", line 130, in read_register
val = self._read_register(register_info["register_type"], register_info)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/pi/energy_diverter/lib/python3.11/site-packages/solaxx3/rs485.py", line 82, in _read_register
val = self._unsigned16(register_type, register_info["address"])
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/pi/energy_diverter/lib/python3.11/site-packages/solaxx3/rs485.py", line 47, in _unsigned16
return self._input_registers_values_list[addr]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^
IndexError: list index out of range

Hello Jorge,
Could you please send me the code you are running that produces that error so that I can try to reproduce it on my side?
Also, but inverter model do you use and what firmware version?

Hello,
Thanks for your reply.
I don't know how to check the firmware version, if you could help me I would appreciate it.
But the X3-MIC/PRO-G2 10KW inverter was purchased and installed last week, so it must have the latest version..
I tried using the software on two inverters (X3-MIC/PRO-G2 10KW  and X1-Boost/Air/Mini 5KW) and got the same error.
Here is the software and the message obtained.
I hope you can help me resolve it.
Thanks
Jorge
THE PROGRAM
from solaxx3.rs485 import SolaxX3
adjust the serial port and baud rate as necessary
s = SolaxX3(port="/dev/ttyUSB0", baudrate=9600)
if s.connect():
s.read_all_registers()
available_stats = s.list_register_names()
for stat in available_stats:
    print(stat)

# battery_temperature = s.read("temperature_battery")[0]
# print(f"\n\nBattery temperature: {s.read('temperature_battery')[0]}")
inverter_ac_power = s.read("grid_power")[0]
etoday_togrid = s.read("energy_to_grid_today")[0]
print(inverter_ac_power,etoday_togrid)

else:
print("Cannot connect to the Modbus Server/Slave")
exit()
RUNNING THE PROGRAM:
(energy_diverter) @.:~/programacao/working $ python ler_rs485.py
grid_voltage
grid_current
grid_power
pv_voltage_1
pv_voltage_2
pv_current_1
pv_current_2
grid_frequency
radiator_temperature
run_mode
power_dc1
power_dc2
temperature_fault_value
pv1_volt_fault_value
pv2_volt_fault_value
gfci_fault_value
grid_fault_value
grid_freq__fault__value_t
dci_fault_value
time_count_down
battery_voltage_charge_1
battery_current_charge_1
battery_power_charge1
bms_connect_state
temperature_battery
bdc_status
grid_status
mppt_count
battery_capacity
output_energy_charge
output_energy_charge_today
input_energy_charge
input_energy_charge_today
bms_charge_max_current
bms_discharge_max_current
power_to_ev
ref_power_to_ev
pcs_major_fault
battery_major_fault
inv_fault_message
mgr_fault_message
bat_bms_fault_message
feed_in_power
energy_to_grid_meter
energy_from_grid_meter
off_grid_voltage
off_grid_current
off_grid_power
off_grid_frequency
energy_to_grid_today
energy_to_grid_total
lock_state
bus_volt
w_dcv_fault_val
w_overload_fault_val
w_battery_volt_fault_val
grid_voltage_r
grid_current_r
grid_power_r
grid_frequency_r
grid_voltage_s
grid_current_s
grid_power_s
grid_frequency_s
grid_voltage_t
grid_current_t
grid_power_t
grid_frequency_t
off_grid_volt_r
off_grid_current_r
off_grid_power_active_r
off_grid_power_s_r
off-grid-volt-s
off_grid_current_s
off_grid_power_active_s
off_grid_power_s_s
off_grid_volt_t
off_grid_current_t
off_grid_power_active_t
off_grid_power_s_t
feedin_power_r_phase
feedin_power_s_phase
feedin_power_t_phase
ongrid_run_time
offgrid_run_time
offgrid_yield_total
offgrid_yield_today
echarge_today
echarge_total
solar_energy_total
solar_energy_today
feed_in_energy_today
consumption_energy_today
inv_volt_r
inv_volt_s
inv_volt_t
feedin_power_meter_2
feedin_energy_total_meter_2
consum_energy_total_meter_2
feedin_energy_today_meter_2
consum_energy_today_meter_2
feedin_power_r_phase_meter_2
feedin_power_s_phase_meter_2
feedin_power_t_phase_meter_2
meter_1_communication_state
meter_2_communication_state
battery_tem_high
battery_tem_low
cell_voltage_high
cell_voltage_low
bms_user_soc
bms_user_soh
grid_reactive_power_total_meter
grid_reactive_power_r_meter
grid_reactive_power_s_meter
grid_reactive_power_t_meter
grid_power_factor_total_meter
grid_power_factor_r_meter
grid_power_factor_s_meter
grid_power_factor_t_meter
grid_frequency_meter
grid_voltage_total_meter
grid_voltage_r_meter
grid_voltage_s_meter
grid_voltage_t_meter
grid_current_total_meter
grid_current_r_meter
grid_current_s_meter
grid_current_t_meter
modbus_power_control
target_finish_tag
active_power_target
w_reactive_power_target
w_active_power_real
w_reactive_power_real
w_active_power_upper
w_active_power_lower
w_reactive_power_upper
w_reactive_power_lower
target_energy
charge_discharge_power
chargeable_electric_capacity
dischargeable_electric_capacity
time_of_duration
target_soc
soc_upper
soc_lower
remote_control_timeout
w_battery_force_charge_flag
w_bms_relay_state
serial_number
firmware_version_dsp
hardware_version_dsp
firmware_version_modbus_rtu
firmware_version_arm
firmware_version_arm_bootloader
rtc_datetime
registration_code
inverter_power_type
user_password
advanced_password
machine_type
Traceback (most recent call last):
File "/home/pi/programacao/working/ler_rs485.py", line 15, in
inverter_ac_power = s.read("grid_power")[0]
^^^^^^^^^^^^^^^^^^^^
File "/home/pi/energy_diverter/lib/python3.11/site-packages/solaxx3/rs485.py", line 143, in read
value = self.read_register(register_info)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/pi/energy_diverter/lib/python3.11/site-packages/solaxx3/rs485.py", line 130, in read_register
val = self._read_register(register_info["register_type"], register_info)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/pi/energy_diverter/lib/python3.11/site-packages/solaxx3/rs485.py", line 82, in _read_register
val = self._unsigned16(register_type, register_info["address"])
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/pi/energy_diverter/lib/python3.11/site-packages/solaxx3/rs485.py", line 47, in _unsigned16
return self._input_registers_values_list[addr]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^
IndexError: list index out of range
(energy_diverter) @.:~/programacao/working $

No dia 26/02/2024, às 07:10, mkfam7 @.***> escreveu:
Hello Jorge,
Could you please send me the code you are running that produces that error so that I can try to reproduce it on my side?
Also, but inverter model do you use and what firmware version?
—
Reply to this email directly, view it on GitHub https://github.com/mkfam7/solaxx3/issues/6#issuecomment-1963451068, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQK7YCRMVYTBQHEVR34YCY3YVQYPVAVCNFSM6AAAAABDZCUGROVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRTGQ2TCMBWHA.
You are receiving this because you authored the thread.

Hello Jorge,
This is how I get the firmware version from my inverter:
From the display of the inverter I navigate to the following paths:

About -> Inverter -> DSP
About -> Inverter -> ARM

After doing some tests on my side, I suppose the error you get is because the program does not see any register at address "2" (which is kind of weird).
Please send me the firmware information and also try with the following requirements package versions:
pymodbus==3.6.3
pyserial==3.5
Also please run the following program and send me the output (it should display 2 lists with all registers):
from solaxx3.rs485 import SolaxX3

# adjust the serial port and baud rate as necessary
s = SolaxX3(port="/dev/ttyUSB0", baudrate=115200)

if s.connect():
    s.read_all_registers()

    print(f"Input registers: {s._input_registers_values_list}")
    print(f"Holding registers: {s._holding_registers_values_list}")

else:
    print("Cannot connect to the Modbus Server/Slave")
    exit()

Hello,
FirmWare is:
"ver":"2.035.01","type":4,”Data"
PROGRAM RESULT
(venv) @.:~/programacao/working $ pip list | grep pyserial
pyserial         3.5
pyserial-asyncio 0.6
(venv) @.:~/programacao/working $ pip list | grep pymodbus
pymodbus         3.6.3
(venv) @.:~/programacao/working $ python test1.py
Input registers: []
Holding registers: []
(venv) @.:~/programacao/working $
Regards
Jorge

No dia 28/02/2024, às 09:23, mkfam7 @.***> escreveu:
Hello Jorge,
This is how I get the firmware version from my inverter:
From the display of the inverter I navigate to the following paths:
About -> Inverter -> DSP
About -> Inverter -> ARM
After doing some tests on my side, I suppose the error you get is because the program does not see any register at address "2" (which is kind of weird).
Please send me the firmware information and also try with the following requirements package versions:
pymodbus==3.6.3
pyserial==3.5
Also please run the following program and send me the output (it should display 2 lists with all registers):
from solaxx3.rs485 import SolaxX3
adjust the serial port and baud rate as necessary
s = SolaxX3(port="/dev/ttyUSB0", baudrate=115200)
if s.connect():
s.read_all_registers()
print(f"Input registers: {s._input_registers_values_list}")
print(f"Holding registers: {s._holding_registers_values_list}")

else:
print("Cannot connect to the Modbus Server/Slave")
exit()
—
Reply to this email directly, view it on GitHub https://github.com/mkfam7/solaxx3/issues/6#issuecomment-1968559546, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQK7YCXEHZIMPDWY232XGK3YV3ZQTAVCNFSM6AAAAABDZCUGROVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRYGU2TSNJUGY.
You are receiving this because you authored the thread.

Hello Jorge,
It looks like the program does not see any memory location in your inverter's registers, so you get an error because of that. Please contact the Solax support and ask them about how to configure your inverter to be read from a program via RS485 RTU.
Sorry I could not help.


How to use with proxy?

For an ordinary docker build, I'll do something like:
docker build --build-arg http_proxy=my.proxy.com:3128 --build-arg https_proxy=my.proxy.com:3128 --build-arg no_proxy=<IP_ADDRESS>,localhost,<IP_ADDRESS> -t image-name .

Similarly , for maven dependencies I have I have in ~/.m2/settings.xml
    <proxy>
      <id>my-proxy</id>
      <active>true</active>
      <protocol>http</protocol>
      <host>my.proxy.com</host>
      <port>3128</port>
    </proxy>

    <proxy>
      <id>my-proxy</id>
      <active>true</active>
      <protocol>https</protocol>
      <host>my.proxy.com</host>
      <port>3128</port>
    </proxy>

How do I get this to work for this plugin?
I've tried passing build args with:
	<buildArgs>
		<JAR_FILE>${project.build.finalName}.jar</JAR_FILE>
		<http_proxy>my.proxy.com:3128</http_proxy>
		<https_proxy>my.proxy.com:3128</https_proxy>
		<no_proxy>localhost,<IP_ADDRESS>,<IP_ADDRESS></no_proxy>
	</buildArgs>

Or not specifying anything at all (hoping the it's smart enough to recoginise the proxy in my settings.xml, but neither work. I get:
[]([ERROR] Failed to execute goal com.spotify:dockerfile-maven-plugin:1.4.0:build (default-cli) on project java-rest-api: Could not build image: Get https://registry-1.docker.io/v2/: dial tcp <IP_ADDRESS>:443: getsockopt: connection refused -> [Help 1])

This might be a red herring. It looks like my ordinary proxy isn't working. Will post back when I've solved.

Ok, can confirm that it works without needing any build args, if your settings.xml is properly configured.


A note should be added for creating the Windows Hello for business Cert Template.

A note should be added at the create a Windows Hello for Business Certificate Template. When enrolling through Intune, The Subject name of the template should be 'Supply in the request' in stead of build from Active Directory.
Select the Build from this Active Directory information button if it isn't already selected
Select Fully distinguished name from the Subject name format list if Fully distinguished name isn't already selected
Select the User Principal Name (UPN) check box under Include this information in alternative subject name

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 7e9cc344-d2c1-1f8b-232a-b2cccd8b32a3
Version Independent ID: eb87d132-cc0b-8ab2-4417-51e1bc719c14
Content: Deploy certificates for remote desktop sign-in
Content Source: windows/security/identity-protection/hello-for-business/hello-deployment-rdp-certs.md
Product: windows-client
Technology: itpro-security
GitHub Login: @paolomatarazzo
Microsoft Alias: paoloma

@Riinmo thank you for the feedback! I will add a note, it makes sense


Fixed to use mb_substr instead of substr

Q
A

Is bugfix?
yes

New feature?
no

Breaks BC?
no

Tests pass?
yes

Merged. Thanks!

If you compare against non-multibyte chars on the end of the string, substr and mb_substr are the same, while substr is faster: https://3v4l.org/5T2Hk

Oh I see https://github.com/yiisoft/di/pull/39 now, nvm


init.py namespace error

I have made a mistake, and the errors I talk about here occur in the older version of easygui, 0.97
I downloaded easygui and put it in my site-packages folder. When I typed import easygui into IDLE I got this error:
Traceback (most recent call last):   File "<pyshell#2>", line 1, in <module>     import easygui   File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/easygui/__init__.py", line 3, in <module>     __all__ = easygui.__all__ NameError: name 'easygui' is not defined
So I went into the init.py and I think I found the error. In the first line it says from easygui import * which means that you don't have to put easygui. in front of easygui functions. But then in the third line it says __all__ = easygui.__all__
Python looks for easygui.all when we don't have that namespace because of the way easygui was imported.
But when I change the first line to say import easygui python gives me the error that module 'easygui' has no attribute '__all__'
What's going on?
EDIT: I think I figured how to fix it. I changed the script to this:
import easygui pass __all__ = [easygui]
EDIT 2: This has been changed it this version, it is only a problem in the older versions that you are suggested to download here, version 0.97 When will those ones be updated?

Try using 'from easygui import *' instead of 'import easygui', and you
should import everything.
Alternatively, use 'from easygui import ' in order to keep your namespace clean.
Attributes like 'all' are private and get name mangled. As a general
rule of thumb you don't want to access things like that. You can still
access private attributes if you really want.
Does that help?

Ok thanks, but is there an issue with my fix?

Short answer - use v0.98 from GitHub (here!) or from PIP. I'll update SourceForge to point people here.
Longer answer - I'm curious about what wasn't working and how your fix works and want to look into it. When I get the chance I'll try to reproduce it and understand how this works.

@zadacka
Okay, but make sure to tell people to isolate the easygui folder from the .zip file that gets downloaded, it was a little confusing at first. Thanks!


Add API for institution configuration options for institution

This depends on the service introduced in #146
GET /institution-configuration-options/dev.organisation.example

{
  "use_ra_locations": false,
  "show_raa_contact_information": true
}

@DRvanR

with the 404 implemented :+1:

oh and please create a tech debt issue that controllers should be converted services rather than using the container to retrieve whatever they  please :cat:

Controllers as services, yes please! Makes 'em a bit more testable than mere web test cases.

Note: after using the JsonSerializable behaviour on the InstitutionConfigurationOptions, the format has been aligned with how showing all options works in the Management API, for example:
GET /institution-configuration-options/dev.organisation.example

{
    "dev.organisation.example" : {
        "use_ra_locations": false,
        "show_raa_contact_information": true
    }
}


Release failing to push to PyPi due to similar named project

Tracks: https://github.com/pypi/support/issues/3755

@ologistio/magi-maintainers FYI


⚠ Bofrost.at has degraded performance

In 1f5300d, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 2224 ms

Resolved: Bofrost.at performance has improved in 6d53a8f.


PHP 7.4 Compatibility Fix

fixes Deprecated: Array and string offset access syntax with curly braces is deprecated in...

Looks like CI is broken across the entire project for 7.1 and integrations and is unrelated to this PR.

Thanks @chingor13! Apologies for the noise, I should have searched for other PRs that fixed this issue before filing this one - was working with @rlerdorf on fixing up our dependencies for PHP 7.4.
Any chance you could tag a release for the main branch that includes this fix?


Class string color scopes incorrect when v-model contains TS "as" cast

Example:
<textarea
  v-model="var as string"
  class="fld-module h-full resize-none">
...

Class string is assigned incorrect scopes meta.namespace.declaration.ts and source.ts.embedded.html.vue etc..
The order of attributes seems to make no difference. Workarounds:

bracket the entire v-model expression eg. v-model="(var as string)"
use angle bracket casting instead, eg. v-model="<string>var"

How it appears (using tomorrow night theme):

How it should appear:

This problem similar to #112, it's embed language syntax issue, we can't fix, you need to use () to catch it.

@johnsoncodehk which upstream package is responsible for this issue?

This: https://github.com/microsoft/TypeScript-TmLanguage

@johnsoncodehk adding round parentheses fixes it. It might be interesting for volar to auto-add those inside templates.

@mesqueeb you can open a FR, but there is not necessarily a way to do it.

What issue in https://github.com/microsoft/TypeScript-TmLanguage is the upstream issue for this? It doesn't make sense to have this closed without notifying the upstream repo to fix it.

Marking any issue as duplicate of this one yet closing it without a proper path to get it fixed is kind of frustrating. How can we further track this issue, maybe over at microsoft/TypeScript-TmLanguage ?

@matthew-dean Even in .ts files, problems can occur when writing syntax equivalent to the original topic.

This is the code where we embed the ts syntax, you can try investigating:
https://github.com/vuejs/language-tools/blob/ffa590af35b0d6aa838dbb47b0eeda27da0a1422/extensions/vscode/syntaxes/vue.tmLanguage.json#L1042
I don't think upstream has a chance to fix it, it's more like a design limitation of the embedded language syntax highlight.

Anyway this can't be fixed in this repo, but I just suggested a possible fix at https://github.com/microsoft/TypeScript-TmLanguage/issues/985#issuecomment-2127996567.

Related: https://github.com/prettier/prettier/issues/15201


nyc coverage shows 0%

i have been trying to use riteway, in one of my sideprojects. When trying to get it working with instanbul coverage report it shows 0% coverage.
I currently have only a single test.js file , it imports a class from another js file, and runs tests on it.
Output:

    ----------|---------|----------|---------|---------|-------------------
    File      | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s
    ----------|---------|----------|---------|---------|-------------------
    All files |       0 |        0 |       0 |       0 |
    ----------|---------|----------|---------|---------|-------------------

  passed: 2,  failed: 0  of 2 tests  (4.1s)

package.json
   "test": "riteway -r @babel/register -r @babel/polyfill src/**/*-test.js",
    "coverage": "nyc npm run test  | tap-nirvana",

.babelrc
{
  "presets": [
    [
      "@babel/preset-env",
      {
        "targets": [
          "last 2 versions",
          "safari >= 7"
        ]
      }
    ],
  ],
  "plugins": ["istanbul"]
}

.nycrc
{
    "extends": "@istanbuljs/nyc-config-babel"
}

Have you tried nyc riteway -r @babel/register -r @babel/polyfill src/**/*-test.js?

Yes, I tried this as well, still shows 0 %
1..2
# tests 2
# pass  2

# ok

----------|---------|----------|---------|---------|-------------------
File      | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s
----------|---------|----------|---------|---------|-------------------
All files |       0 |        0 |       0 |       0 |
----------|---------|----------|---------|---------|-------------------

both subject and test file for reference:
https://github.com/ankitkhedekar/angular-cric-scorer/tree/master/src/app/common

I wouldn't know how to begin investigating this. Have you asked the nyc team about this?


Update annotation redirect to 1.8.0-beta02

Bump to the current version: https://developer.android.com/jetpack/androidx/releases/annotation#1.8.0-beta02
Testing
Test: N/A

Did we snap  the annotation subfolder at this commit? We shouldn't change redirect to another version without a reason

No actual changes in the code. But we need to avoid using alpha in more stable versions if it's available

Ok


[10.x] Added "userOrFail" auth method.

Hey! This PR is only a small one and proposes a new userOrFail method for getting the authenticated user.
You can use the method like so:
$user = auth()->userOrFail();

// or...

$user = Auth::userOrFail();

This method works in a similar way to the auth()-user() method and will return the authenticated user if there is one. However, if there isn't one, an \Illuminate\Auth\AuthenticationException will be thrown.
The idea behind this is that I sometimes want to be double-sure that I have all the necessary data needed in my controllers, views, etc. So I see this as being an extra defence to ensure that there is an authenticated user before we try acting on them (calling any methods or properties).
I'd like to think of it as being a similar sort of approach to using sole() in DB queries or Collections, whereby you're 99% sure that your data is correct, but you just want that extra confidence at runtime.
I get that this is a really small (and possibly unneeded) addition, but I thought I'd propose it because I like to use something similar in some of my projects. So it's totally cool if you think it's unneeded!
If it's something you think might be handy to other developers, please give me a shout if you need anything changed. Apologies if I've missed anything.
P.s. - If you do think this is useful, and it gets merged, would you also be open to me adding a similar method to requests classes (e.g. - $request->userOrFail())? 🙂

Looking at this, I'm wondering if a different exception would be more suitable? I think the \Illuminate\Auth\AuthenticationException already has some handling in the app to redirect the user to the login route (at least from what I can see in one of my local projects), which we might not want to do.

Looking at this, I'm wondering if a different exception would be more suitable? I think the \Illuminate\Auth\AuthenticationException already has some handling in the app to redirect the user to the login route (at least from what I can see in one of my local projects), which we might not want to do.

@ash-jc-allen  I think using this exception is okay since the exception is just been thrown and redirectTo default is null so there shouldn't be any redirect.

Can you give a real example of this method?
One way you can use auth middleware instead of this method!

Can you just do:
$user = Auth::user() || throw new Exception;


Restore Set.InsertAll

This was removed by https://github.com/istio/istio/pull/38140, but should not have been. The Insert/InsertAll separation avoids a needless array allocation for the vast majority of Insert calls.
Please provide a description of this PR:

OK. let's have a benchmark test to see the difference.

goos: linux
goarch: amd64
pkg: istio.io/istio/pkg/util/sets
cpu: Intel(R) Xeon(R) Gold 6161 CPU @ 2.20GHz
BenchmarkSet_Insert-8      	48236504	        34.43 ns/op
BenchmarkSet_InsertOne-8   	47176616	        30.24 ns/op
PASS
ok  	istio.io/istio/pkg/util/sets	3.156s


Attach video recording to robot log report

Hi,
I would like to request to have video attachment to robot framework report log.
The expected outcome should same with Take Screenshot keyword. Currently screenshot image will attached to report log, but it is not able to do so with video recording.

Video should be in the log.html file, in the Open Page keyword.
Video can not be separate keyword, because recording of the video starts when page starts and stops when page closes.

Basically what you want is not possible, because video recording can not be controlled in the way you wanting. Therefore I am going to close the issue.


Translations + fix

Updated Polish translations and credited myself
Fixed counting opened windows when closing the app. There were some abstract windows (such as adorner) preventing closing the app. Now only loaded and non-empty windows are counted and the app closes successfully.

PS I keep making the same mistake over and over, updating fork on master and not squashing. Sorry. You can squash merge now if you want to.

Thank you. :)


experiment details

Hi, how many epochs do I have to train to achieve acceptable results? Could you upload a train log to see the loss changes?

Hi! I believe for first stage ~200 epochs is enough (things are the same
for the original PVD). For reflow and distillation stage, if you samples m
times size of the training set, you can fine tune it for something like
200/m epochs. For example, in our original setup, we sample the reflow set
10 times larger than training set so we only fine tune it for 100 epochs.
Sorry the training log was saved in the internal server so it is not easy
to export it out, if you have trouble training it with 200 epochs, please
let me know.
On Fri, Dec 15, 2023 at 12:27 AM dreamcubeblock @.***>
wrote:

Hi, how many epochs do I have to train to achieve acceptable results?
Could you upload a train log to see the loss changes?
—
Reply to this email directly, view it on GitHub
https://github.com/klightz/PSF/issues/7, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AD4FEVNYLDAHB2VPZ2PCPFDYJPUWBAVCNFSM6AAAAABAV677YKVHI2DSMVQWIX3LMV43ASLTON2WKOZSGA2DEOJYGM4DGNQ
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

It works, thanks!


Error: Ledger merkle tree doesn't acceptable for current tree

Hi,
I'm trying to use the Python wrapper against the master of hyperledger/indy-node and it fails consistently when running open_pool_ledger. Initially I though there's something wrong with my Python code, but then I tried running the code from samples and got the same error: Ledger merkle tree doesn't acceptable for current tree:
cd samples/python
python3 src/main.py

Error:
...
 INFO|indy::services::pool          |           src/services/pool/mod.rs:544 | RemoteNode::send_str Node1 {"op":"LEDGER_STATUS","txnSeqNo":4,"merkleRoot":"EBEbqTXvTpgJ6z6W9YGme41TdcnWW6AQjqXt7duTnbRP","ledgerId":0,"ppSeqNo":null,"viewNo":null}
TRACE|indy::services::pool          |           src/services/pool/mod.rs:246 | zmq poll loop <<
TRACE|indy::services::pool          |           src/services/pool/mod.rs:240 | zmq poll loop >>
TRACE|indy::services::pool          |           src/services/pool/mod.rs:348 | get_zmq_poll_timeout first_event Tm { tm_sec: 21, tm_min: 59, tm_hour: 16, tm_mday: 15, tm_mon: 1, tm_year: 118, tm_wday: 4, tm_yday: 45, tm_isdst: 0, tm_utcoff: 0, tm_nsec: 454409000 }
TRACE|indy::services::pool          |           src/services/pool/mod.rs:349 | get_zmq_poll_timeout now_utc Tm { tm_sec: 31, tm_min: 58, tm_hour: 16, tm_mday: 15, tm_mon: 1, tm_year: 118, tm_wday: 4, tm_yday: 45, tm_isdst: 0, tm_utcoff: 0, tm_nsec: 534605000 }
TRACE|indy::services::pool          |           src/services/pool/mod.rs:351 | get_zmq_poll_timeout diff Duration Duration { secs: 49, nanos: 919804000 }
TRACE|indy::services::pool          |           src/services/pool/mod.rs:353 | get_zmq_poll_timeout diff ms 49919
TRACE|indy::services::pool          |           src/services/pool/mod.rs:293 | zmq poll 2
 INFO|indy::services::pool          |           src/services/pool/mod.rs:538 | RemoteNode::recv_msg Node4 {"viewNo":null,"op":"LEDGER_STATUS","ledgerId":0,"merkleRoot":"FTH83QNd84mnaXFD8vQdRHbRmmkZqz22pbHFjzy9mYt1","ppSeqNo":null,"txnSeqNo":4}
 INFO|indy::services::pool          |           src/services/pool/mod.rs:538 | RemoteNode::recv_msg Node3 {"merkleRoot":"FTH83QNd84mnaXFD8vQdRHbRmmkZqz22pbHFjzy9mYt1","ledgerId":0,"viewNo":null,"ppSeqNo":null,"op":"LEDGER_STATUS","txnSeqNo":4}
TRACE|indy::services::pool          |           src/services/pool/mod.rs:244 | process_actions - Invalid library state: Ledger merkle tree doesn't acceptable for current tree.
ERROR|indy::services::pool          |           src/services/pool/mod.rs:426 | Pool worker thread finished with error CommonError(InvalidState("Ledger merkle tree doesn\'t acceptable for current tree."))
 INFO|indy::commands                |                src/commands/mod.rs:99  | PoolCommand command received
 INFO|indy::commands::pool          |               src/commands/pool.rs:68  | OpenAck handle 4, pool_id 5, result Err(CommonError(InvalidState("Ledger merkle tree doesn\'t acceptable for current tree.")))
ERROR|indy::errors::indy            |                 src/errors/indy.rs:68  | Casting error to ErrorCode: Invalid library state: Ledger merkle tree doesn't acceptable for current tree.
WARNING:indy.libindy:_indy_loop_callback: Function returned error 112
Traceback (most recent call last):
  File "src/main.py", line 15, in <module>
    loop.run_until_complete(main())
  File "/usr/local/Cellar/python3/3.6.4_2/Frameworks/Python.framework/Versions/3.6/lib/python3.6/asyncio/base_events.py", line 467, in run_until_complete
    return future.result()
  File "src/main.py", line 10, in main
    await ledger.demo()
  File "/Users/me/Projects/hyperledger/indy-sdk/samples/python/src/ledger.py", line 24, in demo
    pool_handle = await pool.open_pool_ledger(pool_name, None)
  File "/Users/me/Projects/hyperledger/indy-sdk/wrappers/python/indy/pool.py", line 82, in open_pool_ledger
    open_pool_ledger.cb)
indy.error.IndyError: ErrorCode.CommonInvalidState

Background

I'm on OSX
I have Indy running locally, following the instructions from https://github.com/hyperledger/indy-node/blob/master/environment/docker/pool/README.md with default parameters
I compiled libindy as described in https://github.com/hyperledger/indy-sdk/blob/master/doc/mac-build.md and the build completed successfully
I pointed at my local build/check-out of indy-sdk using LD_LIBRARY_PATH and PYTHONPATH

I tried many different ways of connecting to Indy using the Python wrapper but it always fails with CommonInvalidState.
I found this issue report: https://jira.hyperledger.org/browse/IS-355?page=com.atlassian.streams.streams-jira-plugin%3Aactivity-stream-issue-tab
My suspicion is that the version of indy-crypto may be inconsistent between indy-sdk and indy-node, but I can't see the way to roll it back for indy-sdk without losing the whole lot of recent changes.
Any guidance how to fix it would be highly appreciated.
Stan

I suggest to compare genesis transactions of ledger and genesis transactions of client you use. Most probable Node IPs are different.
Nodes use <IP_ADDRESS> ip from internal interface inside of VirtualBox, but most probable you are trying to connect to <IP_ADDRESS> ips.

Thank you, @vimmerru. I'm using the environment variable TEST_POOL_IP to override the IPs to my docker IP.
Apologies, I'm new to Indy. Do I understand your recommendation correctly, that the transactions defined in https://github.com/hyperledger/indy-sdk/blob/master/samples/python/src/utils.py (see below)
def pool_genesis_txn_data():
    pool_ip = environ.get("TEST_POOL_IP", "<IP_ADDRESS>")

    return "\n".join([
        '{{"data":{{"alias":"Node1","blskey":"4N8aUNHSgjQVgkpm8nhNEfDf6txHznoYREg9kirmJrkivgL4oSEimFF6nsQ6M41QvhM2Z33nves5vfSn9n1UwNFJBYtWVnHYMATn76vLuL3zU88KyeAYcHfsih3He6UHcXDxcaecHVz6jhCYz1P2UZn2bDVruL5wXpehgBfBaLKm3Ba","client_ip":"{}","client_port":9702,"node_ip":"{}","node_port":9701,"services":["VALIDATOR"]}},"dest":"Gw6pDLhcBcoQesN72qfotTgFa7cbuqZpkX3Xo6pLhPhv","identifier":"Th7MpTaRZVRYnPiabds81Y","txnId":"fea82e10e894419fe2bea7d96296a6d46f50f93f9eeda954ec461b2ed2950b62","type":"0"}}'.format(
            pool_ip, pool_ip),
        '{{"data":{{"alias":"Node2","blskey":"37rAPpXVoxzKhz7d9gkUe52XuXryuLXoM6P6LbWDB7LSbG62Lsb33sfG7zqS8TK1MXwuCHj1FKNzVpsnafmqLG1vXN88rt38mNFs9TENzm4QHdBzsvCuoBnPH7rpYYDo9DZNJePaDvRvqJKByCabubJz3XXKbEeshzpz4Ma5QYpJqjk","client_ip":"{}","client_port":9704,"node_ip":"{}","node_port":9703,"services":["VALIDATOR"]}},"dest":"8ECVSk179mjsjKRLWiQtssMLgp6EPhWXtaYyStWPSGAb","identifier":"EbP4aYNeTHL6q385GuVpRV","txnId":"1ac8aece2a18ced660fef8694b61aac3af08ba875ce3026a160acbc3a3af35fc","type":"0"}}'.format(
            pool_ip, pool_ip),
        '{{"data":{{"alias":"Node3","blskey":"3WFpdbg7C5cnLYZwFZevJqhubkFALBfCBBok15GdrKMUhUjGsk3jV6QKj6MZgEubF7oqCafxNdkm7eswgA4sdKTRc82tLGzZBd6vNqU8dupzup6uYUf32KTHTPQbuUM8Yk4QFXjEf2Usu2TJcNkdgpyeUSX42u5LqdDDpNSWUK5deC5","client_ip":"{}","client_port":9706,"node_ip":"{}","node_port":9705,"services":["VALIDATOR"]}},"dest":"DKVxG2fXXTU8yT5N7hGEbXB3dfdAnYv1JczDUHpmDxya","identifier":"4cU41vWW82ArfxJxHkzXPG","txnId":"7e9f355dffa78ed24668f0e0e369fd8c224076571c51e2ea8be5f26479edebe4","type":"0"}}'.format(
            pool_ip, pool_ip),
        '{{"data":{{"alias":"Node4","blskey":"2zN3bHM1m4rLz54MJHYSwvqzPchYp8jkHswveCLAEJVcX6Mm1wHQD1SkPYMzUDTZvWvhuE6VNAkK3KxVeEmsanSmvjVkReDeBEMxeDaayjcZjFGPydyey1qxBHmTvAnBKoPydvuTAqx5f7YNNRAdeLmUi99gERUU7TD8KfAa6MpQ9bw","client_ip":"{}","client_port":9708,"node_ip":"{}","node_port":9707,"services":["VALIDATOR"]}},"dest":"4PS3EDQ3dW1tci1Bp6543CfuuebjFrg36kLAUcskGfaA","identifier":"TWwCRQRZ2ZHMJFn9TzLp7W","txnId":"aa5e817d7cc626170eca175822029339a444eb0ee8f0bd20d3b0b76e566fb008","type":"0"}}'.format(
            pool_ip, pool_ip)
    ])

don't match the genesis transactions in the Indy instance as defined in https://github.com/hyperledger/indy-node/blob/master/environment/docker/pool/?

Update:
Here are the pool transactions taken from the ledger node (Node1, /home/indy/.indy-cli/networks/sandbox/pool_transactions_genesis):
{"data":{"alias":"Node1","blskey":"4N8aUNHSgjQVgkpm8nhNEfDf6txHznoYREg9kirmJrkivgL4oSEimFF6nsQ6M41QvhM2Z33nves5vfSn9n1UwNFJBYtWVnHYMATn76vLuL3zU88KyeAYcHfsih3He6UHcXDxcaecHVz6jhCYz1P2UZn2bDVruL5wXpehgBfBaLKm3Ba","client_ip":"<IP_ADDRESS>","client_port":9702,"node_ip":"<IP_ADDRESS>","node_port":9701,"services":["VALIDATOR"]},"dest":"Gw6pDLhcBcoQesN72qfotTgFa7cbuqZpkX3Xo6pLhPhv","identifier":"Th7MpTaRZVRYnPiabds81Y","txnId":"fea82e10e894419fe2bea7d96296a6d46f50f93f9eeda954ec461b2ed2950b62","type":"0"}
{"data":{"alias":"Node2","blskey":"37rAPpXVoxzKhz7d9gkUe52XuXryuLXoM6P6LbWDB7LSbG62Lsb33sfG7zqS8TK1MXwuCHj1FKNzVpsnafmqLG1vXN88rt38mNFs9TENzm4QHdBzsvCuoBnPH7rpYYDo9DZNJePaDvRvqJKByCabubJz3XXKbEeshzpz4Ma5QYpJqjk","client_ip":"<IP_ADDRESS>","client_port":9704,"node_ip":"<IP_ADDRESS>","node_port":9703,"services":["VALIDATOR"]},"dest":"8ECVSk179mjsjKRLWiQtssMLgp6EPhWXtaYyStWPSGAb","identifier":"EbP4aYNeTHL6q385GuVpRV","txnId":"1ac8aece2a18ced660fef8694b61aac3af08ba875ce3026a160acbc3a3af35fc","type":"0"}
{"data":{"alias":"Node3","blskey":"3WFpdbg7C5cnLYZwFZevJqhubkFALBfCBBok15GdrKMUhUjGsk3jV6QKj6MZgEubF7oqCafxNdkm7eswgA4sdKTRc82tLGzZBd6vNqU8dupzup6uYUf32KTHTPQbuUM8Yk4QFXjEf2Usu2TJcNkdgpyeUSX42u5LqdDDpNSWUK5deC5","client_ip":"<IP_ADDRESS>","client_port":9706,"node_ip":"<IP_ADDRESS>","node_port":9705,"services":["VALIDATOR"]},"dest":"DKVxG2fXXTU8yT5N7hGEbXB3dfdAnYv1JczDUHpmDxya","identifier":"4cU41vWW82ArfxJxHkzXPG","txnId":"7e9f355dffa78ed24668f0e0e369fd8c224076571c51e2ea8be5f26479edebe4","type":"0"}
{"data":{"alias":"Node4","blskey":"2zN3bHM1m4rLz54MJHYSwvqzPchYp8jkHswveCLAEJVcX6Mm1wHQD1SkPYMzUDTZvWvhuE6VNAkK3KxVeEmsanSmvjVkReDeBEMxeDaayjcZjFGPydyey1qxBHmTvAnBKoPydvuTAqx5f7YNNRAdeLmUi99gERUU7TD8KfAa6MpQ9bw","client_ip":"<IP_ADDRESS>","client_port":9708,"node_ip":"<IP_ADDRESS>","node_port":9707,"services":["VALIDATOR"]},"dest":"4PS3EDQ3dW1tci1Bp6543CfuuebjFrg36kLAUcskGfaA","identifier":"TWwCRQRZ2ZHMJFn9TzLp7W","txnId":"aa5e817d7cc626170eca175822029339a444eb0ee8f0bd20d3b0b76e566fb008","type":"0"}

And this is what  https://github.com/hyperledger/indy-sdk/blob/master/samples/python/src/utils.py generates when I run the samples (~/.indy_client/pool/pool1/pool1.txn):
{"data":{"alias":"Node1","blskey":"4N8aUNHSgjQVgkpm8nhNEfDf6txHznoYREg9kirmJrkivgL4oSEimFF6nsQ6M41QvhM2Z33nves5vfSn9n1UwNFJBYtWVnHYMATn76vLuL3zU88KyeAYcHfsih3He6UHcXDxcaecHVz6jhCYz1P2UZn2bDVruL5wXpehgBfBaLKm3Ba","client_ip":"<IP_ADDRESS>","client_port":9702,"node_ip":"<IP_ADDRESS>","node_port":9701,"services":["VALIDATOR"]},"dest":"Gw6pDLhcBcoQesN72qfotTgFa7cbuqZpkX3Xo6pLhPhv","identifier":"Th7MpTaRZVRYnPiabds81Y","txnId":"fea82e10e894419fe2bea7d96296a6d46f50f93f9eeda954ec461b2ed2950b62","type":"0"}
{"data":{"alias":"Node2","blskey":"37rAPpXVoxzKhz7d9gkUe52XuXryuLXoM6P6LbWDB7LSbG62Lsb33sfG7zqS8TK1MXwuCHj1FKNzVpsnafmqLG1vXN88rt38mNFs9TENzm4QHdBzsvCuoBnPH7rpYYDo9DZNJePaDvRvqJKByCabubJz3XXKbEeshzpz4Ma5QYpJqjk","client_ip":"<IP_ADDRESS>","client_port":9704,"node_ip":"<IP_ADDRESS>","node_port":9703,"services":["VALIDATOR"]},"dest":"8ECVSk179mjsjKRLWiQtssMLgp6EPhWXtaYyStWPSGAb","identifier":"EbP4aYNeTHL6q385GuVpRV","txnId":"1ac8aece2a18ced660fef8694b61aac3af08ba875ce3026a160acbc3a3af35fc","type":"0"}
{"data":{"alias":"Node3","blskey":"3WFpdbg7C5cnLYZwFZevJqhubkFALBfCBBok15GdrKMUhUjGsk3jV6QKj6MZgEubF7oqCafxNdkm7eswgA4sdKTRc82tLGzZBd6vNqU8dupzup6uYUf32KTHTPQbuUM8Yk4QFXjEf2Usu2TJcNkdgpyeUSX42u5LqdDDpNSWUK5deC5","client_ip":"<IP_ADDRESS>","client_port":9706,"node_ip":"<IP_ADDRESS>","node_port":9705,"services":["VALIDATOR"]},"dest":"DKVxG2fXXTU8yT5N7hGEbXB3dfdAnYv1JczDUHpmDxya","identifier":"4cU41vWW82ArfxJxHkzXPG","txnId":"7e9f355dffa78ed24668f0e0e369fd8c224076571c51e2ea8be5f26479edebe4","type":"0"}
{"data":{"alias":"Node4","blskey":"2zN3bHM1m4rLz54MJHYSwvqzPchYp8jkHswveCLAEJVcX6Mm1wHQD1SkPYMzUDTZvWvhuE6VNAkK3KxVeEmsanSmvjVkReDeBEMxeDaayjcZjFGPydyey1qxBHmTvAnBKoPydvuTAqx5f7YNNRAdeLmUi99gERUU7TD8KfAa6MpQ9bw","client_ip":"<IP_ADDRESS>","client_port":9708,"node_ip":"<IP_ADDRESS>","node_port":9707,"services":["VALIDATOR"]},"dest":"4PS3EDQ3dW1tci1Bp6543CfuuebjFrg36kLAUcskGfaA","identifier":"TWwCRQRZ2ZHMJFn9TzLp7W","txnId":"aa5e817d7cc626170eca175822029339a444eb0ee8f0bd20d3b0b76e566fb008","type":"0"}

Everything seems to match, except the IP addresses (10.0.0.x is the Docker internal IP and <IP_ADDRESS> is the IP of my docker service on OSX)
Is there anything else I need to look at?

Everything seems to match, except the IP addresses (10.0.0.x is the Docker internal IP and <IP_ADDRESS> is the IP of my docker service on OSX)

Yes, and it is a cause of your problem. ip address must be the same.

IP is a part of Node transaction in pool ledger and present in merkle tree hashes.

@vimmerru aha! So please correct me if I'm wrong, this means that if I wanted to run the Python client code against my test Indy instance (on OSX), I either need to do it inside a Docker container (so that I can use the internal IPs), or run Indy locally, and not through Docker?
And, forgive me for asking too many questions, is the hard-binding to the IP address done for security reasons? I'm just thinking about the implications in the future if there was ever a need to move Indy instances around.

The solution that we use:

Run all nodes inside of one docker container and use <IP_ADDRESS> address in genesis transactions
Use port mapping of local machine to docker ports and connect client to <IP_ADDRESS>

You can use corresponded Docker config from indy-sdk repo: https://github.com/hyperledger/indy-sdk/blob/master/ci/indy-pool.dockerfile It runs all nodes in one container and by default uses <IP_ADDRESS> ip:
On windows the following commands will work:
docker build -f ci/indy-pool.dockerfile -t indy_pool .
docker run -itd -p 9701-9709:9701-9709 indy_pool

Please note that this port mapping between container and local host requires latest Docker for Windows (linux containers) and windows system with Hyper-V support.
On MacOS most probable use some Docker distribution based on Virtual Box that can miss port mapping feature. You can use Virtual Box's port forwarding future to map 9701-9709 container ports to local 9701-9709 ports.

@vimmerru Thank you, your suggestion works as a charm. I mapped the ports in VMWare Fusion by following the instructions from https://medium.com/@tuweizhong/how-to-setup-port-forward-at-vmware-fusion-8-for-os-x-742ad6ca1344 and adding the following to /Library/Preferences/VMware Fusion/vmnet8/nat.conf:
# Use these with care - anyone can enter into your VM through these...
# The format and example are as follows:
#<external port number> = <VM's IP address>:<VM's port number>
#8080 = <IP_ADDRESS>:80
9709 = <IP_ADDRESS>:9709
9707 = <IP_ADDRESS>:9707
9702 = <IP_ADDRESS>:9702
9701 = <IP_ADDRESS>:9701
9708 = <IP_ADDRESS>:9708
9703 = <IP_ADDRESS>:9703
9704 = <IP_ADDRESS>:9704
9706 = <IP_ADDRESS>:9706
9705 = <IP_ADDRESS>:9705

where <IP_ADDRESS> is my Docker host IP. Then, after rebooting my docker machine, the samples worked. There's another hicckup deep in the weeds (an exception at samples/python/src/getting_started.py, line 203), but that's a problem for another day.
Thank you so much for you help! We are planning to use Indy (and the SDK) in a proof-of-concept for our product. If everything goes well, we might even consider developing a wrapper for Golang. To be contributed to this project, if it happens.
Stan

@kazarena
Could you add this info to https://github.com/hyperledger/indy-sdk/blob/master/doc/mac-build.md instruction and send PR?

@vimmerru will do

@vimmerru Apologies for the delay. See my PR https://github.com/hyperledger/indy-sdk/pull/632.


Allow data from gulp-data

I have updated the plugin to receive be compatible with latest version of gulp-data. According to https://github.com/colynb/gulp-data#note-to-gulp-plugin-authors plugins should also listen for file.data besides opts.data.

Hi @tuanpham-dev, just letting you know this is working flawlessly on my local fork. This PR adds the ability to work with gulp-data. Like this:
gulp
  .pipe(data(function(file) {
    // build your data for liquid
  })
  .pipe(liquid())

Thank you!

Hi Tuan, thanks for taking this PR.
Do you know if this should be reflected on the NPM repository?
It doesn't seem to be updated.

Hi @pabliqe - I've just check, it's still working fine. Make sure you use latest version of @tuanpham-dev/gulp-liquidjs


Add a string based problem from LeetCode

Is your feature request related to a problem? Please describe.
Add a string based problem, named Reverse Vowels of a String from LeetCode
Problem Link
Describe the solution you'd like
I would like to solve it in C++

You may go ahead @kiruba-r11 !


[BUG] Files input doesn't work when running with act

Is there an existing issue for this?

[X] I have searched the existing issues

Does this issue exist in the latest version?

[X] I'm using the latest release

Describe the bug?
When running this action with act (medium image) and providing a files input, the full list of modified files is returned rather than the a filtered list.
To Reproduce

Add action to repo as configured below
Add multiple changed files in commit, but only 1 with a .yaml extension
Run action locally with act

name: Test

on:
  push:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v2
        with:
          fetch-depth: 0

      - name: Get changes
        id: changes
        uses<EMAIL_ADDRESS>        with:
          files: \.yaml$

      - name: Show changes
        shell: bash
        run: |
          set -euo pipefail

          for file in ${{ steps.changes.outputs.all_modified_files }}
          do
            echo "${file}"
          done

What OS are you seeing the problem on?
ubuntu-latest or ubuntu-20.04
Expected behavior?
The same output should happen with act and on GitHub.
Relevant log output
No response
Anything else?
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct

After testing this locally I can confirm that this is a problem with act, and I created a related issue.


is whereRaw supported?

Hi there,
Is whereRaw supported or any plan to add in the future?
I wanna use it like this:
$repository->where('slug', '=', 'example')->whereRaw("(\"references\" #> '{project, id}' = '{$id}')");

We could definitely add it. Thanks for the tip

Do not forget this：
$repository->where('filedName1', '=', $value)->whereBetween('fieldName2', [$a, $b]);

We found that the former 'where' is ignored.


fix(optimizer): reduce expr tree depth when merge logical operations

Signed-off-by: Bugen Zhao<EMAIL_ADDRESS>hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.
What's changed and what's your intention?
When creating an expression with a series of logical operations OR or AND together, instead of chaining it simply with fold or reduce, try to build a perfect binary tree.
There are no significant benefits to doing this, but it reduces the depth of the expression tree, making it more readable and less likely to cause a stack overflow (see #17224 for the background).
A real customer example for stack overflow is a complicated full outer join after #8520, where we apply a NotNull filter on all key columns chained with OR. Added as a test case.
Checklist

[x] I have written necessary rustdoc comments
[x] I have added necessary unit tests and integration tests
[x] All checks passed in ./risedev check (or alias, ./risedev c)

Documentation

[ ] My PR needs documentation updates. (Please use the Release note section below to summarize the impact on users)

Release note
If this PR includes changes that directly affect users or other significant modifications relevant to the community, kindly draft a release note to provide a concise summary of these changes. Please prioritize highlighting the impact these changes will have on users.

I am confused by Postgres's behavior of expression evaluation order. @xiangjinwu Do you have any idea? Any potential risk if we reorder the expression among conjunctions or disjunctions?
Postgres result:
dev=#  select false and (1/0 is null);
 ?column?
----------
 f
(1 row)

dev=#  select (1/0 is null) and false;
ERROR:  division by zero

dev=# \timing
Timing is on.
tpch=# select    (pg_sleep(20) is null) and false;
 ?column?
----------
 f
(1 row)

Time: 0,470 ms
dev=# select    (pg_sleep(20) is null) and false;
 ?column?
----------
 f
(1 row)

Time: 0,584 ms

((A and B) and C) and D is NOT equivalent to (A and B) and (C and D), if short-circuiting is taken into account.
We could try implementing and/or as vararg exprs rather than binary exprs, to avoid a deep tree.
Alternatively, we could just give up on the short-circuiting / evaluation order guarantee for and/or. PostgreSQL only provides it for case when/coalesce (which we already implemented as vararg and there is no depth problem) but not and/or.

related: #6202


Details - Instead of user name, incorrect title "Attachment" is shown

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Version Number: 1.4.8-0
Reproducible in staging?: Y
Reproducible in production?: N
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:
Action Performed:

Go to https://staging.new.expensify.com/
Tap on a group chat
Tap header display names
Tap on a profile icon

Expected Result:
In profile page, user name / mail id must be displayed as title
Actual Result:
In profile page, instead of user name, incorrect title "Attachment" is shown
This issue occurs in individual chat, room chat, group chat, workspace in all profile pages, incorrect title "attachment" displayed instead of user name/mail id
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

Screenshots/Videos
Add any screenshot/video evidence

https://github.com/Expensify/App/assets/78819774/8e6ac07f-3a81-4659-8ef5-3916e226912b
View all open jobs on GitHub

looking at this right now

The revert PR was merged. Now fixed on main

ah nice thanks for the info! 🙇


Transfer learning to refine predicted library

Hello,
I am learning to refine our predicted spectral library to better match various samples (various proteolytic peptides, novel modifications, etc.). I am starting with standard unmodified tryptic peptides to ensure I am using AlphPeptDeep correctly, but I have run into issues with the file uploads. I have tried importing various speclib_tsv libraries (initially with then without modifications) as well as diann reports but am running into the same errors. I did not locate any log output, but attached is the output from my Windows PowerShell
2024-02-22_log.txt
I suspect I am loading inappropriate/invalid files. Are there any example file formats that I can test with?

Could you please check diann report file? "Modified.Sequence" must be in the header

Yes, "Modified.Sequence" is one of the column headers for each of the reports I have tried.
Would you be able to provide an example report and raw file that I may try through the gui? Perhaps there are other setting that I am not considering, e.g. modificaitons.

The file path you upload contains multiple files, and the software cannot read the corresponding files. You only need to delete the remaining files and keep only one psm file


HAWKULAR-236 Adjust Feedback messages style

This Travis failure obviously has nothing to do with UI as it is a pinger test, so I'm merging.


feat: Add support for rewriting imports in declaration files

This PR adds minimal support for rewriting imports in declaration (.d.ts) files by adding an "afterDeclarations" handler to supplement the existing "after" handler. To enable this feature, set the dtsExtName config value in the tsc-multi target config. The value should be the file extension of the declaration files you want. Sourcemap files and their references are also rewritten. Their extensions will match the configured dtsExtName with .map appended.
This is an example configuration that configures an ESNext output using the .mjs extension for code files and .d.mts extension for declaration files.
{
	"targets": [
		{
			"extname": ".mjs",
			"dtsExtName": ".d.mts",
			"module": "ESNext",
			"moduleResolution": "Node16",
			"outDir": "./lib"
		}
	],
	"projects": ["tsconfig.json"]
}

If dtsExtName is omitted, behavior should match exactly what it is today without this feature.
To keep the behavior separate, I copied the existing transformer and adjusted it specifically for declarations. This way any issues with the declaration files is clearly because of the new code - it shares no functional code with the old transformer.
There is some shared code in worker.ts to rename file extensions, but even in that file most logic is clearly separated so without opting in via config, behavior should match what it is today.

This PR appears to be targeting main on your fork, rather than upstream main. Was this intentional?

This PR appears to be targeting main on your fork, rather than upstream main. Was this intentional?

Yes. It's not anywhere near ready to open as an upstream change. There are no tests, plus it's lacking features that would be expected in a "real implementation." I'd love to do that extra work, but I don't have the time now.

@jason-ha I realized this pr includes changes not yet in fluid framework main. I think commit 486ad76f588aa709c2657ee4b8c01cf0ad390026 is what's currently in main.


Option to disable websocket compression at runtime

We want to be able to disable websocket compression at runtime in case it causes problems (or to help rule it out as the cause of problems).
[1] https://bitsharestalk.org/index.php/topic,21848.msg284818.html

Clarification:  This is a command line option.


⚠ PrivateHD has degraded performance

In 32660de, PrivateHD ($PHD) experienced degraded performance:

HTTP code: 200
Response time: 3558 ms

Resolved: PrivateHD performance has improved in 8662434.