Please raise dep version

PHP Depend provides a 2.1.0 version
http://pdepend.org/news/pdepend-2.1.0-released.html
Please allow this by incrementing the version filter in composer.json.

There is already release 2.2.3 that uses PDepend 2.1.0

Are you sure? The dependency still says ~2.0.

You can try it with:
$ composer.phar require "phpmd/phpmd:@stable"
./composer.json has been created
Loading composer repositories with package information
Updating dependencies (including require-dev)
  - Installing symfony/filesystem (v2.6.8)
    Loading from cache

  - Installing symfony/config (v2.6.8)
    Loading from cache

  - Installing symfony/dependency-injection (v2.6.8)
    Loading from cache

  - Installing pdepend/pdepend (2.1.0)
    Loading from cache

  - Installing phpmd/phpmd (2.2.3)
    Loading from cache

symfony/dependency-injection suggests installing symfony/yaml ()
symfony/dependency-injection suggests installing symfony/proxy-manager-bridge (Generate service proxies to lazy load them)
Writing lock file
Generating autoload files

Thanks!


Add fn_call_layout configuration option

Closes #5218
The fn_call_layout was added to give users more control over how function calls are formatted.
The values are identical to those for fn_args_layout, which is a stable option that controls how function declarations are laid out.

Haven't looked at the diff yet but quite excited about the possibilities from the title alone :smile:
Want to make sure you'd also seen the transitively linked issues in #2010 and #4146 too given some of the challenges and questions posed there. Let's also be sure we account for calls that include the various types of more complex args, like large chains, large closures, etc.

Thanks for linking those related issues. I went ahead and read the threads and added test cases for each linked issue. I also added a test case with some more complex arguments. Totally happy to add more. I think the Compressed case can lead to some weird formatting when the arguments aren't "simple", but I've opted to not force that restriction in the event that the user has explicitly requested for the mixed layout since it feels like we should honor what the user is requesting. Something also seems to be a little off with the complex chain formatting in the Tall case.

Yeah that indentation is definitely off in the Tall case. I'll also add that I'm pleasantly surprised by the small size of the diff!

To be honest, I was just as surprised when I started working on this. Fingers crossed the Tall case isn't too tricky to get right, and doesn't add too much to the size of the diff 🤞🏼.

Alright, I think I i've got it working as intended. There might be some edge cases I'm not thinking about though. I believe the weird formatting we saw before had to do with rewrite_method_call's call to rewrite_call. Since we don't want these changes to affect chain's I updated rewrite_call's signature to take force_list_tactic: Option<ListTactic>, and always pass None when rewriting methods.

I'm content deferring this to a follow up, but want to make sure we've got test cases that include combinations with other (potentially) relevant config options, like indent_style, hard_tabs, etc. along with the new variants for this option

Few follow up questions:

why are all the tests set with version to Two? is that just how you opted to structure the tests or is there some call-related formatting with the default that looks particularly odd with this option?
is the min of 2 args required to trigger vertical aligned with what we do for params in signatures as well?

I like the consistency with the variant names aligning with those for fn_args_layout although at the same time given the higher degree of complexity with calls/args I won't be surprised if we need additional/different variants down the road.
Tangential, but we should really name fn_args_layout to something like fn_params_layout. Since this option has already been stabilized we'd have to be able to support a soft deprecate an automapping to the renamed/new option though. This doesn't need to be done in this PR of course, but would be good if we could get that change bundled with this in the same release

I'm content deferring this to a follow up, but want to make sure we've got test cases that include combinations with other (potentially) relevant config options, like indent_style, hard_tabs, etc. along with the new variants for this option

Totally agree. I'll make sure to add some additional tests cases!

why are all the tests set with version to Two? is that just how you opted to structure the tests or is there some call-related formatting with the default that looks particularly odd with this option?

version=Two was used to format if a == 998765390 { -b * 3 } else { c } on a single line. It doesn't have any direct impact on fn_call_layout (that I can tell). I can see why the inclusion of version=Two would be confusing so I'm going to rebase and remove it.

is the min of 2 args required to trigger vertical aligned with what we do for params in signatures as well?

I believe so. testing locally seems to confirm that. I'll include a test case for this just to be sure the behavior doesn't change!

@calebcartwright #5387 is the follow up PR that renames fn_args_layout.

Oh, and not necessary but may want to consider adding an entry for this to the changelog to save ourselves some work down the road :sweat_smile:

Oh, and not necessary but may want to consider adding an entry for this to the changelog to save ourselves some work down the road 😅

Great idea. I'll add the entry when I make the other changes!

Thank you for pushing this one over the finish line! I'll do a final pass but I think we're good to go from a code perspective.
Afterwards, if you're up for it, I would like to run some functional-type testing with this change against some larger codebase (we've got a couple in the r-l org obviously and can look at others like Tokio and friends) to make sure it's still idempotent as compared to current nightly.
Just want to be cautious and not have another expression memoization scenario that causes unnecessary churn, even on nightly

That's all totally reasonable! I'd definitely be up for helping out with the testing! Would testing be as simple as cloning each repo we want to test and then run this version of rustfmt on it?

Would testing be as simple as cloning each repo we want to test and then run this version of rustfmt on it?

Precisely :+1:

rust, clippy, and rls would be the first ones i'd look at under our org just because of their size and because they run nightly rustfmt as part of their ci checks (though worth noting that the rust repo is pinned to a rolling version that's a few weeks/months behind the latest, so minor diffs may be observed there)

Thanks for pointing me in the right direction. I'll report back once I've done some testing!👨🔬

Planning to run through some other repos, but just want to walk through the steps I took:

compiled a release binary for the fn_call_args version of rustfmt and copied it for later use
compiled a release binary of the latest master rustfmt and copied it for later use
cloned the rust repo
updated the submodules
ran cargo fmt in the root of the rust repo RUSTFMT=/path/to/fn_call_rustfmt cargo fmt > fn_call_diff.txt
ran cargo fmt in the root of the rust repo RUSTFMT=/path/to/rustfmt cargo fmt > rustfmt_diff.txt
compared the diffs git diff --no-index fn_call_diff.txt rustfmt_diff.txt

