Grammar support for interpolations like ${.}. ${..} etc.

This enables implementing a form of select with a default value:
Side note, we should rethink support for passing the parent node automatically on demand (${.}), it will simplify this use case.
from typing import Any

from omegaconf import OmegaConf
from omegaconf.omegaconf import _EMPTY_MARKER_

yaml = """\
a: 10
no_default: ${oc.select:${.}, a}
not_using_default: ${oc.select:${.}, a, 20}
using_default: ${oc.select:${.}, not_there, 20}
"""

def oc_select(node: Any, key: str, default: Any = _EMPTY_MARKER_):
    if default is _EMPTY_MARKER_:
        return OmegaConf.select(node, key)
    else:
        return OmegaConf.select(node, key, default=default)

OmegaConf.register_new_resolver("oc.select", oc_select)

cfg = OmegaConf.create(yaml)
assert cfg.a == 10
assert cfg.no_default == 10
assert cfg.not_using_default == 10
assert cfg.using_default == 20

Notes:

I did not like the complexity of the testing in test_grammar.py. seems like a new testing framework instead of a test designed to test some logic.
I created a simpler more localized test for interpolations. happy to discuss.

while it's not very big, it can be easier to review one commit at a time.

GitHub got issues now.
Leave it alone for now and come back later.
https://www.githubstatus.com/

Side note, we should rethink support for passing the parent node automatically on demand (${.}), it will simplify this use case.

Not sure, I'd say that the example you provided is clearer with explicitly passing ${.} (if it was implicit we also couldn't select from arbitrary nodes).

I did not like the complexity of the testing in test_grammar.py. seems like a new testing framework instead of a test designed to test some logic.
I created a simpler more localized test for interpolations. happy to discuss.

Yeah the boilerplate code ended up being more complex than I would have liked. Adding new tests should be straightorward though (once you understand how things work). The motivation was to be able to add a lot of tests with a minimum of extra "fluff" for each test. IMO this makes tests more readable (not the code, but the test data).
There were no relative interpolation tests though it seems in that file (definitely an oversight) => right now tests with .. wouldn't be supported since we assume that we resolve an interpolation at the top-level. However it would be trivial to move it down one level.
I don't mind changing things if you can be specific on the formatting you would like to see (I'd rather not take a guess and end up with something worse).

Side note, we should rethink support for passing the parent node automatically on demand (${.}), it will simplify this use case.

Not sure, I'd say that the example you provided is clearer with explicitly passing ${.} (if it was implicit we also couldn't select from arbitrary nodes).

The motivation is to support the use case of providing a default value for interpolation.
foo :${bar} # or 10 if bar does not exist.

This is coming from #541, which is proposing a completely new syntax for it:
a : 10
b : ${a,  20}  # 20 if a is not there.

I think a new syntax is an overkill and we should be able to leverage custom resolvers.
The idea to add oc.select() came from that use case. Interplation syntax already supports selecting from arbitrary nodes.
foo is foo in the config root. .foo is a sibling foo etc.
The following is cleaner than forcing the ${.} everywhere and it seems just as flexible.
v1: val1
foo:
  v2 : val2
  b: ${oc.select: v1, default} # val1
  c: ${oc.select: .v2, default}  # val2

In fact, this function is more Container.select() than OmegaConf.select().
maybe the resolver name should be oc.container.select or oc.node.select.

I did not like the complexity of the testing in test_grammar.py. seems like a new testing framework instead of a test designed to test some logic.
I created a simpler more localized test for interpolations. happy to discuss.

Yeah the boilerplate code ended up being more complex than I would have liked. Adding new tests should be straightorward though (once you understand how things work). The motivation was to be able to add a lot of tests with a minimum of extra "fluff" for each test. IMO this makes tests more readable (not the code, but the test data).

Will respond to this part later. gtg.

The following is cleaner than forcing the ${.} everywhere and it seems just as flexible.

Got it. No objection from me as long as it remains optional.

Would it be difficult to add support for going up multiple levels in the hierarchy?
For example, something like ${...} or ${...key} with three dots or more.

Would it be difficult to add support for going up multiple levels in the hierarchy?
For example, something like ${...} or ${...key} with three dots or more.

Like this?
In [2]: cfg = OmegaConf.create({"v": 1, "a": {"b": {"c": "${...v}"}}})

In [3]: cfg
Out[3]: {'v': 1, 'a': {'b': {'c': '${...v}'}}}

In [4]: cfg.a.b.c
Out[4]: 1

Like this?

Yes, exactly :)
Would probably be good to add a test or two for that...

I did not like the complexity of the testing in test_grammar.py. seems like a new testing framework instead of a test designed to test some logic.
I created a simpler more localized test for interpolations. happy to discuss.

Yeah the boilerplate code ended up being more complex than I would have liked. Adding new tests should be straightorward though (once you understand how things work). The motivation was to be able to add a lot of tests with a minimum of extra "fluff" for each test. IMO this makes tests more readable (not the code, but the test data).

This in general is objectively a bit hard to test directly because we depend on a config object in the parsing.
Still, I feel like you your test has too many input modes, which makes it harder to understand.
In fact, I would claim that without debugging the test it's not really possible to fully understand the how the test is working.
That's not a good situation for a test.
I think my test can be simplified (a part can be factored out to a different function. we can do it if and when we add a similar test).

There were no relative interpolation tests though it seems in that file (definitely an oversight) => right now tests with .. wouldn't be supported since we assume that we resolve an interpolation at the top-level. However it would be trivial to move it down one level.

Can you explain what is not supported with an example?

I don't mind changing things if you can be specific on the formatting you would like to see (I'd rather not take a guess and end up with something worse).
Edit: oh, there was also another motivation, which is to just copy the test data into Hydra => it's easier if it's isolated

You can do this:
interpolation_test_data = [
    # config root
    param(
        "${}",
        "",
        {"dict": {"bar": 20}, "list": [1, 2]},
        id="absolute_config_root",
    ),
    # simple
    param("${dict.bar}", "", 20, id="dict_value"),
    ...
]

@mark.parametrize(
    ("inter", "key", "expected"),
    interpolation_test_data,
)
def test_parse_interpolation(inter: Any, key: Any, expected: Any) -> None:
 ...

I think it's still valuable to have the test data close to the test itself. stashing it all at the top of the file makes it significantly harder to understand the tests.

Like this?

Yes, exactly :)

Don't try {..} through unless you like stack overflows. :P

In fact, I would claim that without debugging the test it's not really possible to fully understand the how the test is working.

Right, I can definitely see how the current code is difficult to understand. However, once you know what's going on, you don't have to look at the code anymore and you can just add new test items in the corresponding list.

There were no relative interpolation tests though it seems in that file (definitely an oversight) => right now tests with .. wouldn't be supported since we assume that we resolve an interpolation at the top-level. However it would be trivial to move it down one level.

Can you explain what is not supported with an example?

If I add the following item to the list PARAMS_SINGLE_ELEMENT_WITH_INTERPOLATION:
("rel_test", "${..foo}", None),

then it will fail with with this traceback:
                root = root._get_parent()
                if root is None:
>                   raise ConfigKeyError(f"Error resolving key '{orig}'")
E                   omegaconf.errors.InterpolationKeyError: ConfigKeyError while resolving interpolation: Error resolving key '..foo'

because the parent is the root config, so the parent of the parent doesn't exist.
It'd be easy to fix by doing the resolution at a deeper level in the config.

You can do this:
interpolation_test_data = [
    # config root
    param(
        "${}",
        "",
        {"dict": {"bar": 20}, "list": [1, 2]},
        id="absolute_config_root",
    ),
    # simple
    param("${dict.bar}", "", 20, id="dict_value"),
    ...
]

@mark.parametrize(
    ("inter", "key", "expected"),
    interpolation_test_data,
)
def test_parse_interpolation(inter: Any, key: Any, expected: Any) -> None:
 ...

Yeah, that's essentially what I did except that I got rid of the param and id stuff (not a big deal, but I find it a bit cleaner, and more importantly, it is less likely for a test to be formatted over multiple lines by black, which makes it harder to read). Also I don't like adding a key item that would be "" 99% of the time.

I think it's still valuable to have the test data close to the test itself. stashing it all at the top of the file makes it significantly harder to understand the tests.

I hear you. But that's kind of how it is in a sense: the way I see it, TestOmegaConfGrammar is actually one single test, and the 3 lists of parameters on top of it are semantically almost the same (and can be almost seen as a single list of everything we want to test here). Having all the data at the top makes it easier in practice because you don't have to scroll down through code to find the section you are looking for (also, the config definition is closer).
The exception is test_deprecated_empty_args() which has its own list of parameters within the class: the reason is that it's testing a deprecated feature so I thought it wouldn't be worth creating an extra list just for it, since it would be removed later.
In terms of practical action item, I can easily move everything to @mark.parametrize() with param(..., id=...) next to each method if you want. But I think the main complexity of the test right now is in the code that processes this data. It's a bit tricky in particular because of the error handling. I could split the test in two to handle errors separately if you prefer, though personally for such a large amount of tests, I find the current approach more readable (not in the test code, but when looking at the test data, because you can easily see both the working and error situations for each category of item being parsed).
Let me know whether to proceed with some of these changes (or others).

