ValidateSetAttribute enhancement: support set values to be dynamically generated from a custom ValidateSetValueGenerator #3784

iSazonov · 2017-05-15T08:18:41Z

Currently ValidateSetAttribute accepts only explicit constants as valid values. This is a significant limitation. Sometimes we need to get valid values dynamically, ex., Azure VMs, logged-on users and so on. The PR add follow possibilities:

pass a custom type (a valid values generator) implementing IValidateSetValuesGenerator interface to get valid values dynamically.
pass a custom type (a valid values generator) derived from CachedValidValuesGeneratorBase abstract class to get valid values dynamically and cache the list to share with other ValidateSetAttribute attributes.

We support valid values generators on PowerShell and C#.

lzybkr · 2017-05-15T17:02:07Z

src/System.Management.Automation/engine/Attributes.cs

+        public ValidateSetAttribute(Type type)
+        {
+            IValidateSetValuesGenerator validValuesGenerator;
+            if (typeof(IValidateSetValuesGenerator).IsAssignableFrom(type))


You can use the as operator.

typeof(class) as IValidateSetValuesGenerator don't work.

lzybkr · 2017-05-15T17:02:44Z

src/System.Management.Automation/engine/Attributes.cs

+            }
+            else
+            {
+                throw PSTraceSource.NewArgumentNullException("validValues");


Cut and paste? I would use ArgumentException and please use the correct parameter name.

I'm somewhat confused that must be reported - thanks for clarify.
Fixed.

lzybkr · 2017-05-15T17:04:47Z

src/System.Management.Automation/engine/Attributes.cs

+                throw PSTraceSource.NewArgumentNullException("validValues");
+            }
+
+            _validValues = validValuesGenerator.GetValidValues().ToArray();


We shouldn't cache the values during construction - the set may change over time.

Also - we may want a way to query other bound parameters from the generator - which would not be possible in the constructor.

I eliminated the caching.

Please clarify - do you say to put validValuesGenerator in a property?

lzybkr · 2017-05-15T17:05:39Z

test/powershell/Language/Classes/Scripting.Classes.Attributes.Tests.ps1

+                    }
+                }
+
+                /// Implement of test IValidateSetValuesGenerator to return Null


This implementation does not return null - it returns an empty list.

Could you help me here?

I recommend learning more about how the yield keyword is implemented under the covers, e.g. this is a good article: http://csharpindepth.com/Articles/Chapter6/IteratorBlockImplementation.aspx

Thanks for useful link!

Test was removed.

lzybkr · 2017-05-15T17:06:17Z

test/powershell/Language/Classes/Scripting.Classes.Attributes.Tests.ps1

@@ -216,3 +218,96 @@ Describe 'Type resolution with attributes' -Tag "CI" {
        }
    }
 }
