[.NET] Case sensitive string comparisons

Platform
What platform is your issue or question related to? (Delete other platforms).

.NET HTML
.NET WPF

Issue
.NET seems to be making case sensitive string comparisons. The button in the following card does not render due to the type being "Action.OpenURL" rather than "Action.OpenUrl"
{
  "$schema": "http://adaptivecards.io/schemas/adaptive-card.json",
  "type": "AdaptiveCard",
  "version": "1.0",
  "body": [
    {
      "type": "TextBlock",
      "text": "This card's action will open a URL"
    }
  ],
  "actions": [
    {
      "type": "Action.OpenURL",
      "title": "Action.OpenUrl",
      "url": "http://adaptivecards.io"
    }
  ]
}

Moving this out of 1.2 for now

Fixing this issue is not currently on our roadmap. Feel free to continue the conversation on this issue. If you feel strongly about this issue, please let us know and we can reevaluate.


Revert "update falco chart to 3.6.1"

Reverts falcosecurity/charts#527

Thanks for your pull request. Before we can look at it, you'll need to add a 'DCO signoff' to your commits.
:memo: Please follow instructions in the contributing guide to update your commits with the DCO
Full details of the Developer Certificate of Origin can be found at developercertificate.org.
The list of commits missing DCO signoff:

6bcc64c Revert "update falco chart to 3.6.1░"

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: Issif
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [Issif]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

you need to move forward never backwards


Fails to recognize wasm-bindgen outside of [dependencies] in Cargo.toml

🐛 Bug description
Currently wasm-pack will automatically verify that wasm-bindgen is listed in your manifest (yay!) but it doesn't catch situations like:
[target.wasm32-unknown-unknown.dependencies]
wasm-bindgen = "0.2"

printing the error:
Ensure that you have "wasm-bindgen" as a dependency in your Cargo.toml file:
[dependencies]
wasm-bindgen = "0.2"

Projects that support multiple platforms may not always pull wasm-bindgen in on all platforms, so this may come up in various libraries that want to use wasm-pack test but also want to have a different api for other platforms!

This should be fixed by using lockfiles now, yeah?


Investigate improving visual regression tests

https://github.com/bokuweb/reg-actions should make it possible to generate regression suites and add them as artifacts, making the presentation in a PR much better than the current setup.

More important than this: Figure out how to make them stable. Locally, I've run several times in a row, updating the baseline each time, and always had failures..


Convert NewType.hs to ghc-lib-parser

Very "initial"
I might need help/hand-holding for stuff outside this module, which is:

Pretty-printing (which currently only seems to come from HSE, as far as I could see)
Correctly propagating newtypeHint

All the things that need to be done are TODO'd

Be aware that https://github.com/ndmitchell/hlint/pull/698 is changing the newtype hints simultaneously.

Be aware that #698 is changing the newtype hints simultaneously.

Thanks! I'll rebase at some point.

I've decided to not do #697 here, because it's a bit more complicated than I thought, and I see no benefit to trying to do both at once.

@ndmitchell
I think this is ready to go (tests are passing)! I left some comments on uncertainties I had/have.

Thanks a lot - nice work!


Added ICU 59.1 URL

Thanks for contributing this pull request. However, the repositories of individual Symfony Components are read-only, so pull requests are ignored. Please, submit this pull request to the main Symfony repository at https://github.com/symfony/symfony/pulls
Thank you!


Memory leak when repeatedly loading and deleting keras models

If a Keras model is saved using tf.saved_model.save and then repeatedly loaded with tf.saved_model.load and deleted with del it becomes apparent that there is a slow memory leak.  keras.backend.clear_session does not resolve this issue.  See attached gist for an example that reproduces this issue in TensorFlow 2.2 on Google Colab.
System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow):
I have attached a custom repro case, but this appears to happen for various types of typical keras models.
OS Platform and Distribution (e.g., Linux Ubuntu 16.04):
Can reproduce in Google Colab and Docker RedHat images
Mobile device (e.g. iPhone 8, Pixel 2, Samsung Galaxy) if the issue happens on mobile device:
not tested
TensorFlow installed from (source or binary):
binary (from pip)
TensorFlow version (use command below):
('2.2.0', 'v2.2.0-0-g2b96f3662b')
Python version:
3.6.9 (google colab)
Bazel version (if compiling from source):
N/A
GCC/Compiler version (if compiling from source):
N/A
CUDA/cuDNN version:
default in google colab
GPU model and memory:
default in google colab

Describe the current behavior
When Keras models are saved / loaded repeatedly, memory usage gradually continues to grow over time.  For dynamic model servers that load and unload models over time, this may eventually lead to a crash due to memory exhaustion.
Describe the expected behavior
All memory should be recovered after a keras model instance is deleted with del and the garbage collector is run with gc.collect().
Standalone code to reproduce the issue
The following GitHub gist demonstrates the issue (can also be run in Colab):
https://gist.github.com/idfah/dff83de8d2a6406c9b92221e6282a8d6

Was able to reproduce the issue with TF v2.2 and TF-nightly. Please find the attached gist. Thanks!

verified that the same behavior is present in 2.0, 2.1 and 2.2

Hello,
I have some more info to add to this issue. I have run a bunch of experiments and have observed the following:

There is a small but persistent memory leak whenever models are loaded multiple times.
The leak seems to depend on the number of layers.
The leak seems to be independent of number of variables/parameters.

I have uploaded my experiments here. I have 3 models having roughly the same number of parameters but spread across different layers. The memory leak seems to be the least when there is only 1 hidden layer. There is almost a 10x memory leak increase when I increase the layers from 1 hidden layer to 15 hidden layers. All while keeping the # of parameters/variables (roughly) fixed. Maybe there is something in the way Keras instantiates layers that is causing this issue?
cc: @frreiss

Preliminary results from profiling the example program @kmh4321 provided with pympler and gperftools:

The leak does not appear to be in the Python heap (or at least the portion of the Python heap that pympler can see).
There's a pretty substantial amount of memory leakage of objects allocated from various subroutines of TF_GraphImportGraphDefWithResults. I'm guessing that some part of the Python code is leaking handles to TF_Graph objects located on the C++ heap.
The memory that gperftools' profiler can see adds up to about 75% of the actual memory usage of my test process. That's probably good enough for this case.
The stack traces I'm getting from pprof --text --stacks are kind of garbled right now, probably because I'm using TensorFlow 2.2.0 binaries from PyPI. I'll try building a version of TensorFlow with debug symbols overnight.

Here's the output of pprof --text --stacks in case anyone else can make more sense out of it:pprof.out.txt

I've identified the cause of this leak. While loading functions from the SavedModel file, function_deserialization.load_function_def_library() executes these two lines:
    if context.executing_eagerly():
      func.add_to_graph(ops.get_default_graph())

See source file here.
These lines create a second copy of the body of each function and stick that second copy into a dictionary hanging off a tf.Graph that is in turn hanging off a global variable. That second copy of the function is never deleted.
This problem appears to have been patched on the master branch four months ago; see this commit.
It would be a really good idea to backport this fix to the 2.2 branch. I'm not sure why it wasn't backported in the first place. TensorFlow 2.2.0 came out almost two months after this fix was pushed into the master branch.
It would also be a good idea to backport this fix to the 2.1 branch.