There were no relative interpolation tests though it seems in that file (definitely an oversight) => right now tests with .. wouldn't be supported since we assume that we resolve an interpolation at the top-level. However it would be trivial to move it down one level.

Can you explain what is not supported with an example?

If I add the following item to the list PARAMS_SINGLE_ELEMENT_WITH_INTERPOLATION:
("rel_test", "${..foo}", None),

then it will fail with with this traceback:
                root = root._get_parent()
                if root is None:
>                   raise ConfigKeyError(f"Error resolving key '{orig}'")
E                   omegaconf.errors.InterpolationKeyError: ConfigKeyError while resolving interpolation: Error resolving key '..foo'

What are you expecting ${..foo} to resolve to in the above fragment and why?
Is there a user facing issue this is causing?

because the parent is the root config, so the parent of the parent doesn't exist.
It'd be easy to fix by doing the resolution at a deeper level in the config.

Can you file a followup PR?

You can do this:
interpolation_test_data = [
    # config root
    param(
        "${}",
        "",
        {"dict": {"bar": 20}, "list": [1, 2]},
        id="absolute_config_root",
    ),
    # simple
    param("${dict.bar}", "", 20, id="dict_value"),
    ...
]

@mark.parametrize(
    ("inter", "key", "expected"),
    interpolation_test_data,
)
def test_parse_interpolation(inter: Any, key: Any, expected: Any) -> None:
 ...

Yeah, that's essentially what I did except that I got rid of the param and id stuff (not a big deal, but I find it a bit cleaner, and more importantly, it is less likely for a test to be formatted over multiple lines by black, which makes it harder to read). Also I don't like adding a key item that would be "" 99% of the time.

I think we should use a single testing style in the codebase.
I agree that it's annoying the black is breaking the test lines. I am actually okay with increasing black line length in OmegaConf and Hydra. This can be a standalone diff to OmegaConf first).

I think it's still valuable to have the test data close to the test itself. stashing it all at the top of the file makes it significantly harder to understand the tests.

I hear you. But that's kind of how it is in a sense: the way I see it, TestOmegaConfGrammar is actually one single test, and the 3 lists of parameters on top of it are semantically almost the same (and can be almost seen as a single list of everything we want to test here). Having all the data at the top makes it easier in practice because you don't have to scroll down through code to find the section you are looking for (also, the config definition is closer).

I have similar patterns in other places, like in test_errors.py (that I am not really happy with).
I can tell you that even though it has advantages, it also have many disadvantages over more compact style grouping tests by the functionality they are testing.
Here is an example of a large test in Hydra. The test functions are usually the same and are calling a common generic function.
Splitting by functionality makes it easier to introduce tests for new areas (like I did with testing relative interpolations in this PR).
Having a common function to test with reduces the overhead of many different test functions.
Another problem I have with the current test is that the base config it's using to test has everything and it's mother, and it's defined far away from the test code.
It would be easier to understand in the way my test is done, where the test config is defined in or near the test function.
I think different test functions typically are focused on different needs and it does not make sense for all of them to get a config with every possible thing.

The exception is test_deprecated_empty_args() which has its own list of parameters within the class: the reason is that it's testing a deprecated feature so I thought it wouldn't be worth creating an extra list just for it, since it would be removed later.
In terms of practical action item, I can easily move everything to @mark.parametrize() with param(..., id=...) next to each method if you want. But I think the main complexity of the test right now is in the code that processes this data. It's a bit tricky in particular because of the error handling. I could split the test in two to handle errors separately if you prefer, though personally for such a large amount of tests, I find the current approach more readable (not in the test code, but when looking at the test data, because you can easily see both the working and error situations for each category of item being parsed).
Let me know whether to proceed with some of these changes (or others).

I think a lot of the complexity now is that the test is trying to handle an arbitrary list of parameters in a generic way, even though the list looks different in each case.
Things can probably be simplified by allowing each test to be more specialized (while reusing whatever is possible through some utility functions).
All this is not particularly urgent, so no need to interrupt what you are working on. but I think we should add it to the queue.

If I add the following item to the list PARAMS_SINGLE_ELEMENT_WITH_INTERPOLATION:
("rel_test", "${..foo}", None),

then it will fail with with this traceback:
                root = root._get_parent()
                if root is None:
>                   raise ConfigKeyError(f"Error resolving key '{orig}'")
E                   omegaconf.errors.InterpolationKeyError: ConfigKeyError while resolving interpolation: Error resolving key '..foo'

What are you expecting ${..foo} to resolve to in the above fragment and why?
Is there a user facing issue this is causing?

Oh, I was expecting ${..foo} to crash since that's how this test currently works (it resolves the expression as if it was in a top-level node in the config). There is no user-facing issue.

because the parent is the root config, so the parent of the parent doesn't exist.
It'd be easy to fix by doing the resolution at a deeper level in the config.

Can you file a followup PR?

Probably not worth it at this point since you already added relative interpolation tests in this PR. Would probably make more sense to do it at the same time the tests would be refactored.

All this is not particularly urgent, so no need to interrupt what you are working on. but I think we should add it to the queue.

Ok will add it in my list somewhere. To be honest though I'm still not entirely sure how such splitting would look like. There aren't that many different things tested here, it's essentially all the same stuff (take an expression, parse it with the desired rule, check the result). But we can discuss it later when we get to it.

What I did in Hydra, which makes a lot of sense there - is to test primitive rules separately.
@mark.parametrize(
    "value,expected",
    [
        param("[]", [], id="list:empty"),
        param("[1]", [1], id="list:item"),
        param(
            "['a b']",
            [QuotedString(text="a b", quote=Quote.single)],
            id="list:quoted_item",
        ),
        param(
            "['[a,b]']",
            [QuotedString(text="[a,b]", quote=Quote.single)],
            id="list:quoted_item",
        ),
        param("[[a]]", [["a"]], id="list:nested_list"),
        param("[[[a]]]", [[["a"]]], id="list:double_nested_list"),
        param("[1,[a]]", [1, ["a"]], id="list:simple_and_list_elements"),
    ],
)
def test_list_container(value: str, expected: Any) -> None:
    ret = parse_rule(value, "listContainer")
    assert ret == expected

Not sure it's applicable here.
I also don't want this to become a major time sink. See if you can clear things up a bit.

I guess it could be applicable in the context of an individual config object. (that can have the minimum needed to test the specific rule).

What I did in Hydra, which makes a lot of sense there - is to test primitive rules separately.
(...)
Not sure it's applicable here.

We could to some extent (that would essentially mean splitting PARAMS_SINGLE_ELEMENT_NO_INTERPOLATION). One small thing though is that I would prefer to create new rules for testing single rules, like:
singleListContainer: listContainer EOF;

because if we only test listContainer, the parser is happy with an expression that starts with a list, regardless of what comes after. So for instance [1, 2, 3]] would be accepted as a valid list in tests.

I think it's reasonable to use the existing rules as is.
Not sure I like adding a bunch of extra rules and logic in the code for testing purposes here.
Do you know what is commonly done in such cases with other grammars elsewhere? Personally I was always okay with this.

I think it's reasonable to use the existing rules as is.
Not sure I like adding a bunch of extra rules and logic in the code for testing purposes here.
Do you know what is commonly done in such cases with other grammars elsewhere? Personally I was always okay with this.

Thinking about it a bit more, I think a better solution is to check that the whole string was processed.


Add sendmsg and recvmsg

This PR adds sendmsg(2) and recvmsg(2) calls to the uring library. This means having to wrap the msghdr struct and I have a few questions.
I have this working with Eio_linux when I take the simple UDP test from https://github.com/ocaml-multicore/eio/pull/171 and turn it into an executable. This also seems to work if I place lots of Gc.{minor,full_major}() calls in that test. However, as soon as it runs in mdx I get: Exception: Unix.Unix_error(Unix.EINVAL, "recv_msg", ""). Note, this is running on WSL. I think something must be being GCed or moved about (although I investigated the msghdr just before this exception is raised and it seemed okay). I'll push the code to Eio after opening this PR . Is there something obviously wrong in the C stubs I wrote perhaps?

Thanks for the speedy review :))

To test this, I suggest doing a Gc.minor () after allocating the memory and just before the call. That will ensure it's on the major heap, and the multicore GC never moves things after that anyway. You're already checking it before the io_uring_prep_recvmsg and if you also log a message when it's freed then that rules most things out.

With the executable I tried this and things seemed to be working well.

But I though WSL didn't support io_uring anyway, or has it been updated?

The very latest release of the Microsoft Linux kernel supports io_uring and all the other tests etc. seem to be working okay.

I assume the failing test is the one added by the UDP PR?

