Add new resolvers `oc.dict.keys` and `oc.dict.values` #644

odelalleau · 2021-03-24T20:12:36Z

Fixes #643

Better check commits separately: the meaningful one is the second one, the other two are refactor commits with no functional changes.

docs/source/usage.rst

omegaconf/built_in_resolvers.py

odelalleau · 2021-03-24T20:56:14Z

Something else: I just remembered that I have a WIP change that reverts the automatic conversion of list/dict resolver outputs, relying on explicitly using oc.create instead (relevant discussion: #606 (comment))

Do you prefer that oc.dict.keys output plain dicts / lists (enforcing the usage of oc.create to convert them to config containers), or that they output directly DictConfig / ListConfig (the latter is a bit less flexible but probably better for most use cases, so I'm leaning towards it)

omry · 2021-03-24T21:12:00Z

Side notes:

It becomes more important that we refactor the documentation to give space to detailed resolvers docs. The primary config should contain a list of built in resolvers with a short description of each, and point to another page (not in this PR).
There is also oc.select to introduce to support interpolation with a default value.

odelalleau · 2021-03-24T21:16:13Z

It becomes more important that we refactor the documentation to give space to detailed resolvers docs. The primary config should contain a list of built in resolvers with a short description of each, and point to another page (not in this PR).

There is also oc.select to introduce to support interpolation with a default value.

I added an item in #535 for point 1.
Is there already a 2.1 issue to add oc.select? (or requiring it?). I don't have it on my radar right now.

omry · 2021-03-24T21:23:10Z

541, I just milestoned it for 2.1. I think it should be straight forward at this point.
in fact, I already implemented it in a local hack (without testing and docs):

http://paste.ubuntu.com/p/4JRYBMR3Y6/

omry · 2021-03-25T01:30:40Z

omegaconf/built_in_resolvers.py

+    dict_method = getattr(in_dict, keys_or_values)
+    assert isinstance(_parent_, BaseContainer)
+    ret = OmegaConf.create(list(dict_method()), parent=_parent_)
+    assert isinstance(ret, ListConfig)
+    return ret


IMO would be cleaner to return the dict/DictConfig object and allow the caller to just call the appropriate function.

Done in cdc60a8

omry · 2021-03-25T01:32:35Z

omegaconf/built_in_resolvers.py

+    return _dict_impl(
+        keys_or_values="values", in_dict=in_dict, _root_=_root_, _parent_=_parent_
+    )


What is the desired behavior if there is a missing value in the doct selected from?
I think right now this will raise an exception on the call to access the values.

Yeah, I think it's fine, I added tests in 57c3613

We may consider raising an InterpolationToMissingValueError instead of a generic InterpolationResolutionError wrapping a MissingMandatoryValue exception. I can see arguments for either option, so let me know how you feel about this.

omry · 2021-03-25T01:42:32Z

docs/source/usage.rst

+    ...         # Config node name `machines` as input.
+    ...         "ips": "${oc.dict.values:machines}",


You are changing two things at once, makes it a bit confusing (using os.dict.values instead of oc.dict.keys and using the alternative selection method). Update the comment to reflect those two changes?

Clearer in 6898d48?

omry · 2021-03-25T01:43:59Z

tests/interpolation/built_in_resolvers/test_dict.py

+def test_dict_keys(restore_resolvers: Any, cfg: Any, key: Any, expected: Any) -> None:
+    OmegaConf.register_new_resolver("sum", lambda x: sum(x))
+
+    cfg = OmegaConf.create(cfg)
+    val = cfg[key]
+    assert val == expected
+    assert type(val) is type(expected)
+
+    if isinstance(val, ListConfig):
+        assert val._parent is cfg


Could be a bit cleaner to split into a basic test_dict_keys function and one that tests it with nesting into sum.
Beyond making the test simpler, the input data can also become pure lists (as the expected output type is always ListConfig).

Done in 018d521

omry · 2021-03-25T02:35:58Z

tests/interpolation/built_in_resolvers/test_dict.py

+def test_dict_missing(cfg: Any) -> None:
+    cfg = OmegaConf.create(cfg)
+    with raises(InterpolationResolutionError, match="MissingMandatoryValue"):
+        cfg.x


One none obvious behavior here is that those two functions are resolving interpolations eagerly.
OmegaConf interpolations are generally resolved on access.
This can lead to surprising behavior.

device: cuda models_zoo: resnet50: device: ${device} # ... alexnet: device: ${device} # ... test_models: ${oc.dict.values:models_zoo}

cfg = OmegaConf.create(cfg) tester = ModelsTester(cfg.test_models) if not torch.cuda.is_available(): cfg.device = 'cpu' # At this point, the device in ModelsTester will no longer track cfg.device so the change will not be reflected. # This is in contrast to the case where `test_models` was a "real" list in the yaml file.

I think this is not a huge deal, but it's solvable by iterating on the underlying _content and copying the contained nodes directly).
This would also make the MISSING behavior consistent (and lazy).

Hmm, that's an interesting idea. I have a PoC that works with your example (using [v for _, v in in_dict.items_ex(resolve=False)] instead of list(in_dict.values()) for DictConfigs.

There's a problem though: relative interpolations get broken if we do this. One potential solution (besides trying to "fix" relative references) would be instead to create nodes in the output ListConfig that are interpolated to the target nodes... but this would start getting a bit hairy => maybe best left for later?

I think changing the parent after copying the nodes to _parent_ should make relative interpolations be relative to the the node with ${oc.dict.values:...}.

ret = [] for _, v in in_dict.items_ex(resolve=False): vc = copy.deepcopy(v) vc._set_parent(_parent_) ret.append(vc)

Also, although I agree that it would be nice to support this, note that the current behavior is actually (at least partially) consistent with "interpolations are resolved on access": the reason it doesn't work in your example is because you compute cfg.test_models only once, but if you re-access it after changing cfg.device, you will get the updated version.
(just making sure that part is clear, doesn't change that I agree "deeper" dynamism would be better)

Can you tell me how such config nodes interact with OmegaConf.merge()?

Going to depend on the exact scenario (what are you merging into what?). Not sure it's worth spending too much time on it now -- people merging dynamically generated configs deserve whatever happens to them.

Anyway, I forced-pushed 2e604f9 to override my initial implementation with a new one that doesn't introduce any new low-level mechanics. An error referring to #650 is raised in case someone tries to extract values from a transient DictConfig that's not accessible through a path from the root. I'll fill in the content of #650 once we agree this is a good way to go.

(I force-pushed it as I assume it'd be easier for you to review, but let me know if you need the diff w.r.t. my initial implementation too)

Going to depend on the exact scenario (what are you merging into what?). Not sure it's worth spending too much time on it now -- people merging dynamically generated configs deserve whatever happens to them.

Dynamically generating config nodes is an alternative to config composition.
Saying people using both deserves whatever happens is not a great approach.
If this feature is not compatible with merging we should be explicit about it and not leave it undefined.
In particular, if you are merging into an interpolating node, the node is expanded and inlined now:

In [4]: cfg = OmegaConf.create({"a": {"b": 10, "c": 20}, "z": "${a}"}) In [5]: cfg Out[5]: {'a': {'b': 10, 'c': 20}, 'z': '${a}'} In [6]: OmegaConf.merge(cfg, {"z": {"d": 30}}) Out[6]: {'a': {'b': 10, 'c': 20}, 'z': {'b': 10, 'c': 20, 'd': 30}}

In particular, if you are merging into an interpolating node, the node is expanded and inlined now:

I guess people deserve it to work the same way:

OmegaConf.register_new_resolver( "make", lambda _parent_: OmegaConf.create({"b": 10, "c": 20}, parent=_parent_), replace=True) cfg = OmegaConf.create({"z": "${make:}"}) OmegaConf.merge(cfg, {"z": {"d": 30}}) # {'z': {'b': 10, 'c': 20, 'd': 30}}

Great, can you add a test covering this?

Done in e87784c (I also rebased on top of master)

tests/interpolation/built_in_resolvers/test_dict.py

omry

Went through it except the tests.

Some requests/questions inline.
Also, while playing with it, I found a bug:

from omegaconf import OmegaConf

cfg = OmegaConf.create(
    {
        "a": {
            "b": {
                "x1": 10,
            },
            "abs_key": "${oc.dict.values:a.b}",
            "abs_dc": "${oc.dict.values:${a.b}}",
            # "relative_key": "${oc.dict.values:.b}",  # this one is breaking
            "relative_dc": "${oc.dict.values:${.b}}",
        },
        "abs_key": "${oc.dict.values:a.b}",
        "abs_dc": "${oc.dict.values:${a.b}}",
        "relative_key": "${oc.dict.values:.a.b}",
        "relative_dc": "${oc.dict.values:${.a.b}}",
    }
)
print("=== unresolved\n\n", OmegaConf.to_yaml(cfg))
print("=== resolved\n\n", OmegaConf.to_yaml(cfg, resolve=True))

omegaconf/built_in_resolvers.py

omry · 2021-03-31T22:33:51Z

omegaconf/built_in_resolvers.py

+        dict_key: Optional[str] = None
+        if in_dict._get_root() is _root_:
+            # Try to obtain the full key through which we can access `in_dict`.
+            if in_dict is _root_:
+                dict_key = ""
+            else:
+                dict_key = in_dict._get_full_key(None)
+                if dict_key:
+                    dict_key += "."  # append dot for future concatenation
+                else:
+                    # This can happen e.g. if `in_dict` is a transient node.
+                    dict_key = None


I think the root check is actually not enough.
We want two things:

The root of the input DictConfig is the same as our root.

Each node along the path is a child of it's parent.

cfg = OmegaConf.create({}) fake_child = OmegaConf.create({}, parent=cfg)

Even though fake_child is in the same root, an interpolation into fake_child is not possible.

I think we want to ensure that OmegaConf.select(root, dict_key) is indeed able to select the in_dict object.
If this succeeds, we don't even need to validate that it's the same root - it goes without saying.

Maybe this is all you need:

dict_key = in_dict._get_full_key(None) if OmegaConf.select(_root_, dict_key) is not in_dict: # error

cfg = OmegaConf.create({}) fake_child = OmegaConf.create({}, parent=cfg)

Even though fake_child is in the same root, an interpolation into fake_child is not possible.

But here fake_child._get_full_key(None) is equal to "" so it's properly detected as invalid.
I guess someone could create a fake child with a fake key as well, that couldn't be obtained from the parent, but at this point I think it's fair for some stuff to break.

OmegaConf.select(_root_, dict_key) is not in_dict wouldn't actually work for dynamically generated DictConfigs (in addition to add extra overhead). See the test test_dict_values_dictconfig_resolver_output for what I mean by that.

But here fake_child._get_full_key(None) is equal to "" so it's properly detected as invalid.
I guess someone could create a fake child with a fake key as well, that couldn't be obtained from the parent, but at this point I think it's fair for some stuff to break.

It could also be a real node incorrectly reused by changing it's parent without copying it (leaving the whole config broken).

OmegaConf.select(root, dict_key) is not in_dict wouldn't actually work for dynamically generated DictConfigs (in addition to add extra overhead). See the test test_dict_values_dictconfig_resolver_output for what I mean by that.

Yes. It won't. and I think we should not support them now.
Select is just calling _get_node(key) iteratively with fragments of the key, it should be very efficient. (we only need to validate the input node, not all the generated interpolation nodes).

Select is just calling _get_node(key) iteratively with fragments of the key, it should be very efficient. (we only need to validate the input node, not all the generated interpolation nodes).

Just flagging that select() still has to resolve interpolations along the way (if any).

Maybe if we only support the "select" syntax, i.e. ${oc.dict.values:abc.def}, then it will be easier since we directly know the correct path.

Should be solved now with 27e59f8 (and companion commit 5a1f49c)

omegaconf/built_in_resolvers.py

docs/source/usage.rst

omry · 2021-03-31T22:45:04Z

omegaconf/base.py

+                # The interpolation is returning a transient (key-less) node attached
+                # to the current parent. By setting its key to this node's key, we make
+                # it possible to refer to it through an interpolation path.
+                resolved._set_key(value._key())


When resolving an interpolation key and walking up the hierarchy, it is not enough that a node knows is key in the parent container.
the node should actually be in the _content_ of the parent (ListConfig or DictConfig).
I don't think this is actually achieving the goal (and I don't think this is actually a goal of this PR, I thought we agreed that we only support real DictConfig objects in oc.dict.{list,values}.

It's working for the use case I wanted to support, which is the one in test_dict_values_dictconfig_resolver_output().
We agreed not to support DictConfig objects that couldn't be accessed through interpolations. The specific change you quoted makes it possible to access dynamically generated DictConfig objects through interpolations.

Edit: re-reading what I wrote, that last sentence can be confusing / misleading. A better version (I think) would be: "The specific change you quoted makes it possible for resolvers like oc.dict.values to know which full key to use to access dynamically generated input nodes through interpolations".

Okay. I will take a closer look at this test to form an opinion (could be a few days).
Hold with any changes for now.

Should also be resolved by 27e59f8

omry · 2021-03-31T23:23:25Z

omegaconf/built_in_resolvers.py

+        if in_dict is _DEFAULT_SELECT_MARKER_:
+            raise ConfigKeyError(f"Key not found: '{key}'")
+
+    if not isinstance(in_dict, Mapping):


If we limit to DictConfig nodes, don't forget to change this.

That was done in 27e59f8

tests/interpolation/built_in_resolvers/test_dict.py

odelalleau · 2021-04-01T01:02:09Z

Also, while playing with it, I found a bug:
(...)

I didn't think of relative interpolations with select(). I think there's probably indeed a bug because I'm calling select(root, ...) while it should be on the parent if we want relative interpolations to work.

That being said, I couldn't get relative interpolations to work with select() at all (outside of this resolver). The following code snippet works without crashing, but (1) I would have liked at least one of these select() to actually find the node .b, and (2) I would have liked the return value to be 0 when not finding it. So it seems like select() doesn't work right now for relative interpolations (unless I'm missing something)

from omegaconf import OmegaConf

cfg = OmegaConf.create({"a": {"b": 0}, "b": 1})

assert OmegaConf.select(cfg, ".b", default=0) is None
assert OmegaConf.select(cfg.a, ".b", default=0) is None
assert OmegaConf.select(cfg._get_node("a"), ".b", default=0) is None

odelalleau · 2021-04-01T02:30:23Z

That being said, I couldn't get relative interpolations to work with select() at all (outside of this resolver).

So, for now I just explicitly removed support for relative interpolations with the select syntax (see f52dbeb). We can revisit once select() works with them.

omry · 2021-04-01T20:17:58Z

I looked at test_dict_values_dictconfig_resolver_output.
Generally speaking, I don't want to push the envelop too far with support for transient config nodes (dynamically generated).

I think oc.dict.values() should support only permanent config nodes in the same config tree.
A way to detect them is to walk up the parent hierarchy and test that each parent contains the key of the node.
This is an alternative approach to using _get_full_key() + select, which is doing something similar to generate the full key.
Something like:

from omegaconf import OmegaConf, Node, DictConfig, Container

cfg = OmegaConf.create(({"a": {"b": 10}}))


def is_permanent_member_of(node: Node, root: Container) -> bool:
    if node is root:
        return True

    parent = node._get_parent()
    if parent is None:
        return False

    node_in_parent = parent._get_node(
        node._key(),
        throw_on_missing_value=False,
        throw_on_missing_key=False,
        validate_access=False,
    )

    if node_in_parent is not node:
        return False

    # could also be implemented iteratively.
    return is_permanent_member_of(parent, root)


# positive cases
assert is_permanent_member_of(cfg, root=cfg)
assert is_permanent_member_of(cfg.a, root=cfg)
assert is_permanent_member_of(cfg.a._get_node("b"), root=cfg)

# negative cases
assert not is_permanent_member_of(DictConfig(content={}), root=cfg)
assert not is_permanent_member_of(DictConfig(content={}, parent=cfg), root=cfg)
assert not is_permanent_member_of(DictConfig(content={}, parent=cfg.a), root=cfg)

As for the select bug, see #656.

odelalleau · 2021-04-02T20:40:46Z

I think oc.dict.values() should support only permanent config nodes in the same config tree.

Ok, I'll change it in the next few days.

odelalleau · 2021-04-07T15:14:26Z

This is still a WIP but @omry can you please have a look at 27e59f8 to tell me if you agree with the direction?
The main idea is to support only the "select" syntax, i.e. ${oc.dict.keys/values: abc.def} instead of ${oc.dict.keys/values: ${abc.def}}. This makes the code simpler and there is no confusion regarding the differences between the two syntaxes.

I'll just wait for your green light before updating the tests & documentation.
(current implementation might not be working 100% since I haven't updated the tests yet)

omry · 2021-04-07T23:52:10Z

This is still a WIP but @omry can you please have a look at 27e59f8 to tell me if you agree with the direction?
The main idea is to support only the "select" syntax, i.e. ${oc.dict.keys/values: abc.def} instead of ${oc.dict.keys/values: ${abc.def}}. This makes the code simpler and there is no confusion regarding the differences between the two syntaxes.

I'll just wait for your green light before updating the tests & documentation.

I think that's a good idea.
It cuts right through the Gordian knot we got ourselves into by trying to support so many different kinds of inputs.

odelalleau · 2021-04-08T15:36:18Z

This is still a WIP but @omry can you please have a look at 27e59f8 to tell me if you agree with the direction?
The main idea is to support only the "select" syntax, i.e. ${oc.dict.keys/values: abc.def} instead of ${oc.dict.keys/values: ${abc.def}}. This makes the code simpler and there is no confusion regarding the differences between the two syntaxes.
I'll just wait for your green light before updating the tests & documentation.

I think that's a good idea.
It cuts right through the Gordian knot we got ourselves into by trying to support so many different kinds of inputs.

Alright done in 5a1f49c
(NB: I kept the test accessing the config root in spite of other discussions towards forbidding it, because right now it is working, but it'll be ok to break it later if we don't want to support it anymore)

omry

Looking good. a few nits about docs and news fragment.

omry · 2021-04-09T23:06:52Z

docs/source/usage.rst

+Some config options that are stored as a ``DictConfig`` may sometimes be easier to manipulate as lists,
+when we care only about the keys or the associated values.
+
+The resolvers ``oc.dict.keys`` and ``oc.dict.values`` simplify such operations by extracting respectively


Extracting sounds like it's creating a new list.
Maybe something along the lines of "by offering an alternative view of a dictionary's keys or values as a list"

Extracting sounds like it's creating a new list.

It is creating a new list.

Maybe something along the lines of "by offering an alternative view of a dictionary's keys or values as a list"

Done in 70e61fc

omry · 2021-04-09T23:10:06Z

news/643.feature

+New resolvers `oc.dict.keys` and `oc.dict.values` allow extracting the lists of keys and values of config nodes
+


Suggested change

New resolvers `oc.dict.keys` and `oc.dict.values` allow extracting the lists of keys and values of config nodes

New resolvers `oc.dict.keys` and `oc.dict.values` provides a list view of the keys or values or a DictConfig node.

Done in 8a65897 (up to minor typo fixes)

omry · 2021-04-09T23:14:55Z

omegaconf/built_in_resolvers.py

+import os
+import warnings
+from typing import Any, List, Optional


In retrospect, it would have been better to make the refactoring a standalone pull request.
With so much moved code, it makes it hard to review.

Yeah, it was initially meant to be a very simple PR easily reviewed by individual commits... I should have cleaned it up when it started getting more complex.
To make it easier I rebased to have the two refactoring commits as the first two commits, and I created a dummy PR on my fork where you can see the diff without these refactoring commits: https://github.com/odelalleau/omegaconf/pull/8/files

omry · 2021-04-09T23:16:46Z

omegaconf/built_in_resolvers.py

+def dict_keys(
+    key: str,
+    _parent_: Container,
+) -> ListConfig:
+    assert isinstance(_parent_, BaseContainer)
+
+    in_dict = _get_and_validate_dict_input(
+        key, parent=_parent_, resolver_name="oc.dict.keys"
+    )
+
+    ret = OmegaConf.create(list(in_dict.keys()), parent=_parent_)
+    assert isinstance(ret, ListConfig)
+    return ret
+
+
+def dict_values(key: str, _root_: BaseContainer, _parent_: Container) -> ListConfig:
+    assert isinstance(_parent_, BaseContainer)
+    in_dict = _get_and_validate_dict_input(
+        key, parent=_parent_, resolver_name="oc.dict.values"
+    )
+
+    content = in_dict._content
+    assert isinstance(content, dict)
+
+    ret = ListConfig([])
+    for k, node in content.items():
+        ref_node = AnyNode(f"${{{key}.{k}}}")
+        ret.append(ref_node)
+
+    # Finalize result by setting proper type and parent.
+    element_type: Any = in_dict._metadata.element_type
+    ret._metadata.element_type = element_type
+    ret._metadata.ref_type = List[element_type]
+    ret._set_parent(_parent_)
+
+    return ret


Great, so much simpler.

Looking at it again, there was one more simplification to do: ccba9b8

lgtm-com · 2021-04-10T13:28:29Z

This pull request introduces 1 alert when merging ccba9b8 into e1a599f - view on LGTM.com

new alerts:

1 for Unused import

No functional change

Fixes omry#643

* Can now take a string as input for convenience * The output is always a ListConfig, whose parent is the parent of the node being processed

Of particular note: * When the result of an interpolation is a node whose parent is the current node's parent, but has no key, then we set its key to the current node's key. This makes it possible to use its full key as an identifier. * _get_and_validate_dict_input() now properly raises an exception if the desired key does not exist

Co-authored-by: Omry Yadan <omry@fb.com>

Plus some additional code clean-up.

omry

shipit!

odelalleau requested a review from omry March 24, 2021 20:14

omry reviewed Mar 24, 2021

View reviewed changes

docs/source/usage.rst Outdated Show resolved Hide resolved

omegaconf/built_in_resolvers.py Outdated Show resolved Hide resolved

odelalleau mentioned this pull request Mar 24, 2021

Follow-up plan regarding changes to resolvers #535

Closed

22 tasks

omry requested changes Mar 25, 2021

View reviewed changes

odelalleau requested a review from omry March 25, 2021 02:27

omry reviewed Mar 25, 2021

View reviewed changes

tests/interpolation/built_in_resolvers/test_dict.py Outdated Show resolved Hide resolved

odelalleau force-pushed the dict_keys_values branch from 0cc68f2 to 2e604f9 Compare March 29, 2021 15:41

odelalleau requested a review from omry March 29, 2021 15:54

odelalleau force-pushed the dict_keys_values branch from 388f52a to e87784c Compare March 30, 2021 12:06

omry requested changes Mar 31, 2021

View reviewed changes

odelalleau marked this pull request as draft April 2, 2021 20:40

odelalleau force-pushed the dict_keys_values branch 2 times, most recently from 988c238 to 27e59f8 Compare April 7, 2021 15:12

odelalleau marked this pull request as ready for review April 8, 2021 15:36

odelalleau requested a review from omry April 8, 2021 15:36

omry requested changes Apr 9, 2021

View reviewed changes

odelalleau force-pushed the dict_keys_values branch 2 times, most recently from 5f51751 to fe3a692 Compare April 10, 2021 13:15

odelalleau and others added 19 commits April 10, 2021 09:33

Refactor: move built-in resolvers to built_in_resolvers.py

80371a6

No functional change

Refactor: move functions around in built_in_resolvers.py

afb7f8d

No functional change

Add new resolvers oc.dict.keys and oc.dict.values

3d77807

Fixes omry#643

Improvements to oc.dict.{keys,values}

aa49502

* Can now take a string as input for convenience * The output is always a ListConfig, whose parent is the parent of the node being processed

Un-factorize some code

5024744

Add tests for missing values

34a33b3

Clarify comments in doc

62e0bd4

Refactor some tests

19954b5

More tests refactoring

5fc2630

Add test for merging into a resolver's output

26b2372

Update omegaconf/built_in_resolvers.py

890017c

Co-authored-by: Omry Yadan <omry@fb.com>

Update doc to show interpolations for oc.dict.values

89496b0

Clearer error when trying to use a relative interpolation

b0fadcd

Only support the select syntax in oc.dict.{keys,values}

7541343

Update tests and documentation

ce794a6

Plus some additional code clean-up.

Update doc

5692ed9

Update news item

517b852

Small code simplification

d1a4ef7

odelalleau force-pushed the dict_keys_values branch from ccba9b8 to d1a4ef7 Compare April 10, 2021 13:33

omry approved these changes Apr 10, 2021

View reviewed changes

omry merged commit 8972c91 into omry:master Apr 11, 2021

		... # Config node name `machines` as input.
		... "ips": "${oc.dict.values:machines}",

		New resolvers `oc.dict.keys` and `oc.dict.values` allow extracting the lists of keys and values of config nodes

Add new resolvers oc.dict.keys and oc.dict.values #644

Add new resolvers oc.dict.keys and oc.dict.values #644

Conversation

odelalleau commented Mar 24, 2021 • edited Loading

odelalleau commented Mar 24, 2021 • edited Loading

omry commented Mar 24, 2021 • edited Loading

odelalleau commented Mar 24, 2021

omry commented Mar 24, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

omry Mar 25, 2021 • edited Loading

Choose a reason for hiding this comment

odelalleau Mar 25, 2021 • edited Loading

Choose a reason for hiding this comment

omry Mar 25, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

odelalleau Mar 29, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

omry left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

odelalleau Apr 1, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

odelalleau Apr 1, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

odelalleau commented Apr 1, 2021

odelalleau commented Apr 1, 2021

omry commented Apr 1, 2021

odelalleau commented Apr 2, 2021

odelalleau commented Apr 7, 2021

omry commented Apr 7, 2021 • edited Loading

odelalleau commented Apr 8, 2021

omry left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

odelalleau Apr 10, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lgtm-com bot commented Apr 10, 2021

omry left a comment

Choose a reason for hiding this comment

Add new resolvers `oc.dict.keys` and `oc.dict.values` #644

Add new resolvers `oc.dict.keys` and `oc.dict.values` #644

odelalleau commented Mar 24, 2021 •

edited

Loading

odelalleau commented Mar 24, 2021 •

edited

Loading

omry commented Mar 24, 2021 •

edited

Loading

omry Mar 25, 2021 •

edited

Loading

odelalleau Mar 25, 2021 •

edited

Loading

omry Mar 25, 2021 •

edited

Loading

odelalleau Mar 29, 2021 •

edited

Loading

odelalleau Apr 1, 2021 •

edited

Loading

odelalleau Apr 1, 2021 •

edited

Loading

omry commented Apr 7, 2021 •

edited

Loading

odelalleau Apr 10, 2021 •

edited

Loading