This was the only code change that the fn_call_args version produced that the current master did not.
Here's the input
        if let Ok(check) = CastCheck::new(
            &fn_ctxt, e, from_ty, to_ty,
            // We won't show any error to the user, so we don't care what the span is here.
            DUMMY_SP, DUMMY_SP,
        ) {

Diff in rust/src/tools/clippy/clippy_lints/src/transmute/utils.rs at line 54:
         );

         if let Ok(check) = CastCheck::new(
-            &fn_ctxt, e, from_ty, to_ty,
+            &fn_ctxt,
+            e,
+            from_ty,
+            to_ty,
             // We won't show any error to the user, so we don't care what the span is here.
-            DUMMY_SP, DUMMY_SP,
+            DUMMY_SP,
+            DUMMY_SP,

The reason for the diff can be tracked down to the changes made for the Tall case.
In theory we could remove the match arm for the Tall case entirely, and things should basically continue to operate like the current version of rustfmt does. The reason why I added the check was that in my interpretation Tall means, format horizontally, and as soon as you need to wrap go vertical instead of going mixed. When playing around with it, that interpretation of Tall lead to some tests breaking, so I amended it to only force a vertical layout if any list item except the last had a line comment. Trying to force a vertical layout if any list item including the last had aline comment also lead to existing tests failing. @calebcartwright I hope that additional context is helpful. As I mentioned let me know if you'd prefer I just remove the Tall arm or if this is an acceptable behavior change.
Again, I'm planning to run through the same process with other repos, but just thought I'd share my thoughts since I hit a formatting discrepancy right away.

Thanks for testing and sharing the findings with such detail.
Unfortunately we cannot make any changes to the default formatting behavior, even if they are objectively better, so we'll need to do something different. I'm not sure whether that's best accomplished via an additional variant that covers the current behavior and/or some combination with a version gate

hmm I feel like going with a new option to handle the current behavior seems like the best approach to me. Maybe going with something like Inferred or Computed to say that "rustfmt, you figure out what the best argument layout is", but maybe calling it Legacy or even Default would also work.
I think the reason why I wouldn't want to version gate the change is that there are probably plenty of projects that are already using Version=Two, and this would change their formatting unexpectedly.

hmm I feel like going with a new option to handle the current behavior seems like the best approach to me

Sounds good, especially with your reasoning around the version gate. I still want to keep this a priority, but given the findings so far I'm going to punt to the next release as it's more important we get it done correctly vs quickly.
Happy to bikeshed on the name for a bit too. I'd like to avoid any additional cases of Default named variants given their temporal nature and potential for a change to the default at some point down the road, and I'd also prefer to avoid Legacy because of the associated connotations. Perhaps there's a phrase we could derive from the behavior currently prescribed by the Style Guide?

Perhaps there's a phrase we could derive from the behavior currently prescribed by the Style Guide?

Here's what the style guide has to say about function calls, and function definitions. I'm struggling to come up with something derived from what's in the style guide, but I was thinking on it and maybe can call the new option Wraps or Wrap.
Tall could then be used to transition between Horizontal and Vertical, while Wrap(s) is a more gradual transition from Horizontal -> Compressed -> Vertical (aka the current behavior).

Maybe we take inspiration from imports_layout, and keep Tall as the default to maintain the old behavior, but add a new HorizontalVertical option, which will always force a vertical layout if a horizontal layout isn't possible.

Maybe we take inspiration from imports_layout, and keep Tall as the default to maintain the old behavior, but add a new HorizontalVertical option, which will always force a vertical layout if a horizontal layout isn't possible.

I'm not sure I follow, could you elaborate on what you mean? There's two things that should be our guiding principles, or really constraining bounds:

The default variant for this new option has to be identical to current behavior so that rustfmt defaults will remain idempotent after we release this
The variants for this new option that have the same name as varants for fn_params_layout should have the same behavior. E.g. I think it would be too confusing if Tall did one thing for params, while Tall for args did something different

Sorry if that was unclear. Do let me know if I'm misunderstanding what you're saying. What I'm suggesting is that we keep Tall as is, and we introduce a new HorizontalVertical option to handle the formatting that I mentioned.
Currently this is the code change that is causing the formatting discrepancy in the Tall case:
        // we only care if the any element but the last has a sigle line comment
        let any_but_last_contains_line_comment = list_items
            .iter()
            .rev()
            .skip(1)
            .any(|item| item.has_single_line_comment());

        match self.force_list_tactic {
            Some(Density::Tall)
                if tactic == DefinitiveListTactic::Mixed && any_but_last_contains_line_comment =>
            {
                // If we determined a `Mixed` layout, but we configured tall then force
                // the tactic to be vertical only if any of the items contain single line comments.
                // Otherwise, the tacitc was properly set above.
                tactic = DefinitiveListTactic::Vertical
            }

What I'm suggesting is we add a new variant (or a new option altogether) for Density::HorizontalVertical that will act as the Tall case in the current implementation above ☝🏼, so that Tall retains its current meaning, and we use this new option to introduce the "breaking change".
        // we only care if the any element but the last has a sigle line comment
        let any_but_last_contains_line_comment = list_items
            .iter()
            .rev()
            .skip(1)
            .any(|item| item.has_single_line_comment());

        match self.force_list_tactic {
-            Some(Density::Tall)
+            Some(Density::HorizontalVertical)
                if tactic == DefinitiveListTactic::Mixed && any_but_last_contains_line_comment =>
            {
                // If we determined a `Mixed` layout, but we configured tall then force
                // the tactic to be vertical only if any of the items contain single line comments.
                // Otherwise, the tacitc was properly set above.
                tactic = DefinitiveListTactic::Vertical
            }

However if you don't want to introduce a new variant that's fine, and I'm happy to just remove the match arm for the Tall case, which would also solve the formatting issue that we're seeing here.

Perhaps there's some nuance I'm missing as I've not been as deep into the weeds as this as you've been.
I'm :100: with you that we'll need a 4th variant, which for the sake of simplicity I'll just call Foo for now. However, I feel like there's some outstanding questions or at least I'm not sure what you're proposing are:

What the associated formatting behavior would be for the Foo and Tall variants
Whether the default variant would be Foo or Tall

My impression is that your original definition and associated behavior for Tall was logical, consistent, and thus "correct" in the sense of being synonymous with the formatting behavior of the Tall variant for fn_params_layout, but that we needed to implement the new Foo variant that covers whatever the current behavior is, and make Foo the default.
Thoughts?

Okay, I can see where there might have been a disconnect. I've been pitching ideas to keep Tall as the default and introduce something else as the "new" behavior that I described. I'm totally on board with making Foo (name pending) the default, and keeping Tall as I previously defined it. We're on the same page 👍🏼.
I'm going to go ahead and implement this 4th option for the default behavior, and we can brainstorm ideas while I continue to test!

Would TallWithComments be an accurate (albeit poor) reflection of the behavior associated with our current Foo

Some notes on what's going on in the Foo case:
When we call try_overflow_last_item we calculate the initial tactic on line 496-501
https://github.com/rust-lang/rustfmt/blob/23ef4b7ac476714886582865b39d396d615a3901/src/overflow.rs#L496-L501
because there are line comments definitive_tactic returns DefinitiveListTactic::Vertical
https://github.com/rust-lang/rustfmt/blob/23ef4b7ac476714886582865b39d396d615a3901/src/lists.rs#L222-L238
jumping back to try_overflow_last_item we hit this last match arm:
https://github.com/rust-lang/rustfmt/blob/23ef4b7ac476714886582865b39d396d615a3901/src/overflow.rs#L533-L583
And because we have more than one argument and the tactic is Vertical we enter the following if block to see if another list tactic might work, and this is where we end up deciding we should assign a Mixed layout.
https://github.com/rust-lang/rustfmt/blob/23ef4b7ac476714886582865b39d396d615a3901/src/overflow.rs#L552-L581
So from what I can the behavior that we're seeing in the default case comes down to whether the inputs are simple and fall under the short_array_element_width_threshold. I do find it odd that an option that's intended for use with array elements might change how my function arguments are laid out. Maybe this is worth discussing in a future issue, but part of me wonders if try_overflow_last_item is a little too generic, and maybe we should pass some additional information to it so that we know what node the list items came from. Maybe an enum like expr::RhsAssignKind but for list items?
Regardless, here are some inputs I've been playing with that further illustrate what's going on:
Input all elements are simple, and each element is short.
fn main() {
    lorem(
        ipsum,
        dolor,
        sit,
        amet, // some inline comment
        adipiscing,
        elit,
    );
}

output
fn main() {
    lorem(
        ipsum, dolor, sit, amet, // some inline comment
        adipiscing, elit,
    );
}

Input Not all elements are simple, but each element is short.
fn main() {
    lorem(
        ipsum,
        dolor,
        sit(amet), // <--- function calls are not "simple"
        adipiscing,
        elit,
    );
}

output
fn main() {
    lorem(
        ipsum,
        dolor,
        sit(amet), // <--- function calls are not "simple"
        adipiscing,
        elit,
    );
}

Input All elements are simple, but consectetur is not short because it exceed the default short_array_element_width_threshold=10.
fn main() {
    lorem(
        ipsum,
        dolor,
        consectetur, // <--- this item is not "short"
        adipiscing,
        elit,
    );
}

output
fn main() {
    lorem(
        ipsum,
        dolor,
        consectetur, // <--- this item is not "short"
        adipiscing,
        elit,
    );
}

Input The argument list does not fit within max_width normally, but with the comments each line technically does.  I could also see users not totally understanding it.
I think we'd just need to make it extra clear from documentation that TallWithComments produces a pseudo-compresed layout in certain situations when comments are present as I tried to explain above.

@ytmimi @calebcartwright I'm trying (motivated by #5578) to figure out the status of this PR.
From your discussion it seems like the implementation is complete only remaining work was finding a suitable config name for it?


Make neon npm-installable

For building apps based on Neon, it would be nice if it could be installed with npm.

How much are you looking to be installed with npm?  It should be simple enough to bundle the build artifacts (neon.war, neon.js, neon-nodeps.js) together in an npm module.  However, the Neon WAR file is typically installed under a Tomcat instance or equivalent web container.  Once the artifacts are pulled via NPM, it may be preferable to deploy the installed war file via another npm package like grunt-tomcat-deploy or node-tomcat-deploy.

I'm adding this as part of a general clean up of the neon.js dependencies.  So when it goes to npm, it won't require jquery 1 or some ancient version of lodash.

Recent stable builds have been pushed to Neon Framework.


RATIS-588 LogStream StateMachine export

Thanks a lot, @joshelser for the detailed review.  WDYT about the current state now?

UT's pass locally for me too. I think this is just about ready. If Ankit can get the rest of the minor stuff I covered in my last review updated, I think this is ready to go.

Thanks @joshelser , Last commit should have the review comments taken care of.

b618849 looks perfect! Thanks Ankit!


Corrected missing text property on msg object

Proposed Changes
On lines 119 and 140 of UserProfileDialog.cs, the sample incorrectly passes the message object, msg.ToString(), as a response to a disclosed/non-disclosed age. Instead, it should pass the message's text value, msg.Text.ToString().
Line 31 of UserProfileDialog.lg and UserProfileDialog.fr-fr.lg incorrectly checks for a null value when the user selects "No" as a response. It should check for a -1 which is the value that is actually returned.

/azp run


Limitations of autograd's custom primitives

I am wanting to write a custom primitive that implements a forward pass from a pytorch model. I want it to be a custom primitive so that I can use pytorch to differentiate it because autograd cannot do it due to it not being able to handle pytorch tensors.
However, I am finding a pretty significant limitation of custom primitives that is not mentioned in the docs: the custom primitive cannot return an object such as a pytorch tensor that autograd cannot differentiate. This is true, even if you give autograd the vector jacobian product of that primitive and tell autograd not to look inside the primitive.
Here is a basic example:
import torch
from autograd import grad

@primitive
def myfunc(x):
    x_torch = torch.tensor(x)
    return x_torch**2

def myfunc_vjp(ans,x):
    return 2*x

defvjp(myfunc,myfunc_vjp)

def example_func(x):
    return 1+myfunc(x)

x=np.arange(10)
grad_example = grad(example_func)
grad_example(x)

Results in the following error:
TypeError: Can't differentiate w.r.t. type <class 'torch.Tensor'>

Then what is the point of defvjp(myfunc,myfunc_vjp)? I thought it was so that you could black box off your primitive function.

For context, I have a library that uses autograd for differentiating other parts of the call stack that aren't Pytorch objects. I have a Pytorch model plugin in the middle of the stack. My options are try to box off the Pytorch plugin using this custom primitive approach or rewrite the library entirely in Pytorch. Option 1 is highly preferred if it is possible.

Try explicitly casting the output of myfunc, and the output of myfunc_vjp, to NumPy arrays. Note also that myfunc_vjp needs to return a function...
In  [1]: import torch
    ...: from autograd import grad
    ...: from autograd.extend import primitive, defvjp
    ...: import autograd.numpy as np
    ...:
    ...:
    ...: @primitive
    ...: def myfunc(x):
    ...:     x_torch = torch.tensor(x)
    ...:     return np.array(torch.sum(x_torch ** 2))
    ...:
    ...: def myfunc_vjp(ans,x):
    ...:     return lambda g: np.array(2 * x * g)
    ...:
    ...: defvjp(myfunc, myfunc_vjp)
    ...:
    ...: def example_func(x):
    ...:     return 1 + myfunc(x)
    ...:
    ...: x=np.arange(10, dtype='float64')
    ...: grad_example = grad(example_func)
    ...: grad_example(x)
Out [1]: array([ 0.,  2.,  4.,  6.,  8., 10., 12., 14., 16., 18.])

Let me explain why I want myfunc to return a Pytorch tensor. Here is a common pattern in Pytorch for getting gradients via backprop:
a = torch.tensor([2., 3.], requires_grad=True) # some parameter whose gradient I want
Q = a**2 # some loss function(param)
external_grad = torch.tensor([1., 1.]) # dQ/dQ
# backprop
Q.backward(gradient=external_grad) # computes vector Jacobian product
# now we can retreive dQ/da
a.grad # should return 2a = 4, 6

In my real use case, Q contains some Pytorch objects and operations on those objects. Also, Q is called from within another function, example_fun, which doesn't have any Pytorch statements and whose gradient I am getting using autograd:
def Q(x):
    # some Pytorch operations on x ...
    return x**2

def example_func(x):
    return 1+Q(x)

Since Q is not wrapped with @primitive here, Autograd will balk at this because of the Pytorch operations inside of Q. Once I wrap Q, I need to tell autograd how to get dQ/dx. I want to use the Pytorch pattern above to do that, which I will do by using ans.backward inside of the vjp function. That will only work is if ans, the return value of Q, is a Pytorch tensor:
import torch
from autograd import grad
from autograd.extend import primitive, defvjp
import autograd.numpy as np

@primitive
def Q(x):
    # some Pytorch operations on x ...
    global x_torch
    x_torch = torch.tensor(x,requires_grad=True)
    return x_torch**2

def Q_vjp(ans,x):
    external_gradient = torch.ones(len(x))
    ans.backward(gradient=external_gradient)
    dQdx = x_torch.grad
    print(dQdx)
    return lambda g: np.array(dQdx*g)

def example_func(x):
    return 1+Q(x)

defvjp(Q,Q_vjp)

x=np.arange(10, dtype='float64')
grad_example = grad(example_func)
grad_example(x)

The printed value, print(dQdx), is the correct gradient. However, before the code completes I get an error:
Input In [256], in example_func(x)
     20 def example_func(x):
---> 21     return 1+Q(x)

File ~/anaconda3/envs/seldo-pytorch/lib/python3.9/site-packages/autograd/tracer.py:46, in primitive.<locals>.f_wrapped(*args, **kwargs)
     44     ans = f_wrapped(*argvals, **kwargs)
     45     node = node_constructor(ans, f_wrapped, argvals, kwargs, argnums, parents)
---> 46     return new_box(ans, trace, node)
     47 else:
     48     return f_raw(*args, **kwargs)

File ~/anaconda3/envs/seldo-pytorch/lib/python3.9/site-packages/autograd/tracer.py:120, in new_box(value, trace, node)
    118     return box_type_mappings[type(value)](value, trace, node)
    119 except KeyError:
--> 120     raise TypeError("Can't differentiate w.r.t. type {}".format(type(value)))

TypeError: Can't differentiate w.r.t. type <class 'torch.Tensor'>

Which to me indicates that issue is that Q returns a tensor, which autograd cannot differentiate. This surprises me because by wrapping Q with @primitive I am explicitly telling autograd not to differentiate Q. So why is it trying to?
I can get around this by using another global variable, which is inefficient and bad style, but my question still stands
import torch
from autograd import elementwise_grad as egrad
from autograd.extend import primitive, defvjp
import autograd.numpy as np

@primitive
def Q(x):
    # some Pytorch operations on x ...
    global x_torch
    x_torch = torch.tensor(x,requires_grad=True)
    global Q_torch
    Q_torch = x_torch**2
    return x**2

def Q_vjp(ans,x):
    external_gradient = torch.ones(len(x))
    Q_torch.backward(gradient=external_gradient)
    dQdx = x_torch.grad
    print(dQdx)
    return lambda g: np.array(dQdx*g)

def example_func(x):
    return 1+Q(x)

defvjp(Q,Q_vjp)

x=np.arange(10, dtype='float64')
grad_example = egrad(example_func)
grad_example(x)

@austinhoag did you ever figure anything out? Dealing with a similar issue here. Note that with Jax it seems you can have a bit more control over defining your own vjp maker, but you need to register your object as a pytree for things to work properly https://jax.readthedocs.io/en/latest/notebooks/Custom_derivative_rules_for_Python_code.html

The defvjp function works by storing the gradient function in a Python dictionary, where the key is the callable returned by primitive. I think your setup means the dictionary lookup is not working because the key changes between registering and lookup.
Is it possible for you to do something like this:
import autograd.numpy as np
from autograd import grad
from autograd.extend import primitive, defvjp

class myModel():
    def myfunc(self,x):
        # some Pytorch operations on x ...
        return np.sum(x**2)

    def myfunc_grad(self,ans,x):
        return lambda g: np.array(2*x*g)

m = myModel()

myfunc = primitive(m.myfunc)
defvjp(myfunc, m.myfunc_grad)

def example_func(x,model):
    return 1+myfunc(x)  # This must be the same (same Python object id) myfunc passed to defjvp above

x=np.arange(10, dtype='float64')
grad_example = grad(example_func)
grad_example(x,m)

If you can I would also consider moving to using JAX, which supports this functionality but is much better documented.

Thanks, that solution worked for me. For anyone else interested, it is also possible to put the defvjp() call inside of __init__() like this:
import autograd.numpy as np
from autograd import grad
from autograd.extend import primitive, defvjp

class myModel():
    def __init__(self):
        myfunc_primitive = primitive(self.myfunc)
        defvjp(myfunc_primitive, self.myfunc_grad)

    def myfunc(self,x):
        # some Pytorch operations on x ...
        return np.sum(x**2)

    def myfunc_grad(self,ans,x):
        return lambda g: np.array(2*x*g)

def example_func(x,model):
    return 1+model.myfunc(x)

m = myModel()
x=np.arange(10, dtype='float64')
grad_example = grad(example_func)
grad_example(x,m)

I have looked into JAX some, though not for this purpose. The reason I stay with autograd is that JAX is actually slower for my library's tasks even with vmapping and jitting. I need to play around a bit more with trying to optimize, though, as I suspect there will be a way to restructure my code to make it faster. It does seem like there are many other reasons to move to JAX, so I may try to migrate anyway.
The last thing that remains to be addressed before I close this is: "why can't the primitive function return a PyTorch tensor, even if I wrap it with @primitive?"

The reason I stay with autograd is that JAX is actually slower for my library's tasks even with vmapping and jitting.

Interesting. JAX used to be pretty slow on CPU, due to large 'dispatch overheads'. Basically launching the correct compiled code for a given function and input requires some logic, which was implemented in Python, but has now been sped up by a C++ implementation. I think for certain things (particularly things which bottleneck on BLAS calls) NumPy (and therefore Autograd) might still be faster though. As you say you can often tune the implementation to whichever library you're using and see some improvements, and there are certain things where having a proper compiler underneath means that jit-compiled JAX will be significantly faster than NumPy.

why can't the primitive function return a PyTorch tensor, even if I wrap it with @primitive?

Autograd has a small, built-in type system, of what we call VSpaces (short for 'vector spaces'). The main definition is here. In order for a Python value to be a valid intermediate in a function that is being differentiated by Autograd (that is an input, or an output, of a primitive), its type must have a registered VSpace. The VSpace for a given Python type tells Autograd how to add elements of that type, how to materialize a 'zero' of that type, and how to multiply that type by a scalar, basically the things you'd expect for a vector space. We don't have VSpaces setup for PyTorch Tensors.
The VSpace system is actually extensible, although completely undocumented. You can see how VSpaces are defined for NumPy arrays here.

Thanks, that makes sense.


[SerperRM Bug]

valid_url_to_snippets.get(url, {}) get none value.
call strip function will be fix it. just like url.strip("'")

Could you contribute this fix directly to main branch? Thanks!


YARN-11534. Fixed exception handling when container signalling is interrupted

Change-Id: I5cc10436be452ee51c604acd60d92b49fa10a75b

Description of PR
Fixed exception handling when container signalling is interrupted. Issue details are in this ticket: https://issues.apache.org/jira/browse/YARN-11534
Previously in LinuxContainerExecutor we threw only IOException when an error occurred during signalling a container. In RecoveredContainerLaunch, where we are calling this method, we use an "interrupted" flag to determine if the container reacquisition was interrupted. In that case we won't persist the default LOST state in the NM state store.
This flag is only set when catching Interrupted and InterruptedIOExceptions during container recovery. For that reason we need to differentiate the cases when signalling is interrupted, and we can use the ContainerExecutionException's exit code for that.
How was this patch tested?
With unit tests.
For code changes:

[x] Does the title or this PR starts with the corresponding JIRA issue id (e.g. 'HADOOP-17799. Your PR title ...')?
[ ] Object storage: have the integration tests been executed and the endpoint declared according to the connector-specific documentation?
[ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
[ ] If applicable, have you updated the LICENSE, LICENSE-binary, NOTICE-binary files?

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 51s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

-1 :x:
test4tests
0m  0s

The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
49m 30s

trunk passed

+1 :green_heart:
compile
1m 29s

trunk passed with JDK Ubuntu-11.0.19+7-post-Ubuntu-0ubuntu120.04.1

+1 :green_heart:
compile
1m 24s

trunk passed with JDK Private Build-1.8.0_362-8u372-ga~us1-0ubuntu1~20.04-b09

+1 :green_heart:
checkstyle
0m 37s

trunk passed

+1 :green_heart:
mvnsite
0m 43s

trunk passed

+1 :green_heart:
javadoc
0m 46s

trunk passed with JDK Ubuntu-11.0.19+7-post-Ubuntu-0ubuntu120.04.1

+1 :green_heart:
javadoc
0m 36s

trunk passed with JDK Private Build-1.8.0_362-8u372-ga~us1-0ubuntu1~20.04-b09

+1 :green_heart:
spotbugs
1m 29s

trunk passed

+1 :green_heart:
shadedclient
40m  8s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 35s

the patch passed

+1 :green_heart:
compile
1m 23s

the patch passed with JDK Ubuntu-11.0.19+7-post-Ubuntu-0ubuntu120.04.1

+1 :green_heart:
javac
1m 23s

the patch passed

+1 :green_heart:
compile
1m 17s

the patch passed with JDK Private Build-1.8.0_362-8u372-ga~us1-0ubuntu1~20.04-b09

+1 :green_heart:
javac
1m 17s

the patch passed

-1 :x:
blanks
0m  0s
/blanks-eol.txt
The patch has 1 line(s) that end in blanks. Use git apply --whitespace=fix <<patch_file>>. Refer https://git-scm.com/docs/git-apply

+1 :green_heart:
checkstyle
0m 27s

the patch passed

+1 :green_heart:
mvnsite
0m 35s

the patch passed

+1 :green_heart:
javadoc
0m 34s

the patch passed with JDK Ubuntu-11.0.19+7-post-Ubuntu-0ubuntu120.04.1

+1 :green_heart:
javadoc
0m 30s

the patch passed with JDK Private Build-1.8.0_362-8u372-ga~us1-0ubuntu1~20.04-b09

+1 :green_heart:
spotbugs
1m 27s

the patch passed

+1 :green_heart:
shadedclient
38m 30s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
24m  3s

hadoop-yarn-server-nodemanager in the patch passed.

+1 :green_heart:
asflicense
0m 35s

The patch does not generate ASF License warnings.

170m 14s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5864/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/5864

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets

uname
Linux 18c4a4356254 4.15.0-213-generic #224-Ubuntu SMP Mon Jun 19 13:30:12 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 5069cc15c593abdbad1b27791f92b1f1db9a80d5

Default Java
Private Build-1.8.0_362-8u372-ga~us1-0ubuntu1~20.04-b09

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.19+7-post-Ubuntu-0ubuntu120.04.1 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_362-8u372-ga~us1-0ubuntu1~20.04-b09

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5864/1/testReport/

Max. process+thread count
529 (vs. ulimit of 5500)

modules
C: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager U: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5864/1/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 32s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
35m 46s

trunk passed

+1 :green_heart:
compile
1m  8s

trunk passed with JDK Ubuntu-11.0.19+7-post-Ubuntu-0ubuntu120.04.1

+1 :green_heart:
compile
1m  3s

trunk passed with JDK Private Build-1.8.0_362-8u372-ga~us1-0ubuntu1~20.04-b09

+1 :green_heart:
checkstyle
0m 30s

trunk passed

+1 :green_heart:
mvnsite
0m 35s

trunk passed

+1 :green_heart:
javadoc
0m 38s

trunk passed with JDK Ubuntu-11.0.19+7-post-Ubuntu-0ubuntu120.04.1

+1 :green_heart:
javadoc
0m 32s

trunk passed with JDK Private Build-1.8.0_362-8u372-ga~us1-0ubuntu1~20.04-b09

+1 :green_heart:
spotbugs
1m  6s

trunk passed

+1 :green_heart:
shadedclient
23m 26s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 25s

the patch passed

+1 :green_heart:
compile
0m 53s

the patch passed with JDK Ubuntu-11.0.19+7-post-Ubuntu-0ubuntu120.04.1

+1 :green_heart:
javac
0m 53s

the patch passed

+1 :green_heart:
compile
0m 50s

the patch passed with JDK Private Build-1.8.0_362-8u372-ga~us1-0ubuntu1~20.04-b09

+1 :green_heart:
javac
0m 50s

the patch passed

-1 :x:
blanks
0m  0s
/blanks-eol.txt
The patch has 3 line(s) that end in blanks. Use git apply --whitespace=fix <<patch_file>>. Refer https://git-scm.com/docs/git-apply

+1 :green_heart:
checkstyle
0m 18s

the patch passed

+1 :green_heart:
mvnsite
0m 25s

the patch passed

+1 :green_heart:
javadoc
0m 26s

the patch passed with JDK Ubuntu-11.0.19+7-post-Ubuntu-0ubuntu120.04.1

+1 :green_heart:
javadoc
0m 25s

the patch passed with JDK Private Build-1.8.0_362-8u372-ga~us1-0ubuntu1~20.04-b09

+1 :green_heart:
spotbugs
0m 59s

the patch passed

+1 :green_heart:
shadedclient
23m  3s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
22m  8s

hadoop-yarn-server-nodemanager in the patch passed.

+1 :green_heart:
asflicense
0m 29s

The patch does not generate ASF License warnings.

118m  0s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5864/3/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/5864

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets

uname
Linux 0c63f459da9f 4.15.0-213-generic #224-Ubuntu SMP Mon Jun 19 13:30:12 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 6ed8f29c1501afd65a2439a40034fdcb79917aba

Default Java
Private Build-1.8.0_362-8u372-ga~us1-0ubuntu1~20.04-b09

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.19+7-post-Ubuntu-0ubuntu120.04.1 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_362-8u372-ga~us1-0ubuntu1~20.04-b09

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5864/3/testReport/

Max. process+thread count
553 (vs. ulimit of 5500)

modules
C: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager U: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5864/3/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
1m  0s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  1s

codespell was not available.

+0 :ok:
detsecrets
0m  1s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
55m  2s

trunk passed

+1 :green_heart:
compile
1m 30s

trunk passed with JDK Ubuntu-11.0.19+7-post-Ubuntu-0ubuntu120.04.1

+1 :green_heart:
compile
1m 23s

trunk passed with JDK Private Build-1.8.0_362-8u372-ga~us1-0ubuntu1~20.04-b09

+1 :green_heart:
checkstyle
0m 38s

trunk passed

+1 :green_heart:
mvnsite
0m 44s

trunk passed

+1 :green_heart:
javadoc
0m 47s

trunk passed with JDK Ubuntu-11.0.19+7-post-Ubuntu-0ubuntu120.04.1

+1 :green_heart:
javadoc
0m 38s

trunk passed with JDK Private Build-1.8.0_362-8u372-ga~us1-0ubuntu1~20.04-b09

+1 :green_heart:
spotbugs
1m 30s

trunk passed

+1 :green_heart:
shadedclient
38m 41s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 34s

the patch passed

+1 :green_heart:
compile
1m 21s

the patch passed with JDK Ubuntu-11.0.19+7-post-Ubuntu-0ubuntu120.04.1

+1 :green_heart:
javac
1m 21s

the patch passed

+1 :green_heart:
compile
1m 15s

the patch passed with JDK Private Build-1.8.0_362-8u372-ga~us1-0ubuntu1~20.04-b09

+1 :green_heart:
javac
1m 15s

the patch passed

-1 :x:
blanks
0m  0s
/blanks-eol.txt
The patch has 2 line(s) that end in blanks. Use git apply --whitespace=fix <<patch_file>>. Refer https://git-scm.com/docs/git-apply

+1 :green_heart:
checkstyle
0m 26s

the patch passed

+1 :green_heart:
mvnsite
0m 34s

the patch passed

+1 :green_heart:
javadoc
0m 34s

the patch passed with JDK Ubuntu-11.0.19+7-post-Ubuntu-0ubuntu120.04.1

+1 :green_heart:
javadoc
0m 30s

the patch passed with JDK Private Build-1.8.0_362-8u372-ga~us1-0ubuntu1~20.04-b09

+1 :green_heart:
spotbugs
1m 27s

the patch passed

+1 :green_heart:
shadedclient
38m 57s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
24m  0s

hadoop-yarn-server-nodemanager in the patch passed.

+1 :green_heart:
asflicense
0m 34s

The patch does not generate ASF License warnings.

175m  0s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5864/2/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/5864

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets

uname
Linux d15ae3fa708d 4.15.0-213-generic #224-Ubuntu SMP Mon Jun 19 13:30:12 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / ce2c183455df5710ae2655565f0312b6ffd82589

Default Java
Private Build-1.8.0_362-8u372-ga~us1-0ubuntu1~20.04-b09

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.19+7-post-Ubuntu-0ubuntu120.04.1 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_362-8u372-ga~us1-0ubuntu1~20.04-b09

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5864/2/testReport/

Max. process+thread count
571 (vs. ulimit of 5500)

modules
C: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager U: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5864/2/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

Sure, thanks for the review @brumi1024!

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 48s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
54m 48s

trunk passed

+1 :green_heart:
compile
1m 30s

trunk passed with JDK Ubuntu-11.0.19+7-post-Ubuntu-0ubuntu120.04.1

+1 :green_heart:
compile
1m 25s

trunk passed with JDK Private Build-1.8.0_362-8u372-ga~us1-0ubuntu1~20.04-b09

+1 :green_heart:
checkstyle
0m 38s

trunk passed

+1 :green_heart:
mvnsite
0m 44s

trunk passed

+1 :green_heart:
javadoc
0m 47s

trunk passed with JDK Ubuntu-11.0.19+7-post-Ubuntu-0ubuntu120.04.1

+1 :green_heart:
javadoc
0m 38s

trunk passed with JDK Private Build-1.8.0_362-8u372-ga~us1-0ubuntu1~20.04-b09

+1 :green_heart:
spotbugs
1m 28s

trunk passed

+1 :green_heart:
shadedclient
38m 58s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 34s

the patch passed

+1 :green_heart:
compile
1m 24s

the patch passed with JDK Ubuntu-11.0.19+7-post-Ubuntu-0ubuntu120.04.1

+1 :green_heart:
javac
1m 24s

the patch passed

+1 :green_heart:
compile
1m 17s

the patch passed with JDK Private Build-1.8.0_362-8u372-ga~us1-0ubuntu1~20.04-b09

+1 :green_heart:
javac
1m 17s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
0m 28s

the patch passed

+1 :green_heart:
mvnsite
0m 35s

the patch passed

+1 :green_heart:
javadoc
0m 33s

the patch passed with JDK Ubuntu-11.0.19+7-post-Ubuntu-0ubuntu120.04.1

+1 :green_heart:
javadoc
0m 30s

the patch passed with JDK Private Build-1.8.0_362-8u372-ga~us1-0ubuntu1~20.04-b09

+1 :green_heart:
spotbugs
1m 27s

the patch passed

+1 :green_heart:
shadedclient
38m 56s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
23m 59s

hadoop-yarn-server-nodemanager in the patch passed.

+1 :green_heart:
asflicense
0m 35s

The patch does not generate ASF License warnings.

174m 34s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5864/4/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/5864

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets

uname
Linux 784747a2927e 4.15.0-213-generic #224-Ubuntu SMP Mon Jun 19 13:30:12 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / f64a9234791cf78eac94c1eaefa705cf5a481c23

Default Java
Private Build-1.8.0_362-8u372-ga~us1-0ubuntu1~20.04-b09

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.19+7-post-Ubuntu-0ubuntu120.04.1 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_362-8u372-ga~us1-0ubuntu1~20.04-b09

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5864/4/testReport/

Max. process+thread count
583 (vs. ulimit of 5500)

modules
C: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager U: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5864/4/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

Merged to trunk.


Chrome Driver throws error when trying to open new tab in Incognito mode

Steps to reproduce:
    driver.StartChrome

    driver.OpenBrowser incognito:=True

    driver.NavigateTo "https://www.wikipedia.org/"
    driver.Wait 1000

    hnd = driver.SwitchToNewWindow(svbaTab) 'error happens here

Above results in "Failed to open new tab - no browser is open".
It doesn't happen with Edge - only Chrome.
Look similar to this bug report - I will need to report same to the Chrome Driver team...

I can confirm all

The Chrome and Edge Driver teams seem to be VERY SLOW fixing bugs. Here is a work-around until the bug is fixed:
'In Edge/Chrome, creating new windowType:=svbaTab while using incognito mode will throw an error
'instead of this:
'driver.Windows.SwitchToNew windowType:=svbaTab  'error happens here
'use this:
driver.ExecuteScript "window.open('', '_blank')" 'creates the new tab
driver.Windows.SwitchToByUrl("about:blank") 'switches to new tab

I confirm that your workaround works on my system too


BPF masquerade works only in veth mode

When I enabled bpf-masquerade in ipvlan mode. I got the error message. Do you have some milestones to support bpf-masq in ipvlan mode? Thanks for any reply.

It's been planned with a very low priority. However, the new datapath mode based on veth which performance is on par with ipvlan is coming this week (https://linuxplumbersconf.org/event/7/contributions/674/attachments/568/1002/plumbers_2020_cilium_load_balancer.pdf slide 79).

excellent !!


Fix ara-pruner to find where the ARA db is

The ARA cli program looks for ansible.cfg in a few places, and if it
doesn't find it, it uses some defaults and creates a new ARA db.
This leads the ara-pruner script to not be looking at the right
database. This points it at the right place.
Signed-off-by: Bradon Kanyid<EMAIL_ADDRESS>

I'm abandoning this for now, because activating it now will probably slow the bastion WAY down for a while.


update cs50 courses

What does this PR do?
Remove resource | Improve repo
For resources
Description
Introduction to Computer Science is not a C language course. The course is added in the Computer Science section as CS50's Introduction to Computer Science.
Explanation of other changes: CS50 courses are updated between 1-3 years. The latest version has the year in which it was updated e.g. /ai/2020. If the links are changed just to e.g. /ai/, removing the year, the site will automatically redirect to the latest year which is better than getting sent to some older version of the course after it gets updated.
Why is this valuable (or not)?
How do we know it's really free?
For book lists, is it a book? For course lists, is it a course? etc.
Checklist:

[x] Read our contributing guidelines.
[x] Search for duplicates.
[x] Include author(s) and platform where appropriate.
[x] Put lists in alphabetical order, correct spacing.
[x] Add needed indications (PDF, access notes, under construction).
[x] Used an informative name for this pull request.

Follow-up

Check the status of GitHub Actions and resolve any reported warnings!

very helpful


Move migration and publishing of contracts (Ethereum) to GH Actions

As described in RFC-18, there is a need for a refactorization of Keep
and tBTC release processes in order to reduce human involvement and
make the processes faster and less error prone. A part of this task is
migration from CircleCI jobs to GitHub Actions. This commit enhances
the workflow for building and testing Solidity with a job migrating
contracts and publishing them to the npm registry. Contracts also get
pushed to Tenderly and uploaded to Google Cloud Storage. For now, only
keep-test configuration is implemented. Implementation for other
environments will be done at a later stage of work on RFC-18.
The migrate-and-publish-ethereum job is configured to execute only if
workflow is started by a push or workflow_dispatch event on master or
rfc-18/* branch. The rfc-18/* condition will need to be removed
once whole build-test-migrate-publish-keep-test CircleCI process
gets migrated to GH Actions.
Additionally, as we may not always want to migrate and publish
contracts on every push (or workflow_dispatch) on master, the job was
configured to require manual approval in GitHub GUI. This is done by
configuration of environment protection rules on keep-test and using
environment: keep-test config in the workflow.

@lukasz-zimnoch, @nkuba - migration and push to Tenderly are finally working (see run #650) :tada: You can review and merge if no changes needed.

Good to merge. The comments I left can be handled in another PR.

Thanks for the input :) I applied the proposed changes as part of this cleanup PR: https://github.com/keep-network/keep-core/pull/2378.


chore: Update dependencies

This pull request was auto-generated by GitHub Actions.

Codecov Report

Merging #52 (28a0bc5) into master (6519e2f) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##            master       #52   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            2         2
  Lines            2         2
=========================================
  Hits             2         2

Impacted Files
Coverage Δ

deps.ts
100.00% <100.00%> (ø)

tests/deps.ts
100.00% <100.00%> (ø)

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 6519e2f...28a0bc5. Read the comment docs.


[firebase_messaging] better handling on background isolate initialization

Description
Handles the creation of the background isolate/view/channel by adding a guard if its already available.
Reproducing steps:

Launch activity and add an background handler for firebase message.
Press the back button.
Launch again the activity.
Press the home button.
Send FCM and as you will see you won't see your method being called in the background.

Related Issues
Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] If the pull request affects only one plugin, the PR title starts with the name of the plugin in brackets (e.g. [cloud_firestore])
[x] My PR includes unit or integration tests for all changed/updated/fixed behaviors (See Contributor Guide).
[x] All existing and new tests are passing.
[x] I updated/added relevant documentation (doc comments with ///).
[x] The analyzer (flutter analyze) does not report any problems on my PR.
[x] I read and followed the Flutter Style Guide.
[x] I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy.
[ ] I updated CHANGELOG.md to add a description of the change.
[x] I signed the CLA.
[x] I am willing to follow-up on review comments in a timely manner.

Breaking Change

[ ] Yes, this is a breaking change (please indicate a breaking change in CHANGELOG.md and increment major revision).
[x] No, this is not a breaking change.

Is this related to @https://github.com/FirebaseExtended/flutterfire/issues/1754?

Is this related to #1754 ?

I think not. Its a bug i have found when pressing the back button and going to home and then reopening the app, you wont receive background notifications anymore

Reproducing steps:
Launch activity and add an background handler for firebase message.
Press the back button.
Launch again the activity.
Press the home button.
Send FCM and as you will see you won't see your method being called in the background.
I received: "Service took too long to process intent: com.google.android.c2dm.intent.RECEIVE App may get closed."
Is this related to #2196?

I don't know exactly because it never happened to me , or at least I didn't see that error. It has to do more, not been able to receive background notifications, after following the reproducing steps. But I don't know if this problem is solved with newer updates on the plugin... Because it's been like 3 months and I got no responses

I don't know exactly because it never happened to me , or at least I didn't see that error. It has to do more, not been able to receive background notifications, after following the reproducing steps. But I don't know if this problem is solved with newer updates on the plugin... Because it's been like 3 months and I got no responses

The problem persists. I have tried it in the Beta and Dev channel. I am not sure why it happens ... currently the only test I have not done is using embedding v1., Since I use plugins that I use and they benefit from embedding v2

i can try with the new embedding and and inform u, i need some time tho, because i have been in touch with flutter in 2months :(

hi @fbrus92 i've tried it on a new project with the latest version of messaging 6.0.15, and it seems that it works fine without the error you showed me. (i tested it on a xiaomi phone).
But something else got my attention.

If u kill the activity (by pressing back for example) it creates a new background thread without terminating / reusing the old one, i think i am not 100% percent or maybe i have messed up the registration of the background registrant.
`class App : FlutterApplication(), PluginRegistry.PluginRegistrantCallback {
override fun onCreate() {
super.onCreate()
FlutterFirebaseMessagingService.setPluginRegistrant(this)
}
override fun registerWith(registry: PluginRegistry) {
if (!registry.hasPlugin("io.flutter.plugins.firebasemessaging.FirebaseMessagingPlugin")) {
FirebaseMessagingPlugin.registerWith(registry.registrarFor("io.flutter.plugins.firebasemessaging.FirebaseMessagingPlugin"))
}
}
}`
i have tried both with and without the if part. (flutter embedding 2)

I also tried this version of the plugin (from this commit, i have locally on my pc) and seems to work fine. without the multiple threads problem that is occuring on the previous comment.

I also tried this version of the plugin (from this commit, i have locally on my pc) and seems to work fine. without the multiple threads problem that is occuring on the previous comment.

The problem also occurs with the Firebase Messaging version 6.0.15., But this only happens with the messages interpreted by "onBackgroundMessage"
{
  "to": "{firabase_token}",
  "collapse_key": "type_a",
  "id": 4,
"data": {
         "extra_data": "some data",
         "click_action": "FLUTTER_NOTIFICATION_CLICK"
       }
}
Note that using the following configuration:
firebase_messaging:
     git:
       url: git: //github.com/spideythewebhead/flutterfire.git
       path: packages / firebase_messaging
       ref: prevent_multiple_background_views_and_channels_creation_for_background_isolate
The number of references to "main" decreased substantially compared to version 6.0.15
and the error doesn't happen anymore !!!

@Fbrusca i am glad it works for you 👍

Just had an issue and @spideythewebhead repo worked for me as well.
To me the issue started once I've created another background channel. Not sure if it's truly the source though since I've added few other things as well.
Either way this PR should get in.


On device handoff payment on a S700 reader, "Current Activity is missing"

Describe the bug
We are implementing the handoff type with a S700 dev kit, discovery is working as expected without issues on all discovery methods.
Upon collectPaymentMethod, it fails and goes no further. When looking at the device logs with logcat we see the following
Reference to the app's current Activity is missing. Did you call TerminalApplicationDelegate::onCreate before calling initTerminal
After some investigation and digging, I can see in "StripeTerminalReactNativeModule.kt" line 117
UiThreadUtil.runOnUiThread { onCreate(context.applicationContext as Application) }
Is being called in a UIThread.
This occasionally causes this message in the logs when calling initialize StripeTerminal: class=Terminal message="TerminalApplicationDelegate::onCreate was not called before initTerminal.
It is worth noting, I do have this working... By first adding the below into the build.gradle
implementation("com.stripe:stripeterminal-core:3.4.0")
implementation("com.stripe:stripeterminal-handoffclient:3.4.0")
Then importing the below into MainApplication.kt
import com.stripe.stripeterminal.TerminalApplicationDelegate
Then adding
TerminalApplicationDelegate.onCreate(this)
just below the super.onCreate()
However I would imagine the expected behaviour of this library is that it can simply be installed and have the handoff work "on device" without having to edit your MainApplication.kt or am I wrong?
To Reproduce
Steps to reproduce the behavior:

Create a react native application for "on device" POS
Side load and start up the application on a S700
Start logcat or your logger of preference
Initialise the sdk from the function returned by useStripeTerminal()
Discover and connect to a handoff device.
Start a payment (createPaymentIntent -> collectPaymentMethod)
Check the logs and notice the error

Expected behavior
A handoff payment on a S700 should work using the react native sdk implementation.
Screenshots

Stripe Terminal React Native SDK version
0.0.1-beta.17
Smartphone (please complete the following information):

Device: S700, reader version 2.22.2

hey @Sheaffy unfortunately for handoff mode you will need to edit your MainApplication.kt file. We haven't gotten around to updating the documentation yet, but refer to this PR where we added handoff support for our dev-app: https://github.com/stripe/stripe-terminal-react-native/pull/578/files#diff-9164d5d9dc4cce265ff214d6771592da55824301dac5bb2588bc771b6afcfc96R58
You need to import com.stripeterminalreactnative.TerminalApplicationDelegate; and call its onCreate() method.

Ahh, so my solution is correct then.
thank you for the clarification.

Hi, if I can ask, how would I achieve this fix in an Expo app?
As far I can tell, I can't edit the Kotlin files, since there are non in the project files.
The problem appears on the first load of the dev server after starting "npx expo start", if I update any code and it gets pushed to the dev server, it starts working.


Incorrect integer parsing from XLS files

When importing a XLS file with mixed content in one column (e.g.: integer and strings), the integers get parsed as strings with a .0 adding at the end.
XLSX files got parsed as expected.
We can expect the numbers to be parsed as strings, since there is a row with text in the same column. The issue is the .0 that is added to the value.
This is reproducing both in production and onpremise (tested in v1.2.1 and v1.3.0)
Sample data:
test.zip
STR
1

Import dummy_dataset.xls from the sample data
Integers from column d get parsed as 456.0 (string)

2

Import dummy_dataset.xslx from the sample data
Integers from column d get parsed as 456

Expected result
The numbers should get imported as strings, since there is a row with text, but shouldn't have the .0 ending

This problem comes from csvkit, we use in2csv to parse xls or xlsx files to csv in the import process.
Seems like in2csv behaves differently for xls and xlsx:
ubuntu@cdb-dev:/tmp$ in2csv dummy_dataset.xls
a, b, c,lat,lon,d
1.4326,true,thisIsText,37.34,-2.78,234.0
2.3857,false,soIsThis,40.34,-1.94,567.0
,,,,,text
ubuntu@cdb-dev:/tmp$ in2csv dummy_dataset.xlsx
a, b, c,lat,lon,d
1.4326,true,thisIsText,37.34,-2.78,245
2.3857,false,soIsThis,40.34,-1.94,567
,,,,,text

I'll ask the owner of the project about this

https://github.com/wireservice/csvkit/issues/639#issuecomment-232382999

You can use this small script to get over the issue:
https://github.com/pavanvamsi3/random-scripts/blob/master/dot_scripy.py


Find-all-references for [Foo] does not show reference to FooAttribute

Environment data
dotnet --info output:
.NET Command Line Tools (2.0.0-preview1-005977)

Product Information:
 Version:            2.0.0-preview1-005977
 Commit SHA-1 hash:  414cab8a0b

Runtime Environment:
 OS Name:     linuxmint
 OS Version:  18.1
 OS Platform: Linux
 RID:         linuxmint.18.1-x64
 Base Path:   /usr/share/dotnet/sdk/2.0.0-preview1-005977/

Microsoft .NET Core Shared Framework Host

  Version  : 2.0.0-preview1-002111-00
  Build    : 1ff021936263d492539399688f46fd3827169983

VS Code version: 1.15.0-Insider
C# Extension version: 1.11.0
Steps to reproduce
using System;

class FooAttribute : Attribute {}

class C
{
	[Foo]
	void m() {}

	void n(FooAttribute f) {}
}

Find-all-references at Foo.
Expected  behavior
Find all 3 references.
Actual behavior
Only get references to [Foo] and the definition for FooAttribute, but not the use FooAttribute f.

The reason is [Foo] is a constructor symbol not a type symbol, so finding references to it doesn't return the usages of FooAttribute type. Instead it would be fine here:
    class FooAttribute : Attribute { }

    class C
    {
        [Foo]
        void m() { }

        void n() { var x = new FooAttribute(); }
    }

@DustinCampbell Visual Studio behaves the same way, it won't find inline usages of an attribute type from the annotation, it would however report constructor usages. So all things considered, is this something we ought to be addressing in OmniSharp?

@fillipw: I'd be surprised if VS works that way. If it does, it'd be a bug (@Pilchie, is that the case?). VS (and Roslyn) "cascades" between type and constructor symbols. When I looked at OmniSharp, it appeared to have it's own logic for Find All References rather than using the Roslyn API.

at least this is what I see in VS when the caret is on [Foo]:

on the other hand, when moving to FooAttribute parameter, find references finds everything correctly:

Today we do a FAR to the constructor, and that doesn't cascade to the type, though it does cascade in the reverse direction.  See https://github.com/dotnet/roslyn/issues/3225.

OK. So that's consistent with @filipw's screenshots.

This could be an issue with the O# server. If it is still a problem, please open an issue at https://github.com/OmniSharp/omnisharp-roslyn/issues


Add a progress bar to the control panel

We need to gather metrics from the pipeline while it is running then show it in the control-panel. This was supposed to be easy if FlinkRunner's Pipeline.run() was not blocking (more context here). One way to do this is to implement a custom solution for reporting number of fetched resources.

[Investigate and identify feasible solutions]
[Implement the solution]

Hello!  Can we get a brief status update on the progress here?  Have we arrived at a proposed solution and time estimate?  Has that been agreed upon?  Is it being implemented?

Currently the solutions are still being analysed and yet to agree upon a solution. Have documented the approaches in a separate doc, will update back here once the approach is finalised along with estimates.

From @chandrashekar-s
"The implementation is almost complete, should take another day or so to close things."

Chandra, did you say you had a PR for this already?  If so, can you link it to this?


On symptoms custom reports (My Risk Prof / My Sleep Apnea), tweak wording for new answer choices

The "My Risk Profile" and "My Sleep Apnea" surveys were updated on staging to add more answer choices to the symptoms questions. Check to confirm that the custom report works correctly with the new answer choices in place.

Also, this wording should be phrased differently between these two surveys. "My Risk Profile" (screenshot above) has nothing to do with evaluations for sleep apnea or diagnosis.
I think the particular phrasing to confirm/change/remove is the "X% of MyApnea users report experiencing this symptom one year.." We could choose a new cutoff now that we have expanded answer choices, e.g. "at least 3 years.." (choose 3-5 years, 6-10 years, 11 or more years).

Will need the updated question options to go live before doing this - can do a 9.3 point release with the following changes:
_sleep_apnea_symptoms_statistics.html.haml
- ri5 = ReportItem.new(answer_option_counts, answer_template, 5)
- all_ri = [ri1, ri2, ri3, ri4, ri5]
= ri2.percent_raw + ri3.percent_raw + ri4.percent_raw + ri5.percent_raw

%span.primary-orange= ri2.percent_raw + ri3.percent_raw + ri4.percent_raw + ri5.percent_raw
        of MyApnea users report experiencing this symptom at least one year before diagnosis.

Temporarily commented out the soon-to-be-incorrect wording


MerkleStore extract structures

AccountStorage is structured as follow:
pub struct AccountStorage {
    slots: SimpleSmt,   // SMT of depth 8
    store: MerkleStore, // Merkle store for any tree data
}

The leaves of the SimpleSmt can represent roots of Merkle structures stored in the MerkleStore.  For more information on this implementation see here. To support such an implementation we need the ability to extract Merkle structures from the MerkleStore based on their roots.  The interface we would need to implement is:
impl MerkleStore {
    pub fn subtree(&self, root: Word) -> MerkleStore
}

Or maybe even:
impl MerkleStore {
    pub fn subset(&self, roots: &[Word]) -> MerkleStore
}

Closed by #151.


Add auto-attached card

Ticket: CS-6421

[x] top-most card in stack(s) is/are shown in Chat Input as "auto-attached"
[x] "auto-attached" cards show with a dashed border
[x] "auto-attached" cards show a tooltip on hover: "Topmost card is shared automatically"
[x] An "X" is shown at right side of pill and can be used to remove the auto-attached card so that it is not attached when the message is sent
[x] When the top-most card changes (i.e. the user navigates), any current auto-attached cards are removed and the new top-most card(s) is/are attached
[x] If a prospective auto-attached card is already explicitly attached by the user via the Attach Card button, it does not appear as auto-attached

https://github.com/cardstack/boxel/assets/12637010/f236eaaa-6979-4594-b145-ae200a503ce1

I noticed a bug in attached cards, nothing happens when I click on X. Not sure if introduced by this PR.

When I remove the autoattached card, and navigate to other cards in the stack, should the new topmost card now be autoattached? I am not seeing this behaviour here but wondering if it should be like that

Does "◻ Allow access to the cards you can see at the top of your stacks" still make sense now that we are autoattaching them?

This should replace the "share the topmost card" functionality, it'll be part of the context, so we should remove that checkbox.
This updates the message type so that auto-attached and attached cards can both coexist -> https://github.com/cardstack/boxel/pull/1045
Potentially we could change the structure here so that they all sit in "attached" cards and then the concept of an open card is just the ID of what the user is looking at?
Should we block the index card from being attached?

I noticed a bug in attached cards, nothing happens when I click on X. Not sure if introduced by this PR.

2. When I remove the autoattached card, and navigate to other cards in the stack, should the new topmost card now be autoattached? I am not seeing this behaviour here but wondering if it should be like that
3. Does "◻ Allow access to the cards you can see at the top of your stacks" still make sense now that we are autoattaching them?

@jurgenwerk Nice catch! I made a few updates.

I fixed the removing attached card issue.
I implemented the behavior when user navigating to another card after removing the auto-attached card. Now it must displays auto-attached card if user navigating to different card.
I removed the "share the topmost card" checkbox.

https://github.com/cardstack/boxel/assets/12637010/c0a8ad56-ed1f-45bc-abdd-3d68d87d37c3

This should replace the "share the topmost card" functionality, it'll be part of the context, so we should remove that checkbox.
This updates the message type so that auto-attached and attached cards can both coexist -> #1045
Potentially we could change the structure here so that they all sit in "attached" cards and then the concept of an open card is just the ID of what the user is looking at?
Should we block the index card from being attached?

It make sense to block the index card from being attached, I'll make a change for that.
Yeah I agree, it seems I have to change the structure here because currently, we can only choose between sending attached cards or sending a message with context for open card and it breaks lots of tests. I think I have to wait until your PR get merged, what do you think @IanCal ?

@FadhlanR I think my PR should be passing the linting now, I don't mind which way we do this, if it makes sense we could merge mine then I can take over this branch and update it to match the format, then change openCards to just have the ID?

@FadhlanR I think my PR should be passing the linting now, I don't mind which way we do this, if it makes sense we could merge mine then I can take over this branch and update it to match the format, then change openCards to just have the ID?

It sounds good, you can do that. Thanks!

I noticed that the failing matrix tests are recently added tests. I just double checked and these are passing for me in main. I wonder if the upstream merge worked properly?

I noticed that the failing matrix tests are recently added tests. I just double checked and these are passing for me in main. I wonder if the upstream merge worked properly?

I think I see where it's failing. Since in this PR there's an autoattached card, there are 2 cards instead of 1 card. There's a removeAutoAttachedCard helper to get around that. I can update.
I think ideally we shouldn't be auto-attaching the index card, but I don't know what the decision was about this.

I noticed that the failing matrix tests are recently added tests. I just double checked and these are passing for me in main. I wonder if the upstream merge worked properly?

I think I see where it's failing. Since in this PR there's an autoattached card, there are 2 cards instead of 1 card. There's a removeAutoAttachedCard helper to get around that. I can update.
I think ideally we shouldn't be auto-attaching the index card, but I don't know what the decision was about this.

agreed. it's just blindly including the top most card including if the index card is the top most card. i don't think that was an actual decision anyone made. i think it's a bug to be honest.

I'll raise a new ticket and pr for ignoring the index card


Show property labels

In order to make the resource view more human-friendly, consider showing the labels for properties for common vocabularies and ontologies.

I implemented a tooltip to show that info! take a look http://lodview.it/


Implement Ctrl-A/E/K for editor gadgets

I noticed 826112c5a16a6d93bc45661a473d6d466149b6cd and 281ff6b7a3d3b176003e4c2de66884fa7a7b8653 were reverted, is there a better way to implement it?  Or do you not like having this?

I'd rather we didn't mess with the keymap until we implement a mechanism for making it configurable.

http://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_good

Well, my original objection to the match is that it broke my muscle memory. C+e wasn't edit word anymore, etc :-) Also I didn't like that it was OS X-specific.

 Emacs bindings are better.

Oh yeah, I remember back in the day where C-e was the binding for the "edit" command on Emacs... oh wait.
My objection to C-e being edit is that it breaks my muscle memory from every other application on Earth. ;)
I agree with mrjbq7's admonition. The way it is now makes for a crappy UX. I'd love to help write something to make keybindings configurable but unfortunately I can't since C-e won't go to the EOL. :P

Fixed in 928b4c6abcb012fc8ad4963a3976ab88d0ade741.


Injector: Add version 1.4.0

Add fairly utilized (~500 stars) dll injection command line utility:
https://github.com/nefarius/Injector

[x] I have read the Contributing Guide.

/verify

/version

/verify

@aliesbelik


Show, Show Only, and Hide for Muscles do not work

On 4.4-2021-11-30-058542d with Windows 10, options for Show, Show Only, and Hide do not work. Behavior happens whether it's for an individual muscle, group of muscles (chosen by ctrl-click), or all muscles.

Fixed on visualizer side, fix merged, can test on a future PR

Fixed in latest master build, please verify

Tested OpenSim 4.4-2022-04-12-13e8480 on Windows 10, LGTM


i18n(ko-KR): update dev-toolbar-app-reference.mdx

Description (required)

update dev-toolbar-app-reference.mdx
#8224

Related issues & labels (optional)

Closes #
Suggested label:

Lunaria Status Overview
🌕 This pull request will trigger status changes.

Learn more
By default, every PR changing files present in the Lunaria configuration's files property will be considered and trigger status changes accordingly.
You can change this by adding one of the keywords present in the ignoreKeywords property in your Lunaria configuration file in the PR's title (ignoring all files) or by including a tracker directive in the merged commit's description.

Tracked Files

Locale
File
Note

ko
reference/dev-toolbar-app-reference.mdx
Localization changed, will be marked as complete.

Warnings reference

Icon
Description

🔄
The source for this localization has been updated since the creation of this pull request, make sure all changes in the source have been applied.


[fix][fn] Make python install dependencies from requirements.txt

Fixes #20173

Master Issue: #xyz

PIP: #xyz

Motivation
Python instance should install dependencies from requirements.txt
Modifications
Make python instance install dependencies from requirements.txt
Verifying this change

[x] Make sure that the change passes the CI checks.

(Please pick either of the following options)

[x] This change is a trivial rework / code cleanup without any test coverage.

(or)
This change is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:
(example:)

Added integration tests for end-to-end deployment with large payloads (10MB)
Extended integration test for recovery after broker failure

Does this pull request potentially affect one of the following parts:

If the box was checked, please highlight the changes

[ ] Dependencies (add or upgrade a dependency)
[ ] The public API
[ ] The schema
[ ] The default values of configurations
[ ] The threading model
[ ] The binary protocol
[ ] The REST endpoints
[ ] The admin CLI options
[ ] The metrics
[ ] Anything that affects deployment

Documentation

[ ] doc
[ ] doc-required
[x] doc-not-needed
[ ] doc-complete

Matching PR in forked repository
PR in forked repository: https://github.com/jiangpengcheng/pulsar/pull/12

/pulsarbot rerun-failure-checks

/pulsarbot rerun-failure-checks

Meriging...
Thanks for your contribution!


Invalid call. Nonexistent function 'new' in base 'Nil'. if you use @export_group with same class name

Godot version
4.0 RC 3
System information
Macbook m1
Issue description
If I normally use:
Skeleton2D.new()

if works.
If I use:
@export_group("Skeleton2D")
...
Skeleton2D.new()

I get error: Invalid call. Nonexistent function 'new' in base 'Nil'.
Steps to reproduce

Run a script where you have @export_group with same name as a node class name that you use .new() on.

extends Node2D
class_name Test

@export_group("Skeleton2D")

# Called when the node enters the scene tree for the first time.
func _ready():
	var skeleton = Skeleton2D.new()

# Called every frame. 'delta' is the elapsed time since the previous frame.
func _process(delta):
	pass

Minimal reproduction project
BugNew.zip

I believe that the script is checking for its own properties, and export group is effectively exporting a property named Skeleton2D. This will shadow the global Skeleton2D. I'm not certain that I'd consider this a bug necessarily, but perhaps at least a warning when @export_group shadows a global name?

Reopened because https://github.com/godotengine/godot/pull/73870 has been reverted.

Bumping this, since someone came to Discord for help due to this.

Bumping this, since someone came to Discord for help due to this.
Yep it was me.


Emoji selector screen extends into Navigation Bar

Issue is also present in Stream Chats, it's not noticeable because the navigation bar is opaque there

In stream Chat the first 2 emojis gets hidden because they contain extra space for topic input field.

@zulipbot claim

Issue is due to the wrong value of maxHeight in Popup.js. Popup.js is used while display a list for auto-completion in emojis, people, streams and topic so the issue is not just restricted emojis.


Suggestion to simplify public key copying

Installing additional software is overkill, most of the terminals have the ability to copy text from the command output.
Why:
Closes #9388
What's being changed:

Check off the following:

[x] I have reviewed my changes in staging (look for the latest deployment event in your pull request's timeline, then click View deployment).
[x] For content changes, I have completed the self-review checklist.

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

[ ] This pull request impacts the contribution experience

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

@bunyk
Thanks so much for opening a PR! I'll get this triaged for review :zap:

I'm going to commit my change, check the preview, and then this should be ready to merge 🚀


 n)
                #t
                (odd? (- n 1)))))
         (odd?
          (lambda (n)
            (if (zero? n)
                #f
                (even? (- n 1))))))
  (even? 88))                           ⇒  #t

ref: https://www.gnu.org/software/mit-scheme/documentation/mit-scheme-ref/Lexical-Binding.html

[ ] let
[ ] let*
[ ] letrec

Convert let* to let
;; let
(let ((x 1))
  (let ((y (+ 1 x)))
(+ x y)))
;; is
(let* ((x 1)
       (y (+ 1 x)))
(+ x y))

Consider foldr1 by function:
let :: ScmValue -> ScmValue -> ScmValue
-- use
foldr1 let []

let* can implement by let using foldr to construct.
import Parser (readExpr)

Right (List from) = readExpr "(let* ((x 1) (y x)) (+ x y))"
Right (List to) = readExpr "(let ((x 1)) (let ((y x)) (+ x y)))"
[_, List bindings, body] = from

convert bind body = List [Atom "let", List [bind], body]
foldr convert body bindings

special form: letrec ((variable init) …) expression expression …
The variables are bound to fresh locations holding unassigned values, the inits are evaluated in the extended environment (in some unspecified order), each variable is assigned to the result of the corresponding init, the expressions are evaluated sequentially in the extended environment, and the value of the last expression is returned. Each binding of a variable has the entire letrec expression as its region, making it possible to define mutually recursive procedures.

One restriction on letrec is very important: it shall be possible to evaluated each init without assigning or referring to the value of any variable. If this restriction is violated, then it is an error. The restriction is necessary because Scheme passes arguments by value rather than by name. In the most common uses of letrec, all the inits are lambda or delay expressions and the restriction is satisfied automatically.

A letrec expression is equivalent to a let where the bindings are initialized with dummy values, and then the initial values are computed and assigned into the bindings. The above example is equivalent to:

(define (some-procedure ...)
   (let ((helper '*dummy-value*))
      (set! helper (lambda (x)
                      ...
                      (if some-test?
                          (helper ...))))) ; recursive call
     ...
     (helper ...)  ; call to recursive local procedure
     ...))

From: https://www.cs.rpi.edu/academics/courses/fall00/ai/scheme/reference/schintro-v14/schintro_126.html

(let ((until (lambda (stop init) (if (> init stop) init (until stop (+ init 1)))))) (until 10 1))
;;; Can not found variable: until

(let ((until '()))
  (set! until (lambda (stop init)
    (if (> init stop) init (until stop (+ init 1)))))
  (until 10 1))
;;; 11

With letrec we can
(letrec ((until (lambda (stop init) (if (> init stop) init (until stop (+ init 1)))))) (until 10 1))
;;; 11


Update deprecated Travis command

We recently started seeing Travis CI failures in a private repo with:
The command "sh -e /etc/init.d/xvfb start" failed and exited with 127 during .

This is because Travis has updated the API for starting this service (see this official blog post and this post explaining the breaking change). The update seems to be on a rolling basis, so I figured we'd update the config here since it will likely eventually break.

Thanks for the pull request @OmarShehata!

:heavy_check_mark: Signed CLA found.
:grey_question: CHANGES.md was not updated.

If this change updates the public API in any way, please add a bullet point to CHANGES.md.

:grey_question: Unit tests were not updated.

Make sure you've updated tests to reflect your changes, added tests for any new code, and ran the code coverage tool.

Reviewers, don't forget to make sure that:

[ ] Cesium Viewer works.
[ ] Works in 2D/CV.
[ ] Works (or fails gracefully) in IE11.

@lilleyse care to review/merge? I've tested this in the private repo and confirmed it fixes CI.


Develop and publish for Firefox too

https://github.com/salihozkara/LyricsTranslatorOnSpotify/tree/firefox
https://addons.mozilla.org/tr/firefox/addon/lyrics-translator-on-spotify/


Removing info line from keyboard event

This line does not seem necessary and actually seems to be broken

Pull Request Test Coverage Report for Build 114

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.1%) to 7.32%

Totals

Change from base Build 113:
-0.1%

Covered Lines:
53

Relevant Lines:
724

💛  - Coveralls

Thanks! I should have done it but I completely forgot.


obsolete grouping class: metabolising cell

A cell whose primary function is intermediary metabolism.

'metabolising cell'

'fat body cell'
hepatocyte

Currently this groups two classes: hepatocyte (vertebrates) and fat body cell (note this is presumably intended to represent cells in insect fat bodies, not fat pads in mammals... see #710 ).
Surely there is more than one metabolising cell per phylum?
If we are going to keep this, then we need a commitment to completeness and clarity. Make a logical def
This will give us:

But is this even complete?  How do we determine 'primary function' anyway?
I think it's simpler just to obsolete the grouping

Happy to obsolete, but thought worth adding some notes:
capable_of some 'metabolic process' is obviously silly (what cell isn't?) as, I think, is the name.  The def is not too bad though: "A cell whose primary function is intermediary metabolism."  Maybe a better way to do this would be to define in terms of specialized metabolic function - with some reference to whole body physiology/metabolic functions.   Human adipocytes would certainly count under this def, e.g. see https://themedicalbiochemistrypage.org/adipose-tissue-not-just-fat/#:~:text=Specific metabolic processes regulated by,coagulation)%2C%20and%20blood%20pressure.&text=BAT%20specializes%20in%20the%20production,adaptive%20thermogenesis)%20and%20lipid%20oxidation.
Perhaps more useful than a general grouping, would be to have some cross-species grouping wrt specialized metabolic functions.  Maybe worth a mini-project with GO to ensure we have the terms?


add fallback option to package.json

I found that https://bundlephobia.com/package/u8-mqtt refuses to show bundle size. According to https://nodejs.org/api/packages.html#dual-commonjses-module-packages there a few lines to cover fallback should be added.

Thanks for the pull request @nosovk. In testing, I found other constraints on the layout of the package.json exports section, particularly related to recent issue #11.
Both issue #11 and the BundlePhobia parsing logic appear fixed.


CI: route_linux_test.go:234: RouteSuitePrivileged.TestListRules

Stacktrace
	 [10:45:22] START: route_linux_test.go:234: RouteSuitePrivileged.TestListRules
	 [10:45:22] Inside new network ns
	 [10:45:22] route_linux_test.go:235:
	 [10:45:22]     testListRules4(c)
	 [10:45:22] route_linux_test.go:487:
	 [10:45:22]     c.Errorf("expected len: %d, got: %d\n%s\n", len(wantRules), len(rules), diff)
	 [10:45:22] ... Error: expected len: 3, got: 5
	 [10:45:22]   []netlink.Rule{
	 [10:45:22]   	{
	 [10:45:22] - 		Priority: -1,
	 [10:45:22] + 		Priority: 9,
	 [10:45:22]   		Family:   0,
	 [10:45:22] - 		Table:    255,
	 [10:45:22] + 		Table:    2004,
	 [10:45:22] - 		Mark:     -1,
	 [10:45:22] + 		Mark:     512,
	 [10:45:22] - 		Mask:     -1,
	 [10:45:22] + 		Mask:     3840,
	 [10:45:22]   		Tos:      0,
	 [10:45:22]   		TunID:    0,
	 [10:45:22]   		... // 12 identical fields
	 [10:45:22]   	},
	 [10:45:22] + 	s"ip rule 10: from all to all table 2005",
	 [10:45:22] + 	s"ip rule 100: from all to all table 255",
	 [10:45:22]   	{Priority: 32766, Table: 254, Mark: -1, Mask: -1, ...},
	 [10:45:22]   	{Priority: 32767, Table: 253, Mark: -1, Mask: -1, ...},
	 [10:45:22]   }
	 [10:45:22]
	 [10:45:22]
	 [10:45:22]
	 [10:45:22] Closed new network ns
	 [10:45:22] Set back to previous network ns
	 [10:45:22] Inside new network ns
	 [10:45:22] Closed new network ns
	 [10:45:22] Set back to previous network ns
	 [10:45:22] FAIL: route_linux_test.go:234: RouteSuitePrivileged.TestListRules

Jenkins: https://jenkins.cilium.io/job/Cilium-PR-Runtime-net-next/5091/testReport/junit/(root)/Suite-runtime/RuntimePrivilegedUnitTests_Run_Tests/
Sysdump:
42153405_RuntimePrivilegedUnitTests_Run_Tests.zip

Hit: https://github.com/cilium/cilium/actions/runs/7219827471/job/19671605097


[BUG] Rollup action inside index policy not executed in the second day for a daily deleted and created index

What is the bug?
When an index is deleted and created every day, the policy gets applied properly and the states in the policy get transitioned OK.
But, in the last state I have a rollup action.
When I create the policy and apply to the index for the first time, the policy runs properly and the rollup action gets done.
Then, the rollup action changes to "disabled".
In the second day, after index deletion and creation, the policy executes OK but the rollup action does not because the rollup job kept "disabled".
I think that the policy should re-enable the rollup job again. When I go to Index Management, Rollup jobs, and re-enable the job, the rollup runs OK. But I have to do it daily.
How can one reproduce the bug?
Steps to reproduce the behavior:

Create a test index with some data
Create index policy with rollup action
Apply policy to index
In the next moment, delete, recreate and repopulate the test index
Watch policy being re-applied again to the index by calling GET _plugins/_ism/explain/test-index
Wait for rollup action and confirm it did not run as expected by calling GET _plugins/_rollup/jobs/your-rollup-job-id/_explain

What is the expected behavior?
In the second day the policy will re-enable and re-invoke the rollup job properly
What is your host/environment?

Linux amd64 / Kubernetes v1.20.9 / Rancher 2.5.7
OpenSearch 1.3.2 official docker image
Official set of plugins (no customization)

I'm considering the following workaround: delete rollup job (if exists) and create it every day out of ISM policy.
What do you think about this?

Feel free to re-open this.

Hi @bowenlan-amzn.
My use case is pretty different from typical log ingestion. I generate a vulnerability report every day and store it on a clean (delete and recreate) index. Then, I roll it up to a historical index (much smaller) in order to have statistical information. The goal is to retain this information for years.


What is the best / suggested method to input more than 1 parameter (*val)?

Annyang command uses a *val to input values to the callback function. What should I do if I want to input more than one item ?
For example, I want to update a form based on user input. So I could have a command like
set Name *val

then val would contain the Name value that I could then assign to the field. But if my form has lot of fields writing a command like this for all fields could be tedious. Instead, I could have
set *FieldName *FieldVal

This command, would return two parameters instead FieldName and FieldVal. If FieldName is valid name of available fields on the page, then I could update the value with FieldVal, or ignore the command.
One way to achieve this, is, ofcourse parse the val to first get the FieldName and then FieldVal from a command like
set *val

but I dont think it would always result in clean solutions.
is there a suggested method to achieve this ?

Regular Expressions to the rescue: https://github.com/TalAter/annyang/tree/master/docs#using-regular-expressions-in-commands

http://stackoverflow.com/questions/32440426/what-is-the-best-suggested-method-to-input-more-than-1-parameter-val-throug/32449660#32449660
Named-variables, is what I was looking for, thanks anyway. :)

Yes. If your parameters are single words, that would be easiest. I guess I misunderstood your case. :+1:


Add MorrisTraversal.java

Description
Added a MorrisTraversal.java in Java
Fixes #374
Please delete options that are not relevant

[x] New feature (non-breaking change which adds functionality)
[x] This change requires a documentation update

Checklist:

[x] I have read the contribution guidelines before making this PR.
[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented in my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation (Language folder or any other readme instructed to)
[x] My changes generates no new warnings
[x] I have added tests that prove my fix is effective or that my feature works

https://www.geeksforgeeks.org/inorder-tree-traversal-without-recursion-and-without-stack/
Next time don't do this


Helm desctop data changes

Part of required changes

thanks @BogdanScherban
Please explain these changes here.. this is the core PulseTile react repo.. so what changes does this PR mean for the codebase?

Update from Bogdan:
so the core code base changes are to add conditional logic to determine if should be shown or not
you are not taking anything anyway, you are adding smart stuff to the core codebase


Docs by G

Improvements in usage pipeline

This PR will update main page (Readme)
and fix main tests


[Cirrus] Implement ability to reconstruct the federation from a given height.

Currently this needs to be done from before the multisig has been removed.

The code seems a bit risky in the way it modifies the existing list of polls while the node is running. Would it be possible to make the changes on a separate list and switch to this list only when done?

The code seems a bit risky in the way it modifies the existing list of polls while the node is running. Would it be possible to make the changes on a separate list and switch to this list only when done?
Alternatively (or in addition?), one could focus on making the polls repository more robust, similar to other repositories using tips, rewind etc.

Good points @quantumagi, we definitely need to improve on the polls repo to bring in tips etc. To me this is a OK for now until we do that work. I'm going to add to board.


Refactor/1301/products theme

Description
Removed ThemeContext from products
Checklist

[x] 🔽 My branch is up-to-date with "development" branch
[x] ✅All tests passed locally
[x] ✨My changes working with up-to-date admin and back-end part locally, like charm
[x] 🔗 Link pull request to issue

Please add screenshot of console. It should be clear.


Bundle with asciidoctor 1.5.7 fails to run

I'm getting this error when building CSD documents:
NoMethodError: undefined method `asciidoc_sub' for #<Asciidoctor::Csd::Converter:0x00007fa889891000>
gems/asciidoctor-csd-41b173a7ed94/lib/asciidoctor/csd/converter.rb:44:in `block (2 levels) in title'

This seems to be an incompatibility with the newly released asciidoctor 1.5.7?
Thanks!

Thanks @PeterTKY  for reporting.
@opoudjis could you help a look at this? Thanks!

@PeterTKY: no. This is a new function just introduced into asciidoctor-iso, which asciidoctor-csd is a subclass off. Please run bundle update.

@opoudjis @PeterTKY the latest asciidoctor-csd apparently requires the newest asciidoctor-iso (0.7.5), I've updated the gems now; this issue is resolved.