Fix #126 (Add parens in util > print where necessary)

As @kevinbarabash proposed in #126, add parenthesis around any + (as well as -) operation if it isn't the root node. It also fixes #120 issue as well.
print({ "/" [ { "+" [ "x", "2" ] } "2" }) => "(x + 2) / 2"
print({ "+" [ { "+" [ "x", "x" ] } { "+" [ "2", "2" ] } ] }) => "(x + x) + (2 + 2)"

update: I'm heading home for reading week tomorrow and am not totally sure how much time I have, but I really wanna check this out so we can finish up this change :) I'll hopefully work on it in the car but I'll keep you updated

@evykassirer Ok. Btw it is actually hard to test this case, since nor removeUnnecessaryParens, nor flattenOperands does not remove parenthesis it this case - (2 + 3)x. It is removed between substeps in collectAndCombineSearch. Will work on this

alright I have investigated the broken tests and am here to report how I fixed it 🎉
step 1:
Cloning does help, because the flatten function changes the structure of the node, and sometimes it needs to stay the way it was for the next step to work. So some of the tests were fixed with this:

step 2:
The equation tests were broken for a totally unrelated reason - it was never turning the node into a string. It hadn't been caught yet, until I added that clone in, and then it was like "hey you can't clone a string" so I fixed that too

step 3: update the remaining tests that are failing.
one of them was related to flattening and getting rid of parens:

the rest are all because flattening makes some multiplication implicit and others not implicit and so it changes things around... so just update the tests like this to be passing again:

you good to add these changes into your diff? let me know if you have any questions :)

Ok, I've updated print.js according to comments & fixed the tests. Everything is great.
The last thing is to add new tests for this fix.
As I wrote before, the parenthesis were removed only between substeps in collectAndCombineSearch. Precisely, newNode after GROUP_COEFFICIENTS & oldNode before SIMPLIFY_ARITHMETIC, due to evaluateConstantSum.
If you pass node with parenthesis to evaluateConstantSum, it will return status with oldNode w/o parenthesis.
TestUtil.testSubsteps only checking newNodes. Should I change TestUtil, so that it will check oldNodes as well?

ah yes, this is from the other bug that was found right?
I think testing old nodes would be great, yeah :) if it's straightforward to add, that'd help a lot. right now we're not testing them at all 😕

I added tests for old nodes, as usual some tests are failing.
before change: 2x + 4x + y
change: COLLECT_LIKE_TERMS
after change: (2x + 4x) + y
before change: 2x + 4x + y
change: ADD_POLYNOMIAL_TERMS
after change: 6x + y

The parenthesis are removed in evaluateConstantSum & combineLikeTerms, because of the expression like node = node.content;. Subsequent statuses are based on this mutated node, so status.oldNode is always w/o parenthesis. In order to fix this I need to make several changes like that:
  // STEP 2A: evaluate arithmetic IF there's > 1 constant
  // (which is the case if it's a list surrounded by parenthesis)
  if (Node.Type.isParenthesis(constants)) {
    const constantList = constants.content;
    const evaluateStatus = arithmeticSearch(constantList);
    evaluateStatus.oldNode = constants; // <- assign oldNode manually
    status = Node.Status.childChanged(newNode, evaluateStatus, 0);
    substeps.push(status);
    newNode = Node.Status.resetChangeGroups(status.newNode);
  }

It seems bad & dirty, is there a cleaner way to do this?
Also, if this is beyond the scope of this PR, I can just provide tests for print, but then I have to manually remove parenthesis before printing, like that.
function testPrint(exprStr, outputStr, fn) {
  let input = math.parse(exprStr);
  if (fn) {
    fn(input);
  }
  TestUtil.testFunctionOutput(print, input, outputStr);
}

describe('print asciimath', function () {
// ...
});

describe('print with parenthesis', function () {
  const tests = [
    ['(2 + 3)x', '(2 + 3) * x'],
    ['(7 - 4)^x', '(7 - 4)^x'],
    ['(9 + 2)/x', '(9 + 2) / x'],
  ];
  tests.forEach(t => {
    testPrint(
      t[0], t[1],
      (input) => { input.args[0] = input.args[0].content });
  });
})

If I'm understanding what's going on correctly (correct me if not) I think you can fix with clone (and that's actually why we started cloning in the first place! but we probably missed a few places)
"Subsequent statuses are based on this mutated node" - it should clone before mutating, so the original one stays the same
I'm a bit tired today so I don't have the brainpower to figure out where the clone would happen, but take a crack and it and I can take a look later today or tomorrow if you need another pair of eyes on it :)

I think it also is reasonable to just put this in another PR, especially if that's easier (either is fine for me)
why do you have to remove the parens before printing? how will the test fail otherwise? (this seems unrelated to the other issue, right?)

hey btw do you want some mathsteps stickers as a thank you for your contributions? 😸

if you're interested, email<EMAIL_ADDRESS>with your mailing address and I can send them over!

why do you have to remove the parens before printing? how will the test fail otherwise? (this seems unrelated to the other issue, right?)

They will not fail. The point of this PR is to print ({ "/" [{ "+" ["x", "2"] }, "2"] }) => "(x + 2) / 2". It is just hard to reproduce this node, since nor removeUnnecessaryParens, nor flattenOperands does not remove parens, they are removed between substeps in evaluateConstantSum.

Ohhh okay I'd say just create nodes with the mathjs constructors then, like in the flatten tests. Do you think that would work?

Ohh, how did I miss that? Yeah, totally, will add ASAP

everything looks good! just fix the linter issues
https://travis-ci.org/socraticorg/mathsteps/builds/203692251
(you can run npm run lint to see them locally)

DONE [x]
Thank you a lot for helping me with this PR.

perfect! thanks so much for taking this on!
are you up for taking on the other change we were discussing in another PR?
also don't forget to email us if you want stickers ^__^
🎉 🎉 🎉

Yeah, I planned to check it carefully before creating an issue.

childChanged is used in the case where the content of a parenthesis node is changed, so it should add the parens back around both the old node and new node... hm

I've sent an email stickers ^^

hi @Flyr1Q are you still interested in working on the followup PR to this?

sorry @evykassirer, don't think I'll be able to work on this in the near future :(

no problem :) thanks for replying so quickly


We should keep the page active so that users can still view it after, and allow users that aren't fully caught up to finish it.
We'd probably need some other status returned from the live stream API to tell us there was a stream in order to keep it active on the page.
We'll need to make the instructions clearer that this will be the new behavior, and that users can remove the claim if they don't want it active afterwards.

What about an option to enable / disable recording? Since some streams like music streams shouldn't need recording, and don't appear to utilize the recording to begin with?

This is already possible today, we give them their replays.


offered an expired version

installed an old version, prompted to reload, reloaded, saw this indicating the extension couldn't be installed. instead, we shouldn't show expired versions as options

Testing #172034

This message comes from the extension (see lower left of the notification) so my guess is there's nothing VS Code can do to prevent this. AFAIK Marketplace doesn't have a notion of "expired".

We do not control this. I would recommend to file the issue against gitlens extension.


let users request to be notified when a term appears

Issue created by CharlesF#0306.

Watchword functionality is now active and in alpha. It's very barebones right now and will need some additional stuff to be very valuable, I've got issues open for enhancements and features.


Question: There is a way to download packages secuentially?

Did you check the docs?

[X] I have read all the lazy.nvim docs

Is your feature request related to a problem? Please describe.
My nvim distro has 80+ packages, which trigger GitHub rate limit on fast connections (1Gb/s).
Describe the solution you'd like
x
Describe alternatives you've considered
x
Additional context
No response

Giving a grace period to packages in the download queue instead of directly show errors found while downloading, would also fix this in a more elegant way.

Check the concurrency config option


Revert assertion addition

It's just not true - alias symbol targets can be named whatever 🤷♂  (but we can still only reuse the target's cached type if the name is the same.)
Fixes a test in our RWC suite.

@weswigham has this been ported to release-2.8 branch?

https://github.com/Microsoft/TypeScript/pull/22920

thanks!


digest CheckAuth assumes nonce-count always increases

The digest module CheckAuth function makes the reasonable assumption that the client-sent nonce-count ("nc") always increases. Unfortunately, in practice, because a client can have multiple connections to a server, some possibly through proxies and/or via AJAX, client-sent nonce-counts don't always increase from the POV of the server. Strictly the requirement is that a nonce-count is not reused, not that it always increases. I am observing this as I try to use go-http-auth in a real world setting. I will send a PR to either track nonces with a bitmap or add an option to turn off nc checking. Thank you for open sourcing this excellent lib.
References:
https://lists.w3.org/Archives/Public/ietf-http-wg/2003JulSep/0006.html
https://code.google.com/p/chromium/issues/detail?id=37526

It's not just broken clients (which exist), it's also possible to get out of order nc values due to ajax requests, proxies between client and server, etc. In my case I've used go-http-auth to implement auth in a proxy server and I routinely see out of order ncs while surfing through my proxy.
I made a local change to optionally disable nc checking via a flag in the DigestAuth struct, will send you a PR soon


cluster manager init takes minutes due to slow DNS and STRICT_DNS behaviour

I noticed recently that cluster manager init can take quite some time. For example here it takes 3+ minutes
2020-11-10T16:53:13.792Z info envoy[44013] [Originator@6876 sub=upstream] cds: add 109 cluster(s), remove 1 cluster(s)
...
2020-11-10T16:53:13.943Z info envoy[44013] [Originator@6876 sub=upstream] cds: add/update cluster '/'
2020-11-10T16:56:58.923Z info envoy[44013] [Originator@6876 sub=upstream] cm init: all clusters initialized