Yep that's the one. Interestingly, this (clearly not a fix) patch gets the test in MDX to pass. I think it suggests something is being moved along the way somewhere. I'll keep having a look :))
diff --git a/lib/uring/uring_stubs.c b/lib/uring/uring_stubs.c
index 0261f0d..a3a7354 100644
--- a/lib/uring/uring_stubs.c
+++ b/lib/uring/uring_stubs.c
@@ -459,30 +459,42 @@ ocaml_uring_submit_connect(value v_uring, value v_id, value v_fd, value v_sockad
   CAMLreturn(Val_true);
 }

+struct msghdr msg_send;
+
 // v_msghdr must not be GC'd while the call is in progress
 value
 ocaml_uring_submit_send_msg(value v_uring, value v_id, value v_fd, value v_msgh
dr) {
   CAMLparam2(v_uring, v_msghdr);
   struct io_uring *ring = Ring_val(v_uring);
   struct msghdr *msg = Msghdr_val(Field(v_msghdr, 0));
+  msg_send.msg_name = msg->msg_name;
+  msg_send.msg_namelen = msg->msg_namelen;
+  msg_send.msg_iov = msg->msg_iov;
+  msg_send.msg_iovlen = msg->msg_iovlen;
   struct io_uring_sqe *sqe = io_uring_get_sqe(ring);
   if (!sqe) CAMLreturn(Val_false);
   dprintf("submit_sendmsg\n");
-  io_uring_prep_sendmsg(sqe, Int_val(v_fd), msg, 0);
+  io_uring_prep_sendmsg(sqe, Int_val(v_fd), &msg_send, 0);
   io_uring_sqe_set_data(sqe, (void *)Long_val(v_id));
   CAMLreturn(Val_true);
 }

+struct msghdr msg_recv;
+
 // v_msghdr must not be GC'd while the call is in progress
 value
 ocaml_uring_submit_recv_msg(value v_uring, value v_id, value v_fd, value v_msgh
dr) {
   CAMLparam2(v_uring, v_msghdr);
   struct io_uring *ring = Ring_val(v_uring);
   struct msghdr *msg = Msghdr_val(Field(v_msghdr, 0));
+  msg_recv.msg_name = msg->msg_name;
+  msg_recv.msg_namelen = msg->msg_namelen;
+  msg_recv.msg_iov = msg->msg_iov;
+  msg_recv.msg_iovlen = msg->msg_iovlen;
   struct io_uring_sqe *sqe = io_uring_get_sqe(ring);
   if (!sqe) CAMLreturn(Val_false);
   dprintf("submit_recvmsg:msghdr %p: registering iobuf base %p len %lu\n", msg,
 msg->msg_iov[0].iov_base, msg->msg_iov[0].iov_len);
-  io_uring_prep_recvmsg(sqe, Int_val(v_fd), msg, 0);
+  io_uring_prep_recvmsg(sqe, Int_val(v_fd), &msg_recv, 0);
   io_uring_sqe_set_data(sqe, (void *)Long_val(v_id));
   CAMLreturn(Val_true);
 }

I got the CI working on the Eio PR and it gives a different error 😅
File "tests/test_network.md", line 1, characters 0-0:
         git (internal) (exit 1)
(cd _build/default && /usr/bin/git --no-pager diff --no-index --color=always -u tests/test_network.md tests/.mdx/test_network.md.corrected)
diff --git a/tests/test_network.md b/tests/.mdx/test_network.md.corrected
index 95ce3d3..a93244b 100644
--- a/tests/test_network.md
+++ b/tests/.mdx/test_network.md.corrected
@@ -174,8 +174,7 @@ val pp_addr :
       Eio.Net.send e e2 (Cstruct.of_string "UDP Message"));;
 +Waiting to receive data on udp:<IP_ADDRESS>:8082
 +Sending data from udp:<IP_ADDRESS>:8081 to udp:<IP_ADDRESS>:8082
-+Received message from <IP_ADDRESS>:8081: UDP Message
-- : unit = ()
+Exception: Unix.Unix_error(Unix.ENOBUFS, "send_to", "")

Ah! I think I need to memset the msghdr to 0 or at the very least set msg_control, msg_controllen, msg_flags to 0. Trying that now 🤞


NIFI-4561 ExecuteSQL returns no FlowFile for some queries

In some scenarios the updated ExecuteSQL returns no FlowFile, even when the SQL was executed without error. This is a bug I introduced in https://github.com/apache/nifi/pull/1471.
If you execute a stored procedure that returns only a row count, or if the row count is the first result and the ResultSet follows it, then no FlowFile will be generated. This is because getMoreResults() and execute() return false to indicate that the ResultSet does not exist OR that the statement returned a number and not a ResultSet. So if ResultSet's and numerical responses are inter mixed this will also result in missed result sets.
Some JDBC drivers allow for multi-statement requests to be submitted using Statement.execute. In these cases you can have an INSERT statement followed by a SELECT statement. In this case no ResultSet would be returned either.
Prior to NIFI-3432, executing any number of statements would result in a single ResultSet, which may or may not include data. I've seen examples of a DELETE followed by several INSERT statements and our JDBC driver (Teradata) would execute them and NiFi would return a single empty FlowFile.
This update corrects the logic. The new logic:

For every ResultSet, output a FlowFile
Skip non-ResultSet outputs
If we have no more results, there were no errors, there was no original inbound FlowFile, and no ResultSet's were found at all (statements were Insert/Update/Delete only), then output a blank FlowFile.

@mattyb149 You reviewed https://github.com/apache/nifi/pull/1471 for me, not sure if you have the time to review this fix as well. I know in the past you weren't big on the idea of executing non SELECT statements from ExecuteSQL, but it's something I'm seeing in our environment since the JDBC driver allows it, and since we can do multi-statement requests.
For all changes:

[x] Is there a JIRA ticket associated with this PR? Is it referenced
in the commit message?

[x] Does your PR title start with NIFI-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.

[x] Has your PR been rebased against the latest commit within the target branch (typically master)?

[x] Is your initial contribution a single, squashed commit?

For code changes:

[ ] Have you ensured that the full suite of tests is executed via mvn -Pcontrib-check clean install at the root nifi folder?
[ ] Have you written or updated unit tests to verify your changes?
[ ] 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 file, including the main LICENSE file under nifi-assembly?
[ ] If applicable, have you updated the NOTICE file, including the main NOTICE file found under nifi-assembly?
[ ] If adding new Properties, have you added .displayName in addition to .name (programmatic access) for each of the new properties?

For documentation related changes:

[ ] Have you ensured that format looks appropriate for the output in which it is rendered?

Note:
Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible.

@patricker I'll try to take a look at this soon

Updated

@mattyb149 Rebased against 1.6, fixed conflicts.

@patricker Any estimate on when you'll have the next commit?

@MikeThomsen Updated. I found one additional place where a 0 row count needed to be set (just in case). Also added a unit test to verify.


Add PR triage workflow

Replaces #17298.
This patch adds a simple label based workflow for PRs. PRs opened by non-committers will have a triage label automatically added. This allows committers to see which PRs need to be triaged. After 7 days, a needs-attention label will be added. This serves as a reminder to committers and allows them to see which PRs have languished.
For now, the triage label will need to be manually removed by a committer. In the future, we could try to automate this by removing the label after a PR has been reviewed, assigned, or commented on.

I totally love this idea!

After 7 days, a needs-attention label will be added. This serves as a reminder to committers and allows them to see which PRs have languished.

Could we just add label "needs-attention" if the PRs from non-committer have no reviewer after 7 days? That may be more simple and it can remind committers to check those languished PRs as well

@chia7712

Could we just add label "needs-attention" if the PRs from non-committer have no reviewer after 7 days?

Unfortunately, pull_request_reviewed has the same issues as pull_request, but there is no pull_request_reviewed_target event to allow editing details of the PR. I tried a few things, but ultimately don't think we can much automation as the result of a review being submitted :(
So, for now it would be a manual process to remove the triage label. If the triage label is removed, the needs-attention label will not be applied.
One improvement we can make is to use https://github.com/actions/stale?tab=readme-ov-file#exempt-all-pr-assignees to prevent needs-attention from being added if the PR has an assignee. This might not be that useful since we rarely use assignee.

@chia7712 I created a mapping file from the ASF roster and manually matched it up with GitHub user names. https://github.com/mumrah/kafka/blob/asf-committers/README.md
I would like to add this as an orphaned branch to this repo so we can use it as a datasource for this PR (and future automations).
WDYT?

I would like to add this asf-committers as an orphaned branch to this repo so we can use it as a datasource for this PR (and future automations).

My main concern is how to sync the file with committers.html :thinking:

I'm not sure it's that much of a problem TBH. There's already a lot of manual steps involved in becoming a committer. I don't think one more PR is too much of a burden :).
Also, the committers.html is more about personal info (photo, links to social, etc). The dataset I'm proposing is more technical to help power GH automations. If the two are out of sync, I can't think of any real negative outcomes. For the workflow in this PR, the worst outcome is that a committer gets a triage label added to their own PRs.
If we wanted to combine the two data sets, I think that would be do-able as well. This would involve moving the photos to the asf-committers branch along with other committer data and then using that to generate the html. Definitely possible.
I'll start a discussion thread about adding the asf-committers branch, since I can't really a PR for it without first creating the orphaned branch.