I've identified a workaround cuts this memory leakage by about 80%: Load the model from a temporary background thread.
 Still leaks memory, but at a lower rate.
  """
  import threading
  from typing import Any, Dict
  def callback(path: str, result_holder: Dict[str, Any]) -> None:
    try:
      result_holder["model"] = tf.saved_model.load(path)
    except Exception as e:
      result_holder["error"] = e

  # Call saved_model.load() in a background thread
  thread_results = {}
  t = threading.Thread(target=callback, args=[saved_model_path, thread_results])
  t.start()
  t.join()

  # Forward any exceptions thrown by the background thread
  if "error" in thread_results:
    raise thread_results["error"]
  return thread_results["model"]

After putting this workaround in place, the test case described above still leaks memory on TensorFlow 2.2.0. However, the leakage occurs at a much slower rate. I suspect that there is a second memory leak in TensorFlow 2.2.0's model loading path, and that this second leak has also been patched on the master without backporting the patch to the 2.2 branch.

@k-w-w would it be possible to add the fix from the current master branch to the 2.2 branch?

I've identified the cause of this leak. While loading functions from the SavedModel file, function_deserialization.load_function_def_library() executes these two lines:
    if context.executing_eagerly():
      func.add_to_graph(ops.get_default_graph())

See source file here.
These lines create a second copy of the body of each function and stick that second copy into a dictionary hanging off a tf.Graph that is in turn hanging off a global variable. That second copy of the function is never deleted.
This problem appears to have been patched on the master branch four months ago; see this commit.
It would be a really good idea to backport this fix to the 2.2 branch. I'm not sure why it wasn't backported in the first place. TensorFlow 2.2.0 came out almost two months after this fix was pushed into the master branch.
It would also be a good idea to backport this fix to the 2.1 branch.

Some updates:

I have tracked down the second memory leak.
I have identified a workaround for the second leak.
There is a third leak.

Details follow.
The root cause of the second memory leak is the lines immediately before the lines I pointed out in my previous comment:
(python/saved_model/function_deserialization.py:
316    func = function_lib.ConcreteFunction(func_graph)
317    func.add_to_graph()
318    if context.executing_eagerly():
319      func.add_to_graph(ops.get_default_graph())

Line 316 creates a ConcreteFunction object. The initializer for ConcreteFunction adds the function to the current eager execution context and creates an  _EagerDefinedFunctionDeleter callback object to that will remove the function from the context when the ConcreteFunction goes out of scope.
Then line 317 calls add_to_graph() on the ConcreteFunction, implicitly passing None for the g (graph) parameter. ConcreteFunction.add_to_graph() passes its g argument down to _EagerDefinedFunction.add_to_graph(). And _EagerDefinedFunction.add_to_graph() will call TFE_ContextAddFunctionDef if its g parameter is None. TFE_ContextAddFunctionDef is actually a thin wrapper around TFE_ContextAddFunction.
So every function in the SavedModel is passed twice to TFE_ContextAddFunction.
When TFE_ContextAddFunction is called with a function definition whose name happens to match an existing function in the context, TFE_ContextAddFunction ignores the function definition that was passed to it (a disastrous design flaw IMO -- what if the second copy of the function isn't the same as the first one?) and increments the existing function's reference count.
So every function in the SavedModel ends up instantiated in the current context with a reference count of 2.
When the model's surrogate Python object goes out of scope, the ConcreteFunction objects under it also go out of scope, which causes the _EagerDefinedFunctionDeleter objects attached to them to go out of scope, which triggers a single call to TFE_ContextRemoveFunction for each function. In spite of its name, the TFE_ContextRemoveFunction API call does not actually remove the function whose name is passed to it unless the reference count of that function is 1. And every function in the SavedModel has a reference count of 2.
This second memory leak is also fixed in commit<PHONE_NUMBER>f5dd65340f03332ff1d474de69c052
After that commit, line 317 is replaced with:
  func.add_to_graph(graph)

where graph is a temporary Graph object. Having the g parameter of ConcreteFunction.add_to_graph() set to a value other than None prevents the leaky code in _EagerDefinedFunction.add_to_graph() from running.
Here's an updated version of my workaround that corrects for both memory leaks:
def load_model_hack(saved_model_path: str):
  """
  Load a SavedModel without leaking as much memory as usual.

  This function applies two workarounds:
  * Load the model from a temporary background thread so that
    `saved_model.load()` won't leave garbage hanging off of the global
    default graph
  * Unpin functions that `saved_model.load()` pins twice, so that the
    garbage collection logic in `ConcreteFunction` will correctly remove
    these functions when the restored model goes out of scope..
  """
  import threading
  from typing import Any, Dict
  def callback(path: str, result_holder: Dict[str, Any]) -> None:
    """Callback function to be executed in a background thread"""
    try:
      result_holder["model"] = tf.saved_model.load(path)

      # Every function that was pinned twice (and hopefully exactly those
      # functions) should now be in the background thread's global default
      # graph. Unpin these functions once.
      default_graph = tf.compat.v1.get_default_graph()
      for function_name in default_graph._functions.keys():
        tf.python.context.remove_function(function_name)
    except Exception as e:
      result_holder["error"] = e

  # Call saved_model.load() in a background thread
  thread_results = {}
  t = threading.Thread(target=callback, args=[saved_model_path, thread_results])
  t.start()
  t.join()

  # Forward any exceptions thrown by the background thread
  if "error" in thread_results:
    raise thread_results["error"]
  return thread_results["model"]

This workaround further reduces the amount of memory that my test program leaks. However it does not completely eliminate memory leakage.

Updates:

I have found the third leak.
The patch for the first two leaks also patched the third leak.
I have updated my workaround to cover all three leaks.
There is a fourth leak.

Details follow.
Loader._load_nodes() walks through the graph, reconstituting each part of the
graph from its serialized Protocol Buffers representation.
(See line 264 in tensorflow/python/saved_model/load.py)
258    # Re-create everything except slot variables.
259    for node_id, proto in enumerate(self._proto.nodes):
260      if node_id in slot_variable_node_ids:
261        # Defer recreating slot variables so we can use the public Optimizer
262        # interface.
263        continue
264      node, setter = self._recreate(proto, node_id)   <<<<<<<<<<<
265      nodes[node_id] = node
266      node_setters[node_id] = setter

The proto variable here is a surrogate object for a SavedObject message:
(in tensorflow/core/protobuf/saved_object_graph.proto)
message SavedObject {
  // Objects which this object depends on: named edges in the dependency
  // graph.
  //
  // Note: currently only valid if kind == "user_object".
  repeated TrackableObjectGraph.TrackableObject.ObjectReference children = 1;

  // Removed when forking SavedObject from TrackableObjectGraph.
  reserved "attributes";
  reserved 2;

  // Slot variables owned by this object. This describes the three-way
  // (optimizer, variable, slot variable) relationship; none of the three
  // depend on the others directly.
  //
  // Note: currently only valid if kind == "user_object".
  repeated TrackableObjectGraph.TrackableObject.SlotVariableReference
      slot_variables = 3;

  oneof kind {
    SavedUserObject user_object = 4;
    SavedAsset asset = 5;
    SavedFunction function = 6;
    SavedVariable variable = 7;
    SavedBareConcreteFunction bare_concrete_function = 8;
    SavedConstant constant = 9;
    SavedResource resource = 10;
  }
}

Loader._recreate() is an unnecessarily-complex switch statement.  Here are the
relevant snippets:
(in tensorflow/python/saved_model/load.py)
353  def _recreate(self, proto, node_id):
354    """Creates a Python object from a SavedObject protocol buffer."""
355    factory = {
356        "user_object": (
357            lambda: self._recreate_user_object(proto.user_object, node_id)),
358        "asset": lambda: self._recreate_asset(proto.asset),
359        "function": lambda: self._recreate_function(proto.function),
360        "bare_concrete_function": functools.partial(
361            self._recreate_bare_concrete_function,
362            proto.bare_concrete_function),
363        "variable": lambda: self._recreate_variable(proto.variable),
364        "constant": lambda: self._recreate_constant(proto.constant),
365        "resource": lambda: self._recreate_resource(proto.resource),
366    }
367    kind = proto.WhichOneof("kind")
368    if kind not in factory:
369      raise ValueError("Unknown SavedObject type: %r" % kind)
360    return factory[kind]()

...

396  def _recreate_function(self, proto):
397    return function_deserialization.recreate_function(
398        proto, self._concrete_functions), setattr

In the case of this memory leak, the SavedObject message in the variable
proto has its kind field set to bare_concrete_function. So the above
abomination translates into:
if proto.kind is bare_concrete_function:
    node = function_deserialization.setup_bare_concrete_function(proto,
        self._concrete_functions)
    setter = getattr
    return node, setter
else ... # code that doesn't execute for this case

(The reference to getattr feeds another bit of spaghetti code elsewhere in
load.py.)
function_deserialization.setup_bare_concrete_function() looks up the
already-deserialized ConcreteFunction object, then calls that object's
add_to_graph() method (line 172 below).
(in tensorflow/python/saved_model/function_deserialization.py)
159 def setup_bare_concrete_function(saved_bare_concrete_function,
160                                 concrete_functions):
161  """Makes a restored bare concrete function callable."""
160  # Bare concrete functions accept only flat lists of Tensors with unique
163  # names.
164  concrete_function = concrete_functions[
165      saved_bare_concrete_function.concrete_function_name]
166  # pylint: disable=protected-access
167  concrete_function._arg_keywords = (
168      saved_bare_concrete_function.argument_keywords)
169  concrete_function._num_positional_args = (
170      saved_bare_concrete_function.allowed_positional_arguments)
171  # pylint: enable=protected-access
172  concrete_function.add_to_graph()     <<<<<<<<<<
173  return concrete_function

Of course, the code that created the ConcreteFunction object in the first
place has already added it to the graph twice.
And due to same the root cause as leaks 1 and 2, the ConcreteFunction's graph
pointer is set to None, so ConcreteFunction.add_to_graph() calls
_EagerDefinedFunction.add_to_graph(), which adds the function to the eager
execution context a third time.
Unfortunately, the Loader class discards all information about what functions
it has given this special treatment to, so a workaround along the lines of what
I posted in my previous comment is not going to work. Here's my new workaround,
which involves live-patching the function deletion callbacks in the background
thread's global default graph:
class DeleteWithExtremePrejudice(object):
  """
  A version of _EagerDefinedFunctionDeleter (see
  tensorflow/python/eager/function.py) that keeps deleting the target function
  until an InvalidArgumentError execption is thrown.  Checking for that
  exception is the only way to ensure that a function really has been deleted
  and is not, in fact, still taking up memory.
  """

  def __init__(self, func_name):
    self.func_name = func_name

  def __del__(self):
    MAX_ATTEMPTS = 10
    try:
      for i in range(MAX_ATTEMPTS):
        tf.python.context.remove_function(self.func_name)
      # If we get here, removal did *not* fail as expected.
      print(f"WARNING: Failed to remove function "
            f"'{self.func_name}' after {MAX_ATTEMPTS} attempts. "
            f"This problem may result in a memory leak.")
    except tf.errors.InvalidArgumentError:
      # tf.python.context.remove_function() throws this exception when
      # you try to remove a function that has already been removed.
      # In the case of this `try` clause, such behavior is "normal".
      pass
    except Exception as e:
      print(f"WARNING: {e} thrown when attempting to delete function "
            f"'{self.func_name}'. This problem may result in a memory leak.")

def load_model_hack(saved_model_path: str):
  """
  Load a SavedModel without leaking memory.

  This function applies two workarounds:
  * Load the model from a temporary background thread so that
    `saved_model.load()` won't leave garbage hanging off of the global
    default graph
  * Patch the garbage collection callbacks of all `ConcreteFunction`s
    in the returned model so that these functions will be properly removed
    when the restored model goes out of scope.
  """
  import threading
  from typing import Any, Dict
  def callback(path: str, result_holder: Dict[str, Any]) -> None:
    """Callback function to be executed in a background thread"""
    try:
      model = tf.saved_model.load(path)

      # Every function that was pinned two or more times should now be
      # in the current thread's global default graph variable.
      # Replace the deletion callbacks of these functions with a more
      # effective version.
      default_graph = tf.compat.v1.get_default_graph()
      for func in default_graph._functions.values():
        func._function_deleter = DeleteWithExtremePrejudice(func.name)
        # NOTE: This assignment will trigger the previous deletion callback.
        # That's ok, because every function in this list has been pinned
        # at least twice.

      result_holder["model"] = model

    except Exception as e:
      result_holder["error"] = e

  # Call saved_model.load() in a background thread
  thread_results = {}
  t = threading.Thread(target=callback, args=[saved_model_path, thread_results])
  t.start()
  t.join()

After applying this workaround, my test program leaks significantly less memory before, but it still leaks memory.

@idfah Recently there were some updates to reduce the memory leak. I ran your code with recent tf-nightly and see a loss of ~12 MB over 500 iterations. Can you please check the this gist and let us know what you think.
Please verify and close the issue If this was resolved for you. Thanks!

@jvishnuvardhan, I think this issue needs to be kept open a while longer.
So far, we have verified that there is a serious memory leak in tf.saved_model.load() in TensorFlow 2.0.x, 2.1.x, and 2.2.x.
I would categorize this leak as a blocker for any application that needs to cycle models in and out of memory -- for example, to process a corpus of documents that span multiple languages; or to serve multiple versions of the same model. Our simple test program "only" leaks a few megabytes each time the model is loaded, but larger models with weights embedded in their graphs can leak hundreds of megabytes per load/unload cycle.
The leak is actually three leaks, all of which were patched in master back in March (in commit<PHONE_NUMBER>f5dd65340f03332ff1d474de69c052). However, the fix was not included in the May release of TensorFlow 2.2.0.  As of today, five months later, the fix has not been ported to the 2.2.x, 2.1.x, or 2.0.x branches of TensorFlow.
TensorFlow 2.3.0 includes the fix for these three memory leaks.  However, fixing this bug in 2.3.0 does not resolve this issue for us.  My colleagues are currently using TensorFlow 2.2.x.
In addition to the three large leaks, there is a fourth leak that is not currently patched in the master branch.  You can see the presence of this fourth leak in the output of the notebook linked in your previous comment:

With the simple 2-layer model in your example notebook, each call to saved_model.load() leaks about 25kb of memory.  Larger models leak more, probably a megabyte or two for a medium-sized deep learning model.  This level of memory leakage is something that one could plausibly work around with periodic reboots; but I would submit that tf.saved_model.load() ought not to leak any memory at all.  Authors of long-running applications should be able to load and unload TensorFlow models without worrying about running out of memory.
I have tracked the root cause of the fourth leak to a problem in TensorFlow's mechanism for caching kernels.
In addition to creating graphs, tf.saved_model.load() executes operations in those graphs, primarily for the purpose of restoring variable values. The code that executes these operations is EagerExecute(), which calls EagerLocalExecute(), which calls GetOrCreateKernelAndDevice(), which asks the current EagerContext to look for the kernel for each operation in its kernel cache.
The EagerContext class maintains a cache of kernel instances:
(in tensorflow/core/common_runtime/eager/context.h, direct link here)
612  std::unordered_map<Fprint128, core::RefCountPtr<KernelAndDevice>,
613                     Fprint128Hasher>
614      kernel_cache_ TF_GUARDED_BY(cache_mu_);

The kernel cache does not have a size limit. There is an API call to clear the cache, but the Python side of TensorFlow only uses that API call when resetting the global random seed.
Each entry in the cache is parameterized by the "fingerprint" of the associated operation. This "fingerprint" is a hash value computed from multiple parameters of the operation, including all of the operation's attributes.
saved_model.load() restores variables through a process that involves invoking multiple instances of the VarHandleOp operation. Due to the graph rewriting that happens during model loading, each of these operations has a unique value in the shared_name field if its attributes.  These unique values cause the operations to have unique fingerprints, even across multiple load operations on the same model. Each unique fingerprint causes the creation of a new entry in the cache.  The cache is of unlimited size and is never cleared, so memory usage for these cached kernels grows in an unbounded fashion.
The best workaround I've found for this problem is to have your Python application periodically clear the cache via the internal API. Here's some Python code to do so:
import tensorflow.python as tf_internals
context_handle = tf_internals.eager.context.context()._context_handle
if context_handle is not None:
  tf_internals.pywrap_tfe.TFE_ContextClearCaches(context_handle)

A more permanent fix would be to evict stale entries from the cache following a least recently used policy. I'm working on a PR to apply such a fix.
The above workaround reduces but does not eliminate the memory leakage of my test program.  Before the workaround, each call to saved_model.load() leaked about 125kb on TensorFlow 2.3.0 and 115kb on tf-nightly.  After the workaround, each call leaks about 30kb and 20kb on TensorFlow 2.3.0 and nightly, respectively. I haven't checked whether this remaining leakage is constant or whether it scales with model size. However, since the leakage appears to be coming from a graph rewrite, I would expect the amount of memory leaked to scale with model size.

Not sure why tensorflow-butler thinks this issue hasn't had recent activity. There is an open pull request for part of the problem described here.

@frreiss regarding the backport, we typically dont backport bug fixes into previous releases. Is it possible for you to use a later version like TF 2.3.0 which has the fixes ?
Regarding the 4th leak, I dont see any pull request that is open currently, is this something you are working on ?

Hi @goldiegadde . I see from the release notes that TensorFlow 2.3.1 includes 25 bug fixes, and TensorFlow 2.2.1 includes 19 bug fixes. Perhaps you meant to say that you typically don't backport fixes for memory leaks?
Moving to 2.3.x is the only viable option for us at this point, and my colleagues will be doing so in spite of the disruption that this entails.
The fourth leak is currently low on my priority list because https://github.com/tensorflow/tensorflow/issues/33412 is a much more severe problem for us. Hopefully that fourth leak fixes itself.

I just tested the above colab notebook with the latest tf-nightly (version 2.5.0-dev20201214) and this memory increase with iterations looks reduced by a fair bit. Its unclear to me if this is fully fixed, but perhaps the fourth memory leak you mentioned has been fixed.

I think this issue is as fixed as it's going to be. What do you think, @idfah ?

I think this issue is as fixed as it's going to be. What do you think, @idfah ?

@frreiss the patch you referred to has been cherrypicked into 2.2.2 as well. I am closing this bug for now if any other issues linger can you please open a new one?
Thanks!

@frreiss the patch you referred to has been cherrypicked into 2.2.2 as well. I am closing this bug for now if any other issues linger can you please open a new one?
Thanks!

Updates:

I have found the third leak.
The patch for the first two leaks also patched the third leak.
I have updated my workaround to cover all three leaks.
There is a fourth leak.

Details follow.
Loader._load_nodes() walks through the graph, reconstituting each part of the graph from its serialized Protocol Buffers representation.
(See line 264 in tensorflow/python/saved_model/load.py)
258    # Re-create everything except slot variables.
259    for node_id, proto in enumerate(self._proto.nodes):
260      if node_id in slot_variable_node_ids:
261        # Defer recreating slot variables so we can use the public Optimizer
262        # interface.
263        continue
264      node, setter = self._recreate(proto, node_id)   <<<<<<<<<<<
265      nodes[node_id] = node
266      node_setters[node_id] = setter

The proto variable here is a surrogate object for a SavedObject message:
(in tensorflow/core/protobuf/saved_object_graph.proto)
message SavedObject {
  // Objects which this object depends on: named edges in the dependency
  // graph.
  //
  // Note: currently only valid if kind == "user_object".
  repeated TrackableObjectGraph.TrackableObject.ObjectReference children = 1;

  // Removed when forking SavedObject from TrackableObjectGraph.
  reserved "attributes";
  reserved 2;

  // Slot variables owned by this object. This describes the three-way
  // (optimizer, variable, slot variable) relationship; none of the three
  // depend on the others directly.
  //
  // Note: currently only valid if kind == "user_object".
  repeated TrackableObjectGraph.TrackableObject.SlotVariableReference
      slot_variables = 3;

  oneof kind {
    SavedUserObject user_object = 4;
    SavedAsset asset = 5;
    SavedFunction function = 6;
    SavedVariable variable = 7;
    SavedBareConcreteFunction bare_concrete_function = 8;
    SavedConstant constant = 9;
    SavedResource resource = 10;
  }
}

Loader._recreate() is an unnecessarily-complex switch statement. Here are the relevant snippets:
(in tensorflow/python/saved_model/load.py)
353  def _recreate(self, proto, node_id):
354    """Creates a Python object from a SavedObject protocol buffer."""
355    factory = {
356        "user_object": (
357            lambda: self._recreate_user_object(proto.user_object, node_id)),
358        "asset": lambda: self._recreate_asset(proto.asset),
359        "function": lambda: self._recreate_function(proto.function),
360        "bare_concrete_function": functools.partial(
361            self._recreate_bare_concrete_function,
362            proto.bare_concrete_function),
363        "variable": lambda: self._recreate_variable(proto.variable),
364        "constant": lambda: self._recreate_constant(proto.constant),
365        "resource": lambda: self._recreate_resource(proto.resource),
366    }
367    kind = proto.WhichOneof("kind")
368    if kind not in factory:
369      raise ValueError("Unknown SavedObject type: %r" % kind)
360    return factory[kind]()

...

396  def _recreate_function(self, proto):
397    return function_deserialization.recreate_function(
398        proto, self._concrete_functions), setattr

In the case of this memory leak, the SavedObject message in the variable proto has its kind field set to bare_concrete_function. So the above translates into:
if proto.kind is bare_concrete_function:
    node = function_deserialization.setup_bare_concrete_function(proto,
        self._concrete_functions)
    setter = getattr
    return node, setter
else ... # code that doesn't execute for this case

(The reference to getattr feeds another bit of complex code elsewhere in load.py.)
function_deserialization.setup_bare_concrete_function() looks up the already-deserialized ConcreteFunction object, then calls that object's add_to_graph() method (line 172 below).
(in tensorflow/python/saved_model/function_deserialization.py)
159 def setup_bare_concrete_function(saved_bare_concrete_function,
160                                 concrete_functions):
161  """Makes a restored bare concrete function callable."""
160  # Bare concrete functions accept only flat lists of Tensors with unique
163  # names.
164  concrete_function = concrete_functions[
165      saved_bare_concrete_function.concrete_function_name]
166  # pylint: disable=protected-access
167  concrete_function._arg_keywords = (
168      saved_bare_concrete_function.argument_keywords)
169  concrete_function._num_positional_args = (
170      saved_bare_concrete_function.allowed_positional_arguments)
171  # pylint: enable=protected-access
172  concrete_function.add_to_graph()     <<<<<<<<<<
173  return concrete_function

Of course, the code that created the ConcreteFunction object in the first place has already added it to the graph twice.
And due to same the root cause as leaks 1 and 2, the ConcreteFunction's graph pointer is set to None, so ConcreteFunction.add_to_graph() calls _EagerDefinedFunction.add_to_graph(), which adds the function to the eager execution context a third time.
Unfortunately, the Loader class discards all information about what functions it has given this special treatment to, so a workaround along the lines of what I posted in my previous comment is not going to work. Here's my new workaround, which involves live-patching the function deletion callbacks in the background thread's global default graph:
class DeleteWithExtremePrejudice(object):
  """
  A version of _EagerDefinedFunctionDeleter (see
  tensorflow/python/eager/function.py) that keeps deleting the target function
  until an InvalidArgumentError exception is thrown.  Checking for that
  exception is the only way to ensure that a function really has been deleted
  and is not, in fact, still taking up memory.
  """

  def __init__(self, func_name):
    self.func_name = func_name

  def __del__(self):
    MAX_ATTEMPTS = 10
    try:
      for i in range(MAX_ATTEMPTS):
        tf.python.context.remove_function(self.func_name)
      # If we get here, removal did *not* fail as expected.
      print(f"WARNING: Failed to remove function "
            f"'{self.func_name}' after {MAX_ATTEMPTS} attempts. "
            f"This problem may result in a memory leak.")
    except tf.errors.InvalidArgumentError:
      # tf.python.context.remove_function() throws this exception when
      # you try to remove a function that has already been removed.
      # In the case of this `try` clause, such behavior is "normal".
      pass
    except Exception as e:
      print(f"WARNING: {e} thrown when attempting to delete function "
            f"'{self.func_name}'. This problem may result in a memory leak.")

def load_model_hack(saved_model_path: str):
  """
  Load a SavedModel without leaking memory.

  This function applies two workarounds:
  * Load the model from a temporary background thread so that
    `saved_model.load()` won't leave garbage hanging off of the global
    default graph
  * Patch the garbage collection callbacks of all `ConcreteFunction`s
    in the returned model so that these functions will be properly removed
    when the restored model goes out of scope.
  """
  import threading
  from typing import Any, Dict
  def callback(path: str, result_holder: Dict[str, Any]) -> None:
    """Callback function to be executed in a background thread"""
    try:
      model = tf.saved_model.load(path)

      # Every function that was pinned two or more times should now be
      # in the current thread's global default graph variable.
      # Replace the deletion callbacks of these functions with a more
      # effective version.
      default_graph = tf.compat.v1.get_default_graph()
      for func in default_graph._functions.values():
        func._function_deleter = DeleteWithExtremePrejudice(func.name)
        # NOTE: This assignment will trigger the previous deletion callback.
        # That's ok, because every function in this list has been pinned
        # at least twice.

      result_holder["model"] = model

    except Exception as e:
      result_holder["error"] = e

  # Call saved_model.load() in a background thread
  thread_results = {}
  t = threading.Thread(target=callback, args=[saved_model_path, thread_results])
  t.start()
  t.join()

After applying this workaround, my test program leaks significantly less memory than before, but it still leaks memory.

Wow when reading the third leak, I thought it would be hilarious if there is a fourth (though I think there would be a fifth), by any chance, have you documented the thinking and the tools used to track down these leaks?

Wow when reading the third leak, I thought it would be hilarious if there is a fourth (though I think there would be a fifth), by any chance, have you documented the thinking and the tools used to track down these leaks?

My main piece of advice in terms of tools is that the tools lie. TensorFlow is a very complex program with multiple heaps (Python heap, C heap, TensorFlow's own memory manager, and CUDA) and global data structures that can look like leaks at first glance. You need to use several leak checkers and cross-reference their outputs. For this particular issue, I used tcmalloc, pprof, Python's gc package, the PyCharm debugger, and some additional Python code to walk the heap from inside the program under test.


Missing Configuration for Partner tag

Where to configure partner tag?
Getting error as partner tag mismatch

The last parameter of AmazonProductAdvertisingClient


Updated media type to a format compatible with OCI registries

Note that i did not opt for bumping the version in the media type, only changing the encoding. I would be very interesting to hearing the pros/cons. As there are no semantical changes, I kept the semantic versioning. But I'm struggling to come to a resolution if that was a good or bad move. If we bump the semantic versions, some parts of the code will be more complicated client side. I'm easy to convince the semantic version should be bumped if there are more concrete use-cases where it would be simpler 😅
Summary
Closes https://github.com/sigstore/protobuf-specs/issues/165
Release Note
Added a new format for the media type that is compatible with OCI registries
Documentation
N/A

LGTM overall!
I'm also divided on bumping the version here:

On one hand, not bumping here will result in bundles/trust roots that clients will reject if (like sigstore-python) they perform strict matching on the media type.
On the other, this isn't really a breaking change in the underlying formats themselves, and bumping the version contributes to version fatigue here.

On the other, this isn't really a breaking change in the underlying formats themselves, and bumping the version contributes to version fatigue here.

This is exactly the one I tried to avoid :)
But yes, agree with all you said @woodruffw

Are there any clients generating v0.3 bundles yet?

In sigstore-js, we can verify a v0.3 bundle, but don't yet generate them.

sigstore-go isn't generating v3 bundles.

What about java and python, do you produce v0.3 bundles yet? @woodruffw @loosebazooka

I think it's okay to keep it at v3 for java. It's committed in code, but unused.

I think it's okay to keep it at v3 for java. It's committed in code, but unused.

Ah yeah, I forgot that nobody has really rolled out v3 bundle support yet. Given that, I think we're safe to not bump the version here!

Do we need to support application/vnd.dev.sigstore.bundle+json;version=0.3, or could we remove that string so we don't have two ways of representing v3 bundles?

Do we need to support application/vnd.dev.sigstore.bundle+json;version=0.3, or could we remove that string so we don't have two ways of representing v3 bundles?

That is a very tempting idea!
We do have a release/tag v0.3.0 out which specifies the version=0.3. So if we remove the old version 0.3, should we remove that release? And is it used? If we remove it It would be a breaking change? So I'm leaning towards keeping it.
The language we have now is:
        // MUST be application/vnd.dev.sigstore.bundle.v0.3+json when
        // when encoded as JSON.
        // Clients must to be able to accept media type using the previously
        // defined formats:
        // * application/vnd.dev.sigstore.bundle+json;version=0.1
        // * application/vnd.dev.sigstore.bundle+json;version=0.2
        // * application/vnd.dev.sigstore.bundle+json;version=0.3

To minimize the risk of breaking anything I think we should keep as is? It's unlikely, but someone can be using the v3 version in some private scenario and I would hate to make their lives harder.

Removing version=0.3 is temping, but I don't think we should muddle with the version history 😅
IMO, we can do the following

Tweak the language to say "v3 bundles MUST use the new version format, but clients MAY allow the old format for compatibility"
Release 0.3.1 with the changes

In practice, this should have no compatibility concerns, since no clients are generating v3 bundles at the moment.

I think we are more or less saying the same @woodruffw, but I think the language we have is enough? But yes, v0.3.1 tag is what I would propose too (but didn't write that) 😄

I think we are more or less saying the same @woodruffw, but I think the language we have is enough? But yes, v0.3.1 tag is what I would propose too (but didn't write that) 😄

Yes, I think so!

SGTM, agreed we shouldn't yank a release.

Merging since there's 3 LGTMs


Lab 2 typo

At the end of the last section of Lab 2.
"matrices" should say "matrix" here I believe

Agreed. Fixed it. Thanks for reporting and 1 point


Add support for non-Boolean flow variables (UPDATED)

This PR is a re-write of PR #13 based on feedback.
The new syntax is:
if_true eq('ONE', 1) do
  test :test1
 end
# would render to: if "ONE" == 1

if_true lt('ONE', 2) do
  test :test1
 end
# would render to: if "ONE" < 2

if_true expr(:and, eq('ONE',1), lt('ONE', 2)) do
  test :test1
 end
# would render to: if "ONE" == 1 && "ONE" < 2

Obviously, the rendering piece will be in origen_testers (working in a local branch) so this PR is just supporting the necessary ast nodes.

Hi @rlaj,
Thanks for picking this up again, definitely a great addition.
Coming back to this fresh, I'm wondering if we need the inverse if_false qualifier, given that we also have the ne expression to create negative logic.
See below for a proposal with only one keyword, whenever and with variants whenever_all and whenever_any to express AND/OR logic.
I think that aligns with the existing API since you can do if_failed and if_any_failed and if_all_failed to implement similar AND/ORing or multiple conditions.
What do you think?
whenever eq('ONE', 1) do
  test :test1
 end
# would render to: if "ONE" == 1

whenever lt('ONE', 2) do
  test :test1
 end
# would render to: if "ONE" < 2

whenever_all eq('ONE',1), lt('ONE', 2) do
  test :test1
 end
# would render to: if "ONE" == 1 && "ONE" < 2

whenever_any eq('ONE',1), lt('ONE', 2) do
  test :test1
 end
# would render to: if "ONE" == 1 || "ONE" < 2

What about the ability to initialize/set these variables, I think users of this will need/want that.
From the #13 discussion, I still think we should include something like this:
set 'ONE', 0
# would render to: "ONE" = 0

Well, this is timely. I want to render a batch of tests with a qualifier on the flow of site-var= my_site_var 1 and then duplicate the same tests qualified with site-var= my_site_var 2 etc. This syntax addition will be very useful.
The updates from @rlaj satisfy my need. @ginty the additional syntax you mention would provide a way to satisfy a separate internal request from the yammer page.

@rlaj @ginty Would these variable expressions be useful for rendering flow loops like this?
for @vol = 0.3; @vol < 0.4 ; @vol = @vol + 0.1; do
       test_number_loop_increment = 0
       {
          svlr_level_command(14,1,"VDDC",0.7 + @vol);
          {
             run_and_branch(Fmax_Search_g1)
             then
             {
             }
             else
             {
             }
          }, open,"fmax_search", ""
       }

Is 'vol' the type of variable this API interacts with?

I think loops would be an additional thing, but maybe we can at least add the ATP-level side of it right now if @rlaj doesn't mind.
How about this for an API?
# By default the var name will be generated
loop from: 0.3, to: 0.4, step: 0.1 do

end
# Would render:   for @loop1= 0.3; @loop1< 0.4 ; @loop1= @loop1 + 0.1; {

# Can optionally specify the var name if you want to be able to reference it within the block:
loop from: 0.3, to: 0.4, step: 0.1, var: "vol" do

end
# Would render:   for @vol= 0.3; @vol< 0.4 ; @vol= @vol+ 0.1; {

Thanks for the update @rlaj!
Any chance you could add a set method while you are at it?

Yes, will add the set and loop (actually just found my first use case for looping so it works out).

Thanks @rlaj, only minor comment is that I think it might be easier for downstream generation if we store a nil in the case of no var name being given.
Apart from that, looks good to go for me.

Good point, @ginty

OK so the loop code for V93K was never rendered it sounds like--- find this loop API so will work on the render.

Ok have the render for STM7 with a loop variable-- need to know what it would look like in SMT8 (never used) and how to handle if loop var is nil? @ginty ?


Add Racing Models

Added the controller and the logic to the service, but when I go to the endpoint, no data appears.

i was being silly and forgot the return keyword in my if statement lol. all good now


update agent fails to watch for ok-to-reboot label

With following error:
W0206 12:37:02.081765       1 agent.go:152] error waiting for an ok-to-reboot: waiting for annotation "flatcar-linux-update.v1.flatcar-linux.net/reboot-ok" failed: unhandled watch case for watch.Event{Type:"ERROR", Object:(*v1.Status)(0xc00024abe0)}

Reading the code, this is clearly a bug, as https://github.com/kinvolk/flatcar-linux-update-operator/blob/4036c440e59e886a6ee94af562ec3374d3292ba9/pkg/agent/agent.go#L303 assumes, that update should happen within 24 hours from starting the watch. However, if no updates are posted within 24 hours, this watch will be timing out.


Change theme when a different calendar is selected.

Color code the calendars that I am collaborator of and switch main palette depending on the selection.

Theme will be changed mine vs others.


Gh 1831 allow operation chain to be validated in an Operation

Codecov Report

Merging #1849 into develop will increase coverage by 1.52%.
The diff coverage is n/a.

@@              Coverage Diff              @@
##             develop    #1849      +/-   ##
=============================================
+ Coverage      65.33%   66.85%   +1.52%
+ Complexity      2116      680    -1436
=============================================
  Files            845      339     -506
  Lines          27976     9785   -18191
  Branches        3570     1008    -2562
=============================================
- Hits           18278     6542   -11736
+ Misses          8258     2829    -5429
+ Partials        1440      414    -1026

Impacted Files
Coverage Δ
Complexity Δ

...ava/uk/gov/gchq/gaffer/store/ElementValidator.java

...re/operation/declaration/OperationDeclaration.java

...n/java/uk/gov/gchq/gaffer/commonutil/LongUtil.java

...q/gaffer/commonutil/iterable/SuppliedIterable.java

...uk/gov/gchq/gaffer/operation/util/Conditional.java

.../export/resultcache/ExportToGafferResultCache.java

...k/gov/gchq/gaffer/core/exception/ErrorFactory.java

...xport/graph/handler/ExportToOtherGraphHandler.java

...operation/export/graph/GraphForExportDelegate.java

...java/uk/gov/gchq/gaffer/jobtracker/JobTracker.java

... and 493 more

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 03aa624...d234e15. Read the comment docs.


Feature: enable deep merge default directive config with FF

Description of changes
This allows public subscriptions to be generated on models, and adds use of a new feature flag to deep merge directive defaults. For a description of the behavior, see https://github.com/aws-amplify/amplify-cli/pull/10597

Issue #, if available
Internally tracked

Description of how you validated changes
Unit testing and sample application
Checklist

[ ] PR description included
[ ] yarn test passes
[ ] Tests are changed or added
[ ] Relevant documentation is changed or added (and PR referenced)
[ ] New AWS SDK calls or CloudFormation actions have been added to relevant test and service IAM policies

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Making a new branch that isn't a mess


Updated CONTRIBUTING with names of the project committers.

Fixes #749
Added list of project committer names to CONTRIBUTING.md

This should land before #1057


better support .js as entry point, and need more verbose info on slow types

I am trying to publish a tiny utility to test jsr. I really do not want to write typescript, I am ok with providing good typescript support.
why is jsr having issue with this index.js
/**
 * Map string values returned by {URLSearchParams} to boolean.
 * /?param - empty string -> true
 * /?param=1 - "1" -> true
 * /?param=true - "true" -> true
 *
 * false otherwise
 *
 * @param {string|null} val
 * @returns {boolean} boolean
 */
export const urlBool = val => {
  if (val === '' || val === '1' || val === 'true') return true
  return false
}

npx jsr publish --dry-run gives this warning
warning[unsupported-javascript-entrypoint]: used a JavaScript module without type declarations as an entrypoint
 --> C:\wrk\jsx6\libs\url-util\index.js
  = hint: add a type declaration (d.ts) for the JavaScript module, or rewrite it to TypeScript

  info: JavaScript files with no corresponding declaration require type inference to be type checked
  info: fast check avoids type inference, so JavaScript entrypoints should be avoided

I am open to suggestions how to improve the above, if it is possible without too much hassle. jsr.io is a nice idea, but for me ATM is too agressive.

Related https://github.com/jsr-io/jsr/issues/494

@marvinhagemeister thanks for the reference. I will be watching that issue, and try jsr.io again once #494 is resolved.


As a Data user I want to see the distribution of a particular species over time throughout the spatial area of interest ..so that I understand its coverage and the threats it faces

original id#34

We need to discuss the spatial and time aggregation.
Is this a table or a map?


ideas

Hi guys,
have a request idea. I don't know where to post those other than here. sorry.
Is there a way to have a close all function that only closes certain types of positions? like close_all_sell,  or close_all_buy?
thanks
Stuart

HI guys,
i found a way around this.
use magic number -  and enter a switch when trading.  value of 1 for buy,  vlaue of 2 for sell.
then you can do a close all by magic number to enable this functionality.
Stuart

closing.


MM-15219 Added support for introduction text in interactive dialogs

Summary
Adds support for rendering optional markdown formatted introduction text in interactive dialogs.
Ticket Link
https://mattermost.atlassian.net/browse/MM-15219
Checklist

[x] Added or updated unit tests (required for all new features)
[x] Has UI changes

Device Information
This PR was tested on: iPhone X Simulator (iOS 12.1)
Screenshots

@tgkouras margins are a bit off, maybe you can get some help in the UX Design channel for this. In any case horizontal margins are 16pt if I’m right

@enahum looks like the surrounding elements have a margin of 15pt

^I'll first let @aaronrothschild chime in on the second question

@esethna thanks for your feedback!  Regarding your points:

Yes, I agree.  It looks out of place otherwise.  I'll make the style changes to match the labels of the other elements.

That's an interesting point.  It currently uses the Markdown component, which doesn't seem to be stripping any markdown.  I'll try to post a screenshot of the different variations later tonight.

2. What Markdown is supported? What if I put in an inline image with ![test](img link)? Can you post an example screenshot using all the variations of markdown supported? Should we consider supporting only a subset of that and stripping the rest since it could open up cases for intorudcting a bad UX with all types of Markdown support cc// @jasonblais if you have thoughts on this based on the requirements of the feature

I agree that limiting the display of markdown being can avoid a bad experience for the end user .  If we go this route, I think - Bold, Italic, Links would suffice.  Headlines, Maybe.  It's hard to draw the line somewhere.
However, I trust that a developer would also consider the user experience before inserting 10 paragraphs and 6 images.  I think we shouldn't arbitrarily limit what a developer can do - they are trying to communicate with the user - a table may be useful, same with having an image.  It is only if they abuse the text box that it becomes bad... but then, it is likely this is coming from a plugin that can be disabled.
2/5 That we probably shouldn't try to limit what markdown is permitted in the box.
I say

2/5 That we probably shouldn't try to limit what markdown is permitted in the box.

4/5: I agree with @aaronrothschild, and see no compelling reason not to just support full Markdown here. Anything else seems confusing.

Cool, thanks for the feedback, agree with the decision

@migbot Gentle reminder to review this, so we can get this into v1.24.


Database

Completed..PLease Review My Code.

@madhu-1219
Task – database
Code not available. check and commit it once then update PR number with respective task in tracker


Fix typo in Text Compression page

What's changed, or what was fixed?

Changes an instance of content-heading to content-encoding.

Fixes: Issue not filed. If required for workflow, please file a stub issue on my behalf.
Target Live Date: At your convenience

[ ] This has been reviewed and approved by (NAME)
[ ] I have run npm test locally and all tests pass.
[ ] I have added the appropriate type-something label.
[ ] I've staged the site and manually verified that my content displays correctly.

CC: @petele
I have signed an individual CLA.

Thanks for the fix, @cyranix.

:tada: This has been pushed live to https://developers.google.com/web/


Migrated all projects to packagereference

Solves #736
After this the nuget and netstandard branch need to get updated again (should make the changes in those branches alot smaller though).

Nice 👍 Will review and merge soon-ish.
Note to self, things to check:

Does it compile fine "on my machine" in addition to yours + AppVeyor after fresh checkout?
Do a brief editor install check via local package repo, just in case.

Took the liberty of rebasing the netstandard branch and nuget branch in advance on this branch to solve any merge conflicts.
These branches need to be rebased again once this PR is merged to master (should be easy since all conflicts are fixed already).

Took a clean / rebuild on my previous checkout to get rid of some dependency errors, in case anyone runs into this as well - compiles just fine from scratch though. Also did a quick package build and test install in a local repo and it looks like nothing changed on the binary output / compatibility side, as expected.
Merging this.


don't panic, retry instead

Taken from https://github.com/ltcsuite/ltcwallet/pull/9 and updates the repo to the latest upstream master changes.
This PR is required for: https://github.com/decred/dcrdex/issues/261
See: https://github.com/decred/dcrdex/issues/2616#issuecomment-1961399228

Superceded by #2. Thank you @ukane-philemon


Several updates on multiple pages and fixes

Description

Header and footer fixed in new_perl.html and new_raku.html
added pagination in blogs.html
search by user with dropdown feature added
5 cards per page to team.html and guest.html
Pagination updated to fix click issue (2 clicks were required for forward and backward )
Replaced footer link "Reviews" with Rss Feed
Button color in dark mode optimised to greyish color across all pages
Border issues fixed in header dropdown
Button alignment fixed on search-contribution page

Type of Change

[x] ✨ New feature (non-breaking change which adds functionality)
[ ] 🛠 Bug fix (non-breaking change which fixes an issue)
[ ] ❌ Breaking change (fix or feature that would cause existing functionality to change)
[x] 🧹 Code refactor
[ ] ✅ Build configuration change
[ ] 📝 Documentation
[ ] 🗑 Chore

Changes

Please which part of the project your changes affect ?

[x] Frontend (Templates, CSS, JS)
[ ] Backend (Dancer2, api-docs, Dockerfile)

Screenshots

Thanks @himanshisrestha


Minor wording change for new version API

Learn Build status updates of commit a7f8fa0:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

articles/active-directory/governance/lifecycle-workflow-versioning.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the learn.microsoft.com contributor guidesPost your question in the Learn support channel

@OWinfreyATL,
Can you review the proposed changes?
IMPORTANT: When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

#sign-off


1.1

Fixes #25, #24, #23, #20, #18, #7, #26, #27.

Hey @tanner0101, you just merged a pull request, have a coin!
You now have 914 coins.


Update readmes for SDK Auto-gen

MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Changelog
Add a changelog entry for this PR by answering the following questions:

What's the purpose of the update?

[ ] new service onboarding
[ ] new API version
[ ] update existing version for new feature
[ ] update existing version to fix swagger quality issue in s360
[X] Other, please clarify - adding tags to ReadMe for SDK generation

When are you targeting to deploy the new service/feature to public regions? Please provide the date or, if the date is not yet available, the month.
When do you expect to publish the swagger? Please provide date or, the the date is not yet available, the month.
If updating an existing version, please select the specific langauge SDKs and CLIs that must be refreshed after the swagger is published.

[ ] SDK of .NET (need service team to ensure code readiness)
[X] SDK of Python
[ ] SDK of Java
[ ] SDK of Js
[ ] SDK of Go
[ ] PowerShell
[ ] CLI
[ ] Terraform
[ ] No refresh required for updates in this PR

Contribution checklist:

[X] I commit to follow the Breaking Change Policy of "no breaking changes"
[X] I have reviewed the documentation for the workflow.
[X] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

Applicability: :warning:
If your changes encompass only the following scenarios, you should SKIP this section, as these scenarios do not require ARM review.

Change to data plane APIs
Adding new properties
All removals

Otherwise your PR may be subject to ARM review requirements. Complete the following:

[ ] Check this box if any of the following apply to the PR so that label "WaitForARMFeedback" will be added automatically to begin ARM API Review. Failure to comply may result in delays to the manifest.

Adding a new service
Adding new API(s)
Adding a new API version
-[ ] To review changes efficiently, ensure you copy the existing version into the new directory structure for first commit and then push new changes, including version updates, in separate commits.

[   Ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.

[ ] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If any of the following scenarios apply to the PR, request approval from the Breaking Change Review Board as defined in the Breaking Change Policy.

[ ] Removing API(s) in a stable version
[ ] Removing properties in a stable version
[ ] Removing API version(s) in a stable version
[ ] Updating API in a stable or public preview version with Breaking Change Validation errors
[ ] Updating API(s) in public preview over 1 year (refer to Retirement of Previews)

Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Addition details on the process and office hours are on the Breaking change Wiki.
Please follow the link to find more details on PR review process.

I don't think change from single api to multi api is a good idea.. It is not that useful and will bring heavy burden to maintain.

Please remove change about Python. Python does not advise multi api. And your multi-api configuration for Python is not right.

I believe I removed the multiapi config that i had added. Please let me know if there is anything else I need to remove. thanks!


placeholder not working with array data

The title say all
See the example:
https://jsfiddle.net/qfamjc11/1/
To "fix" need to add an empty < option> < /option> there.

This is a duplicate of https://github.com/select2/select2/issues/3553. There is no way to automatically "fix" this.


Docs: Update to new command names and add use case

As the commands were modified in commit 2cd23be, we need to update the documentation to show the correct command names.
I also took the opportunity to add the step-by-step instructions which we can refer to from CONTRIBUTING.md

Perfect


Static analyzer warning

I'm using XCode 4.2 and the LLVM 3.0 compiler, and when the static analyzer runs it complains about AsyncSocket.m line 935.
The line is this:
934: struct sockaddr_in6 *pSockAddr6 = (struct sockaddr_in6 *)[address6 bytes];
935: pSockAddr6->sin6_port = htons(chosenPort);
The warning is "Access to field 'sin6_port' results in a dereference of a null pointer".
The only way I could see to tell the silly analyzer this isn't the case is to add a test:
934: struct sockaddr_in6 *pSockAddr6 = (struct sockaddr_in6 *)[address6 bytes];
935: if (pSockAddr6)
936:     pSockAddr6->sin6_port = htons(chosenPort);
I don't know how to use GitHub well enough to submit this code :-p sorry.

This is fixed in #14, thanks.


Update ember-try config

Run ember init to regenerate config/ember-try.js file. The config gets modified this way:

Add ember-source-channel-url dependency to dynamically pick ember
versions
Add ember-2.18-lts scenario
Use yarn to run the test in travis

This was required to make https://github.com/simplabs/ember-simple-auth/pull/1636 tests pass.

Thanks!


Testing/php83

Still using RC version of the image
No Blackfire (promised day 1) or New Relic support yet
Xdebug extension working on an alpha release
No IMagick support for 8.3 yet
Removed Drupal Console and Drush Launcher and replaced with /app/vendor/bin in the path to pick up composer installed Drush

PHP 8.3 is slated for Nov 23 (1 week) so this is timely. https://stitcher.io/blog/new-in-php-83
+1 for removing drush launcher (adding the path does the same thing), and drupal console (no longer supported).


fix/slugify-non-ascii

This pull request fixes an issue where questions with full Persian titles were causing a "many redirect error" when trying to access them through the link. The issue was caused by the slugify library returning a blank string for the title of these questions. With this fix, the slugify library has been updated to return a proper string for the title, resolving the issue and allowing for smooth access to all questions, regardless of their title.

@LinkinStars Thank you for response.
I solved 3 and 4.

A post with this title has many redirect problem.
title= چگونه می‌توانم مساله گزارش شده را ارزبای کنم؟
And post with this title hasn't problem.
title = چگونه می‌توانم Bug گزارش شده را ارزیابی کنم؟

I think since the slugs aren't saved, it won't be a problem. I also tested a few things and it didn't seem to be a problem. Have you any specific scenario in your mind? Can you tell us your exact solution?


Fix go version in go.mod

Description
This PR fixes an issue on Dependabot. See https://github.com/golang/go/issues/62278 and https://github.com/dependabot/dependabot-core/issues/7895 for details.

/test

/test


helm: allow additionalProperties in values.schema.json

Is your feature request related to a problem? Please describe.
We used ArgoCD multisource applications, so our values.yaml includes chart values body and custom block for application generation, i.e.
chart:
  url: https://charts.jetstack.io
  name: cert-manager
  version: 1.15.3

installCRDs: true

replicaCount: 2
...

Since cert-manager chart version 1.16.0 was released our schema doesn't work anymore, and we and we are forced to stay on version 1.15.x
Describe the solution you'd like
Allow additionalProperties in values validation schema
Environment details (remove if not applicable):

cert-manager version: v1.16.0
Install method: helm via argocd (helm+git)

/kind feature

This sounds like a bug in ArgoCD, chart is not a property that Helm expects afaik.
If too difficult to fix in ArgoCD, we can add a "chart" field in the generated schema.json.
The tool that generates the schema can be found here: https://github.com/cert-manager/helm-tool

@inteon  we have similar issue with using cert-manager as sub-chart.
For example, it's quite common to use a enabled properties like
cert-manager:
  enabled: true

To indicate, if a sub-chart is enabled for deployed or not. ref: https://helm.sh/docs/chart_best_practices/dependencies/#conditions-and-tags
However, this is not longer working, because the enabled property results into a schema violation.
Error: Failed to render chart: exit status 1: Error: UPGRADE FAILED: values don't meet the specifications of the schema(s) in the following chart(s):
  cert-manager:
  - (root): Additional property enabled is not allowed

A similar situation exists for global scope: Various charts supports different global properties. Setting global on the parent chart inherit the whole global scope to sub-charts.
I would recommend to set additionalProperties: true at root level and global scope to relax such situations.

@inteon we have similar issue with using cert-manager as sub-chart.
For example, it's quite common to use a enabled properties like
cert-manager:
  enabled: true

To indicate, if a sub-chart is enabled for deployed or not. ref: https://helm.sh/docs/chart_best_practices/dependencies/#conditions-and-tags
However, this is not longer working, because the enabled property results into a schema violation.
Error: Failed to render chart: exit status 1: Error: UPGRADE FAILED: values don't meet the specifications of the schema(s) in the following chart(s):
  cert-manager:
  - (root): Additional property enabled is not allowed

A similar situation exists for global scope: Various charts supports different global properties. Setting global on the parent chart inherit the whole global scope to sub-charts. Restrict the global property results into various violations.
I would recommend to set additionalProperties: true at root level and global scope to relax such situations.
Edit: covered in #7329

The problem with that approach is that it will prevent us from detecting big errors in user's values.yaml file:
eg. if you misspell a root property, this will go undetected.
Is there no way we can create a list of all root-properties that we have to allow?
My current list would be: "global", "enabled"

Thanks to @erikgb for pointing out that starting from Helm v1.16.0, there is now a flag to disable the json-schema validation '--skip-schema-validation': https://github.com/helm/helm/releases/tag/v3.16.0, https://github.com/helm/helm/pull/12743
This can be useful if you want to use custom additional properties at the root level of your values.yaml

@erikgb That not a solution if cert-manager i used as sub-chart.

We should not relax the schema by allowing additional properties. Doing so would violate most of the intentions behind having a JSON schema.

While it sound great at first, there are various issues in sub-chart conditions which results in conflicts.
In case, you wont lax the schema: Would it be possible to release an alternative chart flavor, just without the schema file?

That not a solution if cert-manager i used as sub-chart

Why not? Can you explain, please?

I have 2 concrete issues:

The global properties may contains more values as known at cert-manager. Other sub-charts uses other properties on the global scope.
It's common to add conditions to sub-charts (ref: https://helm.sh/docs/chart_best_practices/dependencies/#conditions-and-tag. The common is a "enabled" property on the chart scope which controls the toggle. In that case, the non related properties enabled must be part of the cert-manager values schema, if additionalProperties is false on root scope.

I have 2 concrete issues:

The global properties may contains more values as known at cert-manager. Other sub-charts uses other properties on the global scope. Edit: fixed by Update global section to not have "additionalProperties: false" helm-tool#42
It's common to add conditions to sub-charts (ref: https://helm.sh/docs/chart_best_practices/dependencies/#conditions-and-tag. The common is a "enabled" property on the chart scope which controls the toggle. In that case, the non related properties enabled must be part of the cert-manager values schema, if additionalProperties is false on root scope. Thats how opentelemetry chart resolve that issue: add enabled in values.schema.json open-telemetry/opentelemetry-helm-charts#262

If both issues are covered, then I see no more issues with subchart and additionalProperties: false

I like your proposal to add the enabled property in values.schema.json!


Missing topo images

Hello, I noticed that some images are missing from your topo database. For example, the image for topo_id 12872 in area 20 doesn't exist.
I can provide you a complete list if needed.
Also, we regularly add new boulders in our database. Would you like us to work together on a process to add them to your database as well?

Hello Mathias,
You're right, some topos are missing.
Good news is that you can access them directly using this new url: http://assets.boolder.com/proxy/topos/3846
We'll stop adding them to the repo as it's not necessary anymore.

Also, we regularly add new boulders in our database. Would you like us to work together on a process to add them to your database as well?
Yes! Can you send us an email at<EMAIL_ADDRESS>? Thx

Updated doc: https://github.com/boolder-org/boolder-data/tree/main?tab=readme-ov-file#topo

Désolé j'avais pas les notifications, je t'envoie un mail dans la journée.


create environment package version fix

I tested the PR, here are my comments : https://github.com/Quansight/conda-store-ui/issues/99#issuecomment-1263491688


Can't decompil Samsung Browser apk ( error in ASSET : Not a valid dex magic value)

Information

**Apktool Version (apktool -version) Apktool 2.4.1-SNAPSHOT
**Operating System (Mac, Linux, Windows) Windows
**APK From? (Playstore, ROM, Other) ApkMirror

Stacktrace/Logcat
--------------------------------------------------
Batch ApkTool DONATE         : 3.7.7
APKTOOL                      : apktool-2.4.1-b05f19b-SNAPSHOT.jar
Mode expert                  : NO
Signature                    : OUI
--------------------------------------------------

[*] Réglage du cadre AOSP_10.0_API29_framework-res.apk
I: Framework installed to: bin\framework\1.apk

[*] Décompilation SBrowser_<IP_ADDRESS>.apk
I: Using Apktool 2.4.1-SNAPSHOT on SBrowser_<IP_ADDRESS>.apk
I: Loading resource table...
I: Decoding AndroidManifest.xml with resources...
I: Loading resource table from file: bin\framework\1.apk
I: Regular manifest package...
I: Decoding file-resources...
W: Cant find 9patch chunk in file: "drawable/sesl_action_bar_background_divider_alpha.9.png". Renaming it to *.png.
W: Cant find 9patch chunk in file: "drawable-xhdpi-v4/sesl_toast_frame_alpha.9.png". Renaming it to *.png.
W: Cant find 9patch chunk in file: "drawable-xxhdpi-v4/sesl_tab_n_badge_mtrl.9.png". Renaming it to *.png.
W: Cant find 9patch chunk in file: "drawable-xxhdpi-v4/sesl_btn_switch_mtrl.9.png". Renaming it to *.png.
W: Cant find 9patch chunk in file: "drawable-desk-mdpi-v8/sesl_btn_switch_mtrl.9.png". Renaming it to *.png.
W: Cant find 9patch chunk in file: "drawable-xhdpi-v4/sesl_btn_switch_mtrl.9.png". Renaming it to *.png.
W: Cant find 9patch chunk in file: "drawable-mdpi-v4/sesl_index_bar_bg.9.png". Renaming it to *.png.
W: Cant find 9patch chunk in file: "drawable-xxhdpi-v4/sesl_index_bar_bg.9.png". Renaming it to *.png.
W: Cant find 9patch chunk in file: "drawable-xxhdpi-v4/sesl_switch_track_alpha.9.png". Renaming it to *.png.
W: Cant find 9patch chunk in file: "drawable-xxhdpi-v4/sesl_spinner_picker_alpha.9.png". Renaming it to *.png.
W: Cant find 9patch chunk in file: "drawable-mdpi-v4/sesl_toast_frame_alpha.9.png". Renaming it to *.png.
W: Cant find 9patch chunk in file: "drawable-xxxhdpi-v4/sesl_spinner_picker_alpha.9.png". Renaming it to *.png.
W: Cant find 9patch chunk in file: "drawable-xhdpi-v4/sesl_spinner_picker_alpha.9.png". Renaming it to *.png.
W: Cant find 9patch chunk in file: "drawable-hdpi-v4/sesl_btn_switch_mtrl.9.png". Renaming it to *.png.
W: Cant find 9patch chunk in file: "drawable-mdpi-v4/sesl_switch_track_alpha.9.png". Renaming it to *.png.
W: Cant find 9patch chunk in file: "drawable-tvdpi-v4/sesl_btn_switch_mtrl.9.png". Renaming it to *.png.
W: Cant find 9patch chunk in file: "drawable-hdpi-v4/sesl_switch_track_alpha.9.png". Renaming it to *.png.
W: Cant find 9patch chunk in file: "drawable-mdpi-v4/sesl_btn_switch_mtrl.9.png". Renaming it to *.png.
W: Cant find 9patch chunk in file: "drawable-xxhdpi-v4/sesl_toast_frame_alpha.9.png". Renaming it to *.png.
W: Cant find 9patch chunk in file: "drawable/sesl_section_divider_default_alpha.9.png". Renaming it to *.png.
I: Decoding values */* XMLs...
I: Baksmaling classes.dex...
I: Baksmaling classes2.dex...
I: Baksmaling assets/A3AEECD8.dex...
Exception in thread "main" org.jf.dexlib2.dexbacked.DexBackedDexFile$NotADexFile: Not a valid dex magic value: cf 77 4c c7 9b 21 01 cd
	at org.jf.dexlib2.util.DexUtil.verifyDexHeader(DexUtil.java:93)
	at org.jf.dexlib2.dexbacked.DexBackedDexFile.getVersion(DexBackedDexFile.java:111)
	at org.jf.dexlib2.dexbacked.DexBackedDexFile.<init>(DexBackedDexFile.java:78)
	at org.jf.dexlib2.dexbacked.DexBackedDexFile.<init>(DexBackedDexFile.java:138)
	at org.jf.dexlib2.dexbacked.ZipDexContainer$1.getDexFile(ZipDexContainer.java:181)
	at brut.androlib.src.SmaliDecoder.decode(SmaliDecoder.java:90)
	at brut.androlib.src.SmaliDecoder.decode(SmaliDecoder.java:39)
	at brut.androlib.Androlib.decodeSourcesSmali(Androlib.java:96)
	at brut.androlib.ApkDecoder.decode(ApkDecoder.java:164)
	at brut.apktool.Main.cmdDecode(Main.java:170)
	at brut.apktool.Main.main(Main.java:76)
[*] ---> Erreur décompilation SBrowser_<IP_ADDRESS>.apk

Steps to Reproduce

apktool

Frameworks
If this APK is from an OEM ROM (Samsung, HTC, LG). Please attach framework files
(.apks that live in /system/framework or /system/priv-app)
AOSP_10.0_API29_framework-res.apk
http://www.mediafire.com/file/9q8ndvsupk6cs3u/AOSP_10.0_API29_framework-res.apk.apk/file
APK
SBrowser_<IP_ADDRESS>.apk
https://www.apkmirror.com/apk/samsung-electronics-co-ltd/samsung-internet-for-android/samsung-internet-for-android-11-0-00-73-release/samsung-internet-browser-11-0-00-73-android-apk-download/
Questions to ask before submission

Have you tried apktool d, apktool b without changing anything? Yes
If you are trying to install a modified apk, did you resign it? No its original one
Are you using the latest apktool version? Yes

This is not a bug in apktool. In fact, A3AEECD8.dex is not a standard dex file. Please see the command below.
$ file classes.dex
classes.dex: Dalvik dex file version 035
$ file assets/A3AEECD8.dex
assets/A3AEECD8.dex: data
You can use apktool d --only-main-classes to salve the problem. But if you get an error:Unrecognized option: --only-main-classes, you can see #2226

Ok ! Many thanks, i will try to decompil only main classes

As mentioned above. The system is looking for .dex files and not finding one, so the param - --only-main-classes will isolate the search to only dex files in the root.
Closing as not a bug.


FLEX-2124 Improves relation between RelayStatus and Device/Ssld

SonarQube analysis reported 2 issues
Note: The following issues were found on lines that were not modified in the pull request. Because these issues can't be reported as line comments, they are summarized here:

 EventNotificationMessageService.java#L110: The Cyclomatic Complexity of this method "handleLightSwitchingEvents" is 11 which is greater than 10 authorized.
 Ssld.java#L33: Override this superclass' "equals" method.

All is well.

All is well.

SonarQube analysis reported 6 issues

 6 major

Watch the comments in this conversation to review them.
5 extra issues
Note: The following issues were found on lines that were not modified in the pull request. Because these issues can't be reported as line comments, they are summarized here:

 DeviceManagementService.java#L259: Refactor this method to throw at most one checked exception instead of: com.alliander.osgp.shared.exceptionhandling.FunctionalException, com.alliander.osgp.domain.core.exceptions.ArgumentNullOrEmptyException
 DeviceManagementService.java#L259: The Cyclomatic Complexity of this method "findDevices" is 13 which is greater than 10 authorized.
 DeviceManagementService.java#L356: Refactor this code to not nest more than 3 if/for/while/switch/try statements.
 EventNotificationMessageService.java#L110: The Cyclomatic Complexity of this method "handleLightSwitchingEvents" is 11 which is greater than 10 authorized.
 Ssld.java#L33: Override this superclass' "equals" method.

All is well.

SonarQube analysis reported 6 issues

 6 major

Watch the comments in this conversation to review them.
5 extra issues
Note: The following issues were found on lines that were not modified in the pull request. Because these issues can't be reported as line comments, they are summarized here:

 DeviceManagementService.java#L259: The Cyclomatic Complexity of this method "findDevices" is 13 which is greater than 10 authorized.
 DeviceManagementService.java#L259: Refactor this method to throw at most one checked exception instead of: com.alliander.osgp.shared.exceptionhandling.FunctionalException, com.alliander.osgp.domain.core.exceptions.ArgumentNullOrEmptyException
 DeviceManagementService.java#L363: Refactor this code to not nest more than 3 if/for/while/switch/try statements.
 EventNotificationMessageService.java#L110: The Cyclomatic Complexity of this method "handleLightSwitchingEvents" is 11 which is greater than 10 authorized.
 Ssld.java#L33: Override this superclass' "equals" method.

All is well.

SonarQube analysis reported 6 issues

 6 major

Watch the comments in this conversation to review them.
5 extra issues
Note: The following issues were found on lines that were not modified in the pull request. Because these issues can't be reported as line comments, they are summarized here:

 DeviceManagementService.java#L259: The Cyclomatic Complexity of this method "findDevices" is 13 which is greater than 10 authorized.
 DeviceManagementService.java#L259: Refactor this method to throw at most one checked exception instead of: com.alliander.osgp.shared.exceptionhandling.FunctionalException, com.alliander.osgp.domain.core.exceptions.ArgumentNullOrEmptyException
 DeviceManagementService.java#L363: Refactor this code to not nest more than 3 if/for/while/switch/try statements.
 EventNotificationMessageService.java#L110: The Cyclomatic Complexity of this method "handleLightSwitchingEvents" is 11 which is greater than 10 authorized.
 Ssld.java#L33: Override this superclass' "equals" method.

All is well.

SonarQube analysis reported 6 issues

 6 major

Watch the comments in this conversation to review them.
5 extra issues
Note: The following issues were found on lines that were not modified in the pull request. Because these issues can't be reported as line comments, they are summarized here:

 DeviceManagementService.java#L259: The Cyclomatic Complexity of this method "findDevices" is 13 which is greater than 10 authorized.
 DeviceManagementService.java#L259: Refactor this method to throw at most one checked exception instead of: com.alliander.osgp.shared.exceptionhandling.FunctionalException, com.alliander.osgp.domain.core.exceptions.ArgumentNullOrEmptyException
 DeviceManagementService.java#L363: Refactor this code to not nest more than 3 if/for/while/switch/try statements.
 EventNotificationMessageService.java#L115: The Cyclomatic Complexity of this method "handleLightSwitchingEvents" is 11 which is greater than 10 authorized.
 Ssld.java#L33: Override this superclass' "equals" method.

All is well.

SonarQube analysis reported 6 issues

 6 major

Watch the comments in this conversation to review them.
5 extra issues
Note: The following issues were found on lines that were not modified in the pull request. Because these issues can't be reported as line comments, they are summarized here:

 DeviceManagementService.java#L259: Refactor this method to throw at most one checked exception instead of: com.alliander.osgp.shared.exceptionhandling.FunctionalException, com.alliander.osgp.domain.core.exceptions.ArgumentNullOrEmptyException
 DeviceManagementService.java#L259: The Cyclomatic Complexity of this method "findDevices" is 13 which is greater than 10 authorized.
 DeviceManagementService.java#L363: Refactor this code to not nest more than 3 if/for/while/switch/try statements.
 EventNotificationMessageService.java#L128: The Cyclomatic Complexity of this method "handleLightSwitchingEvents" is 11 which is greater than 10 authorized.
 Ssld.java#L33: Override this superclass' "equals" method.

All is well.

SonarQube analysis reported 6 issues

 6 major

Watch the comments in this conversation to review them.
5 extra issues
Note: The following issues were found on lines that were not modified in the pull request. Because these issues can't be reported as line comments, they are summarized here:

 DeviceManagementService.java#L259: Refactor this method to throw at most one checked exception instead of: com.alliander.osgp.shared.exceptionhandling.FunctionalException, com.alliander.osgp.domain.core.exceptions.ArgumentNullOrEmptyException
 DeviceManagementService.java#L259: The Cyclomatic Complexity of this method "findDevices" is 13 which is greater than 10 authorized.
 DeviceManagementService.java#L363: Refactor this code to not nest more than 3 if/for/while/switch/try statements.
 EventNotificationMessageService.java#L128: The Cyclomatic Complexity of this method "handleLightSwitchingEvents" is 11 which is greater than 10 authorized.
 Ssld.java#L33: Override this superclass' "equals" method.

All is well.


Consider converting GRAMMAR.md into test

I'd like to convert the reference grammar in GRAMMAR.md into something that can actually be parsed by an LR(k) parser-generator, so that the grammar can be checked for ambiguity.
I like the hand-written parser, so I'm not saying that Just should actually replace it's parser with a generated one, just that we should add a test that ensure that the language stays LR(k) using the grammar.
I think the best choice here is probably https://github.com/lalrpop/lalrpop.

Also see @nk9's suggestion in https://github.com/casey/just/issues/1247#issuecomment-1169935062 We could use the bnf crate to generate random strings from the grammar.


Shortcut to Open URLs

Dear contributors, thanks for this awesome plugin, I'm gonna stick to it because it supports Git worktrees and master URLs, unlike the one VSCode folks mention on their website.
Is there a chance you could add shortcuts to actually open those URLs in the browser?
I could contribute myself if you don't have time for this, but decided to ask you first.

Thanks for reaching out.  I would be happy to review any contributions you want to make.

From: Sergii Grebeniuk @.>
Sent: Tuesday, July 20, 2021 7:46:19 AM
To: differentmatt/vscode-copy-github-url @.>
Cc: Subscribed @.***>
Subject: [differentmatt/vscode-copy-github-url] Shortcut to Open URLs (#19)
Dear contributors, thanks for this awesome plugin, I'm gonna stick to it because it supports Git worktrees and master URLs, unlike the one VSCode folks mention on their websitehttps://code.visualstudio.com/docs/editor/github.
Is there a chance you could add shortcuts to actually open those URLs in the browser?
I could contribute myself if you don't have time for this, but decided to ask you first.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/differentmatt/vscode-copy-github-url/issues/19, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAWT5NHPNFJMY7HRA73YUK3TYWD3XANCNFSM5AV6QB7A.

Hm, it actually stopped working for me in worktrees with (Copy GitHub URL) Error: .git/HEAD does not exist. error, which is why I'll have to stop using the plugin :( Closing the issue, sorry for disturbing

Sorry to hear this stopped working for you.  We'll have to look into this issue.  Thanks!

From: Sergii Grebeniuk @.>
Sent: Friday, August 6, 2021 1:31:52 AM
To: differentmatt/vscode-copy-github-url @.>
Cc: Matt Lott @.>; Comment @.>
Subject: Re: [differentmatt/vscode-copy-github-url] Shortcut to Open URLs (#19)
Closed #19https://github.com/differentmatt/vscode-copy-github-url/issues/19.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/differentmatt/vscode-copy-github-url/issues/19#event-5121628116, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAWT5NCFKTHFMCCWHEILQVDT3OMXRANCNFSM5AV6QB7A.
Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email.


Port to 1.16?

I've asked people to port this to the newer MC versions, but then noticed that I haven't even asked you first to do it..
So, can you possibly update this to Minecraft 1.16?

Hey, I plan to rewrite this for 1.16+ versions as I'm not happy with the current version and all of it's issues. I just haven't had as much time lately but I plan on it at some point.

That would be nice, I'm planning to update my server from 1.12 to 1.16 anytime soon and this mod is definitely needed again.

@abused I really hate to be that guy, but do you have any ETA yet? :D


website access to latest dreq

The functionality that is available at https://clipc-services.ceda.ac.uk/dreq/index.html is great, which allows direct web access to direct queries to. Is such a service (with the latest version) still going to be available as the exarch repo is retired?
https://github.com/WCRP-CMIP/WGCM_Infrastructure_Panel/issues/29

hi @durack1 , the clipc-services server is independent of the proj.badc.ac.uk server that is being retired so I think the web interface is safe for the moment.

@matthew-mizielinski great, it'd be great to get this updated to the latest 01.00.31 -> 01.00.33 before it becomes too difficult


Fuzzer: nondeterministic data corruption in DCR mode

I'm not sure if this is related to https://gitlab.com/StanfordLegion/legion/-/merge_requests/1473 but I'm running in that branch and seeing a data corruption bug:
$ salloc -n 1 -N 1 -c 40 -p all --exclusive
$ cd /scratch/eslaught/fuzzer-experiment-7-fix
$ i=0; while srun -n 2 --ntasks-per-node 2 ./build_debug_multi/src/fuzzer -fuzz:seed<PHONE_NUMBER>3034 -fuzz:ops 1000 -fuzz:skip 507 -ll:util 2 -ll:cpu 3 -fuzz:replicate 1 -lg:safe_ctrlrepl 1 -level 4; do let i++; echo $i; done
[0 - 7f4227104c40]    0.992555 {6}{fuzz}: Bad region value: 932941568, expected:<PHONE_NUMBER>
[1 - 7ff146313c40]    0.992558 {6}{fuzz}: Bad region value: 932941568, expected:<PHONE_NUMBER>

I'm doing a build with Legion Spy now so that I can compare what it says.
Fuzzer version: https://github.com/StanfordLegion/fuzzer/commit/3ef4c19266907eee6c5df86d9dc25b79b47f2d4b
Legion version: d8762439a692bb0492a3febb51bbf6e3c719d95c (from https://gitlab.com/StanfordLegion/legion/-/merge_requests/1473)

Here are the Legion Spy logs from a set of good and bad runs (i.e., that pass or fail the fuzzer's verification):

Good (passes fuzzer verification): good_0.log good_1.log
Bad (fails fuzzer verification): bad_0.log bad_1.log

Unfortunately I cannot actually run Legion Spy on either of these log files:
$ pypy3 legion/tools/legion_spy.py -lpa bad_*.log
Reading log file bad_0.log...
Traceback (most recent call last):
  File "legion/tools/legion_spy.py", line 14751, in <module>
    main(temp_dir)
  File "legion/tools/legion_spy.py", line 14623, in main
    total_matches += state.parse_log_file(file_name)
  File "legion/tools/legion_spy.py", line 13229, in parse_log_file
    if parse_legion_spy_line(line, self):
  File "legion/tools/legion_spy.py", line 12834, in parse_legion_spy_line
    assert p1 not in state.point_point
AssertionError

I get the same result with the good_*.log files.

Fix here: https://gitlab.com/StanfordLegion/legion/-/merge_requests/1476
This is the best bug found yet as it is a really subtle one involving the interaction of control replication with some really strange patterns of index space task launches.

I finished 400 runs of the specific seed, and a full suite of single- and multi-node runs, and I think the issue is fixed. The only remaining issues I see are this point are the Realm failures reported in #1745.

Merged.


Twittet Suggestion: Make it possible to show one Check In full screen (proof that one checked in)

Feature description
The user should be able to click on a Check In whiled checked in.
The app then shows that the user has checked in and how long the user is already checked in.
Problem and motivation
Currently, if users want to proof that they checked in, they have to show the Check In tab to the controlling person.
The controlling person, however, is not only able to see the current check in, but also the history.
This can be seen as a privacy flaw, as some users might not want the controlling person to see where they went in the past days.
Additional information
This feature request is based on the feedback I received from a Twitter user: https://twitter.com/marginauto/status/1446862229148737536?s=21

Internal Tracking ID: EXPOSUREAPP-13533

This issue stayed unmirrored to JIRA for a prolonged period of time. Please mirror it to JIRA now.

As the CWA project went into ramp-down mode, I don't expect this feature to be implemented. I'm therefore closing this issue.