After debugging the issue it turned out that a STRICT_DNS cluster is considered initialised once the very first DNS resolver completes either with success or failure.
This is a problem for me as during these 3+ minutes envoy wasn't working at all - it was unable to get its listeners and routes because it was stuck in CDS. I only had a few STRICT_DNS clusters and most of my other clusters 100+ are STATIC but unusable due to lack of listeners+routes.
Note that this only happens when DNS is (very) slow. I tried reproducing the issue with iptables+DROP rules but was unable to. c-ares returns failure immediately. This is the only way I was able to slow down DNS in order to reproduce the issue (<IP_ADDRESS> is my DNS server).
tc qdisc add dev eth0 root handle 1: prio
tc qdisc add dev eth0 parent 1:3 handle 30: tbf rate 20kbit buffer 1600 limit 3000
tc qdisc add dev eth0 parent 30:1 handle 31: netem delay 20000ms 10ms distribution normal
tc filter add dev eth0 protocol ip parent 1:0 prio 3 u32 match ip dst <IP_ADDRESS>/32 flowid 1:3

After the initial initialisation all is good as the DNS responses are cached and deduplicated. My apps and services tend to restart from time to time and having a 3+ minute gap when DNS is slow is bad. And DNS happens to sometimes be slow when running a cloud service.
I ended up implementing the following solution:
--- a/source/common/upstream/strict_dns_cluster.cc
+++ b/source/common/upstream/strict_dns_cluster.cc
@@ -59,6 +59,8 @@ void StrictDnsClusterImpl::startPreInit() {
   // resolved in failure.
   if (resolve_targets_.empty()) {
     onPreInitComplete();
+  } else if (info_->addedViaApi()) {
+    onPreInitComplete(); // see StrictDnsWarmupFilter and PR 2673888
   }
 }

--- a/source/extensions/filters/http/common/BUILD
+++ b/source/extensions/filters/http/common/BUILD
@@ -42,6 +42,17 @@ envoy_cc_library(
 )

 envoy_cc_library(
+    name = "strict_dns_warmup_filter_lib",
+    srcs = ["strict_dns_warmup_filter.cc"],
+    hdrs = ["strict_dns_warmup_filter.h"],
+    visibility = ["//visibility:public"],
+    deps = [
+        "//include/envoy/upstream:cluster_manager_interface",
+        "//source/extensions/filters/http/common:pass_through_filter_lib",
+    ],
+)
+
+envoy_cc_library(
     name = "utility_lib",
     hdrs = ["utility.h"],
     # Used by the router filter.  TODO(#9953) clean up.

--- /dev/null
+++ b/source/extensions/filters/http/common/strict_dns_warmup_filter.cc
@@ -0,0 +1,65 @@
+#include "extensions/filters/http/common/strict_dns_warmup_filter.h"
+
+namespace Envoy {
+namespace Http {
+
+Http::FilterHeadersStatus StrictDnsWarmupFilter::decodeHeaders(
+    Http::RequestHeaderMap& /* headers */, bool /* end_stream */) {
+  auto route = decoder_callbacks_->route();
+
+  if (route == nullptr) {
+    return Http::FilterHeadersStatus::Continue;
+  }
+
+  const Router::RouteEntry* entry = route->routeEntry();
+
+  if (entry == nullptr) {
+    return Http::FilterHeadersStatus::Continue;
+  }
+
+  Upstream::ThreadLocalCluster* cluster = cm_.get(entry->clusterName());
+
+  if (cluster == nullptr) {
+    return Http::FilterHeadersStatus::Continue;
+  }
+
+  if (cluster->info()->type() != envoy::config::cluster::v3::Cluster::STRICT_DNS) {
+    return Http::FilterHeadersStatus::Continue;
+  }
+
+  const auto& host_sets = cluster->prioritySet().hostSetsPerPriority();
+
+  if (std::any_of(host_sets.begin(), host_sets.end(),
+                  [](const Upstream::HostSetPtr& host_set) {
+                    const auto& hosts = host_set->hosts();
+                    return std::any_of(hosts.begin(), hosts.end(),
+                                       [](const Upstream::HostSharedPtr& host) {
+                                         return host != nullptr;
+                                       });
+                  })) {
+    return Http::FilterHeadersStatus::Continue;
+  }
+
+  timer_ = decoder_callbacks_->dispatcher().createTimer([this] {
+    host_set_member_update_cb_handle_->remove();
+    decoder_callbacks_->continueDecoding();
+  });
+
+  host_set_member_update_cb_handle_ = cluster->prioritySet().addMemberUpdateCb(
+      [this](const Upstream::HostVector&, const Upstream::HostVector&) {
+    if (timer_ != nullptr) {
+      timer_.reset();
+      decoder_callbacks_->dispatcher().post([this] {
+        host_set_member_update_cb_handle_->remove();
+        decoder_callbacks_->continueDecoding();
+      });
+    }
+  });
+
+  timer_->enableTimer(std::chrono::milliseconds(30000));
+
+  return Http::FilterHeadersStatus::StopAllIterationAndWatermark;
+}
+
+} // namespace Http
+} // namespace Envoy

--- /dev/null
+++ b/source/extensions/filters/http/common/strict_dns_warmup_filter.h
@@ -0,0 +1,32 @@
+#pragma once
+
+#include "envoy/upstream/cluster_manager.h"
+
+#include "extensions/filters/http/common/pass_through_filter.h"
+
+namespace Envoy {
+namespace Http {
+
+
+/**
+ * @class StrictDnsWarmupFilter
+ *
+ *      StrictDns warmup filter.
+ */
+class StrictDnsWarmupFilter : public PassThroughDecoderFilter {
+public:
+  StrictDnsWarmupFilter(Upstream::ClusterManager& cm) : cm_(cm) {}
+
+  // Http::StreamDecoderFilter
+  Http::FilterHeadersStatus decodeHeaders(Http::RequestHeaderMap& headers,
+                                          bool end_stream) override;
+
+private:
+  Upstream::ClusterManager& cm_;
+  Event::TimerPtr timer_;
+  Common::CallbackHandle* host_set_member_update_cb_handle_{};
+};
+
+
+} // namespace Http
+} // namespace Envoy

--- a/source/extensions/filters/http/router/BUILD
+++ b/source/extensions/filters/http/router/BUILD
@@ -24,6 +24,7 @@ envoy_cc_extension(
         "//source/common/router:shadow_writer_lib",
         "//source/extensions/filters/http:well_known_names",
         "//source/extensions/filters/http/common:factory_base_lib",
+        "//source/extensions/filters/http/common:strict_dns_warmup_filter_lib",
         "//source/extensions/filters/http/on_demand:on_demand_update_lib",
         "@envoy_api//envoy/extensions/filters/http/router/v3:pkg_cc_proto",
     ],

--- a/source/extensions/filters/http/router/config.cc
+++ b/source/extensions/filters/http/router/config.cc
@@ -1,5 +1,7 @@
 #include "extensions/filters/http/router/config.h"

+#include "extensions/filters/http/common/strict_dns_warmup_filter.h"
+
 #include "envoy/extensions/filters/http/router/v3/router.pb.h"
 #include "envoy/extensions/filters/http/router/v3/router.pb.validate.h"

@@ -19,6 +21,8 @@ Http::FilterFactoryCb RouterFilterConfig::createFilterFactoryFromProtoTyped(
       proto_config));

   return [filter_config](Http::FilterChainFactoryCallbacks& callbacks) -> void {
+    callbacks.addStreamDecoderFilter(
+        std::make_shared<Http::StrictDnsWarmupFilter>(filter_config->cm_));
     callbacks.addStreamDecoderFilter(std::make_shared<Router::ProdFilter>(*filter_config));
   };
 }

The solution does the following:

All STRICT_DNS clusters received via ADS/CDS are considered initialised immediately. We do not wait for the first DNS resolve to complete. STRICT_DNS clusters in bootstrap are not affected as it is assumed that one may use a STRICT_DNS for ADS/CDS.
Whenever a L7 router filter is requested we install the new StrictDnsWarmupFilter before the router filter.
The StrictDnsWarmupFilter checks if the selected cluster is STRICT_DNS and if it has no hosts waits for at most 30 seconds (currently hardcoded) for any hosts to appear. If no hosts appear then either DNS is completely dead or very slow. In either case we continue to the router filter which either returns no_healthy_upstream or proxies the request.

At the moment I am not using L4 filters so StrictDnsWarmupFilter is specifically for L7 router.
I would like to ask if it would be possible to have the above use case incorporated into envoy for broader use (the patch is only for reference) - that is - initialise STRICT_DNS clusters immediately so that some routing may happen and have a grace period when DNS is slow or down.

To me it would make sense to be able to have a per-cluster configuration to disable warming. This could be coupled with a control to permit connection picking / LB to defer until a cluster is warm. That would then allow normal route timeouts to be applied to control the process. Not sure if that's exactly what's needed, but might have a fewer moving parts than an explicit warming filter.
@snowp @mattklein123 WDYT?

To me it would make sense to be able to have a per-cluster configuration to disable warming. This could be coupled with a control to permit connection picking / LB to defer until a cluster is warm. That would then allow normal route timeouts to be applied to control the process. Not sure if that's exactly what's needed, but might have a fewer moving parts than an explicit warming filter.
@snowp @mattklein123 WDYT?

To me it would make sense to be able to have a per-cluster configuration to disable warming.

