[Yaml] Add tags support #21194

GuilhemN · 2017-01-07T13:47:29Z

Q	A
Branch?	master
Bug fix?	no
New feature?	yes
BC breaks?	no
Deprecations?	yes
Tests pass?	yes
Fixed tickets	#21185
License	MIT
Doc PR

This PR adds custom tags support to the Yaml component.
Symfony tags (!!binary, !str, etc.) are still managed in the parser to have a lighter diff but we'll be able to convert them later if we want to.

The primary addition of this PR is the TagInterface:

interface TagInterface
{
    public function construct(mixed $value): mixed;
}

It can be used to register custom tags. An example that could be used to convert the syntax =iterator to a tag:

final class IteratorTag implements TagInterface
{
    public function construct(mixed $value): mixed
    {
        return new IteratorArgument($value);
    }
}

$parser = new Parser(['iterator' => new IteratorTag()]);

If you think this is too complex, @nicolas-grekas proposed an alternative to my proposal externalizing this support by introducing a new class TaggedValue.

nicolas-grekas · 2017-01-07T16:11:13Z

Note that the simpler TaggedValue proposal is still compatible with having the Yaml component hydrate things. It would just require a separate class whose responsibility would be solely to hydrate the TaggedValue objects to something else. This would remove this responsibility from the Yaml parser classes, which looks like a good idea to me.

sh4ka · 2017-01-09T10:53:17Z

src/Symfony/Component/Yaml/Inline.php

        }
