Add -v and --version flags to ch to print ChakraCore version. #2490

dilijev · 2017-02-08T02:32:28Z

Partially addresses #109 and #2472.

This is intended as a first pass at the issue to provide some information at this point.

Later, we plan to add more information such as whether a binary was produced as a developer build or an official build, what specific commit the binary was built from, which branch, which machine, etc. The specific set of information that we plan to provide is still being discussed in #109.

ch /v
ch /version
ch -v
ch --v
ch -version
ch --version

(Supporting - and -- prefixes for short and long flag names is consistent with how we process all behaviors. The logic I used here is a replica of that in CmdLineArgsParser::Parse.)

The above all display the version information for ch and ChakraCore as <major>.<minor>.<patch>.<QFE> (note: by convention, ChakraCore's QFE is always 0).

For example on Windows for ChakraCore 1.4.1 with ch.exe and ChakraCore.dll from the same build:

$ ch -v
ch.exe version 1.4.1.0
chakracore.dll version 1.4.1.0

If with the same ch.exe, if ChakraCore.dll was from, e.g., a 2.0.0 build:

$ ch -v
ch.exe version 1.4.1.0
chakracore.dll version 2.0.0.0

On Linux:

~/dev/ChakraCore$ ./BuildLinux/Release/ch -v
ch version 1.4.1.0

This flag is available in all flavors (including Release).

Updating the help message. Also enable -h and -help as per request in #2472.

Enables -h and -help for non-release builds, and -?, -h, and -help for release builds.

Messages will look as follows.

debug/test builds:

Usage: ch.exe [-v|-version] [-h|-help] [-?] [flaglist] <source file>
        -v|-version             Displays version info
        -h|-help                Displays this help message
        -?                      Displays this help message with complete [flaglist] info

release builds:

Usage: ch.exe [-v|-version] [-h|-help|-?] <source file>
Note: [flaglist] is not supported in Release builds; try a Debug or Test build to enable these flags.
        -v|-version             Displays version info
        -h|-help|-?             Displays this help message

The distinction is that -? is already implemented in debug/test builds to display full information about the [flaglist] options. This is a minimal change here that will result in guiding the user more accurately in all build flavors, the effect of which is that -? in debug/test builds is still the only way to get information about the [flaglist] options.

Partially addresses chakra-core#109 and chakra-core#2472 ``` ch /v ch /version ch -v ch --v ch -version ch --version ``` The above all display the version in a simple `<major>.<minor>.<patch>` format, e.g.: ``` 1.4.1 ``` This flag is available in all flavors (including Release).

dilijev · 2017-02-08T02:35:31Z

@bterlson @liminzhu We could probably merge this before the 1.4.1 release, so at a minimum 1.4.1 and 2.0.0 binaries can be distinguished at this point.
/cc @mathiasbynens @obastemur @ThomsonTan @ianwjhalliday
What do you think?

dilijev · 2017-02-08T02:39:17Z

Problems building on xplat. What is an xplat alternative for wcsnlen -- or another way to write this?

ThomsonTan · 2017-02-08T02:47:25Z

Linux has wcslen. The build problem is probably about const conversion.

In reply to: 278212465 [](ancestors = 278212465)

ThomsonTan · 2017-02-08T02:48:33Z

bin/ch/ch.cpp

@@ -770,7 +775,36 @@ int _cdecl wmain(int argc, __in_ecount(argc) LPWSTR argv[])
    int cpos = 1;
    for(int i = 1; i < argc; ++i)
    {
-        if(wcsstr(argv[i], _u("-TTRecord=")) == argv[i])
+        wchar *arg = argv[i];


mathiasbynens · 2017-02-08T09:10:51Z

We could probably merge this before the 1.4.1 release, so at a minimum 1.4.1 and 2.0.0 binaries can be distinguished at this point.

🎉

obastemur · 2017-02-08T17:27:38Z

should we include this into -? list?

liminzhu · 2017-02-08T18:36:44Z

This sounds pretty useful. Is there a way for any embedder (not just ch) to programmatically know ChakraCore version #?

jianchun · 2017-02-08T19:01:46Z

This sounds pretty useful. Is there a way for any embedder (not just ch) to programmatically know ChakraCore version #?

We intend to ship "ChakraCoreVersion.h" file, and embedder knows it by including that header.

dilijev · 2017-02-08T22:33:16Z

Yes, additionally, the file info of the compiled binaries already contains information about the version (that's how these macros were being consumed before):

Here's the info for some binaries I built locally:

ch.exe:
        Verified:       Unsigned
        Link date:      6:27 PM 2/7/2017
        Publisher:      Microsoft Corporation
        Description:    Microsoft « Chakra Core Host (Private)
        Product:        Microsoft « Chakra Core Host
        Prod version:   2.0.0.0
        File version:   2.0.0.0
        MachineType:    64-bit

ChakraCore.dll:
        Verified:       Unsigned
        Link date:      5:57 PM 2/7/2017
        Publisher:      Microsoft Corporation
        Description:    Microsoft « Chakra Core (Private)
        Product:        Microsoft « Chakra Core
        Prod version:   2.0.0.0
        File version:   2.0.0.0
        MachineType:    64-bit

And from the preview package I recently published to myget:

microsoft.chakracore.vc140.1.4.1-preview-00010-42060\lib\native\v140\x64\debug\ch.exe:
        Verified:       Signed
        Signing date:   7:17 PM 1/30/2017
        Publisher:      Microsoft Corporation
        Description:    Microsoft « Chakra Core Host
        Product:        Microsoft « Chakra Core Host
        Prod version:   1.4.1.0
        File version:   1.4.1.0 (users/doilij/nufeed:3e2e2f353d71d8e3e8522fa04b9789cf1b5c35ac.00010.42060.170130-1858)
        MachineType:    64-bit

microsoft.chakracore.vc140.1.4.1-preview-00010-42060\lib\native\v140\x64\debug\ChakraCore.dll:
        Verified:       Signed
        Signing date:   7:15 PM 1/30/2017
        Publisher:      Microsoft Corporation
        Description:    Microsoft « Chakra Core
        Product:        Microsoft « Chakra Core
        Prod version:   1.4.1.0
        File version:   1.4.1.0 (users/doilij/nufeed:3e2e2f353d71d8e3e8522fa04b9789cf1b5c35ac.00010.42060.170130-1858)
        MachineType:    64-bit

dilijev · 2017-02-08T22:58:16Z

It looks like the problem is that the signature of main for xplat specifies the following and converts so that argv is a char16*

#ifndef _WIN32
static char16** argv = nullptr;
int main(int argc, char** c_argv)
{
    PAL_InitializeChakraCore(argc, c_argv);
    argv = new char16*[argc];

Instead of the Windows version which uses:

int _cdecl wmain(int argc, __in_ecount(argc) LPWSTR argv[])

Note LPWSTR is typedef'd to wchar_t on Windows at least.

Additionally, I confused things initially by using wchar instead of wchar_t -- apparently not a problem on Windows but it is for xplat.

wcsnlen requires wchar_t * per the standard.

dilijev · 2017-02-08T23:08:32Z

Apparently we have PAL_wcslen but not PAL_wcsnlen -- there's an implementation here but it seems better to just copy the existing PAL_wcslen and add the additional loop bound.

On the other hand @jianchun suggests that since security is not a concern in ch, wcslen should be enough for ch -- and additionally, it may be the case that PAL is too problematic for ch and we should try to avoid using PAL directly.

dilijev · 2017-02-08T23:48:25Z

I'm going to look into using HostConfigFlags instead to avoid introducing the PAL dependency in ch. If that works, I'll update the PR away from the current approach.

obastemur · 2017-02-09T00:14:17Z

Additionally, I confused things initially by using wchar instead of wchar_t -- apparently not a problem on Windows but it is for xplat.

We shouldn't use wchar_t I had cleaned up that one. Its size can be 4 bytes on one platform and 2 on another..

obastemur · 2017-02-09T00:15:43Z

LGTM. Thanks @dilijev for taking care of this!

dilijev · 2017-02-09T00:40:18Z

@jianchun re: shipping ChakraCoreVersion.h -- the NuGet packages do not include this file since it's so minor. Would it be worth including it? Even so, that only solves the problem for Native projects.

For .NET projects which might want to report the ChakraCore version without hardcoding it, is there any kind of solution that would work that doesn't involve exposing a new API that reports the version info? Should we consider implementing such an API for the benefit of hosting? Is there some other approach that could work?

/cc @liminzhu

dilijev · 2017-02-09T00:50:34Z

I'm going to look into using HostConfigFlags instead to avoid introducing the PAL dependency in ch. If that works, I'll update the PR away from the current approach.

From my investigation so far, this seems like a bit of a rabbit hole. There seems to be good reason (at least, it was thought about before) not to initialize the HostConfigFlags in release builds. Working around it to enable these specific parameters seems silly and difficult, so if we went this way, it would involve enabling all HostConfigFlags.

I agree that taking a dependency on PAL for this may be a bit extreme. One workaround is to copy a definition of PAL_wcslen to support taking length of char16 strings to avoid the dependency problem, but I'd like to avoid doing something like that if it's not totally necessary. Any suggestions?

@jianchun @obastemur Think it's safe to merge this as-is and follow-up later if the dependency becomes a problem?

dilijev · 2017-02-09T02:01:09Z

Updating the help message. Also enable -h and -help as per request in #2472.

Enables -h and -help for non-release builds, and -?, -h, and -help for release builds.

Messages will look as follows.

debug/test builds:

Usage: ch.exe [-v|-version] [-h|-help] [-?] [flaglist] <source file>
        -v|-version             Displays version info
        -h|-help                Displays this help message
        -?                      Displays this help message with complete [flaglist] info

release builds:

Usage: ch.exe [-v|-version] [-h|-help|-?] <source file>
Note: [flaglist] is not supported in Release builds; try a Debug or Test build to enable these flags.
        -v|-version             Displays version info
        -h|-help|-?             Displays this help message

The distinction is that -? is already implemented in debug/test builds to display full information about the [flaglist] options. This is a minimal change here that will result in guiding the user more accurately in all build flavors, the effect of which is that -? in debug/test builds is still the only way to get information about the [flaglist] options.

/cc @mathiasbynens @obastemur

…t in chakra-core#2472. Enables `-h` and `-help` for non-release builds, and `-?`, `-h`, and `-help` for release builds. Messages will look as follows. debug/test builds: ``` Usage: ch.exe [-v|-version] [-h|-help] [-?] [flaglist] <source file> -v|-version Displays version info -h|-help Displays this help message -? Displays this help message with complete [flaglist] info ``` release builds: ``` Usage: ch.exe [-v|-version] [-h|-help|-?] <source file> Note: [flaglist] is not supported in Release builds; try a Debug or Test build to enable these flags. -v|-version Displays version info -h|-help|-? Displays this help message ``` The distinction is that `-?` is already implemented in debug/test builds to display full information about the `[flaglist]` options. This is a minimal change here that will result in guiding the user more accurately in all build flavors, the effect of which is that `-?` in debug/test builds is still the only way to get information about the `[flaglist]` options.

dilijev · 2017-02-09T03:03:28Z

@tcare Believes that this is potentially misleading as the version being reported is really just the version of ch, not the version of ChakraCore that ch loads. This echos an earlier concern that I had when I started working on this.

At a minimum, we should report the following at this time:

ch.exe version 1.4.1

We could read the ChakraCore.dll binary information (see above), but the ChakraCore binaries produced in xplat builds don't seem to contain this info at this time, so we would be unable to do the same for xplat right now. It may be reasonable to make this a separate work item for later.

Assuming that in the common case ch will only be used with the ChakraCore library that was built at the same time, the version of ch can be used as a proxy for the version of ChakraCore it will load, and this could mostly resolve the common scenarios that @bterlson @mathiasbynens and others are interested in.

Will discuss with others on the team for opinions about how to proceed before merging this.

dilijev · 2017-02-09T04:01:39Z

https://stackoverflow.com/questions/940707/how-do-i-programatically-get-the-version-of-a-dll-or-exe-file/940743#940743 shows how to read file information from a binary.

Output of ch -v etc. is now:

ch.exe version 1.4.1.0
chakracore.dll version 1.4.1.0

Or, because it reads the DLL info, when the DLL built from a different version, that is reflected in the output as well:

ch.exe version 1.4.1.0
chakracore.dll version 2.0.0.0

Note: At present, this only reports the ChakraCore version on Windows. On xplat, only the ch version will be reported. Reporting the version on xplat will require additional work: embedding that information in the binary and writing an alternate implementation to retrieve that info for xplat.

/cc @tcare

dilijev · 2017-02-09T04:17:41Z

Windows x86_release error:

warning C6388: 'verHandle' might not be '0': this does not adhere to the specification for the function 'GetFileVersionInfoA'.

DWORD
APIENTRY
GetFileVersionInfoSizeA(
        _In_        LPCSTR lptstrFilename, /* Filename of version stamped file */
        _Out_opt_ LPDWORD lpdwHandle       /* Information for use by GetFileVersionInfo */
        );

BOOL
APIENTRY
GetFileVersionInfoA(
        _In_                LPCSTR lptstrFilename, /* Filename of version stamped file */
        _Reserved_          DWORD dwHandle,          /* Information from GetFileVersionSize */
        _In_                DWORD dwLen,             /* Length of buffer for info */
        _Out_writes_bytes_(dwLen) LPVOID lpData            /* Buffer to place the data structure */
        );

What? This seems like a warning that should be suppressed because clearly the value of &verHandle output from GetFileVersionInfoSizeA is supposed to be passed into GetFileVersionInfoA, unless I'm totally misreading this.

tcare · 2017-02-09T18:11:54Z

dwHandle is reserved and is ignored. Just pass in nullptr. https://msdn.microsoft.com/en-us/library/windows/desktop/ms647003(v=vs.85).aspx

dilijev · 2017-02-09T21:04:45Z

@tcare Thanks for confirming, I was thinking that might be the right thing to do but I couldn't find info about it. I didn't think to check the API page since I figured the function signature would be enough to tell why the warning happened (clearly the _Reserved_ was the bit I didn't quite understand).

tcare · 2017-02-09T21:07:00Z

bin/ch/ch.cpp

+    DWORD verHandle = NULL;
+    UINT size = 0;
+    LPBYTE lpBuffer = NULL;
+    DWORD verSize = GetFileVersionInfoSizeA(filename, &verHandle);


verHandle is optional for this and we don't use it later, so you can also pass nullptr here.

tcare · 2017-02-09T21:11:56Z

bin/ch/ChakraRtInterface.cpp

@@ -23,6 +23,11 @@ ChakraRTInterface::ArgInfo* ChakraRTInterface::m_argInfo = nullptr;
 TestHooks ChakraRTInterface::m_testHooks = { 0 };
 JsAPIHooks ChakraRTInterface::m_jsApiHooks = { 0 };

+LPCSTR GetChakraDllName()
+{
+    return chakraDllName;


Where is this defined?

Top of the file. Different string for each platform.

tcare · 2017-02-09T21:12:33Z

bin/ch/ch.vcxproj

@@ -37,6 +37,7 @@
        ole32.lib;
        kernel32.lib;
        Rpcrt4.lib;
+        $(ChakraCommonLinkDependencies);


Do we really need to add this link dependency? Is there a more lightweight way to get the Dll name?

Yes, I'll just link the specific lib.

tcare · 2017-02-09T22:32:13Z

bin/ch/ch.cpp

+            (size != 0))
+        {
+            VS_FIXEDFILEINFO *verInfo = (VS_FIXEDFILEINFO *)lpBuffer;
+            if (verInfo->dwSignature == 0xfeef04bd)


The magic number can be VS_FFI_SIGNATURE

Ah thanks, that was bugging me too.

tcare · 2017-02-09T22:33:13Z

LGTM, please run by @curtisman.

…raCore version. Merge pull request #2490 from dilijev:version-r14 Partially addresses #109 and #2472. This is intended as a first pass at the issue to provide some information at this point. Later, we plan to add more information such as whether a binary was produced as a developer build or an official build, what specific commit the binary was built from, which branch, which machine, etc. The specific set of information that we plan to provide is still being discussed in #109. ``` ch /v ch /version ch -v ch --v ch -version ch --version ``` (Supporting `-` and `--` prefixes for short and long flag names is consistent with how we process all behaviors. The logic I used here is a replica of that in `CmdLineArgsParser::Parse`.) The above all display the version information for `ch` and `ChakraCore` as `<major>.<minor>.<patch>.<QFE>` (note: by convention, ChakraCore's `QFE` is always `0`). For example on Windows for ChakraCore 1.4.1 with `ch.exe` and `ChakraCore.dll` from the same build: ``` $ ch -v ch.exe version 1.4.1.0 chakracore.dll version 1.4.1.0 ``` If with the same `ch.exe`, if `ChakraCore.dll` was from, e.g., a 2.0.0 build: ``` $ ch -v ch.exe version 1.4.1.0 chakracore.dll version 2.0.0.0 ``` On Linux: ``` ~/dev/ChakraCore$ ./BuildLinux/Release/ch -v ch version 1.4.1.0 ``` This flag is available in all flavors (including Release). --- Updating the help message. Also enable `-h` and `-help` as per request in #2472. Enables `-h` and `-help` for non-release builds, and `-?`, `-h`, and `-help` for release builds. Messages will look as follows. debug/test builds: ``` Usage: ch.exe [-v|-version] [-h|-help] [-?] [flaglist] <source file> -v|-version Displays version info -h|-help Displays this help message -? Displays this help message with complete [flaglist] info ``` release builds: ``` Usage: ch.exe [-v|-version] [-h|-help|-?] <source file> Note: [flaglist] is not supported in Release builds; try a Debug or Test build to enable these flags. -v|-version Displays version info -h|-help|-? Displays this help message ``` The distinction is that `-?` is already implemented in debug/test builds to display full information about the `[flaglist]` options. This is a minimal change here that will result in guiding the user more accurately in all build flavors, the effect of which is that `-?` in debug/test builds is still the only way to get information about the `[flaglist]` options.

…to print ChakraCore version. Merge pull request #2490 from dilijev:version-r14 Partially addresses #109 and #2472. This is intended as a first pass at the issue to provide some information at this point. Later, we plan to add more information such as whether a binary was produced as a developer build or an official build, what specific commit the binary was built from, which branch, which machine, etc. The specific set of information that we plan to provide is still being discussed in #109. ``` ch /v ch /version ch -v ch --v ch -version ch --version ``` (Supporting `-` and `--` prefixes for short and long flag names is consistent with how we process all behaviors. The logic I used here is a replica of that in `CmdLineArgsParser::Parse`.) The above all display the version information for `ch` and `ChakraCore` as `<major>.<minor>.<patch>.<QFE>` (note: by convention, ChakraCore's `QFE` is always `0`). For example on Windows for ChakraCore 1.4.1 with `ch.exe` and `ChakraCore.dll` from the same build: ``` $ ch -v ch.exe version 1.4.1.0 chakracore.dll version 1.4.1.0 ``` If with the same `ch.exe`, if `ChakraCore.dll` was from, e.g., a 2.0.0 build: ``` $ ch -v ch.exe version 1.4.1.0 chakracore.dll version 2.0.0.0 ``` On Linux: ``` ~/dev/ChakraCore$ ./BuildLinux/Release/ch -v ch version 1.4.1.0 ``` This flag is available in all flavors (including Release). --- Updating the help message. Also enable `-h` and `-help` as per request in #2472. Enables `-h` and `-help` for non-release builds, and `-?`, `-h`, and `-help` for release builds. Messages will look as follows. debug/test builds: ``` Usage: ch.exe [-v|-version] [-h|-help] [-?] [flaglist] <source file> -v|-version Displays version info -h|-help Displays this help message -? Displays this help message with complete [flaglist] info ``` release builds: ``` Usage: ch.exe [-v|-version] [-h|-help|-?] <source file> Note: [flaglist] is not supported in Release builds; try a Debug or Test build to enable these flags. -v|-version Displays version info -h|-help|-? Displays this help message ``` The distinction is that `-?` is already implemented in debug/test builds to display full information about the `[flaglist]` options. This is a minimal change here that will result in guiding the user more accurately in all build flavors, the effect of which is that `-?` in debug/test builds is still the only way to get information about the `[flaglist]` options.

msftclas added the cla-not-required label Feb 8, 2017

dilijev self-assigned this Feb 8, 2017

dilijev added this to the 1.4.1 milestone Feb 8, 2017

ThomsonTan reviewed Feb 8, 2017

View reviewed changes

dilijev closed this Feb 8, 2017

dilijev reopened this Feb 8, 2017

msftclas added the cla-not-required label Feb 8, 2017

Fix up xplat build.

10f53b4

dilijev force-pushed the version-r14 branch from 1b812c2 to 10f53b4 Compare February 8, 2017 23:45

dilijev mentioned this pull request Feb 9, 2017

ch.exe needs --version #109

Closed

dilijev force-pushed the version-r14 branch from 6ce4499 to 09b9849 Compare February 9, 2017 21:03

tcare reviewed Feb 9, 2017

View reviewed changes

dilijev force-pushed the version-r14 branch 2 times, most recently from 93d53e5 to 57eba6b Compare February 9, 2017 22:14

tcare reviewed Feb 9, 2017

View reviewed changes

Read version information from ChakraCore library.

beb522d

dilijev force-pushed the version-r14 branch from 57eba6b to beb522d Compare February 9, 2017 22:40

chakrabot merged commit beb522d into chakra-core:release/1.4 Feb 9, 2017

dilijev deleted the version-r14 branch February 9, 2017 23:19

dilijev mentioned this pull request Feb 9, 2017

Follow-up items: ch -v and --version #2505

Open

6 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add -v and --version flags to ch to print ChakraCore version. #2490

Add -v and --version flags to ch to print ChakraCore version. #2490

dilijev commented Feb 8, 2017 •

edited

Loading

dilijev commented Feb 8, 2017

dilijev commented Feb 8, 2017 •

edited

Loading

ThomsonTan commented Feb 8, 2017

ThomsonTan Feb 8, 2017

mathiasbynens commented Feb 8, 2017

obastemur commented Feb 8, 2017

liminzhu commented Feb 8, 2017

jianchun commented Feb 8, 2017

dilijev commented Feb 8, 2017

dilijev commented Feb 8, 2017 •

edited

Loading

dilijev commented Feb 8, 2017 •

edited

Loading

dilijev commented Feb 8, 2017 •

edited

Loading

obastemur commented Feb 9, 2017

obastemur commented Feb 9, 2017

dilijev commented Feb 9, 2017 •

edited

Loading

dilijev commented Feb 9, 2017 •

edited

Loading

dilijev commented Feb 9, 2017 •

edited

Loading

dilijev commented Feb 9, 2017 •

edited

Loading

dilijev commented Feb 9, 2017 •

edited

Loading

dilijev commented Feb 9, 2017 •

edited

Loading

tcare commented Feb 9, 2017

dilijev commented Feb 9, 2017 •

edited

Loading

tcare Feb 9, 2017

tcare Feb 9, 2017

dilijev Feb 9, 2017

tcare Feb 9, 2017

dilijev Feb 9, 2017

tcare Feb 9, 2017

dilijev Feb 9, 2017

tcare commented Feb 9, 2017

Add -v and --version flags to ch to print ChakraCore version. #2490

Add -v and --version flags to ch to print ChakraCore version. #2490

Conversation

dilijev commented Feb 8, 2017 • edited Loading

dilijev commented Feb 8, 2017

dilijev commented Feb 8, 2017 • edited Loading

ThomsonTan commented Feb 8, 2017

Choose a reason for hiding this comment

mathiasbynens commented Feb 8, 2017

obastemur commented Feb 8, 2017

liminzhu commented Feb 8, 2017

jianchun commented Feb 8, 2017

dilijev commented Feb 8, 2017

dilijev commented Feb 8, 2017 • edited Loading

dilijev commented Feb 8, 2017 • edited Loading

dilijev commented Feb 8, 2017 • edited Loading

obastemur commented Feb 9, 2017

obastemur commented Feb 9, 2017

dilijev commented Feb 9, 2017 • edited Loading

dilijev commented Feb 9, 2017 • edited Loading

dilijev commented Feb 9, 2017 • edited Loading

dilijev commented Feb 9, 2017 • edited Loading

dilijev commented Feb 9, 2017 • edited Loading

dilijev commented Feb 9, 2017 • edited Loading

tcare commented Feb 9, 2017

dilijev commented Feb 9, 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

tcare commented Feb 9, 2017

dilijev commented Feb 8, 2017 •

edited

Loading

dilijev commented Feb 8, 2017 •

edited

Loading

dilijev commented Feb 8, 2017 •

edited

Loading

dilijev commented Feb 8, 2017 •

edited

Loading

dilijev commented Feb 8, 2017 •

edited

Loading

dilijev commented Feb 9, 2017 •

edited

Loading

dilijev commented Feb 9, 2017 •

edited

Loading

dilijev commented Feb 9, 2017 •

edited

Loading

dilijev commented Feb 9, 2017 •

edited

Loading

dilijev commented Feb 9, 2017 •

edited

Loading

dilijev commented Feb 9, 2017 •

edited

Loading

dilijev commented Feb 9, 2017 •

edited

Loading