+1. I know that @lambdai has also been looking at the general problem of "too many things need warming" and might have thoughts here.

To me it would make sense to be able to have a per-cluster configuration to disable warming.

+1. I know that @lambdai has also been looking at the general problem of "too many things need warming" and might have thoughts here.

To me it would make sense to be able to have a per-cluster configuration to disable warming.
This would work for me.

This could be coupled with a control to permit connection picking / LB to defer until a cluster is warm. That would then allow normal route timeouts to be applied to control the process. Not sure if that's exactly what's needed, but might have a fewer moving parts than an explicit warming filter.
I actually use a custom LB (fifo) and think that it would be too late there as it only has chooseHost that is called from within the router and cannot reschedule and must not block. Here's the code for reference (it is always coupled with envoy.retry_host_predicates.previous_hosts)

HostConstSharedPtr FifoLoadBalancer::chooseHost(LoadBalancerContext* context) {
  for (const auto& hs : priority_set_.hostSetsPerPriority()) {
    for (const auto& host : hs->hosts()) {
      if (host == nullptr || context == nullptr || !context->shouldSelectAnotherHost(*host)) {
        return host;
      }
    }
  }

  return nullptr;
}

In any case I only shared the code as a reference. I know that it is by far not the best solution but wanted to start from somewhere.

To me it would make sense to be able to have a per-cluster configuration to disable warming.
This would work for me.

This could be coupled with a control to permit connection picking / LB to defer until a cluster is warm. That would then allow normal route timeouts to be applied to control the process. Not sure if that's exactly what's needed, but might have a fewer moving parts than an explicit warming filter.
I actually use a custom LB (fifo) and think that it would be too late there as it only has chooseHost that is called from within the router and cannot reschedule and must not block. Here's the code for reference (it is always coupled with envoy.retry_host_predicates.previous_hosts)

HostConstSharedPtr FifoLoadBalancer::chooseHost(LoadBalancerContext* context) {
  for (const auto& hs : priority_set_.hostSetsPerPriority()) {
    for (const auto& host : hs->hosts()) {
      if (host == nullptr || context == nullptr || !context->shouldSelectAnotherHost(*host)) {
        return host;
      }
    }
  }

  return nullptr;
}

In any case I only shared the code as a reference. I know that it is by far not the best solution but wanted to start from somewhere.

Yeah, we would need to block somewhere in router. I think this behavior is generic enough we could have a "block-on-cluster-warming" capability.

Yeah, we would need to block somewhere in router. I think this behavior is generic enough we could have a "block-on-cluster-warming" capability.

Drive by:  per cluster warming might be good.
@ppadevski
Long time ago I remember that strict dns cluster could be warm up by accident, and no healthy upstream will be the error code for Http request. Is this fail-fast not acceptable?
Http filter is an acceptable place but we'd better put it in http router which handles general upstream failure. e.g. add a retry on no healthy upstream host if this option is not there.
Ideally I am planning to experimental asynchronous load balancer, which would return Future so that any terminated network filter, including http conn manager, tcp proxy, the existing rest and future filters can wait on cluster. This can resolve this slow dns use case, and also on demand EDS

Hi all. Is there any update for this feature?

I believe I encountered the same issue. What’s strange is that after the message dns resolution for external-service.gatewayapi-external-services.svc.cluster.local started, there are no further DNS-related logs for the entire 30-second test duration.
I would expect the DNS request to be canceled after 5 seconds (the default timeout as per Envoy’s documentation) and retried. Unless, of course, this DNS configuration needs to be explicitly set for it to apply.
Envoy version v1.32.1
Logs
[2024-11-28 14:30:10.178][23][debug][config] [source/extensions/config_subscription/grpc/grpc_mux_impl.cc:363] Received gRPC message for type.googleapis.com/envoy.config.cluster.v3.Cluster at version 421cc6b7-37c9-4573-8e6b-fe5280d1c34a
[2024-11-28 14:30:10.178][23][debug][config] [source/extensions/config_subscription/grpc/grpc_mux_impl.cc:340] Pausing discovery requests for type.googleapis.com/envoy.config.cluster.v3.Cluster (previous count 0)
[2024-11-28 14:30:10.178][23][debug][config] [source/extensions/config_subscription/grpc/grpc_mux_impl.cc:340] Pausing discovery requests for type.googleapis.com/envoy.config.endpoint.v3.ClusterLoadAssignment (previous count 0)
[2024-11-28 14:30:10.178][23][debug][config] [source/extensions/config_subscription/grpc/grpc_mux_impl.cc:340] Pausing discovery requests for type.googleapis.com/envoy.config.endpoint.v3.LbEndpoint (previous count 0)
[2024-11-28 14:30:10.178][23][debug][config] [source/extensions/config_subscription/grpc/grpc_mux_impl.cc:340] Pausing discovery requests for type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.Secret (previous count 0)
[2024-11-28 14:30:10.178][23][info][upstream] [source/common/upstream/cds_api_helper.cc:32] cds: add 3 cluster(s), remove 3 cluster(s)
[2024-11-28 14:30:10.178][23][debug][misc] [source/common/network/dns_resolver/dns_factory_util.cc:75] create DNS resolver type: envoy.network.dns_resolver.cares
[2024-11-28 14:30:10.178][23][debug][dns] [source/extensions/network/dns_resolver/cares/dns_impl.cc:601] c-ares library initialized.
[2024-11-28 14:30:10.201][23][debug][config] [./source/common/http/filter_chain_helper.h:111]     upstream http filter #0
[2024-11-28 14:30:10.201][23][debug][config] [./source/common/http/filter_chain_helper.h:157]       name: envoy.filters.http.upstream_codec
[2024-11-28 14:30:10.201][23][debug][config] [./source/common/http/filter_chain_helper.h:160]     config: {"@type":"type.googleapis.com/envoy.extensions.filters.http.upstream_codec.v3.UpstreamCodec"}
[2024-11-28 14:30:10.202][23][debug][config] [source/extensions/config_subscription/grpc/grpc_mux_impl.cc:340] Pausing discovery requests for type.googleapis.com/envoy.config.cluster.v3.Cluster (previous count 1)
[2024-11-28 14:30:10.202][23][debug][upstream] [source/common/upstream/cluster_manager_impl.cc:857] add/update cluster external-service-7b2e7f0413991110 starting warming
[2024-11-28 14:30:10.202][23][debug][dns] [source/extensions/network/dns_resolver/cares/dns_impl.cc:391] dns resolution for external-service.gatewayapi-external-services.svc.cluster.local started