In https://kafka.apache.org/committers, we have a
 tag associated with each committer with their GitHub username. For example:

    David Arthur

mumrah

    Committer, and PMC member

    /in/davidarthur

    github.com/mumrah

@mimaison good to know! I had no idea we had the GH usernames in a hidden div. Any idea why we don't create a link to the committer's GitHub page? Privacy concerns?
Thanks to @assignUser for the tip on "author_association" 👍

We can see this in action on my fork.
PR opened by me

https://github.com/mumrah/kafka/pull/28
Triage label workflow run https://github.com/mumrah/kafka/actions/runs/12166085792/job/33931525395?pr=28 (no label is added)

PR opened by collaborator

https://github.com/mumrah/kafka/pull/29
Triage label workflow run https://github.com/mumrah/kafka/actions/runs/12166148750/job/33931734053?pr=29 (label is added)
Triage label removed after a review

As good practice I'd recommend minimising the token permissions: to just what's need.

@chia7712 or @mimaison any feedback on this one?

Well, something isn't quite right. I opened a test PR and it was labeled as triage. Looking into it.

Ok, it is working but there is a little quirk. Filed https://github.com/apache/kafka/pull/18128

Another quirk: this is causing workflows to fail after reviewing PRs: https://github.com/apache/kafka/actions/runs/12266421343
It doesn't block anything, it just seems to generate nuisance emails.


Howdy unlocked my PC (Ubuntu 22.04) using an image

I installed Howdy on Ubuntu 22.04 LTS and did all the config and was working fine.
I tested it out and was fine but I tested it out to see if it unlocks using my image which I took on my mobile.
I took a selfie and went to the login page on my pc (ubuntu 22.04). Then I hid my face and showed the picture on my webcam.
Unfortunately, it got unlocked and is not secure.

Did you read the bottom of the readme? Are you using an IR or visible light camera? Very difficult to get a phone screen to work when using a proper IR camera

I am using C922 PRO HD STREAM WEBCAM.
Link of the webcam:
https://www.logitech.com/en-us/products/webcams/c922-pro-stream-webcam.960-001087.html


Add support of hasUserModel Unleash strategy

Goal
Being able to enroll in an experiment only users that are supported by the model

[x] tested on dev feature flags + recAPI

Tickets:
* Link to JIRA tickets
Implementation Decisions
Use the existing hasUserModel strategy that was developed for recit. It works well here, the only downside that it says recit in property name.

it's the same as https://github.com/Pocket/recommendation-api/pull/1039 that was created from the the dev branch


add: functions

_.bind
_.partial
etc.

Coverage decreased (-0.3%) to 99.667% when pulling 7e08fcbd5915ae09fb9b137454856ee71ff7fa35 on functions into 5c0f11428bc6878c9bdee2385a24e7402b17dd04 on master.


Final fixes and tests

Closing the PR, because a different branch is now merged with the same commits.


Support for the new Angular Control Flow syntax

Description

Hi Team,
The Angular team recently introduced a new Control Flow syntax for templates - https://angular.dev/guide/templates/control-flow
The new control flow syntax provides the following elements - If, else, switch and for loops. These are alternatives to *ngIf, *ngFor and *ngSwitch.
Below is some examples of the control flow syntax and expected output-
Input
With this new feature, when I give like this input:
@if (a > b) {
{{a}} is greater than {{b}}
}

@if (a > b) {
{{a}} is greater than {{b}}
} @else if (b > a) {
{{a}} is less than {{b}}
} @else {
{{a}} is equal to {{b}}
}

@for (item of items; track item.name) {
<li> {{ item.name }} </li>
} @empty {
<li> There are no items. </li>
}

@switch (condition) {
@case (caseA) {
Case A.
}
@case (caseB) {
Case B.
}
@default {
Default case.
}
}

Expected Output
I'd like to see this output:
@if (a > b) {
  {{a}} is greater than {{b}}
}

@if (a > b) {
  {{a}} is greater than {{b}}
} @else if (b > a) {
  {{a}} is less than {{b}}
} @else {
  {{a}} is equal to {{b}}
}

@for (item of items; track item.name) {
  <li> {{ item.name }} </li>
} @empty {
  <li> There are no items. </li>
}

@switch (condition) {
  @case (caseA) {
    Case A.
  }
  @case (caseB) {
    Case B.
  }
  @default {
    Default case.
  }
}

Environment
OS: Mac

This issue deserves more attention, imo, because currently it's a pain to read such code while also no desire to return to the old syntax.
@for (item of items; track item.id) {
<p>{{ item.name }}
} @empty {
<p>[No items.]</p>
}

@gergely-gyorgy-both , great, thanks 😄 just wanted to bump the issue up a bit by commenting here.

@gergely-gyorgy-both Thank you! Really looking forward to it, can't wait 🙏

Any updates on this? The alternative is use Prettier which in my opinion is terrible and I tend to avoid it at all costs.

@bitwiseman FYI this change seems to have possibly unintended consequences.
I use js-beautify to beautify MJML output. With the new release the output changed, see here:

Hm, strange. I would expect the css beautifier  to handle the style tag contents.

@thaoula @bitwiseman FYI this change seems to have possibly unintended consequences.
I use js-beautify to beautify MJML output. With the new release the output changed, see here:
Before:
    <style type="text/css">
      @media only screen and (min-width:480px) {
        .mj-column-per-100 { width:100% !important; max-width: 100%; }
      }
    </style>

After:
   <style type="text/css">
