default namespace in find method

Currently namespaces type in find method is defined as _StrictNSMap = Mapping[str, str], which causes mypy error being reported when default namespace (None key) is used. Is it correct?
lxml supports 2 ways of specifying the default namespace: None and an empty string (""). Because nsmap attribute of Element shows the default namespace under None key, I'd expect find to also be allowed to use this format.
Small snippet from ipython:
In [13]: z = lxml.etree.XML("")

In [14]: z.find('./b')

In [15]: z.find('./b', namespaces={None: "foo"})
Out[15]: <Element {foo}b at 0x7f6df2c0e480>

In [16]: z.find('./b', namespaces={"": "foo"})
Out[16]: <Element {foo}b at 0x7f6df2c0e480>

In [17]: z.find('./b', namespaces={"": "foo"}).nsmap
Out[17]: {None: 'foo'}

You're correct, I have been overzealous with the namespaces dict key change. Originally it is intended to prevent silly usage like find('*', namespaces={None: "foo", "": "bar"}), but such corner cases hurts more general usage. Will fix it soon.


fsSelection REGULAR

The error message is not clear:
$ ./fontbakery-check-ttf.py -s --ghm ../mada/Mada-Black.ttf
…
ERROR    fsSelection REGULAR bit Changes that must be applied to this font: OS/2 fsSelection from 192 to 128

The assumes the only way to set fsSelection is by assigning it an integer, which is unlikely most of time since people will be editing it in some higher level way. It should instead say what the required functional change is, e.g. fsSelection bit 6 (REGULAR) is unset but it should be set for this font, or the other way around or in some other descriptive way.

Completely agree


Add secant method to optimize

Add secant method to the available optimization functions

@certik is this a possible feature to add?

I think so. I also have a Brent's method here: https://github.com/certik/hfsolver/blob/7932fa75a725e8872367cfa2da96c75d75260e75/src/optimize.f90#L47 if you are interested.

I think this looks good, I merged it.


Custom method not allowed