Config:
 "dynamic_warming_clusters": [
    {
     "version_info": "421cc6b7-37c9-4573-8e6b-fe5280d1c34a",
     "cluster": {
      "@type": "type.googleapis.com/envoy.config.cluster.v3.Cluster",
      "name": "external-service-7b2e7f0413991110",
      "type": "STRICT_DNS",
      "connect_timeout": "5s",
      "per_connection_buffer_limit_bytes": 32768,
      "circuit_breakers": {
       "thresholds": [
        {
         "max_connections": 1024,
         "max_pending_requests": 1024,
         "max_requests": 1024,
         "max_retries": 3
        }
       ]
      },
      "dns_lookup_family": "V4_ONLY",
      "load_assignment": {
       "cluster_name": "external-service",
       "endpoints": [
        {
         "lb_endpoints": [
          {
           "endpoint": {
            "address": {
             "socket_address": {
              "address": "external-service.gatewayapi-external-services.svc.cluster.local",
              "port_value": 80
             }
            }
           },
           "metadata": {
            "filter_metadata": {
             "envoy.transport_socket_match": {
              "kuma.io/protocol": "http"
             },
             "envoy.lb": {
              "kuma.io/protocol": "http"
             }
            }
           },
           "load_balancing_weight": 1
          }
         ]
        }
       ]
      },
      "typed_extension_protocol_options": {
       "envoy.extensions.upstreams.http.v3.HttpProtocolOptions": {
        "@type": "type.googleapis.com/envoy.extensions.upstreams.http.v3.HttpProtocolOptions",
        "common_http_protocol_options": {
         "idle_timeout": "3600s",
         "max_connection_duration": "0s",
         "max_stream_duration": "0s"
        },
        "explicit_http_config": {
         "http_protocol_options": {}
        }
       }
      }
     },
     "last_updated": "2024-11-28T14:30:10.202Z"
    }
   ]```

cluster_manager.warming_clusters: 1
control_plane.connected_state: 1
control_plane.pending_requests: 0
control_plane.rate_limit_enforced: 0
dns.cares.get_addr_failure: 0
dns.cares.not_found: 0
dns.cares.pending_resolutions: 1


Update site settings

dev settings_base.py and settings_addons.py have been merged into settings.py. I am using django-enviorn so we can make use of environment variables.
I've also cleaned up some settings that we no longer use for altdev, identitystage and landfill.
r?

That's a good idea, no need to maintain the "private_addons" package anymore!
Maybe we should move to use django-environ for local dev/docker too.
r+


change console.error => console.log so lambda logs it. Also rollback …

…failed transaction, since it wont work otherwise

merged all changes except for 50f230e admin save/modify by api and a backdoorAdminAPIsecret
so closing this PR to avoid merge of that one.


Calculation for DPS doesn't work for crystal gear

Dps calculation ignores the 15% damage boost, And likely the accuracy boost too. i'm sure you're aware most items that have special effects their calculations are not included, beyond that this is a really great addition.

Yeah many extra gear effects haven't been added yet, but I'm hoping to get around to them all over time! Thanks for mentioning this one.

No problem i appreciate what you’ve done already its great :)
On Fri, May 28, 2021 at 11:54 AM LlemonDuck @.***>
wrote:

Yeah many extra gear effects haven't been added yet, but I'm hoping to get
around to them all over time! Thanks for mentioning this one.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/LlemonDuck/dps-calculator/issues/9#issuecomment-850514392,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AUIGNBLA5RUNLFXYIPHZW5LTP64FFANCNFSM45V67SCA
.

Fixed in 77dedbc60e8c54fbbdd9c0f93bdf6ed8942c670a.
Staged for release 1.3.

Awesome, thanks!
On Sat, May 29, 2021 at 2:08 AM LlemonDuck @.***> wrote:

Fixed in 77dedbc
https://github.com/LlemonDuck/dps-calculator/commit/77dedbc60e8c54fbbdd9c0f93bdf6ed8942c670a
.
Staged for release 1.3.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/LlemonDuck/dps-calculator/issues/9#issuecomment-850777824,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AUIGNBLADYV6Q6F3RU3BJ3TTQCAEHANCNFSM45V67SCA
.


fix: allow multiple/custom index pages to be used

Investigate this on a non-cloud library not generating the TOC properly due to missing a README page. However, upon further research, some libraries also used multiple index.rst pages nested. Solving both issues by allowing (1) index.rst to be used in place of README.rst if README.rst is not present so TOC is well formed and still has an overview page, and (2) allow multiple index pages to be present, just under a different name.
Added a non-cloud goldens section to help cover for the additional coverage as no unit test will be available for this specific portion of the code, covered by the goldens. Non Cloud libraries should still be added to the coverage, some time or later when we support non-Cloud libraries as well, so I'm adding them now.
No changes to existing Cloud client libraries and their TOC generation.
Fixes #269.

[x] Tests pass

Oops, region tags shouldn't be added! Stripped them off the files (they're needed as some code snippets were pulled in from Sphinx configs)


instanceof should work as expected for Node constructors

Currently, the Node constructors just return an instance of Node, rather than an instance of a subclass of Node. This means that e.g. g.constructors.Foo() instanceof g.constructors.Foo return false. It would be nice if this would return true.
I implemented that in a branch here: https://github.com/cdglabs/ohm/tree/node-constructors. Unfortunately, it seems to cause a pretty significant performance degradation -- 5-7% when compiling ohm.js with the example ES5 grammar. So I'm not going to land this for now, but wanted to create the bug to keep track of the issue.

This issue was fixed a while ago.


Added Brush color, size, save option

The following fixes have been done

Added brush color , Fix #8
Added brush width selector Fix #14
Added save options for png, jpg, pdf. Fix #9

LGTM


Fix typo "GiitHub" -> "GitHub"

Changed Giithub to Github

Why:
Stumbled onto a typo while reading ES / github-privacy-statement.md

What's being changed (if available, include any code snippets, screenshots, or gifs):
- GiitHub
+ GitHub

Check off the following:

[x] I have reviewed my changes in staging (look for the "Automatically generated comment" and click the links in the "Preview" column to view your latest changes).
[x] For content changes, I have completed the self-review checklist.

Writer impact (This section is for GitHub staff members only):

[ ] This pull request impacts the contribution experience

[ ] I have added the 'writer impact' label
[ ] I have added a description and/or a video demo of the changes below (e.g. a "before and after video")

@EstebanFuentealba Thanks for opening this PR and pointing out this typo! ⚡ Unfortunately, we are not able to accept changes for translated content. Our translation process involves an integration with an external service, where all translation activity happens. We hope to eventually open up the translation process to the open-source community, but we’re not there yet.
See https://github.com/github/docs/blob/main/contributing/types-of-contributions.md#earth_asia-translations. 🌏
I'll open an issue internally to let our translators know about this. Thank you for your interest and passion for improving GitHub Docs! 💖


Interactive Tutorial - Module 4 Step 1 States MiniKube Does Not Support LoadBalancer Option, This is No Longer True

Here's the quote:

To create a new service and expose it to external traffic we’ll use the expose command with NodePort as parameter (minikube does not support the LoadBalancer option yet).

Minikube does support LoadBalancer since 0.31.0, so this should be removed and/or (even better) an updated tutorial added which demonstrates the LoadBalancer functionality.

I think this issue is about https://kubernetes.io/docs/tutorials/kubernetes-basics/expose/expose-intro/
For Kubernetes basics I wouldn't cover load balancing in Minikube.
/kind bug
/language en

Could you tell me how to update the Interactive Tutorial? I took a look at content/en/docs/tutorials/kubernetes-basics/expose/expose-interactive.html but didn't find docs that are related to the Interactive Tutorial.

These tutorials are in a different Git repository: https://github.com/katacoda-scenarios/kubernetes-bootcamp-scenarios

These tutorials are in a different Git repository: https://github.com/katacoda-scenarios/kubernetes-bootcamp-scenarios

Thanks. BTW, removing (minikube does not support the LoadBalancer option yet). is enough?

/triage accepted

/remove-lifecycle rotten

/remove-lifecycle rotten

/remove-lifecycle stale


Automated cherry pick of #8493: fix(region): roll back the optimization of cachedimage list

Cherry pick of #8493 on release/3.5.
#8493: fix(region): roll back the optimization of cachedimage list

/lgtm
/approve


[WIP][SPARK-7380][MLLIB] pipeline stages should be copyable in Python

This PR makes pipeline stages in Python copyable and hence simplifies some implementations. It also includes the following changes:

Rename paramMap and defaultParamMap to _paramMap and _defaultParamMap, respectively.
Accept a list of param maps in fit.
Use parent uid and name to identify param.

@jkbradley

Merged build triggered.

Merged build started.

Test build #32521 has started for   PR 6088 at commit 9630eae.

Test build #32521 has finished for   PR 6088 at commit 9630eae.

This patch fails Python style tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/32521/
Test FAILed.

Merged build triggered.

Merged build started.

Test build #32527 has started for   PR 6088 at commit a163413.

Test build #32527 has finished for   PR 6088 at commit a163413.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
    decisionTreeCode = '''class DecisionTreeParams(Params):
class DecisionTreeParams(Params):
class LinearRegression(JavaEstimator, HasFeaturesCol, HasLabelCol, HasPredictionCol, HasMaxIter,
class LinearRegressionModel(JavaModel):
class TreeRegressorParams(object):
class RandomForestParams(object):
class GBTParams(object):
class DecisionTreeRegressor(JavaEstimator, HasFeaturesCol, HasLabelCol, HasPredictionCol,
class DecisionTreeRegressionModel(JavaModel):
class RandomForestRegressor(JavaEstimator, HasFeaturesCol, HasLabelCol, HasPredictionCol, HasSeed,
class RandomForestRegressionModel(JavaModel):
class GBTRegressor(JavaEstimator, HasFeaturesCol, HasLabelCol, HasPredictionCol, HasMaxIter,
class GBTRegressionModel(JavaModel):
        s"FileOutputCommitter or its subclass is expected, but got a $
trait FSBasedRelationProvider
abstract class OutputWriter

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/32527/
Test PASSed.

Merged build finished. Test PASSed.

It looks good, although I agree it may need more testing to make sure UIDs behave as expected.
One other thought: Do you think it would be worthwhile to try to use the same uid for a Java*Wrapper instance in Python and the Scala instance it is wrapping?

Yes, that certainly helps. Let's get #6019 in first, which should be ready for review.

Merged build triggered.

Merged build started.

Test build #32698 has started for   PR 6088 at commit 46cb6ed.

Test build #32698 has finished for   PR 6088 at commit 46cb6ed.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
class Pipeline(override val uid: String) extends Estimator[PipelineModel]
final class DecisionTreeClassifier(override val uid: String)
final class GBTClassifier(override val uid: String)
class LogisticRegression(override val uid: String)
final class OneVsRest(override val uid: String)
final class RandomForestClassifier(override val uid: String)
class BinaryClassificationEvaluator(override val uid: String)
final class Binarizer(override val uid: String)
final class Bucketizer(override val uid: String)
class ElementwiseProduct(override val uid: String)
class HashingTF(override val uid: String) extends UnaryTransformer[Iterable[_], Vector, HashingTF]
final class IDF(override val uid: String) extends Estimator[IDFModel] with IDFBase
class Normalizer(override val uid: String) extends UnaryTransformer[Vector, Vector, Normalizer]
class OneHotEncoder(override val uid: String)
class PolynomialExpansion(override val uid: String)
class StandardScaler(override val uid: String) extends Estimator[StandardScalerModel]
class StringIndexer(override val uid: String) extends Estimator[StringIndexerModel]
class Tokenizer(override val uid: String) extends UnaryTransformer[String, Seq[String], Tokenizer]
class RegexTokenizer(override val uid: String)
class VectorAssembler(override val uid: String)
class VectorIndexer(override val uid: String) extends Estimator[VectorIndexerModel]
final class Word2Vec(override val uid: String) extends Estimator[Word2VecModel] with Word2VecBase
class Param[T](val parent: String, val name: String, val doc: String, val isValid: T => Boolean)
class DoubleParam(parent: String, name: String, doc: String, isValid: Double => Boolean)
class IntParam(parent: String, name: String, doc: String, isValid: Int => Boolean)
class FloatParam(parent: String, name: String, doc: String, isValid: Float => Boolean)
class LongParam(parent: String, name: String, doc: String, isValid: Long => Boolean)
class BooleanParam(parent: String, name: String, doc: String) // No need for isValid
class ALS(override val uid: String) extends Estimator[ALSModel] with ALSParams
final class DecisionTreeRegressor(override val uid: String)
final class GBTRegressor(override val uid: String)
class LinearRegression(override val uid: String)
final class RandomForestRegressor(override val uid: String)
class CrossValidator(override val uid: String) extends Estimator[CrossValidatorModel]
trait Identifiable

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/32698/
Test PASSed.

Merged build triggered.

Merged build started.

Test build #32735 has started for   PR 6088 at commit b6db1ed.

Test build #32735 has finished for   PR 6088 at commit b6db1ed.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/32735/
Test PASSed.

Merged build finished. Test PASSed.

Merged build triggered.

Merged build started.

Test build #32841 has started for   PR 6088 at commit 7e0d27f.

Test build #32841 has finished for   PR 6088 at commit 7e0d27f.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/32841/
Test PASSed.

Merged build triggered.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/32942/
Test FAILed.

Merged build triggered.

Merged build started.

Test build #32945 has started for   PR 6088 at commit 611c719.

Merged build triggered.

Merged build started.

test this please

Merged build triggered.

Merged build started.

Test build #32966 has started for   PR 6088 at commit 413c463.

Test build #32966 has finished for   PR 6088 at commit 413c463.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
class VectorIndexerModel(JavaModel):

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/32966/
Test PASSed.

LGTM

Merged into master and branch-1.4.


feat(md-select): forward blur events

This make the md-select component forward blur event. For validation errors you also need the changes in validationRenderer #250

Coverage remained the same at 95.154% when pulling f2197529ea84c62680838b1222ba968adada9a43 on Ullfis:md-select-blur into cbc82cc94916fcc190bb156acc5887e3e27ad7bc on aurelia-ui-toolkits:master.


Can't download pretrained weights

Here's a backup #62 (comment)

Thank you very much

The pre-trained weights are not available. The backup link mentioned by @turingfang also not working.

@Riponcs Hi,you can download in https://github.com/sampepose/flownet2-tf/issues/62#issuecomment-441548173


Ogre2 is not found on windows CI builds

Environment

OS Version: Windows
Source or binary build? source

Description

Expected behavior: gz-rendering to build with ogre2 in windows CI jobs
Actual behavior: CMake is unable to find the Ogre2 package even though it's installed. See https://build.osrfoundation.org/view/ign-garden/job/ign_rendering-gz-7-win/30/consoleFull#console-section-20

Here's the output of the CMake configuration:
-- Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.19044.
-- The C compiler identification is MSVC 19.29.30143.0
-- The CXX compiler identification is MSVC 19.29.30143.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.29.30133/bin/Hostx64/x64/cl.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.29.30133/bin/Hostx64/x64/cl.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- gz-rendering7 version 7.2.0
-- Operating system is Windows
-- Looking for gz-math7 -- found version 7.1.0
-- Searching for dependencies of gz-math7
-- Looking for gz-utils2 -- found version 2.0.0
-- Searching for dependencies of gz-utils2
-- Searching for <gz-math7> component [eigen3]
-- Looking for gz-math7-eigen3 -- found version 7.1.0
-- Searching for dependencies of gz-math7-eigen3
-- Looking for gz-math7 - found

-- Looking for gz-common5 -- found version 5.3.1
-- Searching for dependencies of gz-common5
-- Looking for gz-utils2 -- found version 2.0.0
-- Found DL: TRUE
-- Searching for <gz-common5> component [graphics]
-- Looking for gz-common5-graphics -- found version 5.3.1
-- Searching for dependencies of gz-common5-graphics
-- Looking for gz-math7 -- found version 7.1.0
-- Found GzAssimp: TRUE (found version "5.0.1")
-- Searching for <gz-common5> component [events]
-- Looking for gz-common5-events -- found version 5.3.1
-- Searching for dependencies of gz-common5-events
-- Looking for gz-math7 -- found version 7.1.0
-- Searching for <gz-common5> component [geospatial]
-- Looking for gz-common5-geospatial -- found version 5.3.1
-- Searching for dependencies of gz-common5-geospatial
-- Looking for gz-math7 -- found version 7.1.0
-- Looking for gz-common5 -- found version 5.3.1
-- Looking for gz-common5 - found

-- Looking for gz-plugin2 -- found version 2.0.1
-- Searching for dependencies of gz-plugin2
-- Looking for gz-utils2 -- found version 2.0.0
-- Searching for dependencies of gz-utils2
-- Searching for <gz-utils2> component [cli]
-- Looking for gz-utils2-cli -- found version 2.0.0
-- Searching for dependencies of gz-utils2-cli
-- Searching for <gz-plugin2> component [all]
-- Looking for all libraries of gz-plugin2 -- found version 2.0.1
-- Looking for gz-plugin2 -- found version 2.0.1
-- Looking for gz-plugin2-loader -- found version 2.0.1
-- Searching for dependencies of gz-plugin2-loader
-- Looking for gz-plugin2-register -- found version 2.0.1
-- Searching for dependencies of gz-plugin2-register
-- Looking for gz-plugin2 - found

-- Looking for gz-utils2 -- found version 2.0.0
-- Looking for gz-utils2 - found

-- Looking for FreeImage.h FreeImageconfig.h - found
-- Looking for FreeImage library - found
-- Looking for FreeImage - found

-- Found OpenGL: opengl32
-- Looking for OpenGL - found

-- Found OGRE
--   static     : OFF
--   components : Bites;MeshLodGenerator;Overlay;Paging;Property;RTShaderSystem;Terrain;Volume
--   plugins    : Plugin_BSPSceneManager;Plugin_OctreeSceneManager;Plugin_PCZSceneManager;Plugin_ParticleFX;RenderSystem_GL;RenderSystem_GL3Plus;RenderSystem_Direct3D11;Codec_STBI;Codec_FreeImage;Codec_EXR
--   media      : C:/vcpkg/installed/x64-windows/Media
-- Looking for GzOGRE - found

CMake Warning (dev) at C:/Jenkins/workspace/ign_rendering-gz-7-win/ws/install/gz-cmake3/share/cmake/gz-cmake3/cmake3/GzUtils.cmake:444 (message):
   -- THIS MESSAGE IS INTENDED FOR GZ-RENDERING AUTHORS --
      (IF YOU SEE THIS, PLEASE REPORT IT)

  Could not find pkg-config information for GzOGRE.  It was not provided by
  the find-module for the package, nor was it explicitly passed into the call
  to gz_find_package(~).  This is most likely an error in this project's use
  of gz-cmake.
Call Stack (most recent call first):
  CMakeLists.txt:78 (gz_find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Found Boost: C:/vcpkg/installed/x64-windows/include (found version "1.78.0")
-- Looking for GzOGRE2 - not found

CMake Warning at C:/Jenkins/workspace/ign_rendering-gz-7-win/ws/install/gz-cmake3/share/cmake/gz-cmake3/cmake3/GzConfigureBuild.cmake:69 (message):
   CONFIGURATION WARNINGS:
   -- Ogre 1.x versions greater than 1.9 are not officially supported.
   -- The software might compile and even work but support from upstream
   -- could be reduced to accepting patches for newer versions
Call Stack (most recent call first):
  CMakeLists.txt:176 (gz_configure_build)

-- Configuring library: gz-rendering7
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR - Failed
-- Performing Test COMPILER_HAS_DEPRECATED
-- Performing Test COMPILER_HAS_DEPRECATED - Success
-- Adding 5 UNIT tests
-- Configuring library: gz-rendering7-ogre
-- No tests have been specified for UNIT
-- The program [cppcheck] was not found! Skipping codecheck setup
-- Build configuration successful
-- Build type: Release
-- Install prefix: C:/Jenkins/workspace/ign_rendering-gz-7-win/ws/install/gz-rendering7
-- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Jenkins/workspace/ign_rendering-gz-7-win/ws/build/gz-rendering7

looks like vcpkg installs ogre 2.2 but from garden (gz-rendering7) upwards, ogre 2.3 is required so the gz-rendering-ogre2 component is not built

Closing as duplicate of https://github.com/gazebosim/gz-rendering/issues/745


Only get OSX package on OSX

This line should be modified to only be required on OSX.
https://github.com/swharden/ScottPlot/blob/641126646d77c3aefad055e9f31d44da333eb03f/src/ScottPlot/ScottPlot.csproj#L30
There's probably a way to do this...
https://docs.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files#adding-a-packagereference-condition

https://stackoverflow.com/questions/58349524/in-csproj-can-i-conditionally-include-a-file-based-on-runtime-identifier
Something like:
<PackageReference Include="MyLibrary.Linux" Version="1.0.0"
    Condition="'$(RuntimeIdentifier)'=='linux-x64'" />

<PackageReference Include="MyLibrary.Windows" Version="1.0.0"
    Condition="'$(RuntimeIdentifier)'=='win-x64'" />

This was complicated
[System.Runtime.InteropServices.RuntimeInformation]::IsOSPlatform($([System.Runtime.InteropServices.OSPlatform]::OSX))

<PackageReference Include="runtime.osx.10.10-x64.CoreCompat.System.Drawing" Version="5.8.64" Condition="'$([System.Runtime.InteropServices.RuntimeInformation]::IsOSPlatform($([System.Runtime.InteropServices.OSPlatform]::OSX)))' == 'true'" />


meta: fix is_compatible/constructible traits

(my previous PR was empty and got auto-closed, duh)
The previous version relied on the existence of an iterator member type.
As mentioned in comments, this is not the proper way to do it and causes issues with certain types (e.g. views from range-v3 which do not have such an alias).
Add a is_range trait that properly detects the return type of begin/end, and use it instead.

Pull request checklist
Read the Contribution Guidelines for detailed information.

[x]  Changes are described in the pull request, or an existing issue is referenced.
[ ]  The test suite compiles and runs without error.
[x]  Code coverage is 100%. Test cases can be added by editing the test suite.
[x]  The source code is amalgamated; that is, after making changes to the sources in the include/nlohmann directory, run make amalgamate to create the single-header file single_include/nlohmann/json.hpp. The whole process is described here.

Please don't

The C++11 support varies between different compilers and versions. Please note the list of supported compilers. Some compilers like GCC 4.7 (and earlier), Clang 3.3 (and earlier), or Microsoft Visual Studio 13.0 and earlier are known not to work due to missing or incomplete C++11 support. Please refrain from proposing changes that work around these compiler's limitations with #ifdefs or other means.
Specifically, I am aware of compilation problems with Microsoft Visual Studio (there even is an issue label for these kind of bugs). I understand that even in 2016, complete C++11 support isn't there yet. But please also understand that I do not want to drop features or uglify the code just to make Microsoft's sub-standard compiler happy. The past has shown that there are ways to express the functionality such that the code compiles with the most recent MSVC - unfortunately, this is not the main objective of the project.
Please refrain from proposing changes that would break JSON conformance. If you propose a conformant extension of JSON to be supported by the library, please motivate this extension.
Please do not open pull requests that address multiple issues.

I ran make pretty but it seems that it made a lot of changes 🤔

Coverage remained the same at 100.0% when pulling e5dfbdcd0375ad9961499554ca74f787256fe185 on theodelrieu:fix/compatible_array_type into 0b345b20c888f7dc8888485768e4bf9a6be29de0 on nlohmann:develop.

I ran make pretty but it seems that it made a lot of changes 🤔

Would it be worth doing that in a separate commit within the PR or even a separate PR?

Would it be worth doing that in a separate commit within the PR or even a separate PR?

I'll fix it.


What happened this night with v1.5.0

Dear Fellas,
first of all I apologize for the  inconvenience.
Today at about 1 a.m. german time, I wanted to prepare a draft for the next release. I was thinking of saving the next release as a draft, but i misclicked and released the master branch, which was still having 1.4.2 distribution files. After about 5 minutes later I realized, what I did and so I somehow deleted the release, but was worried, that now maybe some automation started to publish the files. So I felt forced to release a real v1.5.0. So I did.
Actually I wanted to prepare it to expedite the release for @MrRio. And I wanted to talk with James about the release plan. Especially I wanted the v.1.5.0 to be a non-stable release and release after few days, when first issues would be reported and fixed to release a stable v1.5.1 and have good new year 2019 with a more stable and extended jsPDF.
I think, that you we (esp. MrRio) will fix everything tonight. So that we have tomorrow a good release, which can be loaded via npm.
Best Regards
Aras Abbasi

Version 1.5.2 fixes all issues.


SimpleRandomRedirector should be enhanced to not repeat directions

The SimpleRandomRedirector should be enhanced to cache where the recent requests were sent and attempt to send repeated requests to a different data service instance if possible. This is part of the resolution to the issue where new data services started by an external orchestration service may not start quickly enough to serve data to clients.

merged into develop


Add ROR to Crossref DOI deposit output when schema available

https://www.crossref.org/blog/roring-ahead-using-ror-in-place-of-the-open-funder-registry/
"We are evolving our metadata schema so that we can collect ROR IDs in places where we already support the collection of Funder IDs – for instance, in the funding section of the metadata for works [...] We’re aiming to release an updated schema that supports these changes in Q1 2024."
The draft specification currently suggests that the following changes will be required:

if we have a ROR for a funder, we should include it instead of the DOI
when sending a ROR ID, we shouldn't also send the funder name
if we don't have a ROR but we do have a DOI, we can continue sending that as we do currently (for now)

Note also from the draft specification:
"If the above instructions make sense and you are ready to generate test XML please send your files to<EMAIL_ADDRESS>


Add SystemProperties and UserProperties to SbMessage

I think it would be of very high value for the module to propagate the SystemProperties and the UserProperties available on a message.

I have merged the PR.  I will be able to take a look at adding the custom output format soon!


Avoid version conflict by pinning docutils (#418)

I think the CLI should always pin dependencies.

The CLI is liable to be installed alongside other Python libraries, increasing the likelihood of unsatisfiable pins if another package also depends on a pinned version of the same package.
For this reason libraries should range their dependencies as loosely as reasonable beyond the major version number.
@jessebrennan can you please describe the version conflict that occurred here, or link to a relevant issue?

@kislyuk it's issue #418. I linked it to the PR and referenced it in the PR title and commit.

Thanks, sorry I missed that. LGTM

The CLI is liable to be installed alongside other Python libraries, increasing the likelihood of unsatisfiable pins if another package also depends on a pinned version of the same package.

For this reason libraries should range their dependencies as loosely as reasonable beyond the major version number.

In my experience, this approach doesn't work in practice, simply because "as loosely as reasonable" is ill-defined and unreliable. Any package can potentially break on any update of a dependency, even minor ones. This problem is the reason virtual environments were invented, and it's the reason why other languages use the share-nothing approach to package management, most prominently Node, Go and Rust.


chore: add switch and switch group

Fixes #25509
Fixes #25510

@KelvinOm Note:

There is no Group component for Switch in react-aria, so using the Checkboxgroup only. Reexporting it as SwitchGroup
The code for Switch is mostly the same except that it uses useSwitch instead of useCheckbox


[RFC] Some performance improvements

I added add and subtract methods that take an operand by value, instead of by reference, so they can work in place instead of always allocating new BigInts for the result.
I'd like to hear if anyone knows a better way of doing this, though - with the various wrappers/forwardings doing this for all the operations is going to be a mess and add a ton of boilerplate. I haven't even tried to do a complete job of it yet.
I'm starting to think the sanest thing to do would be to only have in place implements of most of the operations - and have the wrappers clone() if necessary. That way, the only extra work we're doing is a memcpy(), which is a hell of a lot faster than a heap allocation.

CI failed on rust 1.0 .. We'll want to keep that working if possible.
I actually have been working on something similar.  I'll try to clean that up and push to a branch soon so we can compare/merge approaches.
Do you have comparative benchmark results to share?

On Mon, Nov 16, 2015 at 01:50:04AM -0800, Josh Stone wrote:

CI failed on rust 1.0 .. We'll want to keep that working if possible.

Yeah, I just saw that...

I actually have been working on something similar.  I'll try to clean that up and push to a branch soon so we can compare/merge approaches.

Figures :) I'm definitely interested in seeing what you did. This is my "screw
around and learn Rust" project.
I'm also toying with inline assembly for the inner loops - mainly for the
purpose of getting away from DoubleBigDigit so all the arithmatic can be done in
the native word size. So far just toying, though.

Do you have comparative benchmark results to share?

Yeah, in the patch messages.

Just got it working with inline asm and BigDigit size == usize, if anyone wants to take a look.
https://github.com/koverstreet/num/commits/asm
Very hacky but it does give a nice performance boost on the multiply benchmark.

Found some new performance improvements and rolled them into the patch. The current numbers are:
Before:
multiply_0: 7,137 ns/iter (+/- 620)
multiply_1: 2,104,565 ns/iter (+/- 255,208)
multiply_2: 51,620,572 ns/iter (+/- 2,707,818)
After:
multiply_0: 634 ns/iter (+/- 61)
multiply_1: 60,992 ns/iter (+/- 6,843)
multiply_2: 6,849,681 ns/iter (+/- 388,000)

OK, I pushed my stuff to cuviper:wip.  I think I've got the sort of val/ref forwarding changes you were thinking of.  For the most part, my changes are more incremental tweaks than what you have.  My performance improvement to Add/Sub is similar to yours, I think, but I definitely didn't improve Mul as much as you did.  Take a look -- if it's not too hard for you to refactor your improvements on top of mine, that would be awesome... I think my forwarding simplifies it a bit, but let me know what you think.
As for asm stuff, that's a tricky door to open.  It's a feature only for rust nightly, of course, and only for archs you implement, so there still has to be a pure-Rust fallback.  I think if you want to explore this route, you'd be better off working on ramp.

On Mon, Nov 16, 2015 at 11:23:50AM -0800, Josh Stone wrote:

OK, I pushed my stuff to cuviper:wip.  I think I've got the sort of val/ref forwarding changes you were thinking of.  For the most part, my changes are more incremental tweaks than what you have.  My performance improvement to Add/Sub is similar to yours, I think, but I definitely didn't improve Mul as much as you did.  Take a look -- if it's not too hard for you to refactor your improvements on top of mine, that would be awesome... I think my forwarding simplifies it a bit, but let me know what you think.

Yeah, I can do that. Any idea when your changes will go in?

As for asm stuff, that's a tricky door to open.  It's a feature only for rust nightly, of course, and only for archs you implement, so there still has to be a pure-Rust fallback.  I think if you want to explore this route, you'd be better off working on ramp.

Oh, I'm not in a rush to get the asm stuff in. But I do like my work to be used,
so I'd prefer to just do whatever is necessary to get it into num when it's
ready, no offense to the ramp project :)
Is it possible to use #[cfg] to switch off the rust version? Or would we be
stuck waiting until the oldest version of rust we have to support supports
whatever features we want to use?

:umbrella: The latest upstream changes (presumably 658637d) made this pull request unmergeable. Please resolve the merge conflicts.

There you go, I pushed my changes.  Thanks homu. :)
I don't know any way to #[cfg] the rust version -- I wish there were.  We could add a manual asm or nightly feature in cargo, but nothing automatic that I'm aware of.

@cuviper there is none. Only way to support asm in num would be Carfo feature flag.

On Wed, Nov 18, 2015 at 10:06:03PM -0800, Josh Stone wrote:

There you go, I pushed my changes.  Thanks homu. :)
I don't know any way to #[cfg] the rust version -- I wish there were.  We could add a manual asm or nightly feature in cargo, but nothing automatic that I'm aware of.

Damn, that sounds like a major oversight. If I'm feeling particularly ambitious
maybe I'll work on adding that to rustc.
That said - I also wrote a patch that implements all the low level arithmetic
(the same ones the asm patch implements) without using DoubleBigDigit, so
BigDigit can be changed to usize - that actually gets us most of the performance
of the asm patch (which is still rather simple and dumb).
I pushed that patch out, and also rebased everything on top of your stuff.

Let's step back a little and keep focus in this PR, and especially do what we can without breaking API.  We can do more in followup PRs.  So let's keep the basic add/sub/mul optimizations (first four commits).  The ops against primitives can be their own PR, a lot like what #125 did for complex numbers.  The BigDigit changes constitute an API break -- which I am open to, but we'd need to bump semver, and if we do this I'd like to hide BigDigit entirely as an implementation detail.  (But perhaps some of your optimizations avoiding DoubleBigDigit are still usable right now, if they still help with u32 BigDigit.)
I'll add a few more inline comments too...

Thanks for the review feedback.
On Sun, Nov 22, 2015 at 05:31:23PM -0800, Josh Stone wrote:

Let's step back a little and keep focus in this PR, and especially do what we can without breaking API.  We can do more in followup PRs.  So let's keep the basic add/sub/mul optimizations (first four commits).  The ops against primitives can be their own PR, a lot like what #125 did for complex numbers.

Alright, sounds good.
I do have a patch to improve divide performance - do you mind including that, to
fix the issue with the benchmark taking too long to run?
The only thing I haven't changed per your comments is add/add2 and the way carry
is handled - it's a relatively minor issue, but I feel better about handling the
carry within add2 instead of returning it.
Reason being in the other places where add2 is used (multiply/divide), if they
don't size a correctly to hold the result then that's a serious bug (we'd return
an incorrect result) - and the way I've got it now we always catch that with an
assert, but if add2 is returning a carry bit then it's up to the caller to
check.
We could handle that with more wrapper functions, but... it just seems not worth
it as long as the extra push/pop isn't an actual performance issue (and it
really shouldn't be, having to realloc the vec won't be the common case).
So I wouldn't mind if it's changed later but I lean towards leaving it with the
extra push/pop for now.
Aside from that - I incorporated all your review feedback, and pushed with just
the performance optimizations. Let me know if that works, or if you want me to
split the division optimizations off (but I hate having stuff multiply into a
crapton of different pull requests).

The BigDigit changes constitute an API break -- which I am open to, but we'd need to bump semver, and if we do this I'd like to hide BigDigit entirely as an implementation detail.  (But perhaps some of your optimizations avoiding DoubleBigDigit are still usable right now, if they still help with u32 BigDigit.)

nod Not used to having to consider API breakages.
BTW, what I'd really like is to come up with a good way of separating out the
implementation of the low level arithmetic (into another mod?) with a nice
abstract interface, in a way that's easy to select which one to build with.
And then ideally keep the DoubleBigDigit implementation, along with my BigDigit
= usize implementation and hopefully eventually fancy asm ones. Partly because I
can completely believe the DoubleBigDigit implementation could be faster on
different cpus, but also because it's definitely more readable.
So maybe something to consider if/when we do an API break, if you know a nice
clean way of doing all that.

"The benchmark is too slow?  Let me improve it by 500x..."  That's just scary.  I feel I now need to pick over that with a fine-toothed comb, but who am I to question Knuth's methods.  :smile:
Regarding the carry push/pop, it's a small point, but I'm afraid I still disagree.  I think we'd be better served by having two variants of add2 -- one that returns the extra carry, and one that asserts there is no carry (probably built on the former).  If you don't want to do this, I probably will, unless you can make a better case why this is harmful.  I expect it should perform no worse -- occasionally even better for avoiding capacity growth -- and it's conceptually cleaner to me.
Regarding API and implementations -- technically we could do whatever we want in implementation even now, as long as the public interfaces remain.  BigDigit and DoubleBigDigit could become vestigial types with no bearing on the true innards anymore.  However, new(digits: Vec<BigDigit>) does have a strong implication about what it's doing, that this should be a fast constructor by reusing that vector, so we probably don't want to stray too far.  When we finally do an API break, we should hide these innards completely so we're free to implement however we see best, rather than trying to juggle multiple implementations as you seem to suggest.
Patch comments inbound.  (Some of these may not even be for new changes, just things I didn't notice before.)

On Mon, Nov 30, 2015 at 03:38:14PM -0800, Josh Stone wrote:

"The benchmark is too slow?  Let me improve it by 500x..."  That's just scary.
I feel I now need to pick over that with a fine-toothed comb, but who am I to
question Knuth's methods.  :smile:

:D
The code isn't fresh in my head anymore but I had a suspicion as I was working
on it that the old code had the algorithm slightly wrong - at least, the logic
didn't quite match Knuth's algorithm but I didn't bother to try and figure out
if it affected the behaviour. I dug out my copy of TAOCP and just stuck to
Knuth's algorithm when I was working on it.

Regarding the carry push/pop, it's a small point, but I'm afraid I still disagree.  I think we'd be better served by having two variants of add2 -- one that returns the extra carry, and one that asserts there is no carry (probably built on the former).  If you don't want to do this, I probably will, unless you can make a better case why this is harmful.  I expect it should perform no worse -- occasionally even better for avoiding capacity growth -- and it's conceptually cleaner to me.

Alright, I can do the wrapper thing.

Regarding API and implementations -- technically we could do whatever we want in implementation even now, as long as the public interfaces remain.  BigDigit and DoubleBigDigit could become vestigial types with no bearing on the true innards anymore.  However, new(digits: Vec<BigDigit>) does have a strong implication about what it's doing, that this should be a fast constructor by reusing that vector, so we probably don't want to stray too far.  When we finally do an API break, we should hide these innards completely so we're free to implement however we see best, rather than trying to juggle multiple implementations as you seem to suggest.

Good point. I went and split out the implementations of the low level arithmetic
into different modules like I was talking about:
https://github.com/koverstreet/num/commit/ff06399293e90ffc21178f307aaa11546e6b85ff
btw - the operations I have the low level arithmatic module exposing right now
(like div_wide, which I saw you mentioned in another email) are ones that match
what you can do with (x86 at least, I don't know arm) assembly - that is,
there's no good reasons these operations available as intrinsics and my hope is
that's what happens eventually.
Although for add with carry/subtract with borrow, my language nerd friend (who's
working on Swift, and thus gets to interact with the llvm guys) tells me that
llvm can't really model instructions with two different outputs - the carry bit

so that may never happen.

Re: the vector constructor, if there's actual outside demand for that kind of
functionality (and I suppose there probably is) then it probably makes sense to
support it for multiple sizes of digit (say someone's bridging between gmp or
some other library and num; they're going to be stuck with whatever size digit
that other library uses).
We could do fast in place converion of vectors of arbitrary size digits to
biguints with a tiny bit of unsafe code - just cast (is it transmute in rust?)
the vector to the new type and then just fix the endianness thing in place.
So if you want to keep that functionality and hide BigDigit I could do that.

The new CI failure is in num-macros vs nightly rust -- I'll take a look at that.
I wouldn't even change the size of the public BigDigit without calling that a break.  But if we used TheRealBigDigit = usize internally (or even ditched giving it a name), that would be fine.
Adding vector conversions for any size u8..u64 sounds intriguing.  The example in Vec::from_raw_parts (1.0, nightly) is a good template.  You'd just have to pad zeros for alignment, tear it apart, restore with new lengths, and fix the endianness as you said.
Ideas for new PRs, not here. ;)

A few review items haven't been addressed yet:

Sanity checks in the benchmarks during setup, before iteration.
Add a debug assert for div_wide overflow conditions
Replace public Add/Sub on slices with private functions.
Update cmp_slice names to a/b_len.

They're all simple things, so I don't want to hold back this PR too long.  If you're already on holiday, maybe I'll go ahead and tweak these myself so we can merge. :)

On Thu, Dec 10, 2015 at 10:11:57AM -0800, Josh Stone wrote:

A few review items haven't been addressed yet:

Sanity checks in the benchmarks during setup, before iteration.
Add a debug assert for div_wide overflow conditions
Replace public Add/Sub on slices with private functions.
Update cmp_slice names to a/b_len.

They're all simple things, so I don't want to hold back this PR too long.  If you're already on holiday, maybe I'll go ahead and tweak these myself so we can merge. :)

Whoops, sorry, I got distracted with other code. I'll fix those up today :)

On Thu, Dec 10, 2015 at 10:11:57AM -0800, Josh Stone wrote:

A few review items haven't been addressed yet:

Sanity checks in the benchmarks during setup, before iteration.

Did you want something besides just testing multiply/divide against each other?
Because I added a test that does that.

Did you want something besides just testing multiply/divide against each
other?

That's fine.  I just want a little confidence in what we're benchmarking. :)

Because I added a test that does that.

Right, but that torture test is slow and ignored, and it's not even testing
the same inputs.  That's fine though, since we can easily let the benchmark
sanity-check itself.

On Thu, Dec 10, 2015 at 01:45:41PM -0800, Josh Stone wrote:

Did you want something besides just testing multiply/divide against each
other?

That's fine.  I just want a little confidence in what we're benchmarking. :)

Because I added a test that does that.

Right, but that torture test is slow and ignored, and it's not even testing
the same inputs.  That's fine though, since we can easily let the benchmark
sanity-check itself.

The torture test is doing exactly what I thought you meant for what to test in
the benchmark... or did you mean something else?

But it's ignored, for good reason, and not using the same input values as
the benchmark.
Let's not belabor this small point.  If it's still unclear, leave it to me
to add later.

On Thu, Dec 10, 2015 at 02:07:47PM -0800, Josh Stone wrote:

But it's ignored, for good reason, and not using the same input values as
the benchmark.
Let's not belabor this small point.  If it's still unclear, leave it to me
to add later.

Ok. Change it however you feel like :)

@homu r+ fa372e2

:zap: Test exempted - status

Thanks for your hard work!

Does rust support gprof yet?

Not directly, see rust-lang/rfcs#646.  Apparently kcov works though, like in this tutorial.


fix: logical size query at before initdb_lsn

With more realistic selection of gc_horizon in tests there is an immediate failure with trying to query logical size with lsn < initdb_lsn. Fixes that, adds illustration gathered from clarity of explaining this tenant size calculation to more people.
Cc: #2748, #2599.

The next_gc_cutoff term feels confusing. Next starting from what?

My thinking was that:

Timeline::gc updates Timeline::latest_gc_cutoff_lsn
This "emphemeral" is "more freshly calculated gc_cutoff" so "next_gc_cutoff"
When I was thinking of this, I had missed the cmp::min(cmp::min(disk_consistent_lsn, gc_info.horizon_cutoff), gc_info.pitr_cutoff) so I removed the comment about making moving the next_gc_cutoff as a method in GcInfo


Implement Skeptic pattern as a CircuitBreaker alternative

There's an interesting pattern called a "Skeptic" presented in this paper:
http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-77.pdf
(as seen on Werner Vogel's blog). It's somewhat similar to a CircuitBreaker but has different recovery behavior and perhaps deals better with intermittent problems. This would make an interesting addition to JRugged.

Brian and I are working with Silvia and Karen to implement the SkepticBreaker pattern as a project for an Open Source Computer Science class at UPenn. For now we're working on a forked repo - https://github.com/ekmason12/jrugged - in the CIS399 branch. We're currently in an implementation phase and plan to start rigorous testing once initial implementation is complete.

Awesome - I look forward to seeing the first pull request. :)

We've realized that the best way to include the SkepticBreaker as an alternative will likely involve some refactoring of CircuitBreaker and its related classes. I've attached a few slides below that show how we envision the new architecture.
We'd appreciate any feedback you might have - this direction will require a decent amount of refactoring and changing/adding tests, but we think that it makes sense in terms of structure and will organize the code shared by SkepticBreaker and CircuitBreaker.
Proposed Refactoring for SkepticBreaker.pdf

Ok - So, I think my first question is why two different factories? You went through the trouble to refactor (or propose a refactor) to get yourself an abstract breaker... wouldn't the factory essentially be giving you back a 'breaker' ? Whats the driving reason to have two factories instead of one? ie. a factory that gives me a reg break OR a skeptic breaker is really just an argument difference yes? (Even with having an abstract factory class).

We had wanted to keep them separate because of their different properties, but having one actually makes more sense to keep track of both types. We can handle their differences by having "addSkepticBreaker" and "addCircuitBreaker" methods in BreakerFactory. I've attached the updated architecture.
Proposed Refactoring for SkepticBreaker v2.pdf

Thanks guys - I think that makes much more sense now, the picture looks good and looking for much forward to seeing some of the refactor and code. ;)
@trevmex , @weggert - Any thoughts here on the design?

We're almost done with the refactor and testing, but we have a few questions about some implementation details, about the existing examples in jrugged-examples (we made one for SkepticBreaker), and also about how you'd like to review our changes.
Would you like to check out the code in our branch, or just have us submit a pull request? Also, do you have some time later this week to discuss some of the details about the SkepticBreaker and the examples?

A pull request would be awesome.  :)
Sure - what time did you have in mind?  I am going to be fairly busy on Thursday, but wed and friday are more open.  Lemme know.
Joe

Sounds good - we'll probably be able to send the request tomorrow.
Friday after 4pm would be best for us. If that doesn't work, one of us could probably find some time tomorrow. Thanks!


Toggling in and out of Preview Mode

Describe the bug
Currently on going to Preview mode, the quick button does not disappear and the Exit Preview button does not appear.
To exit you can use Esc button.
To Reproduce
Steps to reproduce the behaviour:

Go to cv-frontend-vue
From quick button panel
Select preview option
compare the difference with current simulator

@devartstar i have already solve this issue and raised a pr previous month regarding this , have a look at it , i think my pr will resolve the issue.

@GarvitSinghal47  Thanks for notifying!


fix: add mutiple packages to cdn modules

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Repeat notification of pokemon & Changing Despawn time

Checklist

[ x] I have read the FAQ
[x ] I have checked if this issue already exists (both open and closed issues)
[ x] I am using the most recent version of pogom from the master branch
[na] If this is an installation issue, I am posting my OS, OS version, python version, pip version
[ ] I'm posting the complete log
[x ] I'm using a descriptive title for this issue

My Issue
I kept getting re-notified when I had a notification on for Dratini.
It originally stated it was going to despawn at 14:00, but I received 3-4 more notifications after a period of 3-4 minutes, and the same Dratini would pop up again and again, and it would shift the despawn timer from :00 to :04~ 0:06 and :09.  It would essentially say it would despawn in about 1-2 minutes later than the last time it reported.
Unsure how to submit any sort of log with this.  If it happens again I can try and reproduce the information.
...

Getting this as well. Dunno why. Shouldnt be happening.

Same issue here some off the notifications keep coming back and timer gets changes Windows/Google Chrome

Same here, also Windows/Google Chrome.

Should be fixed in 08164c0857d5d5af5db7bffb92e5442f47ced84d.


Revert "Hannah's Drawing App Peer Review"

Reverts silshack/spring2016#694
I accidentally merged this pull request because the branch was located under mine for some reason, I'm really sorry!

@tsukori thanks for the apology.  But in this case reverting makes more of a problem, since we want the post to end up in the repo eventually.  You were right to try to fix it, but in the future, just atmention me on a pull request like this instead of merging it yourself.  Remember, never merge your own pull request!

@eah13 I'm not entirely sure what exactly led to my post being under Will's branch. Was this a mistake on my end? (and if so, can it be fixed?)
I also made a second pull request in the case that this one has to be deleted.


[SP-4429] Backport of PDI-17343 - Job Transformation Step does not re…

…ceive parameters from fields (8.1 Suite)

Build Completed
:fire: This pull request has some issues. It would be preferable to fix them in order for it to be just perfect. See below for more details. Some links are also available below for further assistance in addressing those issues.
Build Commands
mvn -B -fn -f 'pom.xml' -pl 'engine' -P '!assemblies' -Dsurefire.runOrder=alphabetical -Daudit -amd clean install

Cleanup Commands
mvn -B -f 'pom.xml' -pl 'engine' -P '!assemblies' -amd build-helper:remove-project-artifact

Changed files
  engine/src/main/java/org/pentaho/di/job/entries/trans/JobEntryTrans.java
  engine/src/test/java/org/pentaho/di/job/entries/trans/JobEntryTransTest.java

Unit Test Coverage
These statistics help you identify how your changes have affected the coverage of the following files. If a file is not in this list, then its coverage was not affected by your changes. To get some help interpreting these metrics, please refer to Jacoco's documentation.

:warning: Coverage Changes (click to expand)
org.pentaho.di.trans.steps.checksum.CheckSumMeta

Instruction Change: -0.2% :small_red_triangle_down:

org.pentaho.di.job.entries.evaluatetablecontent.JobEntryEvalTableContent

Branch Change: -1.1% :small_red_triangle_down:
Complexity Change: -1.1% :small_red_triangle_down:
Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.job.entries.getpop.MailConnectionMeta

Branch Change: -1% :small_red_triangle_down:
Complexity Change: -1.5% :small_red_triangle_down:
Instruction Change: -0.3% :small_red_triangle_down:

org.pentaho.di.trans.steps.ldapoutput.LDAPOutputMeta

Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.trans.steps.replacestring.ReplaceStringMeta

Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.trans.steps.sort.SortRowsMeta

Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.trans.steps.textfileinput.TextFileInputMeta

Branch Change: -0.5% :small_red_triangle_down:

org.pentaho.di.trans.steps.gpload.GPLoadMeta

Branch Change: -0.9% :small_red_triangle_down:
Complexity Change: -0.8% :small_red_triangle_down:
Instruction Change: -0.2% :small_red_triangle_down:


M3-1397 Refactor services/misc

Add comment strings
Add get method for /regions/:regionID

Coverage increased (+0.005%) to 26.712% when pulling 9ca7b5c3403b3c4733c153c1675f7c20b52d51ab on Jskobos:M3-1397-refactor-misc-services into 47bb710493204b948c5113f004cb3a7b25e8413f on linode:develop.


Fireworks

Fireworks show up when you say congrats, or when you tell the bot to say congrats. 🎉

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