-    @media only screen and (min-width:480px) {
-      .mj-column-per-100 {
-        width: 100% !important;
-        max-width: 100%;
-      }
+  @media only screen and (min-width:480px) {
+      .mj-column-per-100
+      {
+      width:100%
+      !important;
+      max-width:
+      100%;
+  }
     }
   </style>

Settings used with htmlBeautify:
indent_size: 2,
preserve_newlines: false,
css: {
  end_with_newline: false,
},
js: {
  end_with_newline: false,
},
html: {
  end_with_newline: true,
},

This is quite strange. Sorry for the inconvenience, @bitwiseman please notify me if you need any help fixing this.

@gergely-gyorgy-both
See also #2246 .  I've switching this feature to off by default (#2247).
Don't feel bad.  This is a hard problem space and these issues are why I lean towards "off by default" changes. In this, I took the change with the feature  "off by default in most cases".  Lesson learned for me. 😄

https://github.com/microsoft/vscode-html-languageservice/issues/177 is the last step needed in getting this made available in VS Code.


Safety Distance From Obstacle

Hello, thanks for this work, that's a good :)
But I am wondering how can I modify the safe distance to be with obstacles?

If I understand correctly, you are essentially looking for a "buffer" around the actual obstacles to have an additional margin of safety?
If so, the simplest solution would be to artificially inflate the obstacles by some safety margin. For example: subtract some margin X_buff, Y_buff from the upper-left corner of an obstacle, and add X_buff, Y_buff to the lower-right corner.
So if you originally had an obstacle defined by the two points [(0,0), (10,10)], and need a margin of 2, you would end up with points [(-2,-2), (12,12)].

Thank you. Yes, I was wondering if it is possible to interfere with the algorithm for a correct safety distance. But as you said, we can solve the problem with an intervention. Thanks again, have a nice day.


Dockerize safe react project

What it solves
The current listed version of electron (9.0.0) does not support the M1 chip (darwin-arm64).
There is another PR open to fix this: https://github.com/gnosis/safe-react/pull/2149
How this PR fixes it
As an alternative, you can use docker to run the safe-react in a container.
How to test it
Install Docker and  run yarn start:docker

I have read the CLA Document and I hereby sign the CLA

recheckcla


sdk API

I started using this SDK. Where can I find the API documentation?

I don't think there is any official documentation as such, but it is fairly easy to get clued up by reading through the examples and also the header files in the extras directory. For the rtos side of things the official FreeRTOS documentation is really helpful and is available as free pre-release copies, see: http://www.freertos.org/Documentation/RTOS_book.html
Bear in mind that EOR itself is based on an earlier version of the official sdk so a lot of the (particularly older) examples on the official forums may work with little or no tweaking.

Hi @slowkdj. Please have a look at the examples/ folder which demonstrates all the different features of ESP Open RTOS and the different additions and drivers people have contributed over the years. These can be found in extras/.


Template/Plan for Documentation of Substrate Types

Need to come up with a plan for documenting types.
I think it should attempt to explain to the user:

Which objects are created from each macro
What those objects look like at a Module level
What those objects look like when combined at the Construct Runtime Level
How those objects ultimately get used exposed at the Javascript API or metadata endpoint

Going to dump some stuff from node-runtime generated code:
#[allow(non_camel_case_types)]
#[structural_match]
pub enum Event {
    system(system::Event),
    indices(indices::Event<Runtime>),
    balances(balances::Event<Runtime>),
    session(session::Event<Runtime>),
    staking(staking::Event<Runtime>),
    democracy(democracy::Event<Runtime>),
    council(council::Event<Runtime>),
    council_voting(council_voting::Event<Runtime>),
    council_motions(council_motions::Event<Runtime>),
    grandpa(grandpa::Event<Runtime>),
    treasury(treasury::Event<Runtime>),
    contract(contract::Event<Runtime>),
    sudo(sudo::Event<Runtime>),
    fees(fees::Event<Runtime>),
}

#[allow(non_camel_case_types)]
#[structural_match]
pub enum Origin {
    system(system::Origin<Runtime>),
    council_motions(council_motions::Origin),

    #[allow(dead_code)]
    Void(::srml_support::Void),
}

#[structural_match]
pub enum Call {
    Timestamp(::srml_support::dispatch::CallableCallFor<Timestamp>),
    Consensus(::srml_support::dispatch::CallableCallFor<Consensus>),
    Indices(::srml_support::dispatch::CallableCallFor<Indices>),
    Balances(::srml_support::dispatch::CallableCallFor<Balances>),
    Session(::srml_support::dispatch::CallableCallFor<Session>),
    Staking(::srml_support::dispatch::CallableCallFor<Staking>),
    Democracy(::srml_support::dispatch::CallableCallFor<Democracy>),
    Council(::srml_support::dispatch::CallableCallFor<Council>),
    CouncilVoting(::srml_support::dispatch::CallableCallFor<CouncilVoting>),
    CouncilMotions(::srml_support::dispatch::CallableCallFor<CouncilMotions>),
    FinalityTracker(::srml_support::dispatch::CallableCallFor<FinalityTracker>),
    Grandpa(::srml_support::dispatch::CallableCallFor<Grandpa>),
    Treasury(::srml_support::dispatch::CallableCallFor<Treasury>),
    Contract(::srml_support::dispatch::CallableCallFor<Contract>),
    Sudo(::srml_support::dispatch::CallableCallFor<Sudo>),
}

/// All possible log entries for the `$trait` runtime. `Encode`/`Decode` implementations
/// are auto-generated => it is not binary-compatible with `generic::DigestItem`.
#[allow(non_camel_case_types)]
#[structural_match]
pub enum InternalLog {
    system(system::Log<Runtime>),
    consensus(consensus::Log<Runtime>),
    grandpa(grandpa::Log<Runtime>),
}

Investigate Yourself
The contents of this page are meant to facilitate a high level understanding of the Substrate runtime.
If you would like to dig deeper, you can do so by investigating these types yourself:

Clone and build the main Substrate repo
Run the following command in the root folder to output to file the Call enum for the Sudo module:cargo +nightly rustc --profile=check --package srml-sudo --lib -- -Zunstable-options --pretty=expanded > sudo-module.rs

Run the following command in the root folder to output to file the Call enum for the Substrate template node:cargo +nightly rustc --profile=check --package node-template-runtime --lib -- -Zunstable-options --pretty=expanded > substrate-template-node.rs

Investigate the Metadata definition in the metadata folder in the SRML.
Get the Metadata JSON by running a node and using the Polkadot.js UI:Toolbox > state > getMetadata(block)

Note: This call requires a valid blockhash since the metadata can change as the runtime gets upgraded.

https://hackmd.io/HLA5rUANTvu09jEYhaUwRg?view#


[Feature] fallback to random available port when 3307 is not available

This is a desktop-only feature.

Reported:

closed by 4e67d9c4ca0421193c20d54a483b775b914975be


Support Pushover notifications

Pushover looks similar to Telegram: https://pushover.net/api#messages. Looks pretty straightforward, basically identical to Telegram. Here's an npm package: https://www.npmjs.com/package/pushover-notifications.

Honestly the API is so simple I'm not sure it's worth using a library where they don't even use .map() in their sample to loop over an array. Maybe just directly make request() calls.

Nah, use a library. Three options:

https://github.com/SamDecrock/node-pushover (28 weekly downloads)
https://github.com/qbit/node-pushover (1,772 weekly downloads)
https://github.com/sqmk/chump (18 weekly downloads)


Using Resource Route

Hi, can we use this package inside Route::resource? Or should we seperate the index route for it to works?

Separate it

Definitely separate it.

Thanks for the reply, I already separate it since I think it's the only way.


Improvements to the Vokuro Repository

I've improved the configuration file (default is config.dist.php)
The services file is improved, prepared for future changes (phanbook and invo)
ControllerBase has some extra functions like saving a log file
Index file (in public) has some extra exceptions in it, so you can distinguish a normal exception from a PDO exception
All view files have been reviewed. When you're looking at users, you don't need to press 'search' anymore, you just see the users.
All still working, tested on localhost

Hello @UnderDogg,
First, I should tell you - thanks for contributing, you really did a great job!
But there are a few things which keep me from accepting your PR.

The principal problem is documentation. Vökuró is our educational repository. Now there is a lot of documentation in English and also translated into many other languages. If I accept your PR then all Vökuró-related documentation becomes not relevant (in all languages).
Actually this is a bad idea when PR contains a lot of big loosely coupled changes. For the big changes we usually use several loosely coupled PRs.

So, could you please make only those changes that do not conflict with the documentation (don't break it)?
If you want to make changes which can break the documentation, then you need someway to solve the documentation issue. Who will correct it and rewrite it?
I am really sorry,

This conversation really discouraged me to contribute to Phalcon...

why?

Sorry, I know the thread is closed; and I said that because not even at work programming is that strict

@Baruch4413 usually that is a huge problem. I saw a lot of bad code just because nobody bother (him/her)self to make it strict. Allowing developers to write the code as they want, you'll end up with a lot of garbage in the code, which 100% will lead to unmaintainable code, high risk for creating bugs and other problems. What is missing here in this case would be a code sniffer like friendsofphp/php-cs-fixer to check the code and report coding standard errors. after that, you can concentrate more on the implementation and architecture. In code reviews should not be comments about spaces, indentation or things that can be automatized. Usually in code reviews I am expecting to see comments about the implementation, logic, functionality and even better respecting solid principles and tell the PR owner if something is wrong from this perspective.


File upload disregards filename

Upon uploading a pdf file the system correctly embeds it and adds to the collection but drops the filename (i.e., "whatever.pdf" becomes ".pdf")
Filename can be later edited to restore the original name.
While uploading the file, i see in the console the following error:
Warning: TT: undefined function: 32
Dunno if it is related or not.
Update: if you upload the file from the prompt (+ symbol on the left of the input box) everything is fine (filename is kept)

I'm seeing the same issue. I'm not seeing any client-side errors in the console, but I am seeing that the very first POST request to supabase/rest/v1/files already has the name attribute set to the file extension, so it seems like it's a client-side transformation that's splitting the filename unexpectedly.


Unable to install Homebrew

I am using Macbook Pro with macOS High Sierra version 10.13.5. I tried installing homebrew using the command: /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)" as suggested in Homebrew homepage. I have met all the requirements as mentioned below:

An Intel CPU
OS X 10.11 or higher
Command Line Tools (CLT) for Xcode: xcode-select --install, developer.apple.com/downloads or Xcode : I am using xcode 9.4
A Bourne-compatible shell for installation (e.g. bash or zsh)

Error message
`rajedei$ /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
==> This script will install:
/usr/local/bin/brew
/usr/local/share/doc/homebrew
/usr/local/share/man/man1/brew.1
/usr/local/share/zsh/site-functions/_brew
/usr/local/etc/bash_completion.d/brew
/usr/local/Homebrew
==> The following new directories will be created:
/usr/local/Cellar
/usr/local/Homebrew
/usr/local/Frameworks
/usr/local/etc
/usr/local/include
/usr/local/opt
/usr/local/sbin
/usr/local/share/zsh
/usr/local/share/zsh/site-functions
Press RETURN to continue or any other key to abort
==> /usr/bin/sudo /bin/mkdir -p /usr/local/Cellar /usr/local/Homebrew /usr/local/Frameworks /usr/local/etc /usr/local/include /usr/local/opt /usr/local/sbin /usr/local/share/zsh /usr/local/share/zsh/site-functions
Password:
==> /usr/bin/sudo /bin/chmod g+rwx /usr/local/Cellar /usr/local/Homebrew /usr/local/Frameworks /usr/local/etc /usr/local/include /usr/local/opt /usr/local/sbin /usr/local/share/zsh /usr/local/share/zsh/site-functions
==> /usr/bin/sudo /bin/chmod 755 /usr/local/share/zsh /usr/local/share/zsh/site-functions
==> /usr/bin/sudo /usr/sbin/chown rajedei /usr/local/Cellar /usr/local/Homebrew /usr/local/Frameworks /usr/local/etc /usr/local/include /usr/local/opt /usr/local/sbin /usr/local/share/zsh /usr/local/share/zsh/site-functions
==> /usr/bin/sudo /usr/bin/chgrp admin /usr/local/Cellar /usr/local/Homebrew /usr/local/Frameworks /usr/local/etc /usr/local/include /usr/local/opt /usr/local/sbin /usr/local/share/zsh /usr/local/share/zsh/site-functions
==> /usr/bin/sudo /bin/mkdir -p /Users/rajedei/Library/Caches/Homebrew
==> /usr/bin/sudo /bin/chmod g+rwx /Users/rajedei/Library/Caches/Homebrew
==> /usr/bin/sudo /usr/sbin/chown rajedei /Users/rajedei/Library/Caches/Homebrew
==> /usr/bin/sudo /bin/mkdir -p /Library/Caches/Homebrew
==> /usr/bin/sudo /bin/chmod g+rwx /Library/Caches/Homebrew
==> /usr/bin/sudo /usr/sbin/chown rajedei /Library/Caches/Homebrew
==> Downloading and installing Homebrew...
remote: Counting objects: 102235, done.
remote: Total 102235 (delta 0), reused 1 (delta 0), pack-reused 102234
Receiving objects: 100% (102235/102235), 23.30 MiB | 1.54 MiB/s, done.
Resolving deltas: 100% (74478/74478), done.
From https://github.com/Homebrew/brew

[new branch]          master     -> origin/master
[new tag]             0.1        -> 0.1
[new tag]             0.2        -> 0.2
[new tag]             0.3        -> 0.3
[new tag]             0.4        -> 0.4
[new tag]             0.5        -> 0.5
[new tag]             0.6        -> 0.6
[new tag]             0.7        -> 0.7
[new tag]             0.7.1      -> 0.7.1
[new tag]             0.8        -> 0.8
[new tag]             0.8.1      -> 0.8.1
[new tag]             0.9        -> 0.9
[new tag]             0.9.1      -> 0.9.1
[new tag]             0.9.2      -> 0.9.2
[new tag]             0.9.3      -> 0.9.3
[new tag]             0.9.4      -> 0.9.4
[new tag]             0.9.5      -> 0.9.5
[new tag]             0.9.8      -> 0.9.8
[new tag]             0.9.9      -> 0.9.9
[new tag]             1.0.0      -> 1.0.0
[new tag]             1.0.1      -> 1.0.1
[new tag]             1.0.2      -> 1.0.2
[new tag]             1.0.3      -> 1.0.3
[new tag]             1.0.4      -> 1.0.4
[new tag]             1.0.5      -> 1.0.5
[new tag]             1.0.6      -> 1.0.6
[new tag]             1.0.7      -> 1.0.7
[new tag]             1.0.8      -> 1.0.8
[new tag]             1.0.9      -> 1.0.9
[new tag]             1.1.0      -> 1.1.0
[new tag]             1.1.1      -> 1.1.1
[new tag]             1.1.10     -> 1.1.10
[new tag]             1.1.11     -> 1.1.11
[new tag]             1.1.12     -> 1.1.12
[new tag]             1.1.13     -> 1.1.13
[new tag]             1.1.2      -> 1.1.2
[new tag]             1.1.3      -> 1.1.3
[new tag]             1.1.4      -> 1.1.4
[new tag]             1.1.5      -> 1.1.5
[new tag]             1.1.6      -> 1.1.6
[new tag]             1.1.7      -> 1.1.7
[new tag]             1.1.8      -> 1.1.8
[new tag]             1.1.9      -> 1.1.9
[new tag]             1.2.0      -> 1.2.0
[new tag]             1.2.1      -> 1.2.1
[new tag]             1.2.2      -> 1.2.2
[new tag]             1.2.3      -> 1.2.3
[new tag]             1.2.4      -> 1.2.4
[new tag]             1.2.5      -> 1.2.5
[new tag]             1.2.6      -> 1.2.6
[new tag]             1.3.0      -> 1.3.0
[new tag]             1.3.1      -> 1.3.1
[new tag]             1.3.2      -> 1.3.2
[new tag]             1.3.3      -> 1.3.3
[new tag]             1.3.4      -> 1.3.4
[new tag]             1.3.5      -> 1.3.5
[new tag]             1.3.6      -> 1.3.6
[new tag]             1.3.7      -> 1.3.7
[new tag]             1.3.8      -> 1.3.8
[new tag]             1.3.9      -> 1.3.9
[new tag]             1.4.0      -> 1.4.0
[new tag]             1.4.1      -> 1.4.1
[new tag]             1.4.2      -> 1.4.2
[new tag]             1.4.3      -> 1.4.3
[new tag]             1.5.0      -> 1.5.0
[new tag]             1.5.1      -> 1.5.1
[new tag]             1.5.10     -> 1.5.10
[new tag]             1.5.11     -> 1.5.11
[new tag]             1.5.12     -> 1.5.12
[new tag]             1.5.13     -> 1.5.13
[new tag]             1.5.14     -> 1.5.14
[new tag]             1.5.2      -> 1.5.2
[new tag]             1.5.3      -> 1.5.3
[new tag]             1.5.4      -> 1.5.4
[new tag]             1.5.5      -> 1.5.5
[new tag]             1.5.6      -> 1.5.6
[new tag]             1.5.7      -> 1.5.7
[new tag]             1.5.8      -> 1.5.8
[new tag]             1.5.9      -> 1.5.9
[new tag]             1.6.0      -> 1.6.0
[new tag]             1.6.1      -> 1.6.1
[new tag]             1.6.2      -> 1.6.2
[new tag]             1.6.3      -> 1.6.3
[new tag]             1.6.4      -> 1.6.4
[new tag]             1.6.5      -> 1.6.5
[new tag]             1.6.6      -> 1.6.6
HEAD is now at 7d2530016 Merge pull request #4274 from DomT4/new_macos
/usr/local/Homebrew/Library/Homebrew/PATH.rb:71:in split': invalid byte sequence in UTF-8 (ArgumentError)  from /usr/local/Homebrew/Library/Homebrew/PATH.rb:71:in block in parse'
from /usr/local/Homebrew/Library/Homebrew/PATH.rb:71:in each'  from /usr/local/Homebrew/Library/Homebrew/PATH.rb:71:in flat_map'
from /usr/local/Homebrew/Library/Homebrew/PATH.rb:71:in parse'  from /usr/local/Homebrew/Library/Homebrew/PATH.rb:8:in initialize'
from /usr/local/Homebrew/Library/Homebrew/global.rb:62:in new'  from /usr/local/Homebrew/Library/Homebrew/global.rb:62:in <top (required)>'
from /System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in require'  from /System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in require'
from /usr/local/Homebrew/Library/Homebrew/brew.rb:23:in <main>' Failed during: /usr/local/bin/brew update --force <img width="1680" alt="screen shot 2018-06-05 at 11 20 18 am" src="https://user-images.githubusercontent.com/39939865/40957382-8a81490a-68b2-11e8-88a9-1211235c324e.png">
Please someone help me with this issue. Its urgent

From the issue template:

Please note we will close your issue without comment if you delete, do not read or do not fill out the issue checklist below and provide ALL the requested information. If you do not read fill out the issue template repeatedly you will be blocked from ever submitting issues to Homebrew again.

Please submit issues like this to our Discourse instead.

@MikeMcQuaid Please guide me on how to do or report it correctly?

@deivigan87 Read the issue template when creating future issues. In this case the problem is likely something in your PATH variable.


docs(github): update code owners about past maintainers

As per suggestion in https://github.com/ratatui-org/ratatui/pull/1067#issuecomment-2079766990
It's good for historical purposes!

Not sure whether this will work... can you elaborate?

I guessing it’ll work because it’s just another comment?

I guessing it’ll work because it’s just another comment?

Ha - I was reading on my phone and didn't notice the comment char :)


Make block compatible with Elemental 4

This looks great! It would be neat to see it work out of the box with the newest (next ATM) version of Elemental though - for this I think all that's needed is
private static $inline_editable = false;

on MapBlock.php :)

Fixed in 0e58f069d6a6ca4098f19acc08350e456d454c0b, thanks!


Adjust dino fall and reborn time

Double the rate at which dino falls
More than halve reborn time
Increase jump height (once fall rate was increased, he couldn't jump high enough to get to all of the floors)
Adjust tests to account for changes
closes #47 closes #56
Just getting some low hanging fruit tonight, will get into the meat of the work tomorrow!

cool. Are you ready for a merge or do you want to include other stuff?

Merging is fine. I'll do separate branches for the rest.

Done!


🐛(api) force single database engine and session per thread

Purpose
We've observed connection issues to the PostgreSQL server when many requests are send in parallel.
Proposal
Use the singleton pattern to avoid opening too many connections to the database and reach the maximal connection pool for database requests during API heavy load.

This is an alternative to #137 originally proposed by @lebaudantoine


Clarify is_fresh() with regard to concurrent insert_with()

Hi, great work on the upcoming entry API!
I am wondering about the interaction of is_fresh() and the coalescing of concurrent calls in insert_with():

This method guarantees that concurrent calls on the same not-existing entry are coalesced into one evaluation of the init future. Only one of the calls evaluates its future, and other calls wait for that future to resolve.

That is, will one of the concurrent calls return an Entry that is_fresh(), will all be considered fresh, or is there no such guarantee?

Hi. Thank you for trying the new feature and asking the question.
Yes, there is a guarantee; is_fresh() must return true only when the init future of the or_insert_with call is resolved.
For example, when two concurrent or_insert_with calls (say call-A and call-B) on the same non-existing key were coalesced into one and call-A's init future was resolved, is_fresh of returned entries should return the following values:

is_fresh of the entry returned from call-A should return true.
is_fresh of the entry returned from call-B should return false.

This behavior was already implemented in the master branch via PR #193, but I realized test cases were missing. So I opened a new PR #218 to update the test cases to verify the behavior and also update the documentation to make the guarantee a bit more clear.

This method guarantees that concurrent calls on the same not-existing entry are coalesced into one evaluation of the init future. Only one of the calls evaluates its future (thus returned entry's is_fresh method returns true), and other calls wait for that future to resolve (and their is_fresh return false).

Thanks!


Cache previous builds

closes #42
I didn't think this change would be useful but after having 8/9 runs of this action complete in parallel and the last one failed I had to re run them all...with this change the actions should exit much faster.
See:

@klutchell on your create_ref PR I mentioned we should throw an error whenever the action is told to do something and the state doesn't change to make it easier to troubleshoot...while I did this change I think I changed my mind because imagine for whatever reason someone finalized a release before you merge to master. Now the action will never be able to pass until you make the release not final so it can finalize it. I'm saying this because in this PR I changed the PR to allow it to skip finalizing if the release is already final.

converting to draft because right now this code only uses cache for PR workflow but it could work for master workflow too. I just got lazy and didn't want to do all the refactoring required for getReleaseByTag to work without the balena-ci-id tag..
will finish later.

@balena-ci I self-certify!


Simple class for tomographic binning

I would like to add a very simple class for tomographic binning. It will be using the point estimate, e.g. mode of the photo-z posterior, to split the sample into tomographic bins according to the Science Requirement Document. The class will probably be placed in summarization, but open to suggestions. Comments, advice, and helps are welcome!

This is a good idea! I think we should actually make at least one additional superclass for classifier stages in a new module under src/rail/estimation (possibly needing several depending on what kinds of inputs they expect, as we do for estimators/summarizers). Then we can implement more sophisticated tomographers under the same API. But it definitely makes sense to mock up one or two simple tomographers first before making an abstract class to support more like them.

In branch issue/10/tomo_bins I have now added a tomographer module under rail_base.estimation. It contains two generic tomographer classes:

PZTomographer, which takes per-galaxy n(z) from a qp.Ensemble object and output a tabular object with tomographic binning;
CatTomographer, which takes catalogue-like data and output a tabular object with tomographic binning;
The second type will be compatible with the classifiers in tomo-challenge, where features in the catalogue are used to assign tomographic bins.
For each of these types, I've added an example classifier in algos/. For the first type this is the simple point estimate SRD binning; for the second type I adapted the random forest classifier from TXPipe.
Is this kind of structure fine? Comments and suggestions are welcome.


[SPARK-49678][CORE][FOLLOWUP] Support spark.master in SparkSubmitArguments

What changes were proposed in this pull request?
This PR is a follow-up in order to support spark.master instead of spark.test.master.

#48126

Why are the changes needed?
By reusing the official config name, we can avoid to add a new test configuration.
Does this PR introduce any user-facing change?
No.
How was this patch tested?
Pass the CIs.
Was this patch authored or co-authored using generative AI tooling?
No.

cc @HyukjinKwon

Thank you, @viirya .

Could we maybe just reuse 'PYSPARK_SUBMIT_ARGS' environment variable set to 'pyspark-shell --master local[1]' if this is just dev/test only? I haven't tested cuz I am away from keyboard today but I think it should work.

To @HyukjinKwon , it was for Python doc generation, but this is a general feature for all. For example, spark-shell and spark-sql works like this. I don't think PYSPARK_SUBMIT_ARGS is the equivalent of this PR.
$ JDK_JAVA_OPTIONS="-Dspark.test.master=local[1]" bin/spark-shell
NOTE: Picked up JDK_JAVA_OPTIONS: -Dspark.test.master=local[1]
NOTE: Picked up JDK_JAVA_OPTIONS: -Dspark.test.master=local[1]
WARNING: Using incubator modules: jdk.incubator.vector
Using Spark's default log4j profile: org/apache/spark/log4j2-pattern-layout-defaults.properties
Setting default log level to "WARN".
To adjust logging level use sc.setLogLevel(newLevel). For SparkR, use setLogLevel(newLevel).
Welcome to
      ____              __
     / __/__  ___ _____/ /__
    _\ \/ _ \/ _ `/ __/  '_/
   /___/ .__/\_,_/_/ /_/\_\   version 4.0.0-SNAPSHOT
      /_/

Using Scala version 2.13.14 (OpenJDK 64-Bit Server VM, Java 21.0.4)
Type in expressions to have them evaluated.
Type :help for more information.
24/09/17 17:35:19 WARN NativeCodeLoader: Unable to load native-hadoop library for your platform... using builtin-java classes where applicable
Spark context Web UI available at http://localhost:4040
Spark context available as 'sc' (master = local[1], app id = local-1726619719887).
Spark session available as 'spark'.

scala>

$ JDK_JAVA_OPTIONS="-Dspark.test.master=local[1]" bin/spark-sql
NOTE: Picked up JDK_JAVA_OPTIONS: -Dspark.test.master=local[1]
NOTE: Picked up JDK_JAVA_OPTIONS: -Dspark.test.master=local[1]
WARNING: Using incubator modules: jdk.incubator.vector
Using Spark's default log4j profile: org/apache/spark/log4j2-pattern-layout-defaults.properties
Setting default log level to "WARN".
To adjust logging level use sc.setLogLevel(newLevel). For SparkR, use setLogLevel(newLevel).
24/09/17 17:35:58 WARN NativeCodeLoader: Unable to load native-hadoop library for your platform... using builtin-java classes where applicable
24/09/17 17:36:00 WARN ObjectStore: Version information not found in metastore. hive.metastore.schema.verification is not enabled so recording the schema version 2.3.0
24/09/17 17:36:00 WARN ObjectStore: setMetaStoreSchemaVersion called but recording version is disabled: version = 2.3.0, comment = Set by MetaStore<EMAIL_ADDRESS>24/09/17 17:36:00 WARN ObjectStore: Failed to get database default, returning NoSuchObjectException
Spark Web UI available at http://localhost:4040
Spark master: local[1], Application Id: local-1726619758755
spark-sql (default)>

Let me close this and go back to the original PR, @HyukjinKwon .

Sorry, @viirya and @HyukjinKwon . I closed this PR and will add a comment to the original PR.


why duration()  can't get total time in android

It works fine on iOS, but on Android the call to getDuration() is returning 0 seconds. Any idea why?

Hi! If you're still experiencing this issue, could you please open an issue with more details following the issue template? Thanks!

@paulmelnikow, i'm facing this issue, any update on it?

@meghaptg Could you please open a new issue following the issue template?


Fix uninitialised filters and minor issues

ISSUE TYPE

Bug fix Pull Request

SUMMARY

This PR,

fixes uninitialized filters (NamespaceChecker, ObjectAnnotationChecker) by moving them out of respective directories.
updates expected values in test/.../botkube.go
removes repetitive assert in test/.../create.go

rebased onto develop


Failed Discovery Check when registering the prometheus adapter to v1beta1.custom.metrics.k8s.io

I installed the kube-prometheus manifests as given in the readme. Changed the prometheus-adapter-apiSevice.yaml to
apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:
  name: v1beta1.metrics.k8s.io
spec:
  group: metrics.k8s.io
  groupPriorityMinimum: 100
  insecureSkipTLSVerify: true
  service:
    name: prometheus-adapter
    namespace: monitoring
  version: v1beta1
  versionPriority: 100
---
apiVersion: apiregistration.k8s.io/v1beta1
kind: APIService
metadata:
  name: v1beta1.custom.metrics.k8s.io
spec:
  service:
    name: prometheus-adapter
    namespace: monitoring
  group: custom.metrics.k8s.io
  version: v1beta1
  insecureSkipTLSVerify: true
  groupPriorityMinimum: 100
  versionPriority: 100
---

But the following error is coming

kubectl get apiservices | grep metrics
v1beta1.custom.metrics.k8s.io          monitoring/prometheus-adapter   False (FailedDiscoveryCheck)   5h54m
v1beta1.metrics.k8s.io                 monitoring/prometheus-adapter   True                           5h53m

kubectl describe apiservice v1beta1.custom.metrics.k8s.io
Name:         v1beta1.custom.metrics.k8s.io
Namespace:
Labels:       <none>
Annotations:  kubectl.kubernetes.io/last-applied-configuration:
                {"apiVersion":"apiregistration.k8s.io/v1beta1","kind":"APIService","metadata":{"annotations":{},"name":"v1beta1.custom.metrics.k8s.io"},"s...
API Version:  apiregistration.k8s.io/v1
Kind:         APIService
Metadata:
  Creation Timestamp:  2020-09-16T06:30:42Z
  Resource Version:    4348330
  Self Link:           /apis/apiregistration.k8s.io/v1/apiservices/v1beta1.custom.metrics.k8s.io
  UID:                 f3510793-90ce-4347-ad0e-838f80723493
Spec:
  Group:                     custom.metrics.k8s.io
  Group Priority Minimum:    100
  Insecure Skip TLS Verify:  true
  Service:
    Name:            prometheus-adapter
    Namespace:       monitoring
    Port:            443
  Version:           v1beta1
  Version Priority:  100
Status:
  Conditions:
    Last Transition Time:  2020-09-16T06:30:42Z
    Message:               failing or missing response from https://<IP_ADDRESS>:6443/apis/custom.metrics.k8s.io/v1beta1: bad status from https://<IP_ADDRESS>:6443/apis/custom.metrics.k8s.io/v1beta1: 404
    Reason:                FailedDiscoveryCheck
    Status:                False
    Type:                  Available
Events:                    <none>

Do I need to follow any other procedure for registering the service into custom.metrics.k8s.io apiGroup?

cc @s-urbaniak

@tanujd11 you also need to configure custom rules (example configuration https://github.com/DirectXMan12/k8s-prometheus-adapter/blob/master/docs/sample-config.yaml), otherwise prometheus-adapter will not serve the custom metrics API.

Closing as this appears to be answered. Please reopen if you think this is still relevant.

Running into the same issue here. I've been uncommenting this line: https://github.com/prometheus-operator/kube-prometheus/blob/c5360561fa3cb52297b652c263794ca474a0ab73/example.jsonnet?ref=morioh.com&utm_source=morioh.com#L8
As far as I understand that should be configuring the custom rules as well?

Running into the same issue here. I've been uncommenting this line: https://github.com/prometheus-operator/kube-prometheus/blob/c5360561fa3cb52297b652c263794ca474a0ab73/example.jsonnet?ref=morioh.com&utm_source=morioh.com#L8
As far as I understand that should be configuring the custom rules as well?

Have you found solution?


thrift: adding xDS RDS support for thrift proxy.

Commit Message:
Adding xDS RDS support for thrift proxy.
Additional Description:

New grpc/restapi endpoint is added for Thrift route discovery service.

This PR is split from #17631
Risk Level:
Low
Testing:

Unittest
Manual test with static routing from bootstrap config, static routing and dynamic routing from GRPC based xDS server.

Docs Changes:
Comment added to the new API field.
Release Notes:
Platform Specific Features:

@htuch
Meanwhile the  original PR has been closed by the bot and I couldn't reopen, so I had to open a new one.
The api change was approved once here, after that just minor changes happened.

Looks like here still lots of similar codes with  HTTP rds. 🤔 Can we make RouteConfigProviderManager a template to reuse more codes?

Looks like here still lots of similar codes with HTTP rds. 🤔 Can we make RouteConfigProviderManager a template to reuse more codes?

The HTTP rds has special needs so I wouldn't bother that, but you are right in that sense the rds_impl.cc/h would be basically the same for other simple protocols like for the thrift currently. So yes, maybe on this level we can bring back some templates.

/lgtm api

/wait

/retest

Are there integration tests planned?

There is unit test to check if the proper TRDS endpoints are referred towards server, also for thrift config with rds on filter level.
The integration of these two parts done by common code which already has higher level test, so I did not plan to add new.

/retest

/retest

/wait

I think we should have a full integration test, since while individual parts and their integration may be tested,

Ok, I have just noticed there are integration tests for thrift I try to add one for trds.

Great PR. Thanks for the rds templating. Then, we can try to add dubbo rds to Envoy just by adding little codes.


[Added] Roboto Condensed and tests

[Added] Roboto Condensed
[Added] test.html - Has tests for all fonts
[Modified] Folder structure and mixins to add more font variants of roboto
Bear with me for lots of files showing deleted/modified. Its just a folder structure changed to accommodate more Roboto font variants.
Please run test.sh and test.html  to make sure everything working as expected.
Thanks,
Purushothaman

Thank you for the PR. Will look into it as soon as I have time.
One thing I already noticed: Is the moving of the .scss/.less files really necessary? This breaks with all previous versions. I am not saying, that I am totally against it, but if we do this, then there should be really good reasons...

Hi @choffmeister,
Thanks for considering the PR. Yeah I too worry it would break previous version's structure.
Its just a separation of concerns to group related files of a particular font variant. where the common 'mixins' will stay outside.
Feel free to modify the structure if needed. Or we can display upgrade notice regarding the change. Will that work?
Thanks,
Purushoth

Published as 0.5.0

That's great :+1:


Adding format package does not change auto-indent rules

I added the "format" package by including it in init.el.
In my use case, I am using C and have a .clang-format in my projectile-root. I'm using <SPC> c f to format my code calling format/buffer-region
However, emacs still has auto indent set to another config. For example, when I type
typedef enum { and press enter, the cursor is aligned with the "t":
typedef enum { // Press enter
|<------ cursor
}

Where it should, according to the format rules, be indented.
typedef enum { // Press enter
  |<------ cursor should be here.
}

Additionally, if I highlight and press "=" to indent, the indentation is not the same as if I do <SPC> c f, which is fairly annoying. I would expect installing the format package to be consistent with evil-indent.
Steps to reproduce:

Install format by adding it to init.el
In a new, empty folder, Install clang-format and run clang-format -style=llvm -dump-config > .clang-format
Create a C file and place the following code:

typedef enum {
  Cmd_Hello,
  Cmd_Write,
  Cmd_Read,
  Cmd_Invalid
} CmdType;

Highlight the region and press "="
The enums are now flush with the left side.
Highlight the region and press <SPC> c f
Observe the different alignment.

Unfortunately, Doom nor any of its plugins can sync your formatting settings with your project's formatter. I'd recommend using editorconfig (Doom also has a :tools editorconfig module for integration) or change the appropriate variables yourself, e.g.
(after! cc-mode (setq c-basic-offset 2)) ; set it globally
(setq-hook! 'c++-mode-hook c-basic-offset 2) ; set it in c++-mode buffers

Or set them project-locally with a .dir-locals.el file in your project's root, containing
((c++-mode . (c-basic-offset . 2)))

Ah, and there's also M-x doom/set-indent-width

Also take a look at c-offsets-alist. For instance to match the Chromium clang-format style, I have this in my private config:
(setq c-offsets-alist '((innamespace . 0)
                        (access-label . /)
                        (inclass . +)))

(setq-hook! '(c-mode-hook c++-mode-hook) c-basic-offset 4)


Port pandas helper module for data from pycompwa

The new data module in pycompwa by @redeboer already provides all of the needed functionality.
From that existing data module, only a fraction of the code and functionality is needed though. Here one should also be careful not to port the flaws imposed by the design of ComPWA (EventCollection).
Update:
The expertsystem now has its own data module. Some of the features of pycompwa could be added here, especially if we allow to have to_pandas() return an actual DataFrame. EventCollection.to_pandas() already formats to the standards set by the PwaAccessor that pycompwa used, so it would just be a matter of porting the PwaAccessor and casting the output dict of to_pandas() to pandas.DataFrame.

Made redundant by #92. If needed, this issue could be reopened in a (future) wrapper packages about QRules, AmpForm, and TensorWaves.


Add support to vault secret type

Why do we create  vault in torpedo code? Vault secrets can be created if absent in job.

Why do we create vault in torpedo code? Vault secrets can be created if absent in job.

@stgleb because torpedo manages the secret it creates, these secrets are defined in https://github.com/portworx/torpedo/blob/102f9f4a753cd378e8697c68fa5c3cb296056af1/drivers/scheduler/k8s/specs/mysql/px-mysql-storage.yaml#L1-L7 so torpedo should cope with secrets creation since it can change

move vault to portworx volume driver sched-ops.

@harsh-px tried to move to sched-ops but there we don't know basic facts like app and which secret to use, cause we define secrets inside each app specs


GCC Availability for Report Message Add-In

With the updated "user submission" policy in GCC, the report message add-in now works.  Verified in a test and customer tenant.  The submission policy disables the option to send the reported message to Microsoft.

The Report Message add-in is currently not available for:
Mailboxes in on-premises Exchange organizations
GCC, GCC HIGH, or DoD subscriptions

This screen shot is from a GCC (demo) tenant.

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

ID: 445892a6-5948-33e4-ce60-72670829d8ef
Version Independent ID: a7407a6f-6563-9a4b-4a95-7ed908ab322b
Content: Enable the Report Message add-in - Office 365
Content Source: microsoft-365/security/office-365-security/enable-the-report-message-add-in.md
Service: o365-seccomp
GitHub Login: @chrisda
Microsoft Alias: chrisda

@jbrysonMSFT, fixed.
Thanks for the feedback.
Closing


Consider using ResourceId namespaceId instead of bytes14 namespace for registering namespaces and in BalanceTransferSystem

Followup to #1544

done in #1544