I'm using the TSDAV package in Deno. https://tsdav.vercel.app/
I use it to interface with the CalDAV protocol.
CalDAV uses certain DAVMethods, in addition to traditional HTTPMethods:
type DAVMethods = 'COPY' | 'LOCK' | 'MKCOL' | 'MOVE' | 'PROPFIND' | 'PROPPATCH' | 'UNLOCK' | 'REPORT' | 'SEARCH' | 'MKCALENDAR';
The Deno port of cross-fetch, which this library depends on, uses your xhr library for the web requests. However, your library explicitly restricts non-standard HTTP methods:
Error: DOMException: The method "PROPFIND" is not allowed.     at new DOMException (ext:deno_web/01_dom_exception.js:114:19)     at XMLHttpRequest.open (https://deno.land/x/xhr@0.3.0/mod.ts:525:13)
Please remove this check, as it is preventing a legitimate use case of your library and is making the Deno environment more difficult for me to use.
Thank you very much.

I double checked the standard and the only thing we should be checking for is forbidden methods.

This is now available in version 0.3.1.

Wow, I truly appreciate the fast turnaround. I did a little more research for you. I'm not sure if you saw this:
https://www.iana.org/assignments/http-methods/http-methods.xhtml
Here is the list of registered HTTP methods. Could be useful for this library if you want to be a little bit more strict about checking methods.

I followed the XHR specification exactly on how it handles methods, so that is better in the end.


If the first resolution contains only a backend address, then we will initially use pick_first instead of grpclb.  So this test is not actually testing whether the grpclb policy reresolves when a backend dies; it's actually testing that pick_first does that.
In order to test that the grpclb policy does that, we need to return a balancer address that is either unreachable or that returns a different list of backends than the re-resolution data.

Comments from Reviewable

****************************************************************

libgrpc.so

     VM SIZE                                                                                FILE SIZE
 ++++++++++++++ GROWING                                                                              ++++++++++++++
  +0.1%    +347 [None]                                                                                +691  +0.0%
   +27%    +320 src/core/ext/filters/client_channel/resolver/fake/fake_resolver.cc                      +320   +27%
      [NEW]    +150 grpc_fake_resolver_response_generator_set_response_upon_error                           +150  [NEW]
       +41%     +56 grpc_fake_resolver_response_generator_set_response                                       +56   +41%
       +90%     +46 fake_resolver_channel_saw_error_locked                                                   +46   +90%
       +15%     +32 [Unmapped]                                                                               +32   +15%
       +30%     +27 set_response_closure_fn                                                                  +27   +30%
       +22%      +9 fake_resolver_destroy                                                                     +9   +22%
  +0.3%     +48 src/core/ext/filters/client_channel/lb_policy/grpclb/grpclb.cc                           +48  +0.3%
      [NEW] +1.46Ki rr_handover_locked(glb_lb_policy*) [clone .part.18]                                  +1.46Ki  [NEW]
      [NEW] +1.22Ki query_for_backends_locked(glb_lb_policy*) [clone .part.12]                           +1.22Ki  [NEW]
      [NEW]    +801 build_lb_channel_args(grpc_lb_addresses const*, grpc_fake_resolver_response_generato    +801  [NEW]
      [NEW]    +303 update_lb_connectivity_status_locked                                                    +303  [NEW]
      [NEW]    +217 rr_on_connectivity_changed_locked                                                       +217  [NEW]
      [NEW]    +210 extract_backend_addresses_locked(grpc_lb_addresses const*) [clone .isra.1]              +210  [NEW]
      [NEW]    +145 lb_call_data_shutdown(glb_lb_policy*) [clone .isra.3]                                   +145  [NEW]
      [NEW]    +125 rr_on_reresolution_requested_locked                                                     +125  [NEW]
      +6.2%     +64 glb_create                                                                               +64  +6.2%
      +2.5%     +16 lb_on_server_status_received_locked                                                      +16  +2.5%
  +9.1%     +45 src/core/ext/filters/client_channel/lb_policy.cc                                         +45  +9.1%
      +883%     +53 grpc_lb_policy_set_reresolve_closure_locked                                              +53  +883%

 -------------- SHRINKING                                                                            --------------
  -2.1%    -112 src/core/ext/filters/client_channel/lb_policy/pick_first/pick_first.cc                  -112  -2.1%
      [DEL]    -138 start_picking_locked(pick_first_lb_policy*) [clone .isra.1]                             -138  [DEL]
      [DEL]    -112 pf_set_reresolve_closure_locked                                                         -112  [DEL]
      [DEL]     -89 destroy_unselected_subchannels_locked(pick_first_lb_policy*) [clone .isra.2]             -89  [DEL]
  -1.8%    -112 src/core/ext/filters/client_channel/lb_policy/round_robin/round_robin.cc                -112  -1.8%
      [DEL]    -112 rr_set_reresolve_closure_locked                                                         -112  [DEL]
      [DEL]    -105 start_picking_locked(round_robin_lb_policy*) [clone .isra.1]                            -105  [DEL]

  +0.0%    +536 TOTAL                                                                                +880  +0.0%

****************************************************************

libgrpc++.so

     VM SIZE        FILE SIZE
 ++++++++++++++  ++++++++++++++

  [ = ]       0        0  [ = ]

[trickle] No significant performance differences

Thanks! I will extract the fake_resolver part out into a new PR when that part has converged.

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

src/core/ext/filters/client_channel/lb_policy/grpclb/grpclb.cc, line 757 at r23 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
Note that there's an edge case here, but I think it's an okay one: It could be that at the moment that this closure runs, we've already scheduled the re-resolution closure, and therefore this call will be a no-op.  But in that case, since there's already a re-resolution request in flight at essentially the same time, that's probably fine.

Yeah, that's OK. Basically grpc_lb_policy_try_reresolve() is idempotent. Also "try" emphasizes there's no guarantee for re-resolution by calling this function.

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

GRPC_LB_POLICY_REF(&glb_policy->base, "rr_on_reresolution_requested_locked");
grpc_lb_policy_set_reresolve_closure_locked(
new_rr_policy, &glb_policy->rr_on_reresolution_requested);

Need to move this down to line 782, so that we only execute this if new_rr_policy is not null.

Done.
Buggy bug.

test/core/client_channel/resolvers/fake_resolver_test.cc, line 76 at r23 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
Suggest calling this create_new_resolver_result().

Done.

test/core/client_channel/resolvers/fake_resolver_test.cc, line 132 at r23 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
I suggest calling grpc_resolver_next_locked() before calling grpc_fake_resolver_response_generator_set_response(), since this illustrates the fact that the resolver will not actually return anything until after the response generator provides one.

Done.
I agree with that now that I've understood how the resolution notification works.

test/core/client_channel/resolvers/fake_resolver_test.cc, line 148 at r23 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
Same here.

Done.

test/cpp/end2end/grpclb_end2end_test.cc, line 1174 at r23 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
If the first resolution contains only a backend address, then we will initially use pick_first instead of grpclb.  So this test is not actually testing whether the grpclb policy reresolves when a backend dies; it's actually testing that pick_first does that.
In order to test that the grpclb policy does that, we need to return a balancer address that is either unreachable or that returns a different list of backends than the re-resolution data.

Done.
I reverted the grpclb code into a state that will consider receiving a serverlist (instead of receiving the initial response) as the criteria of talking to a healthy balancer. This makes testing easier. Because as long as the balancer never returns any serverlist, the client can fall back and then re-resolve due to the fallback backend failure.
Otherwise if we use the initial response as the criteria, we need to have a balancer address that never returns initial response but also never fails the connection so that round_robin can trigger the re-resolution. I don't have a quick solution for such a balancer address.
That said, the important thing is that whether we want to re-resolve when the initial response has been received but no serverlist has been received and the RR has a failed subchannel. I think so, given that we are more aggressive about re-resolution now.

Comments from Reviewable

[microbenchmarks] No significant performance differences

Just one issue left.

Reviewed 3 of 3 files at r24.
Review status: all files reviewed at latest revision, 3 unresolved discussions, some commit checks failed.

test/cpp/end2end/grpclb_end2end_test.cc, line 1174 at r23 (raw file):
Previously, AspirinSJL (Juanli Shen) wrote…
Done.
I reverted the grpclb code into a state that will consider receiving a serverlist (instead of receiving the initial response) as the criteria of talking to a healthy balancer. This makes testing easier. Because as long as the balancer never returns any serverlist, the client can fall back and then re-resolve due to the fallback backend failure.
Otherwise if we use the initial response as the criteria, we need to have a balancer address that never returns initial response but also never fails the connection so that round_robin can trigger the re-resolution. I don't have a quick solution for such a balancer address.
That said, the important thing is that whether we want to re-resolve when the initial response has been received but no serverlist has been received and the RR has a failed subchannel. I think so, given that we are more aggressive about re-resolution now.

Looking at line 194 above, it looks like our balancer implementation will not send an initial response if the client load report interval is 0.  So can't we do this just by testing with a balancer that has that set to 0?
While it's true that we are willing to be more aggressive about re-resolution now, it does seem pointless to re-resolve when we're already connected to a balancer, even if we have not yet seen the initial response.  I think it would be better to avoid this if possible.

Comments from Reviewable

****************************************************************

libgrpc.so

     VM SIZE                                                                                FILE SIZE
 ++++++++++++++ GROWING                                                                              ++++++++++++++
  +0.1%    +347 [None]                                                                                +659  +0.0%
   +27%    +320 src/core/ext/filters/client_channel/resolver/fake/fake_resolver.cc                      +320   +27%
      [NEW]    +150 grpc_fake_resolver_response_generator_set_response_upon_error                           +150  [NEW]
       +41%     +56 grpc_fake_resolver_response_generator_set_response                                       +56   +41%
       +90%     +46 fake_resolver_channel_saw_error_locked                                                   +46   +90%
       +15%     +32 [Unmapped]                                                                               +32   +15%
       +30%     +27 set_response_closure_fn                                                                  +27   +30%
       +22%      +9 fake_resolver_destroy                                                                     +9   +22%
  +0.3%     +48 src/core/ext/filters/client_channel/lb_policy/grpclb/grpclb.cc                           +48  +0.3%
      [NEW] +1.46Ki rr_handover_locked(glb_lb_policy*) [clone .part.18]                                  +1.46Ki  [NEW]
      [NEW] +1.22Ki query_for_backends_locked(glb_lb_policy*) [clone .part.12]                           +1.22Ki  [NEW]
      [NEW]    +801 build_lb_channel_args(grpc_lb_addresses const*, grpc_fake_resolver_response_generato    +801  [NEW]
      [NEW]    +303 update_lb_connectivity_status_locked                                                    +303  [NEW]
      [NEW]    +223 rr_on_connectivity_changed_locked                                                       +223  [NEW]
      [NEW]    +210 extract_backend_addresses_locked(grpc_lb_addresses const*) [clone .isra.1]              +210  [NEW]
      [NEW]    +145 lb_call_data_shutdown(glb_lb_policy*) [clone .isra.3]                                   +145  [NEW]
      [NEW]    +125 rr_on_reresolution_requested_locked                                                     +125  [NEW]
      +6.2%     +64 glb_create                                                                               +64  +6.2%
      +2.5%     +16 lb_on_server_status_received_locked                                                      +16  +2.5%
  +9.1%     +45 src/core/ext/filters/client_channel/lb_policy.cc                                         +45  +9.1%
      +883%     +53 grpc_lb_policy_set_reresolve_closure_locked                                              +53  +883%

 -------------- SHRINKING                                                                            --------------
  -2.1%    -112 src/core/ext/filters/client_channel/lb_policy/pick_first/pick_first.cc                  -112  -2.1%
      [DEL]    -138 start_picking_locked(pick_first_lb_policy*) [clone .isra.1]                             -138  [DEL]
      [DEL]    -112 pf_set_reresolve_closure_locked                                                         -112  [DEL]
      [DEL]     -89 destroy_unselected_subchannels_locked(pick_first_lb_policy*) [clone .isra.2]             -89  [DEL]
  -1.8%    -112 src/core/ext/filters/client_channel/lb_policy/round_robin/round_robin.cc                -112  -1.8%
      [DEL]    -112 rr_set_reresolve_closure_locked                                                         -112  [DEL]
      [DEL]    -105 start_picking_locked(round_robin_lb_policy*) [clone .isra.1]                            -105  [DEL]

  +0.0%    +536 TOTAL                                                                                +848  +0.0%

****************************************************************

libgrpc++.so

     VM SIZE        FILE SIZE
 ++++++++++++++  ++++++++++++++

  [ = ]       0        0  [ = ]

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

test/cpp/end2end/grpclb_end2end_test.cc, line 1174 at r23 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
Looking at line 194 above, it looks like our balancer implementation will not send an initial response if the client load report interval is 0.  So can't we do this just by testing with a balancer that has that set to 0?
While it's true that we are willing to be more aggressive about re-resolution now, it does seem pointless to re-resolve when we're already connected to a balancer, even if we have not yet seen the initial response.  I think it would be better to avoid this if possible.

Done.
I see. Actually it seems that my worry is unnecessary because UpdatesTest already sets the client_load_reporting_interval_seconds to 0.
But the behavior that only sends initial response if client_load_reporting_interval_seconds > 0 seems incorrect. The initial response should always be the first response even when client load reporting is disabled. May need fixing.

Comments from Reviewable

[trickle] No significant performance differences

****************************************************************

libgrpc.so

     VM SIZE                                                                                FILE SIZE
 ++++++++++++++ GROWING                                                                              ++++++++++++++
  +0.1%    +347 [None]                                                                                +659  +0.0%
   +27%    +320 src/core/ext/filters/client_channel/resolver/fake/fake_resolver.cc                      +320   +27%
      [NEW]    +150 grpc_fake_resolver_response_generator_set_response_upon_error                           +150  [NEW]
       +41%     +56 grpc_fake_resolver_response_generator_set_response                                       +56   +41%
       +90%     +46 fake_resolver_channel_saw_error_locked                                                   +46   +90%
       +15%     +32 [Unmapped]                                                                               +32   +15%
       +30%     +27 set_response_closure_fn                                                                  +27   +30%
       +22%      +9 fake_resolver_destroy                                                                     +9   +22%
  +0.3%     +48 src/core/ext/filters/client_channel/lb_policy/grpclb/grpclb.cc                           +48  +0.3%
      [NEW] +1.46Ki rr_handover_locked(glb_lb_policy*) [clone .part.18]                                  +1.46Ki  [NEW]
      [NEW] +1.22Ki query_for_backends_locked(glb_lb_policy*) [clone .part.12]                           +1.22Ki  [NEW]
      [NEW]    +801 build_lb_channel_args(grpc_lb_addresses const*, grpc_fake_resolver_response_generato    +801  [NEW]
      [NEW]    +303 update_lb_connectivity_status_locked                                                    +303  [NEW]
      [NEW]    +223 rr_on_connectivity_changed_locked                                                       +223  [NEW]
      [NEW]    +210 extract_backend_addresses_locked(grpc_lb_addresses const*) [clone .isra.1]              +210  [NEW]
      [NEW]    +145 lb_call_data_shutdown(glb_lb_policy*) [clone .isra.3]                                   +145  [NEW]
      [NEW]    +125 rr_on_reresolution_requested_locked                                                     +125  [NEW]
      +6.2%     +64 glb_create                                                                               +64  +6.2%
      +2.5%     +16 lb_on_server_status_received_locked                                                      +16  +2.5%
  +9.1%     +45 src/core/ext/filters/client_channel/lb_policy.cc                                         +45  +9.1%
      +883%     +53 grpc_lb_policy_set_reresolve_closure_locked                                              +53  +883%

 -------------- SHRINKING                                                                            --------------
  -2.1%    -112 src/core/ext/filters/client_channel/lb_policy/pick_first/pick_first.cc                  -112  -2.1%
      [DEL]    -138 start_picking_locked(pick_first_lb_policy*) [clone .isra.1]                             -138  [DEL]
      [DEL]    -112 pf_set_reresolve_closure_locked                                                         -112  [DEL]
      [DEL]     -89 destroy_unselected_subchannels_locked(pick_first_lb_policy*) [clone .isra.2]             -89  [DEL]
  -1.8%    -112 src/core/ext/filters/client_channel/lb_policy/round_robin/round_robin.cc                -112  -1.8%
      [DEL]    -112 rr_set_reresolve_closure_locked                                                         -112  [DEL]
      [DEL]    -105 start_picking_locked(round_robin_lb_policy*) [clone .isra.1]                            -105  [DEL]

  +0.0%    +536 TOTAL                                                                                +848  +0.0%

****************************************************************

libgrpc++.so

     VM SIZE        FILE SIZE
 ++++++++++++++  ++++++++++++++

  [ = ]       0        0  [ = ]

[trickle] No significant performance differences

[microbenchmarks] Performance differences noted:
Benchmark                                                                                cpu_time    real_time
----------------------------------------------------------------------------------------  ----------  -----------
BM_StreamingPingPongWithCoalescingApi<MinInProcess, NoOpMutator, NoOpMutator>/262144/2/0  +4%         +4%

[microbenchmarks] No significant performance differences

This looks great!  Let's just wait for David's PR to be merged.

Reviewed 1 of 2 files at r25, 1 of 1 files at r26.
Review status: all files reviewed at latest revision, 3 unresolved discussions, some commit checks failed.

test/cpp/end2end/grpclb_end2end_test.cc, line 1174 at r23 (raw file):
Previously, AspirinSJL (Juanli Shen) wrote…
Done.
I see. Actually it seems that my worry is unnecessary because UpdatesTest already sets the client_load_reporting_interval_seconds to 0.
But the behavior that only sends initial response if client_load_reporting_interval_seconds > 0 seems incorrect. The initial response should always be the first response even when client load reporting is disabled. May need fixing.

Agreed, that would probably be a good thing to fix.

Comments from Reviewable

#14228 is merged!

Let us rejoice! :champagne: :fireworks: :tada:

Can you merge the changes into this PR?

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

Comments from Reviewable

Done.

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

Comments from Reviewable

****************************************************************

libgrpc.so

     VM SIZE                                                                                FILE SIZE
 ++++++++++++++ GROWING                                                                              ++++++++++++++
  +0.1%    +347 [None]                                                                                +659  +0.0%
   +27%    +320 src/core/ext/filters/client_channel/resolver/fake/fake_resolver.cc                      +320   +27%
      [NEW]    +150 grpc_fake_resolver_response_generator_set_response_upon_error                           +150  [NEW]
      [NEW]    +117 set_response_closure_locked                                                             +117  [NEW]
       +41%     +56 grpc_fake_resolver_response_generator_set_response                                       +56   +41%
       +90%     +46 fake_resolver_channel_saw_error_locked                                                   +46   +90%
       +15%     +32 [Unmapped]                                                                               +32   +15%
       +22%      +9 fake_resolver_destroy                                                                     +9   +22%
  +0.3%     +48 src/core/ext/filters/client_channel/lb_policy/grpclb/grpclb.cc                           +48  +0.3%
      [NEW] +1.46Ki rr_handover_locked(glb_lb_policy*) [clone .part.18]                                  +1.46Ki  [NEW]
      [NEW] +1.22Ki query_for_backends_locked(glb_lb_policy*) [clone .part.12]                           +1.22Ki  [NEW]
      [NEW]    +801 build_lb_channel_args(grpc_lb_addresses const*, grpc_fake_resolver_response_generato    +801  [NEW]
      [NEW]    +303 update_lb_connectivity_status_locked                                                    +303  [NEW]
      [NEW]    +223 rr_on_connectivity_changed_locked                                                       +223  [NEW]
      [NEW]    +210 extract_backend_addresses_locked(grpc_lb_addresses const*) [clone .isra.1]              +210  [NEW]
      [NEW]    +145 lb_call_data_shutdown(glb_lb_policy*) [clone .isra.3]                                   +145  [NEW]
      [NEW]    +125 rr_on_reresolution_requested_locked                                                     +125  [NEW]
      +6.2%     +64 glb_create                                                                               +64  +6.2%
      +2.5%     +16 lb_on_server_status_received_locked                                                      +16  +2.5%
  +9.1%     +45 src/core/ext/filters/client_channel/lb_policy.cc                                         +45  +9.1%
      +883%     +53 grpc_lb_policy_set_reresolve_closure_locked                                              +53  +883%

 -------------- SHRINKING                                                                            --------------
  -2.1%    -112 src/core/ext/filters/client_channel/lb_policy/pick_first/pick_first.cc                  -112  -2.1%
      [DEL]    -138 start_picking_locked(pick_first_lb_policy*) [clone .isra.1]                             -138  [DEL]
      [DEL]    -112 pf_set_reresolve_closure_locked                                                         -112  [DEL]
      [DEL]     -89 destroy_unselected_subchannels_locked(pick_first_lb_policy*) [clone .isra.2]             -89  [DEL]
  -1.8%    -112 src/core/ext/filters/client_channel/lb_policy/round_robin/round_robin.cc                -112  -1.8%
      [DEL]    -112 rr_set_reresolve_closure_locked                                                         -112  [DEL]
      [DEL]    -105 start_picking_locked(round_robin_lb_policy*) [clone .isra.1]                            -105  [DEL]

  +0.0%    +536 TOTAL                                                                                +848  +0.0%

****************************************************************

libgrpc++.so

     VM SIZE        FILE SIZE
 ++++++++++++++  ++++++++++++++

  [ = ]       0        0  [ = ]

[trickle] No significant performance differences

[microbenchmarks] No significant performance differences

****************************************************************

libgrpc.so

     VM SIZE                                                                                FILE SIZE
 ++++++++++++++ GROWING                                                                              ++++++++++++++
  +0.1%    +347 [None]                                                                                +659  +0.0%
   +27%    +320 src/core/ext/filters/client_channel/resolver/fake/fake_resolver.cc                      +320   +27%
      [NEW]    +150 grpc_fake_resolver_response_generator_set_response_upon_error                           +150  [NEW]
      [NEW]    +117 set_response_closure_locked                                                             +117  [NEW]
       +41%     +56 grpc_fake_resolver_response_generator_set_response                                       +56   +41%
       +90%     +46 fake_resolver_channel_saw_error_locked                                                   +46   +90%
       +15%     +32 [Unmapped]                                                                               +32   +15%
       +22%      +9 fake_resolver_destroy                                                                     +9   +22%
  +0.3%     +48 src/core/ext/filters/client_channel/lb_policy/grpclb/grpclb.cc                           +48  +0.3%
      [NEW] +1.46Ki rr_handover_locked(glb_lb_policy*) [clone .part.18]                                  +1.46Ki  [NEW]
      [NEW] +1.22Ki query_for_backends_locked(glb_lb_policy*) [clone .part.12]                           +1.22Ki  [NEW]
      [NEW]    +801 build_lb_channel_args(grpc_lb_addresses const*, grpc_fake_resolver_response_generato    +801  [NEW]
      [NEW]    +303 update_lb_connectivity_status_locked                                                    +303  [NEW]
      [NEW]    +223 rr_on_connectivity_changed_locked                                                       +223  [NEW]
      [NEW]    +210 extract_backend_addresses_locked(grpc_lb_addresses const*) [clone .isra.1]              +210  [NEW]
      [NEW]    +145 lb_call_data_shutdown(glb_lb_policy*) [clone .isra.3]                                   +145  [NEW]
      [NEW]    +125 rr_on_reresolution_requested_locked                                                     +125  [NEW]
      +6.2%     +64 glb_create                                                                               +64  +6.2%
      +2.5%     +16 lb_on_server_status_received_locked                                                      +16  +2.5%
  +9.1%     +45 src/core/ext/filters/client_channel/lb_policy.cc                                         +45  +9.1%
      +883%     +53 grpc_lb_policy_set_reresolve_closure_locked                                              +53  +883%

 -------------- SHRINKING                                                                            --------------
  -2.1%    -112 src/core/ext/filters/client_channel/lb_policy/pick_first/pick_first.cc                  -112  -2.1%
      [DEL]    -138 start_picking_locked(pick_first_lb_policy*) [clone .isra.1]                             -138  [DEL]
      [DEL]    -112 pf_set_reresolve_closure_locked                                                         -112  [DEL]
      [DEL]     -89 destroy_unselected_subchannels_locked(pick_first_lb_policy*) [clone .isra.2]             -89  [DEL]
  -1.8%    -112 src/core/ext/filters/client_channel/lb_policy/round_robin/round_robin.cc                -112  -1.8%
      [DEL]    -112 rr_set_reresolve_closure_locked                                                         -112  [DEL]
      [DEL]    -105 start_picking_locked(round_robin_lb_policy*) [clone .isra.1]                            -105  [DEL]

  +0.0%    +536 TOTAL                                                                                +848  +0.0%

****************************************************************

libgrpc++.so

     VM SIZE        FILE SIZE
 ++++++++++++++  ++++++++++++++

  [ = ]       0        0  [ = ]

[trickle] No significant performance differences

Reviewed 2 of 9 files at r27, 7 of 7 files at r28.
Review status: all files reviewed at latest revision, 4 unresolved discussions.

src/core/ext/filters/client_channel/lb_policy/grpclb/grpclb.cc, line 854 at r28 (raw file):

  GPR_ASSERT(glb_policy->rr_connectivity_state != GRPC_CHANNEL_SHUTDOWN);
  GPR_ASSERT(glb_policy->rr_connectivity_state != GRPC_CHANNEL_IDLE);
  if ((glb_policy->lb_calld == nullptr ||

It just occurred to me that now that we're going to re-resolve whenever our connection to a single backend fails (which will be handled by rr_on_reresolution_requested_locked() above), we probably don't need to do it here.  I think this code can just go away.

Comments from Reviewable

[microbenchmarks] No significant performance differences

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

src/core/ext/filters/client_channel/lb_policy/grpclb/grpclb.cc, line 854 at r28 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
It just occurred to me that now that we're going to re-resolve whenever our connection to a single backend fails (which will be handled by rr_on_reresolution_requested_locked() above), we probably don't need to do it here.  I think this code can just go away.

Done.
Good catch!
I moved the checking of a good balancer connection to rr_on_reresolution_requested_locked().

Comments from Reviewable

****************************************************************

libgrpc.so

     VM SIZE                                                                                FILE SIZE
 ++++++++++++++ GROWING                                                                              ++++++++++++++
  +9.1%     +45 src/core/ext/filters/client_channel/lb_policy.cc                                         +45  +9.1%
      +883%     +53 grpc_lb_policy_set_reresolve_closure_locked                                              +53  +883%
  +0.1%     +16 src/core/ext/filters/client_channel/lb_policy/grpclb/grpclb.cc                           +16  +0.1%
      [NEW]    +801 build_lb_channel_args(grpc_lb_addresses const*, grpc_fake_resolver_response_generato    +801  [NEW]
      [NEW]    +303 update_lb_connectivity_status_locked                                                    +303  [NEW]
      [NEW]    +210 extract_backend_addresses_locked(grpc_lb_addresses const*) [clone .isra.1]              +210  [NEW]
      [NEW]    +162 rr_on_connectivity_changed_locked                                                       +162  [NEW]
      [NEW]    +145 lb_call_data_shutdown(glb_lb_policy*) [clone .isra.3]                                   +145  [NEW]
      [NEW]    +141 rr_on_reresolution_requested_locked                                                     +141  [NEW]
      +6.2%     +64 glb_create                                                                               +64  +6.2%
      +2.5%     +16 lb_on_server_status_received_locked                                                      +16  +2.5%

 -------------- SHRINKING                                                                            --------------
  -2.1%    -112 src/core/ext/filters/client_channel/lb_policy/pick_first/pick_first.cc                  -112  -2.1%
      [DEL]    -138 start_picking_locked(pick_first_lb_policy*) [clone .isra.1]                             -138  [DEL]
      [DEL]    -112 pf_set_reresolve_closure_locked                                                         -112  [DEL]
      [DEL]     -89 destroy_unselected_subchannels_locked(pick_first_lb_policy*) [clone .isra.2]             -89  [DEL]
  -1.8%    -112 src/core/ext/filters/client_channel/lb_policy/round_robin/round_robin.cc                -112  -1.8%
      [DEL]    -112 rr_set_reresolve_closure_locked                                                         -112  [DEL]
      [DEL]    -105 start_picking_locked(round_robin_lb_policy*) [clone .isra.1]                            -105  [DEL]

 -+-+-+-+-+-+-+ MIXED                                                                                +-+-+-+-+-+-+-
  +0.0%      +3 [None]                                                                               -1.18Ki  -0.0%
      -9.1%      -8 glb_lb_policy_vtable                                                                      -8  -9.1%
      -9.1%      -8 pick_first_lb_policy_vtable                                                               -8  -9.1%
      -9.1%      -8 round_robin_lb_policy_vtable                                                              -8  -9.1%

  -0.0%    -160 TOTAL                                                                                -1.34Ki  -0.0%

****************************************************************

libgrpc++.so

     VM SIZE        FILE SIZE
 ++++++++++++++  ++++++++++++++

  [ = ]       0        0  [ = ]

[trickle] No significant performance differences

Corrupt JSON data (indicates timeout or crash):
    bm_fullstack_streaming_pump.BM_PumpStreamServerToClient_SockPair__8.opt.old: 1
    bm_fullstack_streaming_pump.BM_PumpStreamServerToClient_SockPair__8.counters.new: 1

[microbenchmarks] No significant performance differences

Reviewed 1 of 1 files at r29.
Review status: all files reviewed at latest revision, 5 unresolved discussions, some commit checks failed.

src/core/ext/filters/client_channel/lb_policy/grpclb/grpclb.cc, line 757 at r29 (raw file):

  // Handle the re-resolution request using glb's original re-resolution
  // closure.
  if (glb_policy->lb_calld == nullptr ||

Please add a comment here explaining that we only want to do a re-resolution if we're not talking to a balancer, because otherwise we expect to get updated addresses from the balancer.

src/core/ext/filters/client_channel/lb_policy/grpclb/grpclb.cc, line 855 at r29 (raw file):

    return;
  }
  GPR_ASSERT(glb_policy->rr_connectivity_state != GRPC_CHANNEL_SHUTDOWN);

These assertions don't really buy us anything, because none of the code below requires these constraints, so let's just remove them.

Please add a comment here explaining that we only want to do a re-resolution if we're not talking to a balancer, because otherwise we expect to get updated addresses from the balancer.

Done.

src/core/ext/filters/client_channel/lb_policy/grpclb/grpclb.cc, line 855 at r29 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
These assertions don't really buy us anything, because none of the code below requires these constraints, so let's just remove them.

Done.
Do we add assertions only when the code below require them? I think it's also helpful (e.g., for debugging) to assert some expectations at some points even when the code below don't rely on them.

Comments from Reviewable

[trickle] No significant performance differences

[microbenchmarks] No significant performance differences

Reviewed 1 of 1 files at r30.
Review status: all files reviewed at latest revision, 4 unresolved discussions, some commit checks failed.

src/core/ext/filters/client_channel/lb_policy/grpclb/grpclb.cc, line 855 at r29 (raw file):
Previously, AspirinSJL (Juanli Shen) wrote…
Done.
Do we add assertions only when the code below require them? I think it's also helpful (e.g., for debugging) to assert some expectations at some points even when the code below don't rely on them.

Whenever you add an assertion, you are essentially adding a dependency on some external input whose value you are constraining.  This dependency comes with a cost, because it means that if we ever change the external input such that it can be set to a value that the assertion is preventing, we need to remember to change the assertion -- and we might not even know where the assertion is when we change the external code.  As a result, you should only add assertions if the benefit you get from the assertion outweighs the overhead of adding that dependency.
If you are writing code that is actually using an input but you are not expecting to ever receive certain values and it would unnecessarily complicate things to handle those values, then it makes sense to add an assertion, so that you blow up with a useful message before you get to code that was not written to handle the value (thus resulting in undefined behavior).  In that situation, the assertion adds value (avoiding undefined behavior) and doesn't really add any cost, because if the calling code ever changed such that the assertion would fail, the code protected by the assertion would have needed to change anyway.  In other words, in this case, the code already depends on the external code that provides the value, so the fact that the assertion is there doesn't add a new dependency.
In contrast, if you are writing code that does not actually care about the value that you are asserting on, the assertion does add a dependency without actually providing any significant value, so it's best to avoid it.

Comments from Reviewable

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

src/core/ext/filters/client_channel/lb_policy/grpclb/grpclb.cc, line 855 at r29 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
Whenever you add an assertion, you are essentially adding a dependency on some external input whose value you are constraining.  This dependency comes with a cost, because it means that if we ever change the external input such that it can be set to a value that the assertion is preventing, we need to remember to change the assertion -- and we might not even know where the assertion is when we change the external code.  As a result, you should only add assertions if the benefit you get from the assertion outweighs the overhead of adding that dependency.
If you are writing code that is actually using an input but you are not expecting to ever receive certain values and it would unnecessarily complicate things to handle those values, then it makes sense to add an assertion, so that you blow up with a useful message before you get to code that was not written to handle the value (thus resulting in undefined behavior).  In that situation, the assertion adds value (avoiding undefined behavior) and doesn't really add any cost, because if the calling code ever changed such that the assertion would fail, the code protected by the assertion would have needed to change anyway.  In other words, in this case, the code already depends on the external code that provides the value, so the fact that the assertion is there doesn't add a new dependency.
In contrast, if you are writing code that does not actually care about the value that you are asserting on, the assertion does add a dependency without actually providing any significant value, so it's best to avoid it.

Thanks for explaining!
If we don't have the assertions here, is there any other way to check that the RR never changes to IDLE state? Or do we want to check that?

Comments from Reviewable

****************************************************************

libgrpc.so

     VM SIZE                                                                                FILE SIZE
 ++++++++++++++ GROWING                                                                              ++++++++++++++
  +9.1%     +45 src/core/ext/filters/client_channel/lb_policy.cc                                         +45  +9.1%
      +883%     +53 grpc_lb_policy_set_reresolve_closure_locked                                              +53  +883%

 -------------- SHRINKING                                                                            --------------
  -0.0%    -117 [None]                                                                               -1.26Ki  -0.0%
      -0.0%     -93 [Unmapped]                                                                           -1.24Ki  -0.0%
      -9.1%      -8 glb_lb_policy_vtable                                                                      -8  -9.1%
      -9.1%      -8 pick_first_lb_policy_vtable                                                               -8  -9.1%
      -9.1%      -8 round_robin_lb_policy_vtable                                                              -8  -9.1%
  -2.1%    -112 src/core/ext/filters/client_channel/lb_policy/pick_first/pick_first.cc                  -112  -2.1%
      [DEL]    -138 start_picking_locked(pick_first_lb_policy*) [clone .isra.1]                             -138  [DEL]
      [DEL]    -112 pf_set_reresolve_closure_locked                                                         -112  [DEL]
      [DEL]     -89 destroy_unselected_subchannels_locked(pick_first_lb_policy*) [clone .isra.2]             -89  [DEL]
  -1.8%    -112 src/core/ext/filters/client_channel/lb_policy/round_robin/round_robin.cc                -112  -1.8%
      [DEL]    -112 rr_set_reresolve_closure_locked                                                         -112  [DEL]
      [DEL]    -105 start_picking_locked(round_robin_lb_policy*) [clone .isra.1]                            -105  [DEL]
  -0.7%     -96 src/core/ext/filters/client_channel/lb_policy/grpclb/grpclb.cc                           -96  -0.7%
      [DEL]    -801 build_lb_channel_args(grpc_lb_addresses const*, grpc_fake_resolver_response_generato    -801  [DEL]
      [DEL]    -303 update_lb_connectivity_status_locked                                                    -303  [DEL]
      [DEL]    -210 extract_backend_addresses_locked(grpc_lb_addresses const*) [clone .isra.2]              -210  [DEL]
      [DEL]    -145 lb_call_data_shutdown(glb_lb_policy*) [clone .isra.4]                                   -145  [DEL]
      [DEL]    -143 glb_set_reresolve_closure_locked                                                        -143  [DEL]
      [DEL]     -98 on_rr_connectivity_changed_locked                                                        -98  [DEL]
      -2.6%     -40 rr_handover_locked(glb_lb_policy*) [clone .part.17]                                      -40  -2.6%
      -3.9%     -32 glb_shutdown_locked                                                                      -32  -3.9%
      -2.2%     -16 glb_update_locked                                                                        -16  -2.2%
      -3.0%     -13 [Unmapped]                                                                               -13  -3.0%
      -2.0%      -8 glb_pick_locked                                                                           -8  -2.0%
      -7.4%      -8 glb_ping_one_locked                                                                       -8  -7.4%
      -2.9%      -8 glb_lb_channel_on_connectivity_changed_cb                                                 -8  -2.9%
      -3.5%      -7 glb_destroy                                                                               -7  -3.5%
     -25.0%      -3 glb_check_connectivity_locked                                                             -3 -25.0%
     -25.0%      -3 glb_notify_on_state_change_locked                                                         -3 -25.0%

  -0.0%    -392 TOTAL                                                                                -1.53Ki  -0.0%

****************************************************************

libgrpc++.so

     VM SIZE        FILE SIZE
 ++++++++++++++  ++++++++++++++

  [ = ]       0        0  [ = ]

[trickle] No significant performance differences

[microbenchmarks] No significant performance differences

Anyway, it's so green, let's ship it!

If we don't have the assertions here, is there any other way to check that the RR never changes to IDLE state? Or do we want to check that?

I don't think this is something we need to check for.  In general, we should have tests that cover the behavior of RR, but it's hard to write tests for the absence of a behavior, unless there are specific conditions under which the code is likely to exhibit that behavior (and I don't think there are in this case).


Add Method to Check if File Exsits

Right now best I can see is to use stat and check error case.

+1

@cancan101 @fov42550564 I will implement this feature shortly as it is a quick win.

+1

+1

any workaround this?

fs.readdir on the containing directory is the way to go ;)

+1

This was recently merged in https://github.com/johanneslumpe/react-native-fs/pull/48.

@johanneslumpe Sorry for being inactive for a while. I merged in a pull request for this feature a couple of weeks ago. My test app shows this working so it might be worth doing another NPM release when you get a moment. Thanks

Published with 1.3.0


UI - Miniscript Vault

Task Breakdown
Implement UI, for Miniscript, corresponding to the UX provided under #4008
Dependencies

#4008

Closing as outdated


Fail on run powershell: deploy

Get error message on powershell: Resource Microsoft.Web/sites/sourcecontrols 'mydriving-ypgf7j2agcno/web' failed with message 'The resource operation completed with terminal provisioning state 'Failed'.'
I think the webapp name (mydriving-.../web) is not a valid name. any sugesstion ?
Kevin Kao

Hi KevinKao809, this could be a transient error. The name should be fine. Can you please open the resource group on Azure Portal, open its Deployments history and get the detailed error message there?

A fix has just been merged to fix this bug. Please try again.

Haishi,
Get these two updated json files and re-deploy, but still get same issue.
Kevin Kao

+1

Hi @KevinKao809 / @jainr,
Can you verify if the mobile app's application settings contain a setting named "Project" and that its value is "src/MobileAppService/MyDrivingService/MyDrivingService.csproj". If not, can you delete the mobile app and run the deployment script again.
If you're still having trouble after redeploying, can you include a detailed error message. You can find it in the Azure portal, under the Deployments blade of the resource group.
Thanks


The provided Linux package is missing the openal and FLAC libraries

Prerequisite Checklist

[X] I searched for existing issues to prevent duplicates
[X] I searched for existing discussions on the forum to prevent duplicates
[X] I am here to report an issue and not to just ask a question or look for help (use the forum or Discord instead)

Describe your issue here
The provided Linux package is missing the openal and FLAC libraries
Your Environment
Ubuntu 22.04
Steps to reproduce
。
Expected behavior
I can choose to install manually:
sudo apt-get install libflac-dev
sudo apt-get install libopenal-dev

However, this version was uncertain and I was forced to use SFM 2.5.1 because Ubuntu 22.04 executed the command to install packages that did not meet SFM2.6.1 requirements.
I'm curious why these two dependencies are not packaged together with the provided release, which is exactly what windows does.
Actual behavior
。

The SFML team is not involved in how SFML is packaged for Debian. I think this is something you will have to take up with the Debian maintainers.

But isn't that the release you provided? I downloaded it from you guys.

I assume this was regarding the pre-built binary package, which isn't clear since the reproduction step were left empty.
We recommend to install system dependencies on Linux and thus wouldn't ship it.

Why does the windows version have these two dependencies?

Because Windows doesn't have a central package manager, so users have no way to get these libraries in a standard way.
With SFML 3 we aim to build dependencies from source by default, except on Linux where this option is still opt-in, as using system dependencies is still the recommended way.
For Linux we generally recommend either using SFML provided by the OS package manager or build from source, as all the different Distros and Distro versions makes it near impossible to ship universally compatible binaries.


[CSE-236] Search by time is not working

https://issues.serokell.io/issue/CSE-236

So now we have working epoch paging and we get the epoch page number.
Tested on mainnet works fine.
Missing just the frontend changes.

Tested on mainnet with the frontend changes, all seems good.
Fast & nice.

@ksaric, even before I review the changes I have to say that we must write a migration, because currently the node is compiled with Explorer by default — and hence all our users have a copy of Explorer DB, which will be invalidated by your changes and most likely render their installations broken.

@Pastafarianist I didn't expect that. But wait, don't we run cardano-node-simply only? Ah, yes, the format is incompatible any way you put it.
@akegalj I will start with this ASAP :disappointed:

Tested 4 times.
CPU/memory usage seems fine.
There is a (small) issue which I don't consider critical.
The first page of the 1. epoch has 9 instead of 10 elements.
I'm guessing this is somehow connected to splitEvery, but not sure why. I presume it's because the number of blocks is uneven and it's being reflected on the first page. I think it's not ordering.
It should work fine. For example:
Prelude> filter ((/= 10) . length) $ splitEvery 10 [0..21599]
[]

Prelude> filter ((/= 10) . length) $ splitEvery 10 [0..21598]
[[21590,21591,21592,21593,21594,21595,21596,21597,21598]]

I tested it using this wonderful new recipe:

checkout cardano-sl-1.0
build it using stack
run on mainnet
let it sit for a while, say ~15 minutes (that's how much it takes to sync the mainnet blockchain nowadays)
add caffeine (optional)
go to http://localhost:8100/api/search/epoch/0?slot=1
checkout ksaric/CSE-236-mainnet
build it using stack
run on mainnet
hold your breath and cross your fingers (wearing your lucky clothes)
go to http://localhost:8100/api/epochs/0
admire

The whole recipe step-by-step:
git checkout cardano-sl-1.0
stack build --fast -j4
./scripts/clean/db.sh
./scripts/launch/connect-to-cluster/explorer-mainnet.sh

Then you wait and:
git checkout ksaric/CSE-236-mainnet
stack build --fast -j4
./scripts/clean/db.sh
./scripts/launch/connect-to-cluster/explorer-mainnet.sh

To be squashed, since it contains a lot of irrelevant commits.

Before we had mappings Epoch -> [HeaderHash].
Now we have mappings (Epoch, Page) -> [HeaderHash].
The old key is "e/epoch/" <> serialize' epoch.
The new key is "e/epochs/" <> serialize' epoch <> "/" <> (serialize' $ UnsignedVarInt page).
We can summarize this migration as a function - (Epoch, [HeaderHash]) -> ((Epoch,Page), [HeaderHash]) where we switch from 21600 HeaderHashes we had to 10 per page, per epoch.
We use Conduit since we don't want to load everything into memory at once.

Obviously we'll also need to fix up the conflicts and make the CI pass too.

Fixed merge conflicts.
I run it afterward on the mainnet. Waited until it was synced and tested using the explorer frontend, which seems good to me.

From @fersel:
Not yet to be merged (we have staging but not mainnet deployed, during this "window" we can't merge anything to release branch)


Determine the value of Concurrency support in the language

While it does have cooperative elements via yeilding sub vms, the language has no concept of threads or parallelism.
How might such a thing be possible or beneficial in ulox?

At the same time, one of the most time expensive things we have encountered in usage is a verlet sim, which should be embarrassingly parallel, moving all of it to another thread doesn't actually help that much, we want to go wide on the problem immediately.


Cow: Watch osobakehinde.com.ng

Cow requests the watch of the watch_keyword osobakehinde\.com\.ng. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

osobakehinde\.com\.ng has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by Jeff Schaller in Charcoal HQ


Fix compile using gcc13

adding missing header file for lacking std int definitions

Already done with https://github.com/asmaloney/libE57Format/commit/f554fc32f037a101a06e2925604ce4336c498adc

@adrianschroeter Do you have any idea why FreeCAD is not including libE57Format as a submodule?
Without doing so, FreeCAD effectively takes on maintenance of this library and it becomes a hard fork, which duplicates effort (and usually ends up with stale/old code that nobody over there will maintain except to add band-aids like this).


bump warden cpi

see issues https://github.com/cloudfoundry/bosh-deployment/issues/214

latest set of commits bumps bunch of stuff, including to v40 of warden cpi.


ARROW-2812: [Ruby] Fix Arrow::Array#[] interface for Arrow::StructArray

Arrow::StructArray does not have #get_value method, and Arrow::Array#[] interface depends on #get_value method.
And so, StructArray cannot access internal columns via #[] interface.
Error message is following.
NoMethodError: undefined method `get_value' for #<Arrow::StructArray:0x0000000001859ac0>

This patch fixes it.

I've pushed https://github.com/apache/arrow/pull/2233/commits/347687a9688aa2a27782ff2acc9a6f31d100ba03 for fixing macOS build failure on Travis CI.

I fixed an order of require statement and test code readability.
Would you review this again?

It looks good to me but you've removed https://github.com/apache/arrow/commit/347687a9688aa2a27782ff2acc9a6f31d100ba03 ...
Can you add the change again?

Ah, I'll add again and merge this.

CI is passed except https://travis-ci.org/apache/arrow/jobs/402071558 .
It's unrelated and https://github.com/apache/arrow/pull/2237 fixed it.
I'll merge this.

Done. Thanks!


refactor(server): refactor server with async/await

Closing this PR as it has become stale. Feel free to reopen if needed.


[Feature] Enable Source maps for Typescript

Problem
Debugging the compiled code using the browser dev tools can be cumbersome.
Solution
Add sourcemaps in compiler options

Adding this in, just curious, when do you use it? I always end up just using React/Redux DevTools and I never use the regular JS DevTools. (Only for Node).


Reformatting examples in sections 6 and 7

This PR is as much to make sure we're agreed on stylistic changes as
much as anything else.

Just to make sure: We agree on 4 spaces for indentation, correct?

The checks I ran earlier seems to think that would be fine in terms of Word conversion - where there are very long lines (above ~96 characters) there are almost always comments anyway, and we can move those.

(Will just wait for Rex as well.)

@jskeet I wasn't listed as a reviewer, but your message suggested you were waiting on me, so I added myself and approved this.

Whoops - thanks Rex. Yes, I misread the suggested reviewers.


Last test on js calculator should give a different result

Affected page
JS Calculator
Expected behavior
5 * - + 5 = 25
Additional context
User Story #13: If 2 or more operators are entered consecutively, the operation performed should be the last operator entered (excluding the negative (-) sign). For example, if 5 + * 7 = is entered, the result should be 35 (i.e. 5 * 7); if 5 * - 5 = is entered, the result should be -25 (i.e. 5 * (-5)).
Last test calculates 5 * - + 5 = 10. In the demo calculator when you hit + it removes * and - . I was testing several calculators, all works different but results are always 25 or -25:
Galculator: 5 x - + 5 = 5 x + 5 = 25
google: 5 x - + 5 = 5 x - (+ 5) = -25
I think this should be changed or place a user story which explains this point on why should give 10 and not 25 0r -25

I think this test is fine.

If 2 or more operators are entered consecutively, the operation performed should be the last operator entered (excluding the negative (-) sign)

If you remove all but the last operator, you get 5 + 5 = 10.
We don't want to send users down the route of the complex parsing that Google is attempting to do.

I think the gnome calculator is more accurate, when you hit more than 2 operators the last one is changed. But in the demo 2 operators change, the last "+" removes "-" and "*".
Anyway what happens after you submit the challenges on FCC? I can edit my code just to pass the tests and then edit it again?

But in the demo 2 operators change, the last "+" removes "-" and "*".

I wouldn't describe it that way. In the demo when multiple operations are pressed, only the last one is used.
I could be wrong, but as I understand the intent, are three cases:

One operation is used => call that operation

Two operations are used AND the last one is - => call the first operation, using the - as a negative sign

More than two operations are used OR two operations are used and the last one is not a - => use the last one

This is far simpler than the 'proper' logic, but intentionally so.

If you submit a project you are asserting that it passes all tests. If you want to make an extended version of the project with different behavior, personally I'd keep that separate from the certification version.

To me the real problem is that when adhering to the minimum specs of the project, the - button is pulling double duty as a regular - arithmetic button and a +/- button.
This creates some weird cases.
5 * - 5 is evaluated as 5*(-5).
5 * - + 5 is evaluated as 5+5.
5 * / - 5 is evaluated as 5/(-5).
Requiring students to make separate - and +/- buttons is probably not a good idea as they would then need to implement their own math because it introduces cases that eval() doesn't know how to deal with, such as eval(1--1).
In the end I agree with @jeremylt that 5 * - + 5 = 10 is correct behaviour given the current constraints and any changes to the challenge would only make it more confusing.

5 * / - 5 is evaluated as 5/(-5).

I don't know if this is accurate or not. It's not a tested condition to have both a extraneous operator and a negative sign, so I don't know if that is a case user calculators are supposed to handle in specific way.
I think 'easy to use eval' probably shouldn't be an argument in any direction since use of eval is discouraged.

User Story #13: If 2 or more operators are entered consecutively, the operation performed should be the last operator entered (excluding the negative (-) sign). For example, if 5 + * 7 = is entered, the result should be 35 (i.e. 5 * 7); if 5 * - 5 = is entered, the result should be -25 (i.e. 5 * (-5)).

I believe this user story fully describes the intended behaviour for multiple arithmetic operators. Maybe it's worth to clarify by adding an example that has 3 operators with the last one being '-'?

Thank you for reporting this issue.
This is a standard message notifying you that this issue has been discussed and we have concluded no fix is necessary at this time.
If you think we're wrong in closing this issue, please request for it to be reopened and add further clarification. Thank you and happy coding.


two table join in flink sink to clickhouse, update old data in mysql,  it will delete this row in clickhouse and no insert

I want use flink cdc sql  create a wide table(sink_ck)  in clickhouse,  when I create two or more then two flink cdc source table from mysql , such as tb1 ,tb2.
I submit to a job in flink-client  :
insert into sink_ck SELECT a.*,b.order_name  FROM  tb1 a LEFT JOIN tb2  b ON a.order_id = b.order_id
when tb1 row datas is update  in mysql , the row will be delete in sink_ck , why ?
I want   tb1 row datas is update  in mysql ,this row datas same update in clikchouse.
one table use flink cdc sink to clickhouse , insert \ update\ delete is No problem!
one table update is ok, message :
INSERT INTO ck_order(id, order_id, merchant_code, merchant_name, create_time, update_time)  FORMAT TabSeparated
INSERT INTO ck_order(id, order_id, merchant_code, merchant_name, create_time, update_time)  FORMAT TabSeparated
ALTER TABLE flink.ck_order UPDATE order_id='20042100002', merchant_code='BU0000000002YGP', merchant_name='广州2贸易有限公司_2', create_time='2021-04-21 10:41:22', update_time='2022-04-25 10:33:58' WHERE id=2
ALTER TABLE flink.ck_order UPDATE order_id='20042100002', merchant_code='BU0000000002YGP', merchant_name='广州2贸易有限公司_2', create_time='2021-04-21 10:41:22', update_time='2022-04-25 10:33:58' WHERE id=2
wide table update ,it is delete, no alter table update:
INSERT INTO ck_order_detail(id, order_id, merchant_code, merchant_name, create_time, update_time, order_name)  FORMAT TabSeparated
INSERT INTO ck_order_detail(id, order_id, merchant_code, merchant_name, create_time, update_time, order_name)  FORMAT TabSeparated
ALTER TABLE flink.ck_order_detail DELETE WHERE id=2
ALTER TABLE flink.ck_order_detail DELETE WHERE id=2

Is there any delete event generated by FlinkCDC?
On the sink side, only records of RowKind.DELETE type will convert to delete SQL.
Refer to:https://github.com/itinycheng/flink-connector-clickhouse/blob/master/src/main/java/org/apache/flink/connector/clickhouse/internal/executor/ClickHouseUpsertExecutor.java

我也遇到了同样的问题，用jdbc-connector sink到mysql是没问题的，用itinycheng/flink-connector-clickhouse sink到clickhouse时，在mysql中update左表的数据，在clickhouse被delete掉了。

@zidane-wcp @xuanzhi201111
This seems caused by the order of statement execution, execution order: insert -> update -> delete, refer to: ClickHouseUpsertExecutor.executeBatch.
Check whether option sink.ignore-delete is ture, this conf will prevent the generation of delete statements.

@itinycheng
Thank you for your reply.  I tried with option sink.ignore-delete and it does not works.  I modified the ClickHouseUpsertExecutor.executeBatch. It seems to solve my problem now, but I don't know if it will cause other problems.
    @Override     public void executeBatch() throws SQLException {         for (ClickHousePreparedStatement clickHousePreparedStatement :                 Arrays.asList(deleteStmt, insertStmt, updateStmt)) {             if (clickHousePreparedStatement != null) {                 attemptExecuteBatch(clickHousePreparedStatement, maxRetries);                 LOG.error("executeBatch===========================================================");                 LOG.error(clickHousePreparedStatement.asSql());             }         }     }

我也遇到了同样的问题，用jdbc-connector sink到mysql是没问题的，用itinycheng/flink-connector-clickhouse sink到clickhouse时，在mysql中update左表的数据，在clickhouse被delete掉了。

能把你的clickhouse连接器的jar包发给我测试一下吗？<EMAIL_ADDRESS>，我不会代码，不知道怎么修改。

@itinycheng Thank you for your reply. I tried with option sink.ignore-delete and it does not works. I modified the ClickHouseUpsertExecutor.executeBatch. It seems to solve my problem now, but I don't know if it will cause other problems.  @Override public void executeBatch() throws SQLException { for (ClickHousePreparedStatement clickHousePreparedStatement : Arrays.asList(deleteStmt, insertStmt, updateStmt)) { if (clickHousePreparedStatement != null) { attemptExecuteBatch(clickHousePreparedStatement, maxRetries); LOG.error("executeBatch==========================================================="); LOG.error(clickHousePreparedStatement.asSql()); } } }

@zidane-wcp This is simply a statement execution order problem and the actual data order has been lost in a batch; No matter how to change the order, the problem will not be completely solved. I also have no better way to slove this at the connector side currently.

作者，你好，你能把@zidane-wcp的修改合到进代码里吗，这样通过flinkcdc 把mysql关联后的宽表写到CK，修改也能正常同步了。

@itinycheng Thank you for your reply. I tried with option sink.ignore-delete and it does not works. I modified the ClickHouseUpsertExecutor.executeBatch. It seems to solve my problem now, but I don't know if it will cause other problems.  @Override public void executeBatch() throws SQLException { for (ClickHousePreparedStatement clickHousePreparedStatement : Arrays.asList(deleteStmt, insertStmt, updateStmt)) { if (clickHousePreparedStatement != null) { attemptExecuteBatch(clickHousePreparedStatement, maxRetries); LOG.error("executeBatch==========================================================="); LOG.error(clickHousePreparedStatement.asSql()); } } }

@zidane-wcp 能把你的clickhouse连接器的jar包发给我测试一下吗？<EMAIL_ADDRESS>，我不会代码，不知道怎么修改。

@itinycheng Thank you for your reply. I tried with option sink.ignore-delete and it does not works. I modified the ClickHouseUpsertExecutor.executeBatch. It seems to solve my problem now, but I don't know if it will cause other problems.  @Override public void executeBatch() throws SQLException { for (ClickHousePreparedStatement clickHousePreparedStatement : Arrays.asList(deleteStmt, insertStmt, updateStmt)) { if (clickHousePreparedStatement != null) { attemptExecuteBatch(clickHousePreparedStatement, maxRetries); LOG.error("executeBatch==========================================================="); LOG.error(clickHousePreparedStatement.asSql()); } } }

@zidane-wcp This is simply a statement execution order problem and the actual data order has been lost in a batch; No matter how to change the order, the problem will not be completely solved. I also have no better way to slove this at the connector side currently.

作者，你好，你能把@zidane-wcp的修改合到进代码里吗，这样通过flinkcdc 把mysql关联后的宽表写到CK，修改也能正常同步了。

您好，这个代码并没真正解决乱序问题，所以不能合并；
你可以直接直接用上边的代码将ClickHouseUpsertExecutor.executeBatch覆盖一下即可，这只是一个执行顺序的调整；

@xuanzhi201111 @zidane-wcp
修复了个sink.ignore-delete配置不生效的问题，应该能通过不生成delete来解决当前问题；https://github.com/itinycheng/flink-connector-clickhouse/commit/06d0aedb1cb606d85cb328f4bbe6befd0892d4ca


Add install.sh to install Chaos Mesh

What problem does this PR solve?
add a quick script to install kind local Kubernetes and chaos-mesh #192
What is changed and how does it work?
we can use install.sh -l kind to install Helm Kind Kubernetes and Chaos Mesh
$ ./install.sh -h
This script is used to install chaos-mesh.
Before running this script, please ensure that:
* have installed docker if you run chaos-mesh in local.
USAGE:
    install.sh [FLAGS] [OPTIONS]
FLAGS:
    -h, --help              Prints help information
OPTIONS:
    -v, --version           Version of chaos-mesh, default value: latest
    -l, --local [kind]      Choose a way to run a local kubernetes cluster, supported value: kind,
                            If this value is not set and the Kubernetes is not installed, this script will exit with 1.
    -n, --name              Name of Kubernetes cluster, default value: kind
        --kind-version      Version of the Kind tool, default value: v0.7.0
        --node-num          The count of the cluster nodes,default value: 6
        --k8s-version       Version of the Kubernetes cluster,default value: v1.12.8
        --volume-num        The volumes number of each kubernetes node,default value: 9
        --helm-version      Version of the helm tool, default value: v2.16.1
        --release-name      Release name of chaos-mesh, default value: chaos-mesh
        --namespace         Namespace of chaos-mesh, default value: chaos-testing

Check List
Tests

Manual test (add detailed scripts or steps below)

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@4985de5). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #217   +/-   ##
=========================================
  Coverage          ?   43.64%
=========================================
  Files             ?       18
  Lines             ?      685
  Branches          ?        0
=========================================
  Hits              ?      299
  Misses            ?      353
  Partials          ?       33

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4985de5...60328f0. Read the comment docs.

I think providing the way to install chaosmesh by several simple yaml files is helpful enough for users to get a first quick trial. We don't need to set up a local Kubernetes cluster.
Here are some examples:
https://knative.dev/docs/install/knative-with-any-k8s/#installing-knative
https://istio.io/docs/setup/install/helm/#option-1-install-with-helm-via-helm-template
https://cert-manager.io/docs/installation/kubernetes/#installing-with-regular-manifests

@Yisaer Sometimes users do not have a Kubernetes cluster directly available. I think local Kubernetes is also needed for chaosmesh. we can use this scripts by the following commands
./install.sh # install chaos-mesh without local Kubernetes
./install.sh --local kind # install chaos-mesh with a local kind Kubernetes

We provides helm files to install chaosmesh and this scripts just to help users to simplify the installation steps， like: install helm / kind / local kubernetes

I will pull a single pr to update README.md and document.

I will add --force flag to control whether to force reinstall chaos-mesh.

@YangKeao @zhouqiang-cl @mahjonp PTAL again, thanks!

@mahjonp @zhouqiang-cl PTAL again! thanks!


Getting the geolocation value periodically

Hi Chris,
This is an awesome plugin. works great. just wondering about a small issue that I am facing with my app. I see that the plugin records the geolocation based on the distance calculation.
(round(speed, 5))^2 + distanceFilter
I understand this is to save the battery but my requirement is to catch the location coords after every 20 minutes (user stationary or moving does not matter). Is it possible in this plugin somehow. Is there a workaround to achieve this with your code.
P.S. : I am pretty new to cordova and I am just consuming you plugin through js code. No idea regarding any changes in the java classes.
Thanks in Advance,
Cheers,
Deepak

The premium version has a config disableElasticity.
No you cannot update the location every 20 minutes.  Geolocation APIs don't
work on timers -- they work on distance travelled.
If you want to know where someone is every 20 min, your server can send a
silent push notification to them.
On Wednesday, May 13, 2015, deepak014<EMAIL_ADDRESS>wrote:

Hi Chris,
This is an awesome plugin. works great. just wondering about a small issue
that I am facing with my app. I see that the plugin records the geolocation
based on the distance calculation.
(round(speed, 5))^2 + distanceFilter
I understand this is to save the battery but my requirement is to catch
the location coords after every 20 minutes (user stationary or moving does
not matter). Is it possible in this plugin somehow. Is there a workaround
to achieve this with your code.
P.S. : I am pretty new to cordova and I am just consuming you plugin
through js code. No idea regarding any changes in the java classes.
Thanks in Advance,
Cheers,
Deepak
—
Reply to this email directly or view it on GitHub
https://github.com/christocracy/cordova-plugin-background-geolocation/issues/180
.

--
Snet from Gmail Mobile

Thanks:)
will try the same and let you know
Regards,
Deepak


I'd like to have a function call back for updating progress

For example, I'd like to pass a function pointer to the cppOpt so that I can let users know the progress if the optimisation takes time.

I think you should be able to do so by putting such logic into your calculate method. Since this is called with every step.

My understanding is that the calculate method is the  cost function.  Taken Simulated Annealing for example, the caller does not know how many iterations have been completed.

Each call to calculate would be one iteration. Sho you could simply increment a counter within the method. So you could write a MySolverWithProgressLogging

Can you resolve the issue this way?

I'll close this for now, feel free to reopen it, if you still need help

Hi, thanks for the info.
However, wouldn't it be more logical that a method is provided to return the progress?
A counter can be placed inside the calculate, but that value needs to be divided by the total number of iterations, which again needs to be exposed somewhere, but still not so straightforward.

The issue is that the more logic I add, the more expensive the optimization gets. I had some thoughts about changing the lib in the future and I'd like to make it even more lightweight.
Some users might optimize problems where each calculation takes > 100ms or even seconds / minutes. There these overheads aren't really an issue.
But with fast calculations, which are e.g. presented within the examples, the overhead of the optimization can get very severe.
I think adding e.g. MySolverWithProgressLogging or similar extended base calculators might help here.
The library users could choose the fastest optimization or plug some of the more informative / useful calculators in.

I'll reopen this issue as reference for future changes to the library. But for now I'd suggest extending the calculate method to one's needs

I now refactored the library, and still think it's best to extend the calculation function to track the progress. See the example with logging added to the calculate function. Tracking the progress can be done in a similar way.


Remove references to permit price being calculated from vehicle details

Addresses #266 to give the option of a custom price logic. Will do some more work around this once we have councils fill in what their pricing logic is.
You can switch between the Before/After states on this PR by removing the customPriceLogic option for Argleton in councils.json, or by changing to any other council which doesn't have that variable on /council-picker.
Before

After

Now that the price depends on the boundary, I assume that the permit doesn't allow users to park anywhere within the city centre?

@anthonylord Yep, good catch - Will change that
Also to do: Remove DVLA lookup details for this option.

@kaydale Ready!


#4487: Adding Upsample Op. Raising PR for compute kernel Colloboration

#4848 Implementation  Details.

The op takes NHWC as input and scale as parameter.(scale should be int 2 dim).
Only supporting nearest mode other modes are not supported.
Tested with the random input with the shape provided using purest
added single core version.
Some details regarding Kernel.
N should be 1.

Reader just copies the data in channel format.(small channel size may have issues.)
All of the heavy lifting work is done by writer.
I have added two for loops (scale_h and scale_w) for writer to copy the data to appropriate sticks.

don't think you meant to bump UMD submodule version in this PR

yeah.. It came as when I was rebasing my changes with mainline. Will see how to remove It or create a fresh PR.


use unsafeBytesToString to reuse memory

I found that some operations are very expensive about mem alloc when string(bytes).
Such as:

So I try to reuse some mems by using unsafe.

Just for the record, this is done inside standard library as well: https://go.dev/src/strings/builder.go#L46

Although there will be soon official public API to do this: https://github.com/golang/go/issues/53003


metrics UI graphs don't update when there is no data coming in

"I realized that once the processing has finished, the graph and number stay at “last 5 mins” -> which is basically not true because the application is not running anymore. If it is last 5 mins of application then yes but it can be [confusing]"

This is addressed in #1193.


fix

Suggestion
Hey there! This is just a quick little suggestion i sketched out earlier.
But how would I do that? you may ask

idk, its ur bot.
fix it.

fix your bot
😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡

Fix, when?

Yes ^ i agree with mat plz fix it !

it's fixed

still not fixed

still not fixed

^

still not fixed

^

^

^

still not fixed

^

^

^

^ seems like the bot is slowly dying. Sad.

still not fixed

^

^

^

^ seems like the bot is slowly dying. Sad.

It's dead now. Big sad

bots down now

🦀 workers rewrite is dead 🦀

fix?

fix?


Superset returns an internal server error when there are duplicated calculated column names

Superset returns an internal server error when there are duplicated calculated column names
Expected results
No 5xx
Actual results
5xx
Screenshots

How to reproduce the bug
While recently creating a new set of calculated columns I forgot to change the name from the default of  for all the fields. While attempting to save this, I wound up getting an internal server error on the front end which mapped to a "Duplicate entry '-77284' for key 'uq_table_columns_column_name'" internally.
It would be nice if that exception was caught or a specific error message surfaced so that people knew what they did wrong.
Environment

superset version: master
python version: 3.6
node.js version: 8.6

Checklist
Make sure these boxes are checked before submitting your issue - thank you!

[x] I have checked the superset logs for python stacktraces and included it here as text if there are any.
[x] I have reproduced the issue with at least the latest released version of superset.
[x] I have checked the issue tracker for the same issue and I haven't found one similar.

I'll take this one!


Update depenencies for better colab experience

Before submitting (must do checklist)

[x] Did you read the contribution guide?
[x] Did you update the docs? We use Numpy format for all the methods and classes.
[x] Did you write any new necessary tests?
[ ] Did you update the CHANGELOG?

Proposed Changes

Update holidays library dependency
Update scipy library dependency
Update torch library dependency

There was a problem with saving MLP and RNN with dill, so cloudpickle is used
It still doesn't work on torch-2.0, saving doesn't for nor for cloudpickle, nor for dill

Closing issues
Closes #1266.

Codecov Report

Merging #1268 (670f5e8) into master (0e6d87a) will decrease coverage by 31.84%.
The diff coverage is 0.00%.

:exclamation: Current head 670f5e8 differs from pull request most recent head 695487e. Consider uploading reports for the commit 695487e to get more accurate results

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@             Coverage Diff             @@
##           master    #1268       +/-   ##
===========================================
- Coverage   87.67%   55.84%   -31.84%
===========================================
  Files         186      175       -11
  Lines       10778    10460      -318
===========================================
- Hits         9450     5841     -3609
- Misses       1328     4619     +3291

Impacted Files
Coverage Δ

etna/models/mixins.py
68.37% <0.00%> (-27.89%)
:arrow_down:

etna/settings.py
72.59% <ø> (ø)

... and 124 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

plust Changelog


Run it

Motivation and Context

What has changed

How to test?

Links

Running IT in https://github.com/ONSdigital/rm-actionexporter-service/pull/33


Inclusion of timestamp

Section 2.1.3 indicates that timestamp may be omitted if time information is already included within the encapsulated payload. Section 3.2 states that the header.extend is set to the value of trTsEnable implying that there is no option of omitting the header.timestamp for E-trace if trTsEnable is 1 even for payloads that include a time field. The text in 3.2 further uses terminology such as "an alternative method of providing time". Which interpretation is correct?

I don't see an inconsistency here.  trTsEnable determines whether a timestamp is included in the encapsulation. The references to time being included in the payload relate to optional capabilities included in the E-Trace spec related to time.  These allow for timestamps to be optionally included in all sync packets, and also allow for 'time' packets, though these are not defined beyond this.  If anyone had implemented these capabilities then they may not want to include timestamps in the packet encapsulation as well.

Clarifying the text to state that when trTsEnable is 1, a timestamp may be optionally included and if included the header.extend is set to 1 would suffice.


INFO Maximum call stack size error due to Google

If you encounter
Maximum call stack size of 8339456 bytes (zend.max_allowed_stack_size - zend.reserved_stack_size) reached. Infinite recursion?
It is due to
https://github.com/googleapis/gax-php/issues/584

Thanks for reporting. I've added a bit of info in the troubleshooting section of this package readme. Hopefully it'll get fixed soon.


Slow rendering of PDF with time spent in genericComposeSMask

Attach PDF file here: d2_cheat_sheet.pdf
Configuration:

Web browser and its version: Firefox Nightly 2024-03-25
Operating system and its version: macOS
PDF.js version: ?
Is a browser extension: browser-native

Steps to reproduce the problem:

Load the PDF

What is the expected behavior? It should draw quickly.
What went wrong? It was slow.
Profile: https://share.firefox.dev/49axVfO

The profile shows that all the time is spent waiting for readback in getImageData for genericComposeSMask.
What does genericComposeSMask do? Which APIs would be needed in canvas to allow implementing it on the GPU?

This is probably the same as https://bugzilla.mozilla.org/show_bug.cgi?id=1874013.

See also https://github.com/mozilla/pdf.js/issues/14982#issuecomment-1466141810.

Duplicate of e.g. issue #17779?

Yes!
It seems to be frequent enough that we should prioritize it soon.


PDF: Entrance SDs are wrongly indented at the beginning of scenes

@JackWilton1594 says:
"Some entrance SDD (especially opening SDD) are indented whereas others are flush left. They should all be flush left to align with the SPP. For example AHDM Scene 9."
As far as I can see, SDs at the beginning of a scene are always indented, but those in the middle are not. It's not clear to me whether this was a design feature or is accidental, so I'm asking for consensus on this one before looking for something to change.

Added a fix in rev 19053, although we may reverse this if consensus is not in favour. It's on line 279 of latex_templates_module.xsl.

I'm happy to see all SD in the modern text be aligned flush left. I'm not sure that we intended the opening SD in a scene to be indented.

Assigning back to @martindholmes to implement. Please align all SD in the modern text flush left except for ` which should be aligned right.


Local ./node_modules/.bin should take priority over nvm-selected global .bin

Operating system and version: OSX 11.15.1
nvm debug output:

nvm --version: v0.38.0
$TERM_PROGRAM: iTerm.app
$SHELL: /bin/zsh
$SHLVL: 1
whoami: 'msc'
${HOME}: /Users/msc
${NVM_DIR}: '${HOME}/.nvm'
${PATH}: ${NVM_DIR}/versions/node/v14.17.1/bin:${HOME}/.netlify/helper/bin:./node_modules/.bin:${HOME}/.local/bin:${HOME}/bin:/usr/local/anaconda3/bin:${HOME}/.gem/ruby/2.7.0/bin:/usr/local/opt/ruby/bin:/usr/local/git/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:${HOME}/.composer/vendor/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Applications/VMware Fusion.app/Contents/Public:/Library/TeX/texbin:/Library/Apple/usr/bin:/Library/Frameworks/Python.framework/Versions/3.8/bin
$PREFIX: ''
${NPM_CONFIG_PREFIX}: ''
$NVM_NODEJS_ORG_MIRROR: ''
$NVM_IOJS_ORG_MIRROR: ''
shell version: 'zsh 5.8 (x86_64-apple-darwin20.0)'
uname -a: 'Darwin 20.6.0 Darwin Kernel Version 20.6.0: Wed Jun 23 00:26:31 PDT 2021; root:xnu-7195.141.2~5/RELEASE_X86_64 x86_64'
checksum binary: 'sha256sum'
OS version: macOS 11.5.1 20G80
curl: /usr/local/anaconda3/bin/curl, curl 7.68.0 (x86_64-apple-darwin13.4.0) libcurl/7.68.0 OpenSSL/1.1.1d zlib/1.2.11 libssh2/1.8.2
wget: /usr/local/bin/wget, GNU Wget 1.21.1 built on darwin20.4.0.
sed: /usr/bin/sed
cut: /usr/bin/cut
basename: /usr/bin/basename
rm: /bin/rm
mkdir: /bin/mkdir
xargs: /usr/bin/xargs
git: /usr/local/bin/git, git version 2.32.0
ls: grep:: No such file or directory
grep: grep: aliased to grep --color=auto --exclude-dir={.bzr,CVS,.git,.hg,.svn,.idea,.tox} (grep --color=auto --exclude-dir={.bzr,CVS,.git,.hg,.svn,.idea,.tox}), grep (BSD grep) 2.5.1-FreeBSD
awk: /usr/bin/awk, awk version 20200816
nvm current: v14.17.1
which node: ${NVM_DIR}/versions/node/v14.17.1/bin/node
which iojs: iojs not found
which npm: ${NVM_DIR}/versions/node/v14.17.1/bin/npm
npm config get prefix: ${NVM_DIR}/versions/node/v14.17.1
npm root -g: ${NVM_DIR}/versions/node/v14.17.1/lib/node_modules

nvm ls output:

       v10.23.1
       v10.24.1
       v12.17.0
       v12.19.0
       v12.20.1
       v12.22.1
       v14.15.0
       v14.15.4
       v14.16.1
->     v14.17.1
        v15.0.1
        v15.5.1
        v16.0.0
        v16.1.0
        v16.3.0
         system
default -> node (-> v16.3.0)
iojs -> N/A (default)
unstable -> N/A (default)
node -> stable (-> v16.3.0) (default)
stable -> 16.3 (-> v16.3.0) (default)
lts/* -> lts/fermium (-> v14.17.1)
lts/argon -> v4.9.1 (-> N/A)
lts/boron -> v6.17.1 (-> N/A)
lts/carbon -> v8.17.0 (-> N/A)
lts/dubnium -> v10.24.1
lts/erbium -> v12.22.1
lts/fermium -> v14.17.1

How did you install nvm?

Homebrew
What steps did you perform?
nvm use
What happened?
It prepended $PATH with ${NVM_DIR}/versions/node/v14.17.1/bin.
What did you expect to happen?
It should prepend $PATH with ./node_modules/.bin:${NVM_DIR}/versions/node/v14.17.1/bin.
By not giving the local .bin priority, nvm couples all projects' package version to the globally installed instance rather than the locally installed one. This causes breaking changes.
Is there anything in any of your profile files that modifies the PATH?

No.

It absolutely should not do that - that’s very dangerous and allows node_modules to shadow global binaries, stealing all your secrets.
node never does this by default. Perhaps you’re manually doing this pre-nvm, and are surprised that nvm isn’t replicating this dangerous practice?
(separately, nvm is explicitly unsupported when installed via homebrew; please remove it and reinstall it with the only approved method, the install script in the readme)

I stand corrected. I've been passing my zsh profile from computer to computer for so long, I honestly don't know how long I've had it that way. Thanks!

One more question, actually. Doesn't prepending the global npm bin have the same problem? What prevents it from being a problem?

Global modules are expected to have binaries, and transitive deps’ binaries aren’t available in the path. This isn’t the case with local modules, where a dep 1000 levels deep could suddenly start shipping a cat binary that intercepts every file you cat.

Thanks, this is the part I was missing: "transitive deps’ binaries aren’t available in the path."


Is there a IApplicationLifetime.ServicesStarted??

I need to fire some code after all the IHostedServices have started. Is there a hook for this or can I somehow be sure my IHostedService will get called last?

No, not at the moment.
https://github.com/aspnet/Hosting/blob/c9a4ee8b719ffb01eb44705d68efd158eb80c221/src/Microsoft.AspNetCore.Hosting/Internal/WebHost.cs#L150-L153
You'd have to track some state in a shared service.

We don’t have that event. Today application started fires before hosted services are initialized. When we move to 3.0 we’ll look at restructuring things with the generic host.
For now, if you control the application then just add the hosted service last. There no easy way to guarantee you’re last but it may not matter.

So I have two types of apps, one uses the generic host IHost because it does not need REST and communicates over Kafka the other has REST so it uses IWebHost, this makes things really difficult because the order is different between the two.
I see in WebHost the IApplicationLifetime.ApplicationStarted gets called before any IHostedServices are called.
https://github.com/aspnet/Hosting/blob/release/2.1/src/Microsoft.AspNetCore.Hosting/Internal/WebHost.cs#L150
In Host the IApplicationLifetime.ApplicationStarted gets called after all IHostedServices are called.
https://github.com/aspnet/Hosting/blob/release/2.1/src/Microsoft.Extensions.Hosting/Internal/Host.cs#L51
This seems very inconsistent, can I expect this behavior to change in the future to be more consistent?
What I'm trying to accomplish is to publish metrics to Prometheus of all loaded assemblies and their version number but I want to make sure the application has fully loaded since it does dynamic loading of dlls inside some of the IHostedServices.  Do you know of any better place to hook into?  I don't have full control of the application, I'm just writing the metrics framework that multiple other teams are consuming in their microservices, they make a call to hook metrics into their DI container.

We can look at changing the web host to fire the event after hosted services but that’s a breaking change. We’ll see what it looks like and decide if it’s ok for 2.2 or 3.0.
I’m not sure if you can do much else. All of the workarounds I have are borderline awful and hacky 😬

Thank you for your help!!  If you change asp.net core logic itself to be an IHostedService then that would inherently change the order correct?


Java Track

Attain number one rank in Java Track.

Currently, I'm on Advanced section of Java track.


Run API is  Connection refused

I run api but is error:  Connection refused
And server not display in dashboard. Please help me.

Did you install the OpenTSDB?  If not, here are the step by step instructions: https://github.com/jparicka/cloudly/blob/master/docs/opentsdb.md
Let me know if it helped.


osascript: command not found

[user@localhost Optimized]$ sudo imageOptim -d "/home/Optimized"
/usr/bin/imageOptimBashLib: line 447: osascript: command not found
/usr/bin/imageOptimBashLib: line 451: osascript: command not found
/usr/bin/imageOptim: line 64: osascript: command not found
/usr/bin/imageOptimBashLib: line 455: osascript: command not found
find: unknown predicate `-E'
sort: cannot read: /imageoptim-cli/index.txt: No such file or directory
Running ImageOptim...
/usr/bin/imageOptimBashLib: line 490: osascript: command not found
/usr/bin/imageOptimBashLib: line 492: osascript: command not found
Runtime error (func=(main), adr=9): Divide by zero
(standard_in) 2: syntax error
TOTAL was: 0kb now: 0kb saving: 0kb (%) quality: %

This was probably caused by having GNU find in the $PATH ahead of the one that ships with OSX.

I'm seeing the same thing. I installed via yarn, and am on Ubuntu Studio.
> $(yarn bin)/imageOptim --version
1.15.4

> lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 16.04.3 LTS
Release:	16.04
Codename:	xenial

$(yarn bin)/imageOptim --directory path/to/images
~/my/path/node_modules/.bin/imageOptimBashLib: line 461: osascript: command not found
~/my/path/node_modules/.bin/imageOptimBashLib: line 465: osascript: command not found
~/my/path/node_modules/.bin/imageOptim: line 74: osascript: command not found
~/my/path/node_modules/.bin/imageOptimBashLib: line 469: osascript: command not found
find: unknown predicate `-E'

ImageOptim-CLI is a macOS app. It does not work on Ubuntu.


Tutorial on burn scar analysis using embeddings from partial inputs

This PR adds a tutorial on Burn scar analysis using embeddings from partial inputs
This notebook contains a complete example for how to run Clay. It combines the following three different aspects

Create single-chip datacubes with time series data for a location and a date range
Run the model with partial inputs, in this case RGB + NIR
Study burn scares through the embeddings generated for that datacube

Closes #126
Closes #136

This looks great @yellowcap good to see how you plotted the dates directly from the stack. That works well for single component scenarios, which should be largely sufficient for many stories. More complex ones might require somehting like what I did where I added the non-normalized dates to the batches such that embeddings can be labeled with dates in the plots.
Signal of the burn scars is clear. This looks good to merge. I'll incorporate some takeaways from this into my PR.


Documentation link down

The documentation link is not working.

The doc site is in the repo. If you've installed the package; you can browse them locally...


[Question] slash command

Hi
I was wondering do anyone here have an angular package for slash command?

You don't need an angular package for that. You need to implement a tiptap extension.
You can follow some reference here https://tiptap.dev/experiments/commands.
Closing as this is not an issue with the editor.

Yes while i know that; the example inject vue and or react rendered components which are kind of a different approach
So just wondered how other angular devs goes about that

Please create a discussion. Thanks