+
+        if (null !== self::$tagResolver && $scalar && '!' === $scalar[0]) {


I am not a particular big fan of putting conditions like '&& $scalar' because it takes away some readability. There are a lot of ways of validating '$scalar' (empty(), is_null(), etc...) instead of making me believe (at first sight) that it is a boolean.

In fact we can just remove it, this case is already managed earlier. Thanks!

sh4ka · 2017-01-09T11:27:26Z

src/Symfony/Component/Yaml/Tag/TagResolver.php

+{
+    private $tags = array();
+
+    public function addTag(TagInterface $tag, $priority = 0)


Could be a good idea to add some phpDoc about the parameters here.

sh4ka · 2017-01-09T11:32:00Z

src/Symfony/Component/Yaml/Tag/TagResolver.php

+
+    private function prefixTag($tag)
+    {
+        if ($tag && '!' === $tag[0]) {


Is $tag a bool? If you validate $tag and it is a string I think it makes more sense to use any of the available methods just for improved readability.

nicolas-grekas

Would be great to leverage this for DI =iterator & =closure-proxy in the same PR so that we can juge on an actual use case.

nicolas-grekas · 2017-01-09T13:38:45Z

src/Symfony/Component/Yaml/Exception/UnsupportedTagException.php

+/**
+ * @author Guilhem N. <egetick@gmail.com>
+ *
+ * @internal


not sure this should be internal

It should be part of the api in 4.0 but as it never ends in userland for now, making it internal allows us to change its name (or maybe just remove it in favor of a simple ParseException?).

nicolas-grekas · 2017-01-09T13:41:54Z

src/Symfony/Component/Yaml/Inline.php

+            try {
+                return self::$tagResolver->resolve($scalar, $tag);
+            } catch (UnsupportedTagException $e) {
+                // Ignored for bc


we should trigger a deprecation here

As I removed the exception in the last commit (and its catch), I think we can do it later to focus on the feature.

nicolas-grekas · 2017-01-09T13:42:33Z

src/Symfony/Component/Yaml/Parser.php

@@ -44,6 +48,16 @@ public function __construct($offset = 0, $totalNumberOfLines = null, array $skip
        $this->offset = $offset;
        $this->totalNumberOfLines = $totalNumberOfLines;
        $this->skippedLineNumbers = $skippedLineNumbers;
+        $this->tagResolver = new TagResolver();


make this a constructor argument instead? (default null, no need for any instance when not using tags)

see #21194 (comment)

nicolas-grekas · 2017-01-09T13:42:59Z

src/Symfony/Component/Yaml/Parser.php

+     * @param TagInterface $tag
+     * @param int          $priority
+     */
+    public function addTag(TagInterface $tag, $priority = 0)


no need for this method, requiring a tagResolver as constructor is enough imho

It looked complicated to use to me as there are already 3 internal arguments in the constructor (that should be removed imo but not sure we can do that because of bc).
People would be forced to do new Parser(0, null, array(), new TagResolver());.

Understood, then w know how to make that the first arg: with a BC layer

nicolas-grekas · 2017-01-09T13:43:15Z

src/Symfony/Component/Yaml/Parser.php

+        try {
+            return $this->doParse($value, $flags);
+        } finally {
+            Inline::$tagResolver = null;


this should be restored to the previous value of Inline::$tagResolver

woudln't it be better to pass it as argument instead of forcing to maintain some state externally ?

@nicolas-grekas this is only done for bc (Inline wasn't internal in 3.0) but it must not be used in userland so I think it's fine to always remove the previous value.

@stof it is following this. I think it would be better to instantiate Inline and pass the TagResolver as a constructor argument, wdyt?

nicolas-grekas · 2017-01-09T13:43:47Z

src/Symfony/Component/Yaml/Parser.php

+                try {
+                    return $this->tagResolver->resolve($data, $tag);
+                } catch (UnsupportedTagException $e) {
+                    // ignored for bc


deprecation

nicolas-grekas · 2017-01-09T13:55:05Z

src/Symfony/Component/Yaml/Tag/TagResolver.php

+ *
+ * @internal
+ */
+final class TagResolver


looking at this closer, we might not need it: we could simply feed Yaml\Parser with an associative array of tags-to-tagresolvers:
new Parser(..., ..., array('iterator' => new IteratorTagResolver()) (prefix excluded, or auto added)

we don't need to handle the "priority" + "supports()" logic, it just adds complixity to me, no flexibility

@nicolas-grekas imo #21194 (comment) is a big locker in using a constructor argument. I'll submit a PR to see if we can do something about it.

we don't need to handle the "priority" + "supports()" logic, it just adds complixity to me, no flexibility

It could be useful to allow implicit tags (foo becoming !bar foo for example, based on regexes and on its path) but I'm not sure this is very useful in userland so will try :)

nicolas-grekas · 2017-01-10T19:19:36Z

src/Symfony/Component/Yaml/Parser.php

+                $tagName = '!'.substr($tagName, 18);
+            }
+
+            $this->tags[$tagName] = $tag;


Should we check that $tag has the required interface?

That should indeed be safer

nicolas-grekas · 2017-01-10T20:24:26Z

src/Symfony/Component/Yaml/Parser.php

+
+        foreach ($tags as $tagName => $tag) {
+            if (!$tag instanceof TagInterface) {
+                throw new \InvalidArgumentException(sprintf('Expected tag of type "%s", given "%s".', TagInterface::class, get_class($tag) ?: gettype($tag)));


get_class triggers a warning when given a non-object

good catch, thanks !

GuilhemN · 2017-01-11T20:27:08Z

Should I add mappings/sequences support here to be able to implement !iterator or do you prefer me to do it later in another PR?

fabpot · 2017-01-11T20:40:43Z

It would be good to have support in this PR I think.

nicolas-grekas · 2017-01-11T20:46:26Z

UPGRADE-4.0.md

 * The default value of the strict option of the `Choice` Constraint has been
-   changed to `true` as of 4.0. If you need the the previous behaviour ensure to 
+   changed to `true` as of 4.0. If you need the the previous behaviour ensure to


Double "the" while changing :)

Good catch, but not related ;) see #21250

nicolas-grekas · 2017-01-11T20:53:55Z

src/Symfony/Component/Yaml/Parser.php

+        try {
+            return $this->doParse($value, $flags);
+        } finally {
+            Inline::$tags = array();


Still, when reading this line, I think we should restore to the previous value. I know you explained it's useless, but this requires contextual knowledge, and thus with no guarantee. Better make the code logic local.

Actually you were right, it was creating a bug when entering a block (because of nested parsers).

nicolas-grekas · 2017-01-11T20:58:02Z

src/Symfony/Component/Yaml/Tag/TagInterface.php

+     *
+     * @return mixed
+     */
+    public function construct($value);


I think we should pass $tag and $value, so that one could create a single object to manage several tags if required.
$tag should match the key used when registering if possible (no namespace added/removed).
About "construct' => "createValue"?

This PR was merged into the 3.2 branch. Discussion ---------- Fix a typo | Q | A | ------------- | --- | Branch? | 3.2 | Bug fix? | no | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #21194 (comment) | License | MIT | Doc PR |  Commits ------- 2dcb22e Fix a typo

GuilhemN · 2017-01-12T17:47:46Z

src/Symfony/Component/Yaml/Parser.php

@@ -20,7 +22,7 @@
 */
 class Parser
 {
-    const TAG_PATTERN = '((?P<tag>![\w!.\/:-]+) +)?';
+    const TAG_PATTERN = '!(?P<tag>[\w!.\/:-]+)';


should I create a new constant/inline it instead?

no need imo

nicolas-grekas

Can't wait to see the DI part here also :)

nicolas-grekas · 2017-01-13T09:09:22Z

src/Symfony/Component/Yaml/Parser.php

        $data = array();
        $context = null;
        $allowOverwrite = false;
-        while ($this->moveToNextLine()) {
+
+        if(null !== ($tag = $this->getLineTag($this->currentLine))) {


missing space after if, no need for brackets around assignment

nicolas-grekas · 2017-01-13T09:10:07Z

src/Symfony/Component/Yaml/Parser.php

@@ -129,6 +174,15 @@ public function parse($value, $flags = 0)
                // array
                if (!isset($values['value']) || '' == trim($values['value'], ' ') || 0 === strpos(ltrim($values['value'], ' '), '#')) {
                    $data[] = $this->parseBlock($this->getRealCurrentLineNb() + 1, $this->getNextEmbedBlock(null, true), $flags);
+                } elseif (null !== ($subTag = $this->getLineTag(ltrim($values['value'], ' ')))) {


no need for brackets

nicolas-grekas · 2017-01-13T09:10:33Z

src/Symfony/Component/Yaml/Parser.php

                if ($mergeNode) {
                    // Merge keys
-                } elseif (!isset($values['value']) || '' == trim($values['value'], ' ') || 0 === strpos(ltrim($values['value'], ' '), '#')) {
+                } elseif (!isset($values['value']) || '' == trim($values['value'], ' ') || 0 === strpos(ltrim($values['value'], ' '), '#') || null !== ($subTag = $this->getLineTag(ltrim($values['value'], ' ')))) {


nicolas-grekas · 2017-01-13T09:14:03Z

src/Symfony/Component/Yaml/Parser.php

+
+    private function getLineTag($value)
+    {
+        if ('' === $value || '!' !== $value[0] || 1 !== preg_match('/^'.self::TAG_PATTERN.' *( +#.*)?$/', $value, $matches)) {


"m" modifier missing?

Values passed to this function do not contain newlines, so no need for "m".

nicolas-grekas · 2017-01-13T09:15:01Z

src/Symfony/Component/Yaml/Tag/TagInterface.php

+{
+    /**
+     * @param mixed  $value
+     * @param string $tag the tag name used to register the tag


The + missing alignment (The should start one space after $value, isn't it?)

GuilhemN · 2017-01-13T11:30:52Z

@nicolas-grekas thanks, i'll fix your comments this evening.
I'm locking on the inline part for now and also on how to dump objects, should we add supportsDump/normalize methods to dump DI iterators? We could also dump iterators as simple arrays but that's a bit annoying.

GuilhemN · 2017-01-13T20:11:11Z

Last commits added inline support (!foo {quz: bar}), a IteratorTag in the DependencyInjection component and a way to dump tags (DumpableTagInterface) because of DI YamlDumper.

Fabbot failure is normal (the current yaml parser can't parse the updated yaml files).

nicolas-grekas · 2017-01-14T13:22:29Z

src/Symfony/Component/DependencyInjection/Loader/Tag/IteratorTag.php

+ *
+ * @internal
+ */
+final class IteratorTag implements TagInterface, DumpableTagInterface


there is also "=closure_proxy" which could benefit from yaml tags.
which means we could have only one class - eg "ArgumentTag" for the DI component, able to deal with all tags it'll need to support (these 2 today and more in the future, no forward compat issue here)

nicolas-grekas · 2017-01-15T07:54:23Z

src/Symfony/Component/DependencyInjection/Dumper/YamlDumper.php

-            $value = array('=iterator' => $value->getValues());
-        } elseif ($value instanceof ClosureProxyArgument) {
-            $value = array('=closure_proxy' => $value->getValues());
+        if ($value instanceof IteratorArgument || $value instanceof ClosureProxyArgument) {


instanceof ArgumentInterface?

we don't know the tag corresponding to other instances so I think it's better this way here.

nicolas-grekas · 2017-01-15T07:55:14Z

src/Symfony/Component/DependencyInjection/Loader/Tag/ArgumentTag.php

+ *
+ * @internal
+ */
+final class ArgumentTag implements TagInterface, DumpableTagInterface


no need for final, especially if @internal

nicolas-grekas · 2017-01-15T07:57:17Z

src/Symfony/Component/DependencyInjection/Loader/Tag/ArgumentTag.php

+            return new IteratorArgument($value);
+        }
+
+        if (!is_array($value) || array(0, 1) !== array_keys($value) || !is_string($value[0]) || !is_string($value[1]) || 0 !== strpos($value[0], '@') || 0 === strpos($value[0], '@@')) {


to be safe and explicit, this should be in an if ('closure_proxy' === $tag) { block, and the method should throw otherwise

nicolas-grekas · 2017-01-15T08:07:18Z

src/Symfony/Component/DependencyInjection/Dumper/YamlDumper.php

-            $value = array('=closure_proxy' => $value->getValues());
+        if ($value instanceof IteratorArgument || $value instanceof ClosureProxyArgument) {
+            $argument = clone $value;
+            $argument->setValues($this->dumpValue($argument->getValues()));


this looks like a code smell to me:
this creates an instance of IteratorArgument that is filled with a non usable state. Let's imagine that "setValues" does some validation, which it could very well do - that would make the current design fail.
I think we need a more robust design here, that preserves the semantic of objects.

I'm sure there are ways to fix this with the current design.
I still think the "TaggedValue" proposal could be a good idea to try :)

nicolas-grekas · 2017-01-16T09:22:14Z

src/Symfony/Component/Yaml/Yaml.php

@@ -29,6 +29,7 @@ class Yaml
    const DUMP_OBJECT_AS_MAP = 64;
    const DUMP_MULTI_LINE_LITERAL_BLOCK = 128;
    const PARSE_CONSTANT = 256;
+    const PARSE_CUSTOM_TAGS = 512;


PARSE_TAGGED_VALUE?

I wonder if people won't think that built-in tags are also converted to a TaggedValue with this name. Wdyt?

OK for me, keep as is

xabbuh · 2017-01-18T20:26:53Z

src/Symfony/Component/Yaml/Inline.php

+                        @trigger_error(sprintf('Using the unquoted scalar value "%s" is deprecated since version 3.3 and will be considered as a tagged value in 4.0. You must quote it.', $scalar), E_USER_DEPRECATED);
+                }
+
+            // Optimise for returning strings.


xabbuh · 2017-01-18T20:59:45Z

src/Symfony/Component/Yaml/Parser.php

-        $this->totalNumberOfLines = $totalNumberOfLines;
-        $this->skippedLineNumbers = $skippedLineNumbers;
+        if (func_num_args() > 0) {
+            @trigger_error(sprintf('Constructor arguments $offset, $totalNumberOfLines, $skippedLineNumbers of %s are deprecated and will be removed in 4.0', self::class), E_USER_DEPRECATED);


I agree that this deprecation makes sense. But this PR is already quite big and this change is not really related to the ability to parse YAML tags. Couldn't we move this to a new PR instead?

It is equal to me but I can reopen #21230 if you prefer.

xabbuh · 2017-01-18T21:02:05Z

src/Symfony/Component/Yaml/Tag/TaggedValue.php

+     * @param mixed  $value
+     * @param string $tag
+     */
+    public function __construct($value, $tag)


What about swapping arguments. IMO we usally have key/value pairs, but not value/key pairs.

I personally see the tag as a complement of the value, not as the key; a value could be represented without a tag (a simple plain value).

I felt the same also - swapping would be my preference.

xabbuh · 2017-01-18T21:04:35Z

src/Symfony/Component/Yaml/Tests/ParserTest.php

+                <<<YAML
+- !foo
+    - yaml
+- !!quz [bar]


Tags starting with two exclamation marks are tags defined by the YAML spec. I do not think we should support them through a flag that indicates to parse custom tags (and if we want to parse built-in tags, we will have to validate their names IMO).

should we throw an exception then?

I agree with @xabbuh - we need to keep BC of course

xabbuh · 2017-01-18T21:17:01Z

src/Symfony/Component/Yaml/Inline.php

+        $nextOffset += strspn($value, ' ', $nextOffset);
+
+        // Is followed by a scalar
+        if (!isset($value[$nextOffset]) || !in_array($value[$nextOffset], array('[', '{'))) {


Pass true as the third argument?

xabbuh · 2017-01-18T21:24:13Z

src/Symfony/Component/Yaml/Inline.php

+            return;
+        }
+
+        if ($flags & Yaml::PARSE_CUSTOM_TAGS) {


everywhere else it's the other way around: YAML::PARSE_CUSTOM_TAGS & $flags

xabbuh · 2017-01-18T21:26:06Z

src/Symfony/Component/Yaml/Inline.php

@@ -107,6 +109,10 @@ public static function parse($value, $flags = 0, $references = array())
                $result = self::parseScalar($value, $flags, null, $i, true, $references);


Is it safe to assume that we can always evaluate the scalar even when we are parsing the value of a tag?

@xabbuh tags aren't supported on scalars yet anyway but updated to make sure we don't forget it in 4.0. thanks!

@xabbuh

This PR was squashed before being merged into the 3.3-dev branch (closes #21350). Discussion ---------- [Yaml] Remove internal arguments from the api | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | no | BC breaks? | no | Deprecations? | yes | Tests pass? | yes | Fixed tickets | #21230 | License | MIT | Doc PR | Reopening of #21230 because of [@xabbuh's comment](#21194 (comment)). > This PR removes internal constructor arguments of the `Parser` class. > This should break nothing as they are only used to build errors message and are clearly meant for internal uses. > > This would allow to have a nicer api for #21194 (comment). Commits ------- ebae4ff [Yaml] Remove internal arguments from the api

nicolas-grekas · 2017-02-06T11:51:03Z

rebase needed

xabbuh · 2017-02-09T15:47:26Z

I think we should flag the feature as experimental. @GuilhemN Can you do that?

GuilhemN · 2017-02-09T16:34:56Z

@xabbuh done.

xabbuh

👍

Status: Reviewed

nicolas-grekas · 2017-02-10T14:55:05Z

Thank you @GuilhemN.

carsonbot added Status: Needs Review Yaml Feature labels Jan 7, 2017

GuilhemN force-pushed the TAGS2 branch from 5951921 to deef108 Compare January 8, 2017 10:23

sh4ka reviewed Jan 9, 2017

View reviewed changes

GuilhemN force-pushed the TAGS2 branch from deef108 to a29789e Compare January 9, 2017 11:00

sh4ka reviewed Jan 9, 2017

View reviewed changes

GuilhemN force-pushed the TAGS2 branch from a29789e to 1a00dc3 Compare January 9, 2017 11:42

nicolas-grekas reviewed Jan 9, 2017

View reviewed changes

nicolas-grekas added this to the 3.3 milestone Jan 10, 2017

nicolas-grekas added Status: Needs Work and removed Status: Needs Review labels Jan 10, 2017

GuilhemN mentioned this pull request Jan 10, 2017

[Yaml] Remove internal arguments from the api #21230

Closed

GuilhemN force-pushed the TAGS2 branch from 54beb0b to 05f2bf3 Compare January 10, 2017 18:45

nicolas-grekas reviewed Jan 10, 2017

View reviewed changes

nicolas-grekas reviewed Jan 11, 2017

View reviewed changes

GuilhemN mentioned this pull request Jan 12, 2017

Fix a typo #21250

Merged

GuilhemN commented Jan 12, 2017

View reviewed changes

nicolas-grekas reviewed Jan 13, 2017

View reviewed changes

GuilhemN force-pushed the TAGS2 branch from 7a1c803 to 2c0f572 Compare January 13, 2017 20:07

nicolas-grekas reviewed Jan 14, 2017

View reviewed changes

nicolas-grekas requested changes Jan 15, 2017

View reviewed changes

GuilhemN force-pushed the TAGS2 branch from a189478 to 851f7e2 Compare January 15, 2017 19:51

nicolas-grekas reviewed Jan 16, 2017

View reviewed changes

xabbuh reviewed Jan 18, 2017

View reviewed changes

GuilhemN force-pushed the TAGS2 branch from 0416fb9 to 67c4ee3 Compare January 19, 2017 21:05

GuilhemN mentioned this pull request Jan 19, 2017

[Yaml] Remove internal arguments from the api #21350

Closed

nicolas-grekas mentioned this pull request Feb 1, 2017

[DI] Deprecate underscore-services in YamlFileLoader #21484

Merged

nicolas-grekas mentioned this pull request Feb 6, 2017

[EXPERIMENTAL][DI] Add tail injection for methods + autowiring nicolas-grekas/symfony#11

Closed

[Yaml] Add custom tags support

3bb73c3

GuilhemN force-pushed the TAGS2 branch from 167d6b7 to 3bb73c3 Compare February 6, 2017 17:24

GuilhemN added 2 commits February 6, 2017 18:29

Swap ParsedValue arguments

bf51585

Forbid unsupported built-in tags

24ed20a

Mark as experimental

71ff812

xabbuh approved these changes Feb 10, 2017

View reviewed changes

nicolas-grekas closed this in 5a38804 Feb 10, 2017

GuilhemN deleted the TAGS2 branch February 10, 2017 16:35

javiereguiluz mentioned this pull request Feb 12, 2017

Added support for Yaml tags symfony/symfony-docs#7465

Closed

fabpot mentioned this pull request May 1, 2017

Release v3.3.0-BETA1 #22603

Merged

nicolas-grekas mentioned this pull request Apr 8, 2021

Yaml dumper and parser TaggedValue should be extensible #40743

Closed

		}

		if (null !== self::$tagResolver && $scalar && '!' === $scalar[0]) {

		@@ -107,6 +109,10 @@ public static function parse($value, $flags = 0, $references = array())
		$result = self::parseScalar($value, $flags, null, $i, true, $references);

[Yaml] Add tags support #21194

[Yaml] Add tags support #21194

Conversation

GuilhemN commented Jan 7, 2017 • edited Loading

nicolas-grekas commented Jan 7, 2017 • 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

nicolas-grekas 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

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

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

GuilhemN commented Jan 11, 2017

fabpot commented Jan 11, 2017

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

nicolas-grekas 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

Choose a reason for hiding this comment

GuilhemN commented Jan 13, 2017

GuilhemN commented Jan 13, 2017 • 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

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

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

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

nicolas-grekas commented Feb 6, 2017

xabbuh commented Feb 9, 2017

GuilhemN commented Jan 7, 2017 •

edited

Loading

nicolas-grekas commented Jan 7, 2017 •

edited

Loading

GuilhemN commented Jan 13, 2017 •

edited

Loading