+
+Describe 'ValidateSet support a dynamically generated set' -Tag "CI" {
+    Context 'C# test' {


You should also provide a test implementing the interface in PowerShell.

Do you have in mind something like?

function Get-TestValidateSet3 { [CmdletBinding()] Param ( [ValidateSet([type]::GetType("GenValuesForParam1"))] $Param1 ) $Param1 }

No - I meant:

class GenValuesFromParam2 : IValidateSetValuesGenerator { ... } ... [ValidateSet([GenValuesFromParam2])] ...

In other words - no Add-Type.

Following sample don't work - the type passed as string to public ValidateSetAttribute(params string[] validValues) constructor - wrong binding 😕 :

class GenValuesForParam2 : System.Management.Automation.IValidateSetValuesGenerator { [System.Collections.Generic.IEnumerable[String]] GetValidValues() { return "Test1","TestString","Test2" } } function Get-TestValidateSet3 { [CmdletBinding()] Param ( [ValidateSet([GenValuesForParam2])] $Param1 ) $Param1 }

lzybkr

One other thought - some of the dynamic sets are expensive to compute, e.g. querying Azure or whatever.

One strategy is to cache the set for some time. Nothing in this design prevents such caching, but it would be better to implement the caching in PowerShell so that third party code can use it easily. Maybe that means adding a CacheExpiration parameter that defaults to 0 - immediate expiration.

Still thinking out loud - the cache maybe belongs in the generator, but maybe we provide some helpers to manage it - perhaps as an abstract base class.

lzybkr · 2017-05-22T04:42:59Z

src/System.Management.Automation/engine/Attributes.cs

+                throw PSTraceSource.NewArgumentException("valuesGeneratorType");
+            }
+
+            _validValues = validValuesGenerator.GetValidValues();


The constructor should just save valuesGeneratorType because we create just one instance of the attribute per use.

For example, if someone added ValidateSet to the Name parameter on Get-VM - you would want the name of each vm whenever you called Get-VM, not the names when you first called Get-VM.

By constructing the instance and getting the values during validation, the set is dynamically generated when tab completion or validation is happening - which only aligns with construction once (for scripts, attributes are constructed at first invocation) or never (for binary cmdlets, attributes are eagerly constructed).

lzybkr · 2017-05-22T04:44:15Z

src/System.Management.Automation/engine/Attributes.cs

@@ -1359,7 +1360,7 @@ public ValidateCountAttribute(int minLength, int maxLength)
    [AttributeUsage(AttributeTargets.Field | AttributeTargets.Property)]
    public sealed class ValidateSetAttribute : ValidateEnumeratedArgumentsAttribute
    {
-        private string[] _validValues;


I think this shouldn't change, and I would add a new read-only property for the Type so you can tell the difference on which constructor was used.

lzybkr · 2017-05-22T04:45:02Z

src/System.Management.Automation/engine/Attributes.cs

@@ -1386,7 +1387,7 @@ public IList<string> ValidValues
        {
            get
            {
-                return _validValues;
+                return _validValues.ToList();


For the dynamic case - this should probably return a new collection every time it's called.

iSazonov · 2017-05-22T15:34:35Z

Still thinking out loud - the cache maybe belongs in the generator, but maybe we provide some helpers to manage it - perhaps as an abstract base class.

Wouldn't that be too intrusive? IValidateSetValuesGenerator looks very powerful.
If we want such cache in the generator it seems we should migrate from IValidateSetValuesGenerator interface to ValidateSetValuesGenerator class and force users to inherite from the class. Maybe we stop on IValidateSetValuesGenerator? Now we have 'generic' caching internally in ValidateSet so maybe we'll leave the users full freedom in IValidateSetValuesGenerator?

lzybkr · 2017-05-23T17:58:43Z

I had feedback in the form of a PR to TabExpansionPlusPlus that caching should be built-in.

iSazonov · 2017-05-23T18:53:21Z

Do you mean that the cache has to work between different ValidateSet instances? With validValuesGeneratorType key?

lzybkr · 2017-05-23T20:07:02Z

Many cmdlets have parameters that are common, e.g. there are 72 commands in AzureRM.Compute that accept -ResourceGroupName.

On my machine, it takes >1s to query the resource group names

So I think a cache that works across ValidateSet instances would be very helpful.

powercode · 2017-05-23T20:32:41Z

@lzybkr

I had feedback in the form of a PR to TabExpansionPlusPlus that caching should be built-in.

It feels almost more often than not that I implement some sort of custom completion caching. But often with less than stellar aging/expiration.

iSazonov · 2017-05-24T15:18:25Z

I had to rebase to get autoloading of helper modules.

Global valid values cache was added. The only question is. I clean up this cache never. Should we add clean-up and where? Although it seems superfluous.

iSazonov · 2017-05-26T15:06:47Z

@lzybkr Could you please continue the code review?

lzybkr

This is starting to look pretty good.

I have a feeling that this will make many folks happy, but it will fall short for others, mostly around wanting access to some context, e.g. the cmdlet or some of the already bound parameters.

Hopefully we can get some feedback one way or the other on the usefulness of this as it is though.

lzybkr · 2017-05-26T17:06:03Z

src/System.Management.Automation/engine/parser/Compiler.cs

@@ -739,7 +739,6 @@ static Compiler()
            s_builtinAttributeGenerator.Add(typeof(ParameterAttribute), NewParameterAttribute);
            s_builtinAttributeGenerator.Add(typeof(OutputTypeAttribute), NewOutputTypeAttribute);
            s_builtinAttributeGenerator.Add(typeof(AliasAttribute), NewAliasAttribute);
-            s_builtinAttributeGenerator.Add(typeof(ValidateSetAttribute), NewValidateSetAttribute);


I don't think this should be removed - it's an important optimization.
I think it should be straight forward to update NewValidateSetAttribute.
If we did remove this line, we'd also want to remove the method as well - this was the only reference.

I temporary removed that to pass tests but I forgot to ask you about that.
Now fixed.

lzybkr · 2017-05-31T18:11:48Z

src/System.Management.Automation/engine/Attributes.cs

+                            null,
+                            Metadata.ValidateSetGeneratedValidValuesListIsEmpty);
+                    }
+                    _validValues = validValuesCacheEntry.validValues;


Is there a good reason to store the values in the field instead of return validValuesCacheEntry.validValues;?

I think it would also be useful to clean up the cache - this could be done with something like Task.Delay(CacheExpiration).ContinueWith(() => validValuesCacheEntry.validValues = null);

This might not seem like a big deal, the collection should typically be small, but sometimes it might be large, so we should make the collection collectible if it's truly going to be used again.

Is there a good reason to store the values in the field instead of return validValuesCacheEntry.validValues; ?

We only use this in SetAsString() for error message. We could use ValidValues if we're not afraid that there will be a cache expiration and a recalculation of ValidValues and that there may be other data in the error message.

Task.Delay(CacheExpiration)

Different attributes can have different CacheExpiration. How can we resolve the problem?

Could you please continue?
It seems we should clean up validValuesCache from expired Entries not validValuesCacheEntry.validValues.

Sorry, I thought I had replied.

I now think CacheExpiration should not be an argument to the attribute because, as you point out, different uses might specify conflicting values. Instead, the generator should own the cache expiration policy, and the attribute should not cache the results from the generator.

I still like the idea of providing an abstract base class that implements a default caching policy - it would be optional for a generator to derive from it.

Can we add this to IValidateSetValuesGenerator interface?

And please comment my "It seems we should clean up validValuesCache from expired Entries (generators) ".

Sure, you could add CacheExpiration to IValidateSetValuesGenerator, but it would be something extra that some generators have no need for.

I agree we should clean up validValuesCache - and ideally, I think that cache is optionally available to generators but not required. This is why I suggested an abstract base class that generators could derive from.

@lzybkr I still don't correct tests however please review my next step - Is that the right direction?

I removed valid values cache and CacheExpiration from ValidateSet attribute, enhance a generator cache (add cleanup - the idea is from CoreFX), add an abstract class for generators with valid values cache support.

@lzybkr Now tests adjusted.

lfshr · 2017-06-01T16:11:46Z

Is this definitely limited to 'binary' cmdlets? Has anyone tested this using a PS declared class?

iSazonov · 2017-06-02T02:55:58Z

@lfshr Scripts is supported - see tests in the PR. We will edit the PR description after completing this work.

lfshr · 2017-06-02T08:37:19Z

@iSazonov absolutely brilliant, v good work! Well done @lzybkr for the solution. (I take full credit for the moan that instigated it 😛)

lzybkr · 2017-06-14T01:07:38Z

src/System.Management.Automation/engine/Attributes.cs

+            if (ValidValuesCacheExpiration > 0)
+            {
+                Task.Delay(ValidValuesCacheExpiration).ContinueWith((task) => _validValues = null);
+                _validValues = _validValuesNoCache;


The parameter to Task.Delay is in milliseconds, not seconds.

Can we consider that the ValidValuesCacheExpiration parameter is in milliseconds and add this in our documentation?

We could, but I think that seconds is a more practical unit for the timeout.

lzybkr · 2017-06-14T01:08:17Z

src/System.Management.Automation/engine/Attributes.cs

+                return _validValues;
+            }
+
+            var _validValuesNoCache = GenerateValidValues();


_validValuesNoCache [](start = 16, length = 19)

Local variables should not use a _ prefix.

lzybkr · 2017-06-14T01:13:26Z

src/System.Management.Automation/engine/Attributes.cs

+            if (_validValues != null)
+            {
+                return _validValues;
+            }


There is a race condition here.

The sequence to trigger the race is:

_validValues != null

The background task to release the cache runs, assigning _validValues with null.

The return executes, returning null.

The fix is:

var validValuesLocal = _validValues; if (validValuesLocal != null) { return validValuesLocal; }

Thanks! I thought about it, but I didn't know how to just fix it.

Fixed.

lzybkr · 2017-06-14T01:20:15Z

src/System.Management.Automation/engine/Attributes.cs

        private string[] _validValues;

+        // The valid values generator cache works across 'ValidateSetAttribute' instances.
+        private static ConcurrentDictionary<Type, ValidValuesGeneratorCacheEntry> s_ValidValuesGeneratorCache = new ConcurrentDictionary<Type, ValidValuesGeneratorCacheEntry>();


ValidValuesGeneratorCacheEntry [](start = 50, length = 30)

I think this can be IValidateSetValuesGenerator.
There will be very few types that implement this interface, so I think the extra complexity around cache cleanup on the generator is not needed.

If we remove this, we won't be able to override this generator. This can be useful for script generators. Otherwise, the script writer will have to restart PowerShell.

I'm a little confused. The is cache cleanup not controlled by the user - so restarting PowerShell is a practical necessity.

We can use ValidValuesGeneratorCacheExpiration to implicitly remove expired values from the cache.
Main question is - will we be happy with the PowerShell restart?

Restarting PowerShell is an occasional annoyance, but I'm not sure this will make a difference.

For C# implementations, you need to restart anyway.
For script implementations - I think there are acceptable ways to develop your generator and test it without restarting PowerShell.

So my preference is to keep the code as simple as possible and only introduce additional complexity after gaining more experience with the feature and determining it really is necessary.

I agree that we can wait a feedback from users.
The cache is removed.

lzybkr · 2017-06-14T01:21:34Z

src/System.Management.Automation/engine/Attributes.cs

+                        // We don't cache valid values.
+                        // We expect that valid values can be cached in the valid values generator.
+                        var validValuesGenerator = (IValidateSetValuesGenerator)Activator.CreateInstance(validValuesGeneratorType);
+                        var cacheEntryAccessTime = DateTime.Now;


I think I'd move creating the generator and storing it in the ConcurrentDictionary to the ValidateSet constructor.

Yes, now the cache is removed and we can create the generator in the constructor.
Fixed.

lzybkr · 2017-06-14T01:22:22Z

src/System.Management.Automation/engine/Attributes.cs

+                    }
+
+                    _validValues = ValidValuesGeneratorCacheEntry.validValuesGenerator.GetValidValues()?.ToArray();
+


As long as we're always call ToArray, maybe we should just change the interface to return string[].

Do we really want to change public interface? Is the breaking change?

Sorry for not being clear - I meant the interface introduced in this PR - IValidateSetValuesGenerator - so not a breaking change.

I agree - the more simple for scripts.

daxian-dbw · 2017-07-13T00:41:35Z

test/powershell/Language/Classes/Scripting.Classes.Attributes.Tests.ps1

+        It 'Can implement CachedValidValuesGeneratorBase with cache expiration in PowerShell' {
+            Get-TestValidateSetPS5 -Param1 "TestString1" -ErrorAction SilentlyContinue | Should BeExactly "TestString1"
+            Get-TestValidateSetPS5 -Param1 "TestString1" -ErrorAction SilentlyContinue | Should BeExactly "TestString1"
+            Start-Sleep 2


I think the failure in CI build is due to this. You can either change to base(1), or make it sleep for 3 seconds (not sure which is more reliable).

I am not happy with the solution but set 3 seconds.

daxian-dbw · 2017-07-13T00:52:44Z

I think this is almost ready to be merged -- 2 more comments to be addressed.

I believe we should stop and merge because here we cannot resolve the problem with ValidValues public property while we share valid values generators.

I don't have the context of the 'the problem with ValidValues', can you please elaborate it a bit? But no matter what, it should not block this PR and the further discussion should be captured in an issue.

iSazonov · 2017-07-13T07:48:47Z

@daxian-dbw
From lzybkr optional idea:

I could imagine wanting to know the command, maybe the command ast, the actual parameter the attribute is applied to, and maybe the already bound parameters.
...
We can add an interface:
public interface IExtendedValidateArguments

The idea is to pass a context to a valid value generator.
Using the new interface we can pass the context to Validate() but we have public property ValidValues - I don`t see how we can pass the context to the property. The root of the problem is that we cache and share the generator. If we add "context" to the cache, the effectiveness of the cache will decrease to 0.

iSazonov · 2017-07-13T11:13:06Z

/cc @joeyaiello We are near a Milstone - 996 repo forks :-)

new commits were pushed.

daxian-dbw

LGTM.

daxian-dbw · 2017-07-13T16:34:33Z

I will merge this PR soon. I assume #3744 is fixed by this PR, so for further enhancement discussion, please open a new issue to continue.

@iSazonov now that the design and implementation are complete, could you please update the PR description with a summary of the design and new functionalities? We need that information for the documentation.

iSazonov · 2017-07-14T03:59:48Z

@daxian-dbw I added the PR description - please review.

daxian-dbw · 2017-07-14T04:27:00Z

@iSazonov Perfect! Thank you for the great work!

iSazonov · 2017-07-14T05:05:33Z

Many thanks @lzybkr for ideas and helps!

Menelion · 2018-03-29T16:08:10Z

Hi everyone,
I found this PR when searching for exactly the same solution: how to implement validateSet from a dynamically generated array of subfolders in a PS script. I see that this is merged, but is there any documentation about this? If not, could you please either point me to the test where I can see it in action or just drop a couple lines to illustrate it? And one more question: if I run Windows 10 1709, do I need to update PowerShell to have this working?
Thanks!

markekraus · 2018-03-29T18:38:20Z

@Menelion Generally you should open a new issue for this kind of thing rather than comment on a closed PR you can reference a PR in an issue by doing #3784 and it will appear like this: #3784

You can find some documentation of the API here https://docs.microsoft.com/en-us/dotnet/api/system.management.automation.ivalidatesetvaluesgenerator?view=pscore-6.0.0

This features was added in PowerShell Core 6.0.0. To use, your PowerShell code must run in PowerShell Core 6.0.0 or newer.

You can find example usage here in this PR or at https://github.com/PowerShell/PowerShell/blob/master/test/powershell/Language/Classes/Scripting.Classes.Attributes.Tests.ps1

iSazonov · 2018-03-30T06:07:15Z

where I can see it in action or just drop a couple lines to illustrate it?

@Menelion You could look our tests which was added in the PR.

felixfbecker · 2018-08-19T14:40:57Z

I am trying to use this, but I always get The type or namespace name 'IValidateSetValuesGenerator' could not be found (are you missing a using directive or an assembly reference?)

I am using the latest PowerShellStandard.Library (5.1.0-preview-06). How can I reference this interface?

lzybkr · 2018-08-19T20:56:05Z

That interface was introduced in 6.0.0, so you would need to reference to https://powershell.myget.org/feed/powershell-core/package/nuget/System.Management.Automation

msftclas added the cla-already-signed label May 15, 2017

lzybkr self-assigned this May 15, 2017

lzybkr requested changes May 15, 2017

View reviewed changes

lzybkr requested changes May 22, 2017

View reviewed changes

iSazonov force-pushed the validateset-dynset branch from 256a341 to cf8e2a8 Compare May 22, 2017 15:30

iSazonov force-pushed the validateset-dynset branch 2 times, most recently from b11ca18 to 5a1a9d2 Compare May 24, 2017 15:09

iSazonov force-pushed the validateset-dynset branch from 5a1a9d2 to aa03005 Compare May 24, 2017 15:49

lzybkr requested changes May 31, 2017

View reviewed changes

PowerShell deleted a comment from schittli Jun 8, 2017

lzybkr reviewed Jun 14, 2017

View reviewed changes

iSazonov added 4 commits June 15, 2017 10:15

Add dynamically generated set in ValidateSetAttribute for binary cmdlets

92066ec

Remove caching valid values and unneeded test

78c8bda

Add "powershell" test

84145aa

Dynamic binding for ValidateSetAttribute

788f910

daxian-dbw self-assigned this Jul 13, 2017

daxian-dbw reviewed Jul 13, 2017

View reviewed changes

iSazonov added 2 commits July 13, 2017 11:52

Revert exception.

8b992a9

Fix test

65349de

daxian-dbw approved these changes Jul 13, 2017

View reviewed changes

daxian-dbw changed the title ~~Add dynamically generated set in ValidateSetAttribute for binary cmdlets~~ ValidateSetAttribute enhancement: support set values to be dynamically generated from a custom ValidateSetValueGenerator Jul 13, 2017

daxian-dbw added the Documentation Needed in this repo Documentation is needed in this repo label Jul 13, 2017

daxian-dbw merged commit dc76c86 into PowerShell:master Jul 14, 2017

iSazonov deleted the validateset-dynset branch July 20, 2017 11:29

iSazonov mentioned this pull request Aug 31, 2017

Fix error message in ValidateSetAttribute ValidateElement() #4722

Merged

LethiferousMoose mentioned this pull request Dec 15, 2017

Getting error "Unable to find type" when using IValidateSetValuesGenerator in a PowerShell module #5661

Closed

Menelion mentioned this pull request Mar 29, 2018

Example for dynamic ValidateSet values MicrosoftDocs/PowerShell-Docs#2272

Closed

8 tasks

joeyaiello mentioned this pull request Oct 15, 2018

Docs needed for 'ValidateSetAttribute enhancement: support set values to be dynamically generated from a custom ValidateSetValueGenerator' MicrosoftDocs/PowerShell-Docs#3101

Closed

joeyaiello removed Documentation Needed in this repo Documentation is needed in this repo labels Oct 15, 2018

iSazonov mentioned this pull request Jun 2, 2022

Implemented ScriptBlock support for ValidateSet #17460

Closed

22 tasks

		}

		_validValues = ValidValuesGeneratorCacheEntry.validValuesGenerator.GetValidValues()?.ToArray();

ValidateSetAttribute enhancement: support set values to be dynamically generated from a custom ValidateSetValueGenerator #3784

ValidateSetAttribute enhancement: support set values to be dynamically generated from a custom ValidateSetValueGenerator #3784

Conversation

iSazonov commented May 15, 2017 • edited

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

lzybkr 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

iSazonov commented May 22, 2017

lzybkr commented May 23, 2017

iSazonov commented May 23, 2017

lzybkr commented May 23, 2017

powercode commented May 23, 2017 • edited

iSazonov commented May 24, 2017

iSazonov commented May 26, 2017

lzybkr 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

lfshr commented Jun 1, 2017

iSazonov commented Jun 2, 2017

lfshr commented Jun 2, 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

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

iSazonov Jun 14, 2017 • edited

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

daxian-dbw commented Jul 13, 2017

iSazonov commented Jul 13, 2017

iSazonov commented Jul 13, 2017

daxian-dbw left a comment

Choose a reason for hiding this comment

daxian-dbw commented Jul 13, 2017

iSazonov commented Jul 14, 2017

daxian-dbw commented Jul 14, 2017

iSazonov commented May 15, 2017 •

edited

powercode commented May 23, 2017 •

edited

iSazonov Jun 14, 2017 •

edited

iSazonov commented Mar 30, 2018 •

edited