Re: Python thin client

[Stepan Pilschikov]

Oh, nice

Thanks for quick response

I've check against JS and PHP, now its works properly

Igor, can you approve this patch?

сб, 20 окт. 2018 г. в 0:57, Dmitry Melnichuk :

> Stepan,
>
> My bad. I got the Decimal part of Ignite thin client protocol
> specification totally wrong.
>
> Just submitted a patch tested against Java thin client. Please evaluate.
>
> On 10/20/18 2:00 AM, Stepan Pilschikov wrote:
> > Dmitry,
> >
> > One more thing
> > Discover that Decimal data type can't be getting by others clients
> >
> > Make ticket with description:
> > https://issues.apache.org/jira/browse/IGNITE-9950
> >
> > Please, can you help to investigate this problem?
> >
> > ср, 17 окт. 2018 г. в 23:14, Stepan Pilschikov <
> pilshchikov@gmail.com>:
> >
> >> Dmitry,
> >>
> >> Great, now client works properly on all OS
> >> Thanks
> >>
> >> I hope PR will be merged soon
> >>
> >> Igor, can please help with that?
> >>
> >> ср, 17 окт. 2018 г. в 20:48, Dmitry Melnichuk <
> >> dmitry.melnic...@nobitlost.com>:
> >>
> >>> Stepan,
> >>>
> >>> Sadly, it was a C `long` data type size mismatch between Windows and
> >>> other OSes. I investigated this issue and offered a pull request.
> >>>
> >>> https://github.com/apache/ignite/pull/5017
> >>>
> >>> On 10/17/18 6:29 PM, Stepan Pilschikov wrote:
>  Dmitry,
> 
>  I've trying to use python thin client with Ignite 2.7 it dosn't work
>  Please help to investigate
>  Problem reproduced on several others machines
> 
>  Issue:
>  https://issues.apache.org/jira/browse/IGNITE-9908
> 
> >>>
> >>
> >
>
>

Re: Python thin client

[Dmitry Melnichuk]

Stepan,

My bad. I got the Decimal part of Ignite thin client protocol 
specification totally wrong.


Just submitted a patch tested against Java thin client. Please evaluate.

On 10/20/18 2:00 AM, Stepan Pilschikov wrote:

Dmitry,

One more thing
Discover that Decimal data type can't be getting by others clients

Make ticket with description:
https://issues.apache.org/jira/browse/IGNITE-9950

Please, can you help to investigate this problem?

ср, 17 окт. 2018 г. в 23:14, Stepan Pilschikov :


Dmitry,

Great, now client works properly on all OS
Thanks

I hope PR will be merged soon

Igor, can please help with that?

ср, 17 окт. 2018 г. в 20:48, Dmitry Melnichuk <
dmitry.melnic...@nobitlost.com>:


Stepan,

Sadly, it was a C `long` data type size mismatch between Windows and
other OSes. I investigated this issue and offered a pull request.

https://github.com/apache/ignite/pull/5017

On 10/17/18 6:29 PM, Stepan Pilschikov wrote:

Dmitry,

I've trying to use python thin client with Ignite 2.7 it dosn't work
Please help to investigate
Problem reproduced on several others machines

Issue:
https://issues.apache.org/jira/browse/IGNITE-9908

Re: Python thin client

[Stepan Pilschikov]

Dmitry,

One more thing
Discover that Decimal data type can't be getting by others clients

Make ticket with description:
https://issues.apache.org/jira/browse/IGNITE-9950

Please, can you help to investigate this problem?

ср, 17 окт. 2018 г. в 23:14, Stepan Pilschikov :

> Dmitry,
>
> Great, now client works properly on all OS
> Thanks
>
> I hope PR will be merged soon
>
> Igor, can please help with that?
>
> ср, 17 окт. 2018 г. в 20:48, Dmitry Melnichuk <
> dmitry.melnic...@nobitlost.com>:
>
>> Stepan,
>>
>> Sadly, it was a C `long` data type size mismatch between Windows and
>> other OSes. I investigated this issue and offered a pull request.
>>
>> https://github.com/apache/ignite/pull/5017
>>
>> On 10/17/18 6:29 PM, Stepan Pilschikov wrote:
>> > Dmitry,
>> >
>> > I've trying to use python thin client with Ignite 2.7 it dosn't work
>> > Please help to investigate
>> > Problem reproduced on several others machines
>> >
>> > Issue:
>> > https://issues.apache.org/jira/browse/IGNITE-9908
>> >
>>
>

Re: Python thin client

[Stepan Pilschikov]

Dmitry,

Great, now client works properly on all OS
Thanks

I hope PR will be merged soon

Igor, can please help with that?

ср, 17 окт. 2018 г. в 20:48, Dmitry Melnichuk <
dmitry.melnic...@nobitlost.com>:

> Stepan,
>
> Sadly, it was a C `long` data type size mismatch between Windows and
> other OSes. I investigated this issue and offered a pull request.
>
> https://github.com/apache/ignite/pull/5017
>
> On 10/17/18 6:29 PM, Stepan Pilschikov wrote:
> > Dmitry,
> >
> > I've trying to use python thin client with Ignite 2.7 it dosn't work
> > Please help to investigate
> > Problem reproduced on several others machines
> >
> > Issue:
> > https://issues.apache.org/jira/browse/IGNITE-9908
> >
>

Re: Python thin client

[Dmitry Melnichuk]

Stepan,

Sadly, it was a C `long` data type size mismatch between Windows and 
other OSes. I investigated this issue and offered a pull request.


https://github.com/apache/ignite/pull/5017

On 10/17/18 6:29 PM, Stepan Pilschikov wrote:

Dmitry,

I've trying to use python thin client with Ignite 2.7 it dosn't work
Please help to investigate
Problem reproduced on several others machines

Issue:
https://issues.apache.org/jira/browse/IGNITE-9908

Re: Python thin client

[Stepan Pilschikov]

Dmitry,

I've trying to use python thin client with Ignite 2.7 it dosn't work
Please help to investigate
Problem reproduced on several others machines

Issue:
https://issues.apache.org/jira/browse/IGNITE-9908

вт, 16 окт. 2018 г. в 4:36, Dmitry Melnichuk :

> Igor,
>
> I do not have access to edit wiki pages, so please fill it.
>
> All the features are supported, except for:
>
> - Query API: ScanQuery with filter,
> - Binary API: Get object in BinaryObject form, BinaryObject building,
> - Additional Features: Best effort affinity,
> - Type registration: Enum registration, Type name registration.
>
> On 10/15/18 9:17 PM, Igor Sapego wrote:
> > Dmitry,
> >
> > Since Python thin client is now in master, can you please add it to our
> > "Thin clients features" wiki page, so we can track the feature parity
> > of our clients? Or just tell me which features are supported, so I can
> fill
> > it myself.
> >
> > [1] -
> > https://cwiki.apache.org/confluence/display/IGNITE/Thin+clients+features
> >
> > Best Regards,
> > Igor
> >
>

Re: Python thin client

[Dmitry Melnichuk]

Igor,

I do not have access to edit wiki pages, so please fill it.

All the features are supported, except for:

- Query API: ScanQuery with filter,
- Binary API: Get object in BinaryObject form, BinaryObject building,
- Additional Features: Best effort affinity,
- Type registration: Enum registration, Type name registration.

On 10/15/18 9:17 PM, Igor Sapego wrote:

Dmitry,

Since Python thin client is now in master, can you please add it to our
"Thin clients features" wiki page, so we can track the feature parity
of our clients? Or just tell me which features are supported, so I can fill
it myself.

[1] -
https://cwiki.apache.org/confluence/display/IGNITE/Thin+clients+features

Best Regards,
Igor

Re: Python thin client

[Igor Sapego]

Dmitry,

Since Python thin client is now in master, can you please add it to our
"Thin clients features" wiki page, so we can track the feature parity
of our clients? Or just tell me which features are supported, so I can fill
it myself.

[1] -
https://cwiki.apache.org/confluence/display/IGNITE/Thin+clients+features

Best Regards,
Igor


On Mon, Oct 15, 2018 at 1:38 PM Igor Sapego  wrote:

> Hi,
>
> I've just merged Python thin client to the master and ignite-2.7
>
> Also, I like how the python's results improved and now are comparable to
> node.js.
>
> Great job, guys!
>
> Best Regards,
> Igor
>
>
> On Sat, Oct 13, 2018 at 3:53 PM Степан Пильщиков <
> pilshchikov@gmail.com> wrote:
>
>> Hi
>>
>> Made new run and client definitely become faster
>> I think its right direction for improvements
>>
>> Also rerun java bench with compiler=none option
>>
>> All results you can get in
>> https://issues.apache.org/jira/browse/IGNITE-9824
>> (last comment)
>>
>> сб, 13 окт. 2018 г. в 4:56, Pavel Petroshenko :
>>
>> > Hi Stepan,
>> >
>> > Re your performance questions.
>> >
>> > Firstly, please pull out the latest sources from the ignite-7782 branch
>> as
>> > it has some performance optimizations recently implemented.
>> >
>> > Secondly, Hotspot is a pretty advanced dynamic adaptive compiler and
>> it's
>> > not fair to compare it to a purely interpreted Python language
>> > implementation. To get comparable results, please run your Java
>> benchmark
>> > with -Djava.compiler=NONE. It turns the dynamic compiler off at
>> runtime. I
>> > just did this exercise myself and got comparable scores.
>> >
>> > Please let me know if you still see any significant difference with the
>> > flag set.
>> >
>> > Thanks,
>> > P.
>> >
>> > On Fri, Oct 12, 2018 at 10:02 AM Dmitry Melnichuk <
>> > dmitry.melnic...@nobitlost.com> wrote:
>> >
>> >> Igor,
>> >>
>> >> I fixed my files.
>> >>
>> >> Dmitry
>> >>
>> >> On 10/13/18 12:14 AM, Igor Sapego wrote:
>> >> > Dmitry,
>> >> >
>> >> > I've run the tests and it appears that there are a lot of files
>> without
>> >> > Apache
>> >> > licenses in Python client: [1] (See Unapproved licenses list).
>> >> >
>> >> > Can you either add headers or exclude file from the check, if you can
>> >> not
>> >> > add one? I.e. to this list: [2]
>> >> >
>> >> > [1] -
>> >> >
>> >>
>> https://ci.ignite.apache.org/repository/download/IgniteTests24Java8_LicensesHeaders/2069024:id/rat.zip%21/target/rat.txt
>> >> > [2] -
>> https://github.com/apache/ignite/blob/master/parent/pom.xml#L817
>> >> >
>> >> > Best Regards,
>> >> > Igor
>> >> >
>> >> >
>> >> > On Thu, Oct 11, 2018 at 1:13 PM Igor Sapego 
>> wrote:
>> >> >
>> >> >> Ok, I've filed a ticket [1] for the performance investigation and
>> >> targeted
>> >> >> it to 2.8. Feel free to assign it to yourself.
>> >> >>
>> >> >> I'm going to merge the ticket to master and ignite-2.7 branches by
>> the
>> >> >> end of the week, if no one have any objections.
>> >> >>
>> >> >> [1] - https://issues.apache.org/jira/browse/IGNITE-9850
>> >> >>
>> >> >> Best Regards,
>> >> >> Igor
>> >> >>
>> >> >>
>> >> >> On Thu, Oct 11, 2018 at 12:18 PM Dmitry Melnichuk <
>> >> >> dmitry.melnic...@nobitlost.com> wrote:
>> >> >>
>> >> >>> Stepan,
>> >> >>>
>> >> >>> Thank you for answering my question and for the updated results.
>> >> >>>
>> >> >>> I have ran the profiler (cProfile) against the benchmark code you
>> >> >>> provided and have not found any particular bottleneck. One cycle
>> took
>> >> me
>> >> >>> 434 μs, which is the same order of magnitude as your result.
>> >> >>>
>> >> >>> I will need more time to analyze the performance of my client and
>> >> find a
>> >> >>> way to improve it. But is it a real stopper/blocker for the client
>> >> >>> itself? If there are no other issues, may we merge and release the
>> >> >>> client? Plus submit a jira-improvement to further investigate the
>> >> >>> performance of the Python platform.
>> >> >>>
>> >> >>> Dmitry
>> >> >>>
>> >> >>> On 10/11/18 4:19 PM, Степан Пильщиков wrote:
>> >>  Dmitry,
>> >> 
>> >>  pip install -e from latest sources
>> >> 
>> >>  On Thu, 11 Oct 2018, 06:37 Dmitry Melnichuk, <
>> >> >>> dmitry.melnic...@nobitlost.com>
>> >>  wrote:
>> >> 
>> >> > Stepan!
>> >> >
>> >> > Please tell me one thing about how you created the environment
>> for
>> >> your
>> >> > benchmarks, namely: how did you install the Python client. Did
>> you
>> >> just
>> >> > do `pip install pyignite`, or did you pull my working branch from
>> >> the
>> >> > downstream repository and did `pip install -e
>> >> > ignite/modules/platforms/python`?
>> >> >
>> >> > I highly recommend the latter, because PyPI version do not yet
>> >> include
>> >> > the latest improvements I did thanks to Dmitriy “qvad”
>> Sherstobitov.
>> >> > These improvements can have a noticeable positive effect on
>> speed.
>> >> >
>> >> > Dmitry
>> >> >
>> >> > On 10/10/18 11:06 

Re: Python thin client

[Igor Sapego]

Hi,

I've just merged Python thin client to the master and ignite-2.7

Also, I like how the python's results improved and now are comparable to
node.js.

Great job, guys!

Best Regards,
Igor


On Sat, Oct 13, 2018 at 3:53 PM Степан Пильщиков 
wrote:

> Hi
>
> Made new run and client definitely become faster
> I think its right direction for improvements
>
> Also rerun java bench with compiler=none option
>
> All results you can get in
> https://issues.apache.org/jira/browse/IGNITE-9824
> (last comment)
>
> сб, 13 окт. 2018 г. в 4:56, Pavel Petroshenko :
>
> > Hi Stepan,
> >
> > Re your performance questions.
> >
> > Firstly, please pull out the latest sources from the ignite-7782 branch
> as
> > it has some performance optimizations recently implemented.
> >
> > Secondly, Hotspot is a pretty advanced dynamic adaptive compiler and it's
> > not fair to compare it to a purely interpreted Python language
> > implementation. To get comparable results, please run your Java benchmark
> > with -Djava.compiler=NONE. It turns the dynamic compiler off at runtime.
> I
> > just did this exercise myself and got comparable scores.
> >
> > Please let me know if you still see any significant difference with the
> > flag set.
> >
> > Thanks,
> > P.
> >
> > On Fri, Oct 12, 2018 at 10:02 AM Dmitry Melnichuk <
> > dmitry.melnic...@nobitlost.com> wrote:
> >
> >> Igor,
> >>
> >> I fixed my files.
> >>
> >> Dmitry
> >>
> >> On 10/13/18 12:14 AM, Igor Sapego wrote:
> >> > Dmitry,
> >> >
> >> > I've run the tests and it appears that there are a lot of files
> without
> >> > Apache
> >> > licenses in Python client: [1] (See Unapproved licenses list).
> >> >
> >> > Can you either add headers or exclude file from the check, if you can
> >> not
> >> > add one? I.e. to this list: [2]
> >> >
> >> > [1] -
> >> >
> >>
> https://ci.ignite.apache.org/repository/download/IgniteTests24Java8_LicensesHeaders/2069024:id/rat.zip%21/target/rat.txt
> >> > [2] -
> https://github.com/apache/ignite/blob/master/parent/pom.xml#L817
> >> >
> >> > Best Regards,
> >> > Igor
> >> >
> >> >
> >> > On Thu, Oct 11, 2018 at 1:13 PM Igor Sapego 
> wrote:
> >> >
> >> >> Ok, I've filed a ticket [1] for the performance investigation and
> >> targeted
> >> >> it to 2.8. Feel free to assign it to yourself.
> >> >>
> >> >> I'm going to merge the ticket to master and ignite-2.7 branches by
> the
> >> >> end of the week, if no one have any objections.
> >> >>
> >> >> [1] - https://issues.apache.org/jira/browse/IGNITE-9850
> >> >>
> >> >> Best Regards,
> >> >> Igor
> >> >>
> >> >>
> >> >> On Thu, Oct 11, 2018 at 12:18 PM Dmitry Melnichuk <
> >> >> dmitry.melnic...@nobitlost.com> wrote:
> >> >>
> >> >>> Stepan,
> >> >>>
> >> >>> Thank you for answering my question and for the updated results.
> >> >>>
> >> >>> I have ran the profiler (cProfile) against the benchmark code you
> >> >>> provided and have not found any particular bottleneck. One cycle
> took
> >> me
> >> >>> 434 μs, which is the same order of magnitude as your result.
> >> >>>
> >> >>> I will need more time to analyze the performance of my client and
> >> find a
> >> >>> way to improve it. But is it a real stopper/blocker for the client
> >> >>> itself? If there are no other issues, may we merge and release the
> >> >>> client? Plus submit a jira-improvement to further investigate the
> >> >>> performance of the Python platform.
> >> >>>
> >> >>> Dmitry
> >> >>>
> >> >>> On 10/11/18 4:19 PM, Степан Пильщиков wrote:
> >>  Dmitry,
> >> 
> >>  pip install -e from latest sources
> >> 
> >>  On Thu, 11 Oct 2018, 06:37 Dmitry Melnichuk, <
> >> >>> dmitry.melnic...@nobitlost.com>
> >>  wrote:
> >> 
> >> > Stepan!
> >> >
> >> > Please tell me one thing about how you created the environment for
> >> your
> >> > benchmarks, namely: how did you install the Python client. Did you
> >> just
> >> > do `pip install pyignite`, or did you pull my working branch from
> >> the
> >> > downstream repository and did `pip install -e
> >> > ignite/modules/platforms/python`?
> >> >
> >> > I highly recommend the latter, because PyPI version do not yet
> >> include
> >> > the latest improvements I did thanks to Dmitriy “qvad”
> Sherstobitov.
> >> > These improvements can have a noticeable positive effect on speed.
> >> >
> >> > Dmitry
> >> >
> >> > On 10/10/18 11:06 PM, Степан Пильщиков wrote:
> >> >> Dmitry,
> >> >>
> >> >> Thanks for review
> >> >>
> >> >> Agree with all suggestions.
> >> >>
> >> >> Made and run new benches without any redundant operations
> (prints,
> >> >>> time
> >> >> calculation), only with "put" in "while true" cycle (almost)
> >> >> Case description, environment, results and code in ticket
> >> >> https://issues.apache.org/jira/browse/IGNITE-9824 (last comment)
> >> >>
> >> >> Please review new metrics
> >> >> Because picture is not changed so much, python still have
> >> 

Re: Python thin client

[Степан Пильщиков]

Hi

Made new run and client definitely become faster
I think its right direction for improvements

Also rerun java bench with compiler=none option

All results you can get in https://issues.apache.org/jira/browse/IGNITE-9824
(last comment)

сб, 13 окт. 2018 г. в 4:56, Pavel Petroshenko :

> Hi Stepan,
>
> Re your performance questions.
>
> Firstly, please pull out the latest sources from the ignite-7782 branch as
> it has some performance optimizations recently implemented.
>
> Secondly, Hotspot is a pretty advanced dynamic adaptive compiler and it's
> not fair to compare it to a purely interpreted Python language
> implementation. To get comparable results, please run your Java benchmark
> with -Djava.compiler=NONE. It turns the dynamic compiler off at runtime. I
> just did this exercise myself and got comparable scores.
>
> Please let me know if you still see any significant difference with the
> flag set.
>
> Thanks,
> P.
>
> On Fri, Oct 12, 2018 at 10:02 AM Dmitry Melnichuk <
> dmitry.melnic...@nobitlost.com> wrote:
>
>> Igor,
>>
>> I fixed my files.
>>
>> Dmitry
>>
>> On 10/13/18 12:14 AM, Igor Sapego wrote:
>> > Dmitry,
>> >
>> > I've run the tests and it appears that there are a lot of files without
>> > Apache
>> > licenses in Python client: [1] (See Unapproved licenses list).
>> >
>> > Can you either add headers or exclude file from the check, if you can
>> not
>> > add one? I.e. to this list: [2]
>> >
>> > [1] -
>> >
>> https://ci.ignite.apache.org/repository/download/IgniteTests24Java8_LicensesHeaders/2069024:id/rat.zip%21/target/rat.txt
>> > [2] - https://github.com/apache/ignite/blob/master/parent/pom.xml#L817
>> >
>> > Best Regards,
>> > Igor
>> >
>> >
>> > On Thu, Oct 11, 2018 at 1:13 PM Igor Sapego  wrote:
>> >
>> >> Ok, I've filed a ticket [1] for the performance investigation and
>> targeted
>> >> it to 2.8. Feel free to assign it to yourself.
>> >>
>> >> I'm going to merge the ticket to master and ignite-2.7 branches by the
>> >> end of the week, if no one have any objections.
>> >>
>> >> [1] - https://issues.apache.org/jira/browse/IGNITE-9850
>> >>
>> >> Best Regards,
>> >> Igor
>> >>
>> >>
>> >> On Thu, Oct 11, 2018 at 12:18 PM Dmitry Melnichuk <
>> >> dmitry.melnic...@nobitlost.com> wrote:
>> >>
>> >>> Stepan,
>> >>>
>> >>> Thank you for answering my question and for the updated results.
>> >>>
>> >>> I have ran the profiler (cProfile) against the benchmark code you
>> >>> provided and have not found any particular bottleneck. One cycle took
>> me
>> >>> 434 μs, which is the same order of magnitude as your result.
>> >>>
>> >>> I will need more time to analyze the performance of my client and
>> find a
>> >>> way to improve it. But is it a real stopper/blocker for the client
>> >>> itself? If there are no other issues, may we merge and release the
>> >>> client? Plus submit a jira-improvement to further investigate the
>> >>> performance of the Python platform.
>> >>>
>> >>> Dmitry
>> >>>
>> >>> On 10/11/18 4:19 PM, Степан Пильщиков wrote:
>>  Dmitry,
>> 
>>  pip install -e from latest sources
>> 
>>  On Thu, 11 Oct 2018, 06:37 Dmitry Melnichuk, <
>> >>> dmitry.melnic...@nobitlost.com>
>>  wrote:
>> 
>> > Stepan!
>> >
>> > Please tell me one thing about how you created the environment for
>> your
>> > benchmarks, namely: how did you install the Python client. Did you
>> just
>> > do `pip install pyignite`, or did you pull my working branch from
>> the
>> > downstream repository and did `pip install -e
>> > ignite/modules/platforms/python`?
>> >
>> > I highly recommend the latter, because PyPI version do not yet
>> include
>> > the latest improvements I did thanks to Dmitriy “qvad” Sherstobitov.
>> > These improvements can have a noticeable positive effect on speed.
>> >
>> > Dmitry
>> >
>> > On 10/10/18 11:06 PM, Степан Пильщиков wrote:
>> >> Dmitry,
>> >>
>> >> Thanks for review
>> >>
>> >> Agree with all suggestions.
>> >>
>> >> Made and run new benches without any redundant operations (prints,
>> >>> time
>> >> calculation), only with "put" in "while true" cycle (almost)
>> >> Case description, environment, results and code in ticket
>> >> https://issues.apache.org/jira/browse/IGNITE-9824 (last comment)
>> >>
>> >> Please review new metrics
>> >> Because picture is not changed so much, python still have
>> performance
>> > issues
>> >>
>> >
>> 
>> >>>
>> >>>
>> >
>>
>>

Re: Python thin client

[Pavel Petroshenko]

Hi Stepan,

Re your performance questions.

Firstly, please pull out the latest sources from the ignite-7782 branch as
it has some performance optimizations recently implemented.

Secondly, Hotspot is a pretty advanced dynamic adaptive compiler and it's
not fair to compare it to a purely interpreted Python language
implementation. To get comparable results, please run your Java benchmark
with -Djava.compiler=NONE. It turns the dynamic compiler off at runtime. I
just did this exercise myself and got comparable scores.

Please let me know if you still see any significant difference with the
flag set.

Thanks,
P.

On Fri, Oct 12, 2018 at 10:02 AM Dmitry Melnichuk <
dmitry.melnic...@nobitlost.com> wrote:

> Igor,
>
> I fixed my files.
>
> Dmitry
>
> On 10/13/18 12:14 AM, Igor Sapego wrote:
> > Dmitry,
> >
> > I've run the tests and it appears that there are a lot of files without
> > Apache
> > licenses in Python client: [1] (See Unapproved licenses list).
> >
> > Can you either add headers or exclude file from the check, if you can not
> > add one? I.e. to this list: [2]
> >
> > [1] -
> >
> https://ci.ignite.apache.org/repository/download/IgniteTests24Java8_LicensesHeaders/2069024:id/rat.zip%21/target/rat.txt
> > [2] - https://github.com/apache/ignite/blob/master/parent/pom.xml#L817
> >
> > Best Regards,
> > Igor
> >
> >
> > On Thu, Oct 11, 2018 at 1:13 PM Igor Sapego  wrote:
> >
> >> Ok, I've filed a ticket [1] for the performance investigation and
> targeted
> >> it to 2.8. Feel free to assign it to yourself.
> >>
> >> I'm going to merge the ticket to master and ignite-2.7 branches by the
> >> end of the week, if no one have any objections.
> >>
> >> [1] - https://issues.apache.org/jira/browse/IGNITE-9850
> >>
> >> Best Regards,
> >> Igor
> >>
> >>
> >> On Thu, Oct 11, 2018 at 12:18 PM Dmitry Melnichuk <
> >> dmitry.melnic...@nobitlost.com> wrote:
> >>
> >>> Stepan,
> >>>
> >>> Thank you for answering my question and for the updated results.
> >>>
> >>> I have ran the profiler (cProfile) against the benchmark code you
> >>> provided and have not found any particular bottleneck. One cycle took
> me
> >>> 434 μs, which is the same order of magnitude as your result.
> >>>
> >>> I will need more time to analyze the performance of my client and find
> a
> >>> way to improve it. But is it a real stopper/blocker for the client
> >>> itself? If there are no other issues, may we merge and release the
> >>> client? Plus submit a jira-improvement to further investigate the
> >>> performance of the Python platform.
> >>>
> >>> Dmitry
> >>>
> >>> On 10/11/18 4:19 PM, Степан Пильщиков wrote:
>  Dmitry,
> 
>  pip install -e from latest sources
> 
>  On Thu, 11 Oct 2018, 06:37 Dmitry Melnichuk, <
> >>> dmitry.melnic...@nobitlost.com>
>  wrote:
> 
> > Stepan!
> >
> > Please tell me one thing about how you created the environment for
> your
> > benchmarks, namely: how did you install the Python client. Did you
> just
> > do `pip install pyignite`, or did you pull my working branch from the
> > downstream repository and did `pip install -e
> > ignite/modules/platforms/python`?
> >
> > I highly recommend the latter, because PyPI version do not yet
> include
> > the latest improvements I did thanks to Dmitriy “qvad” Sherstobitov.
> > These improvements can have a noticeable positive effect on speed.
> >
> > Dmitry
> >
> > On 10/10/18 11:06 PM, Степан Пильщиков wrote:
> >> Dmitry,
> >>
> >> Thanks for review
> >>
> >> Agree with all suggestions.
> >>
> >> Made and run new benches without any redundant operations (prints,
> >>> time
> >> calculation), only with "put" in "while true" cycle (almost)
> >> Case description, environment, results and code in ticket
> >> https://issues.apache.org/jira/browse/IGNITE-9824 (last comment)
> >>
> >> Please review new metrics
> >> Because picture is not changed so much, python still have
> performance
> > issues
> >>
> >
> 
> >>>
> >>>
> >
>
>

Re: Python thin client

[Dmitry Melnichuk]

Igor,

I fixed my files.

Dmitry

On 10/13/18 12:14 AM, Igor Sapego wrote:

Dmitry,

I've run the tests and it appears that there are a lot of files without
Apache
licenses in Python client: [1] (See Unapproved licenses list).

Can you either add headers or exclude file from the check, if you can not
add one? I.e. to this list: [2]

[1] -
https://ci.ignite.apache.org/repository/download/IgniteTests24Java8_LicensesHeaders/2069024:id/rat.zip%21/target/rat.txt
[2] - https://github.com/apache/ignite/blob/master/parent/pom.xml#L817

Best Regards,
Igor


On Thu, Oct 11, 2018 at 1:13 PM Igor Sapego  wrote:


Ok, I've filed a ticket [1] for the performance investigation and targeted
it to 2.8. Feel free to assign it to yourself.

I'm going to merge the ticket to master and ignite-2.7 branches by the
end of the week, if no one have any objections.

[1] - https://issues.apache.org/jira/browse/IGNITE-9850

Best Regards,
Igor


On Thu, Oct 11, 2018 at 12:18 PM Dmitry Melnichuk <
dmitry.melnic...@nobitlost.com> wrote:


Stepan,

Thank you for answering my question and for the updated results.

I have ran the profiler (cProfile) against the benchmark code you
provided and have not found any particular bottleneck. One cycle took me
434 μs, which is the same order of magnitude as your result.

I will need more time to analyze the performance of my client and find a
way to improve it. But is it a real stopper/blocker for the client
itself? If there are no other issues, may we merge and release the
client? Plus submit a jira-improvement to further investigate the
performance of the Python platform.

Dmitry

On 10/11/18 4:19 PM, Степан Пильщиков wrote:

Dmitry,

pip install -e from latest sources

On Thu, 11 Oct 2018, 06:37 Dmitry Melnichuk, <

dmitry.melnic...@nobitlost.com>

wrote:


Stepan!

Please tell me one thing about how you created the environment for your
benchmarks, namely: how did you install the Python client. Did you just
do `pip install pyignite`, or did you pull my working branch from the
downstream repository and did `pip install -e
ignite/modules/platforms/python`?

I highly recommend the latter, because PyPI version do not yet include
the latest improvements I did thanks to Dmitriy “qvad” Sherstobitov.
These improvements can have a noticeable positive effect on speed.

Dmitry

On 10/10/18 11:06 PM, Степан Пильщиков wrote:

Dmitry,

Thanks for review

Agree with all suggestions.

Made and run new benches without any redundant operations (prints,

time

calculation), only with "put" in "while true" cycle (almost)
Case description, environment, results and code in ticket
https://issues.apache.org/jira/browse/IGNITE-9824 (last comment)

Please review new metrics
Because picture is not changed so much, python still have performance

issues

Re: Python thin client

[Igor Sapego]

Dmitry,

I've run the tests and it appears that there are a lot of files without
Apache
licenses in Python client: [1] (See Unapproved licenses list).

Can you either add headers or exclude file from the check, if you can not
add one? I.e. to this list: [2]

[1] -
https://ci.ignite.apache.org/repository/download/IgniteTests24Java8_LicensesHeaders/2069024:id/rat.zip%21/target/rat.txt
[2] - https://github.com/apache/ignite/blob/master/parent/pom.xml#L817

Best Regards,
Igor


On Thu, Oct 11, 2018 at 1:13 PM Igor Sapego  wrote:

> Ok, I've filed a ticket [1] for the performance investigation and targeted
> it to 2.8. Feel free to assign it to yourself.
>
> I'm going to merge the ticket to master and ignite-2.7 branches by the
> end of the week, if no one have any objections.
>
> [1] - https://issues.apache.org/jira/browse/IGNITE-9850
>
> Best Regards,
> Igor
>
>
> On Thu, Oct 11, 2018 at 12:18 PM Dmitry Melnichuk <
> dmitry.melnic...@nobitlost.com> wrote:
>
>> Stepan,
>>
>> Thank you for answering my question and for the updated results.
>>
>> I have ran the profiler (cProfile) against the benchmark code you
>> provided and have not found any particular bottleneck. One cycle took me
>> 434 μs, which is the same order of magnitude as your result.
>>
>> I will need more time to analyze the performance of my client and find a
>> way to improve it. But is it a real stopper/blocker for the client
>> itself? If there are no other issues, may we merge and release the
>> client? Plus submit a jira-improvement to further investigate the
>> performance of the Python platform.
>>
>> Dmitry
>>
>> On 10/11/18 4:19 PM, Степан Пильщиков wrote:
>> > Dmitry,
>> >
>> > pip install -e from latest sources
>> >
>> > On Thu, 11 Oct 2018, 06:37 Dmitry Melnichuk, <
>> dmitry.melnic...@nobitlost.com>
>> > wrote:
>> >
>> >> Stepan!
>> >>
>> >> Please tell me one thing about how you created the environment for your
>> >> benchmarks, namely: how did you install the Python client. Did you just
>> >> do `pip install pyignite`, or did you pull my working branch from the
>> >> downstream repository and did `pip install -e
>> >> ignite/modules/platforms/python`?
>> >>
>> >> I highly recommend the latter, because PyPI version do not yet include
>> >> the latest improvements I did thanks to Dmitriy “qvad” Sherstobitov.
>> >> These improvements can have a noticeable positive effect on speed.
>> >>
>> >> Dmitry
>> >>
>> >> On 10/10/18 11:06 PM, Степан Пильщиков wrote:
>> >>> Dmitry,
>> >>>
>> >>> Thanks for review
>> >>>
>> >>> Agree with all suggestions.
>> >>>
>> >>> Made and run new benches without any redundant operations (prints,
>> time
>> >>> calculation), only with "put" in "while true" cycle (almost)
>> >>> Case description, environment, results and code in ticket
>> >>> https://issues.apache.org/jira/browse/IGNITE-9824 (last comment)
>> >>>
>> >>> Please review new metrics
>> >>> Because picture is not changed so much, python still have performance
>> >> issues
>> >>>
>> >>
>> >
>>
>>

Re: Python thin client

[Igor Sapego]

Ok, I've filed a ticket [1] for the performance investigation and targeted
it to 2.8. Feel free to assign it to yourself.

I'm going to merge the ticket to master and ignite-2.7 branches by the
end of the week, if no one have any objections.

[1] - https://issues.apache.org/jira/browse/IGNITE-9850

Best Regards,
Igor


On Thu, Oct 11, 2018 at 12:18 PM Dmitry Melnichuk <
dmitry.melnic...@nobitlost.com> wrote:

> Stepan,
>
> Thank you for answering my question and for the updated results.
>
> I have ran the profiler (cProfile) against the benchmark code you
> provided and have not found any particular bottleneck. One cycle took me
> 434 μs, which is the same order of magnitude as your result.
>
> I will need more time to analyze the performance of my client and find a
> way to improve it. But is it a real stopper/blocker for the client
> itself? If there are no other issues, may we merge and release the
> client? Plus submit a jira-improvement to further investigate the
> performance of the Python platform.
>
> Dmitry
>
> On 10/11/18 4:19 PM, Степан Пильщиков wrote:
> > Dmitry,
> >
> > pip install -e from latest sources
> >
> > On Thu, 11 Oct 2018, 06:37 Dmitry Melnichuk, <
> dmitry.melnic...@nobitlost.com>
> > wrote:
> >
> >> Stepan!
> >>
> >> Please tell me one thing about how you created the environment for your
> >> benchmarks, namely: how did you install the Python client. Did you just
> >> do `pip install pyignite`, or did you pull my working branch from the
> >> downstream repository and did `pip install -e
> >> ignite/modules/platforms/python`?
> >>
> >> I highly recommend the latter, because PyPI version do not yet include
> >> the latest improvements I did thanks to Dmitriy “qvad” Sherstobitov.
> >> These improvements can have a noticeable positive effect on speed.
> >>
> >> Dmitry
> >>
> >> On 10/10/18 11:06 PM, Степан Пильщиков wrote:
> >>> Dmitry,
> >>>
> >>> Thanks for review
> >>>
> >>> Agree with all suggestions.
> >>>
> >>> Made and run new benches without any redundant operations (prints, time
> >>> calculation), only with "put" in "while true" cycle (almost)
> >>> Case description, environment, results and code in ticket
> >>> https://issues.apache.org/jira/browse/IGNITE-9824 (last comment)
> >>>
> >>> Please review new metrics
> >>> Because picture is not changed so much, python still have performance
> >> issues
> >>>
> >>
> >
>
>

Re: Python thin client

[Dmitry Melnichuk]

Stepan,

Thank you for answering my question and for the updated results.

I have ran the profiler (cProfile) against the benchmark code you 
provided and have not found any particular bottleneck. One cycle took me 
434 μs, which is the same order of magnitude as your result.


I will need more time to analyze the performance of my client and find a 
way to improve it. But is it a real stopper/blocker for the client 
itself? If there are no other issues, may we merge and release the 
client? Plus submit a jira-improvement to further investigate the 
performance of the Python platform.


Dmitry

On 10/11/18 4:19 PM, Степан Пильщиков wrote:

Dmitry,

pip install -e from latest sources

On Thu, 11 Oct 2018, 06:37 Dmitry Melnichuk, 
wrote:


Stepan!

Please tell me one thing about how you created the environment for your
benchmarks, namely: how did you install the Python client. Did you just
do `pip install pyignite`, or did you pull my working branch from the
downstream repository and did `pip install -e
ignite/modules/platforms/python`?

I highly recommend the latter, because PyPI version do not yet include
the latest improvements I did thanks to Dmitriy “qvad” Sherstobitov.
These improvements can have a noticeable positive effect on speed.

Dmitry

On 10/10/18 11:06 PM, Степан Пильщиков wrote:

Dmitry,

Thanks for review

Agree with all suggestions.

Made and run new benches without any redundant operations (prints, time
calculation), only with "put" in "while true" cycle (almost)
Case description, environment, results and code in ticket
https://issues.apache.org/jira/browse/IGNITE-9824 (last comment)

Please review new metrics
Because picture is not changed so much, python still have performance

issues

Re: Python thin client

[Степан Пильщиков]

Dmitry,

pip install -e from latest sources

On Thu, 11 Oct 2018, 06:37 Dmitry Melnichuk, 
wrote:

> Stepan!
>
> Please tell me one thing about how you created the environment for your
> benchmarks, namely: how did you install the Python client. Did you just
> do `pip install pyignite`, or did you pull my working branch from the
> downstream repository and did `pip install -e
> ignite/modules/platforms/python`?
>
> I highly recommend the latter, because PyPI version do not yet include
> the latest improvements I did thanks to Dmitriy “qvad” Sherstobitov.
> These improvements can have a noticeable positive effect on speed.
>
> Dmitry
>
> On 10/10/18 11:06 PM, Степан Пильщиков wrote:
> > Dmitry,
> >
> > Thanks for review
> >
> > Agree with all suggestions.
> >
> > Made and run new benches without any redundant operations (prints, time
> > calculation), only with "put" in "while true" cycle (almost)
> > Case description, environment, results and code in ticket
> > https://issues.apache.org/jira/browse/IGNITE-9824 (last comment)
> >
> > Please review new metrics
> > Because picture is not changed so much, python still have performance
> issues
> >
>

Re: Python thin client

[Dmitry Melnichuk]

Stepan!

Please tell me one thing about how you created the environment for your 
benchmarks, namely: how did you install the Python client. Did you just 
do `pip install pyignite`, or did you pull my working branch from the 
downstream repository and did `pip install -e 
ignite/modules/platforms/python`?


I highly recommend the latter, because PyPI version do not yet include 
the latest improvements I did thanks to Dmitriy “qvad” Sherstobitov. 
These improvements can have a noticeable positive effect on speed.


Dmitry

On 10/10/18 11:06 PM, Степан Пильщиков wrote:

Dmitry,

Thanks for review

Agree with all suggestions.

Made and run new benches without any redundant operations (prints, time
calculation), only with "put" in "while true" cycle (almost)
Case description, environment, results and code in ticket
https://issues.apache.org/jira/browse/IGNITE-9824 (last comment)

Please review new metrics
Because picture is not changed so much, python still have performance issues

Re: Python thin client

[Степан Пильщиков]

Dmitry,

Thanks for review

Agree with all suggestions.

Made and run new benches without any redundant operations (prints, time
calculation), only with "put" in "while true" cycle (almost)
Case description, environment, results and code in ticket
https://issues.apache.org/jira/browse/IGNITE-9824 (last comment)

Please review new metrics
Because picture is not changed so much, python still have performance issues

ср, 10 окт. 2018 г. в 12:30, Dmitry Melnichuk <
dmitry.melnic...@nobitlost.com>:

> Stepan!
>
> Can you please update the benchmarks based on my suggestions earlier in
> this thread: use a cleaner time profiling for the loop, remove
> unnecessary operations (string formatting, rounding operations), stick
> to the primitive int value for put operations (agree with Vladimir,
> let's keep it simple). And let me know the results.
>
> On 10/10/18 5:46 PM, Vladimir Ozerov wrote:
> > Hi Dmitry,
> >
> > I agree with your comments on benchmarking code. As more fair
> > alternative we may measure time of loading N elements into the cache, so
> > that it will be necessary to call time() only twice. However, provided
> > that we have real network here, and according to numbers one PUT in
> > Python client requires about 0.3 msec, I hardly can imagine that call to
> > time() or round() may dominate in that response time. But I said, we can
> > easily rule that out by slight benchmark rewrite.
> >
> > As far as serialization, I would prefer to keep primitive objects at the
> > moment, because AFAIK the purpose of the benchmark was to assess
> > underlying infrastructure, looking for some obvious performance issues.
> > Every platform have sockets which use more or less the same API of
> > underlying OS. To the contrast, performance of serialization mechanics
> > may differ widely between platforms depending on implementation. E.g. in
> > Java we spend a lot of time on fine-grained tuning, applied a lot of
> > speculative optimizations. Add to this JIT nature of Java, and you will
> > hardly ever beat Java serialization engine from any interpreted
> > language. So primitive data types make good sense to me.
> >
> > At this point our goal is not make Python equally fast with other
> > platforms, but rather to understand why is it slower than others. Ignite
> > is a product which brings speed to end users. If they do no have speed,
> > they will not use Ignite. So performance questions are always of great
> > importance for us.
> >
> > Vladimir.
> >
> > On Wed, Oct 10, 2018 at 9:57 AM Dmitry Melnichuk
> > mailto:dmitry.melnic...@nobitlost.com>>
>
> > wrote:
> >
> > Hi, Stepan!
> >
> > I looked at the benchmark code and the overall methodics, discussed
> it
> > with fellow programmers, and came up with basically two remarks.
> >
> > First of all, I think, the key for the good (or, at least,
> > unobjectionable) measurement is to isolate the object being measured
> > from the influence of the measurement tool. The usual pattern we use
> in
> > Python looks like:
> >
> > ```
> > from time import time
> >
> >
> > bench_start = time()
> >
> > for _ in range(number_of_tests):
> >   do_test()
> >
> > bench_end = time()
> >
> > print('Performance is {} tests per second'.format(
> >   number_of_tests / (bench_end - bench_start)
> > ))
> > ```
> >
> > I think, you got the idea: the measurement consists almost solely of
> > the
> > time taken by our subject function `do_test`. As few other code as
> > possible influence the result.
> >
> > Now, let's take a look at your code:
> >
> > https://gist.github.com/pilshchikov/8aff4e30d83f8bac20c5a4a9c3917abb
> >
> > Ideally, the `while` loop should include only `cache.put(last_key,
> > some_precomputed_value)`. But instead it also includes:
> >
> > - a series of the `time()` calls, which could be mostly excluded from
> > the measured time, if the measurement done right; each call is
> probably
> > addresses the HPET device, or network time, or both,
> >
> > - some floating-point calculations, including `round()`, which is
> > hardly
> > necessary,
> >
> > - formatting and output of the intermediate result.
> >
> > I suppose the measurement influence can be quite significant here,
> but
> > it is at least more or less constant for each test.
> >
> > But if we look at the other benchmarks:
> >
> > https://gist.github.com/pilshchikov/8a4bdb03a8304136c22c9bf7217ee447
> > [Node.js]
> > https://gist.github.com/pilshchikov/b4351d78ad59e9cd923689c2e387bc80
> > [PHP]
> > https://gist.github.com/pilshchikov/08096c78b425e00166a2ffa2aa5f49ce
> > [Java]
> >
> > The extra code that influence the measurement is not equivalent
> across
> > all platforms. For example, PHP's `time()` is most probably lighter
> > than
> > Python `time()`, since it do not give out milliseconds and may
> address
> > RTC, not 

Re: Python thin client

[Dmitry Melnichuk]

Stepan!

Can you please update the benchmarks based on my suggestions earlier in 
this thread: use a cleaner time profiling for the loop, remove 
unnecessary operations (string formatting, rounding operations), stick 
to the primitive int value for put operations (agree with Vladimir, 
let's keep it simple). And let me know the results.


On 10/10/18 5:46 PM, Vladimir Ozerov wrote:

Hi Dmitry,

I agree with your comments on benchmarking code. As more fair 
alternative we may measure time of loading N elements into the cache, so 
that it will be necessary to call time() only twice. However, provided 
that we have real network here, and according to numbers one PUT in 
Python client requires about 0.3 msec, I hardly can imagine that call to 
time() or round() may dominate in that response time. But I said, we can 
easily rule that out by slight benchmark rewrite.


As far as serialization, I would prefer to keep primitive objects at the 
moment, because AFAIK the purpose of the benchmark was to assess 
underlying infrastructure, looking for some obvious performance issues. 
Every platform have sockets which use more or less the same API of 
underlying OS. To the contrast, performance of serialization mechanics 
may differ widely between platforms depending on implementation. E.g. in 
Java we spend a lot of time on fine-grained tuning, applied a lot of 
speculative optimizations. Add to this JIT nature of Java, and you will 
hardly ever beat Java serialization engine from any interpreted 
language. So primitive data types make good sense to me.


At this point our goal is not make Python equally fast with other 
platforms, but rather to understand why is it slower than others. Ignite 
is a product which brings speed to end users. If they do no have speed, 
they will not use Ignite. So performance questions are always of great 
importance for us.


Vladimir.

On Wed, Oct 10, 2018 at 9:57 AM Dmitry Melnichuk 
mailto:dmitry.melnic...@nobitlost.com>> 
wrote:


Hi, Stepan!

I looked at the benchmark code and the overall methodics, discussed it
with fellow programmers, and came up with basically two remarks.

First of all, I think, the key for the good (or, at least,
unobjectionable) measurement is to isolate the object being measured
from the influence of the measurement tool. The usual pattern we use in
Python looks like:

```
from time import time


bench_start = time()

for _ in range(number_of_tests):
      do_test()

bench_end = time()

print('Performance is {} tests per second'.format(
      number_of_tests / (bench_end - bench_start)
))
```

I think, you got the idea: the measurement consists almost solely of
the
time taken by our subject function `do_test`. As few other code as
possible influence the result.

Now, let's take a look at your code:

https://gist.github.com/pilshchikov/8aff4e30d83f8bac20c5a4a9c3917abb

Ideally, the `while` loop should include only `cache.put(last_key,
some_precomputed_value)`. But instead it also includes:

- a series of the `time()` calls, which could be mostly excluded from
the measured time, if the measurement done right; each call is probably
addresses the HPET device, or network time, or both,

- some floating-point calculations, including `round()`, which is
hardly
necessary,

- formatting and output of the intermediate result.

I suppose the measurement influence can be quite significant here, but
it is at least more or less constant for each test.

But if we look at the other benchmarks:

https://gist.github.com/pilshchikov/8a4bdb03a8304136c22c9bf7217ee447
[Node.js]
https://gist.github.com/pilshchikov/b4351d78ad59e9cd923689c2e387bc80
[PHP]
https://gist.github.com/pilshchikov/08096c78b425e00166a2ffa2aa5f49ce
[Java]

The extra code that influence the measurement is not equivalent across
all platforms. For example, PHP's `time()` is most probably lighter
than
Python `time()`, since it do not give out milliseconds and may address
RTC, not HPET. So the platform-to-platform comparison in your benchmark
does not look completely fair to me.

The second remark concerns not the measurement procedure, but the
object
being measured.

The only client operation being used is OP_CACHE_PUT with a payload
of a
primitive type. (BTW the type is `Long` in case of the Python client;
what about the other clients? Is it `Int`?) I afraid that such an
object, even being properly isolated from the measurement tool, would
show mostly the throughput of the underlying platform's sockets
implementation, not the performance of the client's code. To show the
potential of the thin client itself, more varied and fancy tasks
needed,
i. e. serialization/deserialization of the Complex objects.

But it depends on the goal of the benchmarking. If showing off the raw

Re: Python thin client

[Vladimir Ozerov]

Hi Dmitry,

I agree with your comments on benchmarking code. As more fair alternative
we may measure time of loading N elements into the cache, so that it will
be necessary to call time() only twice. However, provided that we have real
network here, and according to numbers one PUT in Python client requires
about 0.3 msec, I hardly can imagine that call to time() or round() may
dominate in that response time. But I said, we can easily rule that out by
slight benchmark rewrite.

As far as serialization, I would prefer to keep primitive objects at the
moment, because AFAIK the purpose of the benchmark was to assess underlying
infrastructure, looking for some obvious performance issues. Every platform
have sockets which use more or less the same API of underlying OS. To the
contrast, performance of serialization mechanics may differ widely between
platforms depending on implementation. E.g. in Java we spend a lot of time
on fine-grained tuning, applied a lot of speculative optimizations. Add to
this JIT nature of Java, and you will hardly ever beat Java serialization
engine from any interpreted language. So primitive data types make good
sense to me.

At this point our goal is not make Python equally fast with other
platforms, but rather to understand why is it slower than others. Ignite is
a product which brings speed to end users. If they do no have speed, they
will not use Ignite. So performance questions are always of great
importance for us.

Vladimir.

On Wed, Oct 10, 2018 at 9:57 AM Dmitry Melnichuk <
dmitry.melnic...@nobitlost.com> wrote:

> Hi, Stepan!
>
> I looked at the benchmark code and the overall methodics, discussed it
> with fellow programmers, and came up with basically two remarks.
>
> First of all, I think, the key for the good (or, at least,
> unobjectionable) measurement is to isolate the object being measured
> from the influence of the measurement tool. The usual pattern we use in
> Python looks like:
>
> ```
> from time import time
>
>
> bench_start = time()
>
> for _ in range(number_of_tests):
>  do_test()
>
> bench_end = time()
>
> print('Performance is {} tests per second'.format(
>  number_of_tests / (bench_end - bench_start)
> ))
> ```
>
> I think, you got the idea: the measurement consists almost solely of the
> time taken by our subject function `do_test`. As few other code as
> possible influence the result.
>
> Now, let's take a look at your code:
>
> https://gist.github.com/pilshchikov/8aff4e30d83f8bac20c5a4a9c3917abb
>
> Ideally, the `while` loop should include only `cache.put(last_key,
> some_precomputed_value)`. But instead it also includes:
>
> - a series of the `time()` calls, which could be mostly excluded from
> the measured time, if the measurement done right; each call is probably
> addresses the HPET device, or network time, or both,
>
> - some floating-point calculations, including `round()`, which is hardly
> necessary,
>
> - formatting and output of the intermediate result.
>
> I suppose the measurement influence can be quite significant here, but
> it is at least more or less constant for each test.
>
> But if we look at the other benchmarks:
>
> https://gist.github.com/pilshchikov/8a4bdb03a8304136c22c9bf7217ee447
> [Node.js]
> https://gist.github.com/pilshchikov/b4351d78ad59e9cd923689c2e387bc80 [PHP]
> https://gist.github.com/pilshchikov/08096c78b425e00166a2ffa2aa5f49ce
> [Java]
>
> The extra code that influence the measurement is not equivalent across
> all platforms. For example, PHP's `time()` is most probably lighter than
> Python `time()`, since it do not give out milliseconds and may address
> RTC, not HPET. So the platform-to-platform comparison in your benchmark
> does not look completely fair to me.
>
> The second remark concerns not the measurement procedure, but the object
> being measured.
>
> The only client operation being used is OP_CACHE_PUT with a payload of a
> primitive type. (BTW the type is `Long` in case of the Python client;
> what about the other clients? Is it `Int`?) I afraid that such an
> object, even being properly isolated from the measurement tool, would
> show mostly the throughput of the underlying platform's sockets
> implementation, not the performance of the client's code. To show the
> potential of the thin client itself, more varied and fancy tasks needed,
> i. e. serialization/deserialization of the Complex objects.
>
> But it depends on the goal of the benchmarking. If showing off the raw
> platform agility was intended, than this objection is removed.
>
> Dmitry
>
> On 10/9/18 10:50 PM, Stepan Pilshchikov wrote:
> > Hi, all
> >
> > Tried to compare new thin client performance and made similar benchmarks
> for
> > each one
> > And result not so good for python
> >
> > Ticket with results and bench code:
> > https://issues.apache.org/jira/browse/IGNITE-9824
> >
> > Py code src:
> > https://gist.github.com/pilshchikov/8aff4e30d83f8bac20c5a4a9c3917abb
> >
> > Dmitry, please review results and bench code, maybe 

Re: Python thin client

[Dmitry Melnichuk]

Hi, Stepan!

I looked at the benchmark code and the overall methodics, discussed it 
with fellow programmers, and came up with basically two remarks.


First of all, I think, the key for the good (or, at least, 
unobjectionable) measurement is to isolate the object being measured 
from the influence of the measurement tool. The usual pattern we use in 
Python looks like:


```
from time import time


bench_start = time()

for _ in range(number_of_tests):
do_test()

bench_end = time()

print('Performance is {} tests per second'.format(
number_of_tests / (bench_end - bench_start)
))
```

I think, you got the idea: the measurement consists almost solely of the 
time taken by our subject function `do_test`. As few other code as 
possible influence the result.


Now, let's take a look at your code:

https://gist.github.com/pilshchikov/8aff4e30d83f8bac20c5a4a9c3917abb

Ideally, the `while` loop should include only `cache.put(last_key, 
some_precomputed_value)`. But instead it also includes:


- a series of the `time()` calls, which could be mostly excluded from 
the measured time, if the measurement done right; each call is probably 
addresses the HPET device, or network time, or both,


- some floating-point calculations, including `round()`, which is hardly 
necessary,


- formatting and output of the intermediate result.

I suppose the measurement influence can be quite significant here, but 
it is at least more or less constant for each test.


But if we look at the other benchmarks:

https://gist.github.com/pilshchikov/8a4bdb03a8304136c22c9bf7217ee447 
[Node.js]

https://gist.github.com/pilshchikov/b4351d78ad59e9cd923689c2e387bc80 [PHP]
https://gist.github.com/pilshchikov/08096c78b425e00166a2ffa2aa5f49ce [Java]

The extra code that influence the measurement is not equivalent across 
all platforms. For example, PHP's `time()` is most probably lighter than 
Python `time()`, since it do not give out milliseconds and may address 
RTC, not HPET. So the platform-to-platform comparison in your benchmark 
does not look completely fair to me.


The second remark concerns not the measurement procedure, but the object 
being measured.


The only client operation being used is OP_CACHE_PUT with a payload of a 
primitive type. (BTW the type is `Long` in case of the Python client; 
what about the other clients? Is it `Int`?) I afraid that such an 
object, even being properly isolated from the measurement tool, would 
show mostly the throughput of the underlying platform's sockets 
implementation, not the performance of the client's code. To show the 
potential of the thin client itself, more varied and fancy tasks needed, 
i. e. serialization/deserialization of the Complex objects.


But it depends on the goal of the benchmarking. If showing off the raw 
platform agility was intended, than this objection is removed.


Dmitry

On 10/9/18 10:50 PM, Stepan Pilshchikov wrote:

Hi, all

Tried to compare new thin client performance and made similar benchmarks for
each one
And result not so good for python

Ticket with results and bench code:
https://issues.apache.org/jira/browse/IGNITE-9824

Py code src:
https://gist.github.com/pilshchikov/8aff4e30d83f8bac20c5a4a9c3917abb

Dmitry, please review results and bench code, maybe somthing wrong or it's
expected numbers?



--
Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/

Re: Python thin client

[Stepan Pilshchikov]

Hi, all

Tried to compare new thin client performance and made similar benchmarks for
each one
And result not so good for python

Ticket with results and bench code:
https://issues.apache.org/jira/browse/IGNITE-9824

Py code src:
https://gist.github.com/pilshchikov/8aff4e30d83f8bac20c5a4a9c3917abb

Dmitry, please review results and bench code, maybe somthing wrong or it's
expected numbers?



--
Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/

Re: Python thin client installation instructions

[Prachi Garg]

Yes, I will mention the prerequisites.

-Prachi

> On Sep 21, 2018, at 5:18 PM, Denis Magda  wrote:
> 
> I would add a disclaimer or a prerequisite step. That what other companies
> do if a user needs to do some basic installation steps. At least mention it.
> 
> --
> Denis
> 
>> On Fri, Sep 21, 2018 at 3:04 PM Prachi Garg  wrote:
>> 
>> Hi Dmitry,
>> 
>> Thank you for taking the time to explain me everything in such detail :)
>> 
>> I am trying to do this because I have to document. In general, I am
>> assuming that a Python thin client user would already have Python installed
>> and be using it. So, I would not suggest adding any disclaimers regarding
>> Python installation.
>> 
>> The example works with python3 command :)
>> 
>> 
>> -P
>> 
>> 
>> 
>> On Thu, Sep 20, 2018 at 8:31 PM, Dmitry Melnichuk <
>> dmitry.melnic...@nobitlost.com> wrote:
>> 
>>> Prachi,
>>> 
>>> I feel your struggle. It is easier for end user to perceive Python 2 and
>>> Python 3 as different languages, not as versions of one language. They
>>> usually installed alongside each other; their updates are handled
>>> separately. On most systems they have their respective shell commands:
>>> `python2` and `python3`.
>>> 
>>> Shell command `python` can be viewed as an alias of either `python2` or
>>> `python3`. I use an Arch Linux derivative, where `python` is `python3`.
>>> Most other GNU/Linux OSes use `python` as an alias of `python2`. I am not
>>> sure about MacOS. On Windows the latest Python distribution installed
>>> overrule PATH environment variables, so it impossible to predict the
>>> “default” Python version (2 or 3).
>>> 
>>> Luckily, virtualenv was introduced to leverage all these issues. It is
>>> able to handle multiple isolated Python environments, where the `python`
>>> command is set upon the creation of the environment, while the
>>> environment-specific package dependencies are handled transparently with
>>> pip.
>>> 
>>> But the use of pyignite should not be limited to virtualenv. There are
>>> many cases when the use of virtualenv is discouraged or even impossible.
>>> For example, when deploying Python app into an OS-level container or
>>> similar isolating environment, virtualenv would be just a useless
>> overhead.
>>> There are also non-standard Python distributions (used mostly on Windows)
>>> that do not support virtualenv.
>>> 
>>> I am sorry, that users who are not proficient in Python can have so many
>>> problems with following my documentation. But still it seems obvious for
>>> me, that all the details of organizing user's own Python environment are
>>> out of pyignite documentation's scope. The only thing I can suggest to
>>> improve my documentation in this regard is putting a big bold foreword
>> like
>>> this:
>>> 
>>>  It is assumed in this document that you know how to install
>>>  and use Python 3 on your system. Please consult your OS manual pages
>>>  or documentations of your specific Python 3 distribution regarding
>>>  the details of organizing your Python 3 environment. The use of
>>>  virualenv for development with pyignite is highly recommended.
>>> 
>>> But, frankly, I have not seen such disclaimers in the wild and not sure
>> if
>>> it would be useful. It is very vague and do not cover any of the
>> potential
>>> pitfalls.
>>> 
>>> I am sorry for giving such a lengthy explanation here, though I've been
>>> asked a very specific question. I understand you may not have time to
>>> invest in learning virtualenv. If so, you did everything right, just use
>>> `python3` command for launching examples:
>>> 
>>> ```
>>> $ python3 get_and_put.py
>>> ```
>>> 
 On 9/21/18 10:34 AM, Prachi Garg wrote:
 
 Hi Dmitry,
 
 Sorry, I am not familiar with Python.
 
 So there are more issues...
 
 1. The version on my mac remains 2.7.10 even though I tried to link to
 the new version.
 
 ~$ python --version
 Python 2.7.10
 
 ~$ brew unlink python && brew link --overwrite python3
 Unlinking /usr/local/Cellar/python/3.7.0. .. 25 symlinks
 removed
 Linking /usr/local/Cellar/python/3.7.0. .. 25 symlinks
 created
 
 ~$ python --version
 Python 2.7.10
 
 2. Then I tried to update /pip/, uninstall and re-install /pyignite/
 
 ~$ pip install -U pip
 -bash: /Library/Frameworks/Python.framework/Versions/3.7/bin/pip: No
 such file or directory
 ~$ pip3 install -U pip
 Requirement already up-to-date: pip in /Library/Frameworks/Python.fra
 mework/Versions/3.7/lib/python3.7/site-packages (18.0)
 
 ~$ pip3 uninstall pyignite
 Uninstalling pyignite-0.3.0:
   Would remove:
 /Library/Frameworks/Python.framework/Versions/3.7/lib/pytho
 n3.7/site-packages/pyignite-0.3.0.dist-info/*
 /Library/Frameworks/Python.framework/Versions/3.7/lib/pytho
 n3.7/site-packages/pyignite/*
 Proceed (y/n)? y
   Successfully uninstalled 

Re: Python thin client installation instructions

[Denis Magda]

I would add a disclaimer or a prerequisite step. That what other companies
do if a user needs to do some basic installation steps. At least mention it.

--
Denis

On Fri, Sep 21, 2018 at 3:04 PM Prachi Garg  wrote:

> Hi Dmitry,
>
> Thank you for taking the time to explain me everything in such detail :)
>
> I am trying to do this because I have to document. In general, I am
> assuming that a Python thin client user would already have Python installed
> and be using it. So, I would not suggest adding any disclaimers regarding
> Python installation.
>
> The example works with python3 command :)
>
>
> -P
>
>
>
> On Thu, Sep 20, 2018 at 8:31 PM, Dmitry Melnichuk <
> dmitry.melnic...@nobitlost.com> wrote:
>
> > Prachi,
> >
> > I feel your struggle. It is easier for end user to perceive Python 2 and
> > Python 3 as different languages, not as versions of one language. They
> > usually installed alongside each other; their updates are handled
> > separately. On most systems they have their respective shell commands:
> > `python2` and `python3`.
> >
> > Shell command `python` can be viewed as an alias of either `python2` or
> > `python3`. I use an Arch Linux derivative, where `python` is `python3`.
> > Most other GNU/Linux OSes use `python` as an alias of `python2`. I am not
> > sure about MacOS. On Windows the latest Python distribution installed
> > overrule PATH environment variables, so it impossible to predict the
> > “default” Python version (2 or 3).
> >
> > Luckily, virtualenv was introduced to leverage all these issues. It is
> > able to handle multiple isolated Python environments, where the `python`
> > command is set upon the creation of the environment, while the
> > environment-specific package dependencies are handled transparently with
> > pip.
> >
> > But the use of pyignite should not be limited to virtualenv. There are
> > many cases when the use of virtualenv is discouraged or even impossible.
> > For example, when deploying Python app into an OS-level container or
> > similar isolating environment, virtualenv would be just a useless
> overhead.
> > There are also non-standard Python distributions (used mostly on Windows)
> > that do not support virtualenv.
> >
> > I am sorry, that users who are not proficient in Python can have so many
> > problems with following my documentation. But still it seems obvious for
> > me, that all the details of organizing user's own Python environment are
> > out of pyignite documentation's scope. The only thing I can suggest to
> > improve my documentation in this regard is putting a big bold foreword
> like
> > this:
> >
> >   It is assumed in this document that you know how to install
> >   and use Python 3 on your system. Please consult your OS manual pages
> >   or documentations of your specific Python 3 distribution regarding
> >   the details of organizing your Python 3 environment. The use of
> >   virualenv for development with pyignite is highly recommended.
> >
> > But, frankly, I have not seen such disclaimers in the wild and not sure
> if
> > it would be useful. It is very vague and do not cover any of the
> potential
> > pitfalls.
> >
> > I am sorry for giving such a lengthy explanation here, though I've been
> > asked a very specific question. I understand you may not have time to
> > invest in learning virtualenv. If so, you did everything right, just use
> > `python3` command for launching examples:
> >
> > ```
> > $ python3 get_and_put.py
> > ```
> >
> > On 9/21/18 10:34 AM, Prachi Garg wrote:
> >
> >> Hi Dmitry,
> >>
> >> Sorry, I am not familiar with Python.
> >>
> >> So there are more issues...
> >>
> >> 1. The version on my mac remains 2.7.10 even though I tried to link to
> >> the new version.
> >>
> >> ~$ python --version
> >> Python 2.7.10
> >>
> >> ~$ brew unlink python && brew link --overwrite python3
> >> Unlinking /usr/local/Cellar/python/3.7.0. .. 25 symlinks
> >> removed
> >> Linking /usr/local/Cellar/python/3.7.0. .. 25 symlinks
> >> created
> >>
> >> ~$ python --version
> >> Python 2.7.10
> >>
> >> 2. Then I tried to update /pip/, uninstall and re-install /pyignite/
> >>
> >> ~$ pip install -U pip
> >> -bash: /Library/Frameworks/Python.framework/Versions/3.7/bin/pip: No
> >> such file or directory
> >> ~$ pip3 install -U pip
> >> Requirement already up-to-date: pip in /Library/Frameworks/Python.fra
> >> mework/Versions/3.7/lib/python3.7/site-packages (18.0)
> >>
> >> ~$ pip3 uninstall pyignite
> >> Uninstalling pyignite-0.3.0:
> >>Would remove:
> >>  /Library/Frameworks/Python.framework/Versions/3.7/lib/pytho
> >> n3.7/site-packages/pyignite-0.3.0.dist-info/*
> >>  /Library/Frameworks/Python.framework/Versions/3.7/lib/pytho
> >> n3.7/site-packages/pyignite/*
> >> Proceed (y/n)? y
> >>Successfully uninstalled pyignite-0.3.0
> >>
> >> ~$ pip3 install pyignite
> >> Collecting pyignite
> >>Using cached https://files.pythonhosted.org
> >> 

Re: Python thin client installation instructions

[Prachi Garg]

Hi Dmitry,

Thank you for taking the time to explain me everything in such detail :)

I am trying to do this because I have to document. In general, I am
assuming that a Python thin client user would already have Python installed
and be using it. So, I would not suggest adding any disclaimers regarding
Python installation.

The example works with python3 command :)


-P



On Thu, Sep 20, 2018 at 8:31 PM, Dmitry Melnichuk <
dmitry.melnic...@nobitlost.com> wrote:

> Prachi,
>
> I feel your struggle. It is easier for end user to perceive Python 2 and
> Python 3 as different languages, not as versions of one language. They
> usually installed alongside each other; their updates are handled
> separately. On most systems they have their respective shell commands:
> `python2` and `python3`.
>
> Shell command `python` can be viewed as an alias of either `python2` or
> `python3`. I use an Arch Linux derivative, where `python` is `python3`.
> Most other GNU/Linux OSes use `python` as an alias of `python2`. I am not
> sure about MacOS. On Windows the latest Python distribution installed
> overrule PATH environment variables, so it impossible to predict the
> “default” Python version (2 or 3).
>
> Luckily, virtualenv was introduced to leverage all these issues. It is
> able to handle multiple isolated Python environments, where the `python`
> command is set upon the creation of the environment, while the
> environment-specific package dependencies are handled transparently with
> pip.
>
> But the use of pyignite should not be limited to virtualenv. There are
> many cases when the use of virtualenv is discouraged or even impossible.
> For example, when deploying Python app into an OS-level container or
> similar isolating environment, virtualenv would be just a useless overhead.
> There are also non-standard Python distributions (used mostly on Windows)
> that do not support virtualenv.
>
> I am sorry, that users who are not proficient in Python can have so many
> problems with following my documentation. But still it seems obvious for
> me, that all the details of organizing user's own Python environment are
> out of pyignite documentation's scope. The only thing I can suggest to
> improve my documentation in this regard is putting a big bold foreword like
> this:
>
>   It is assumed in this document that you know how to install
>   and use Python 3 on your system. Please consult your OS manual pages
>   or documentations of your specific Python 3 distribution regarding
>   the details of organizing your Python 3 environment. The use of
>   virualenv for development with pyignite is highly recommended.
>
> But, frankly, I have not seen such disclaimers in the wild and not sure if
> it would be useful. It is very vague and do not cover any of the potential
> pitfalls.
>
> I am sorry for giving such a lengthy explanation here, though I've been
> asked a very specific question. I understand you may not have time to
> invest in learning virtualenv. If so, you did everything right, just use
> `python3` command for launching examples:
>
> ```
> $ python3 get_and_put.py
> ```
>
> On 9/21/18 10:34 AM, Prachi Garg wrote:
>
>> Hi Dmitry,
>>
>> Sorry, I am not familiar with Python.
>>
>> So there are more issues...
>>
>> 1. The version on my mac remains 2.7.10 even though I tried to link to
>> the new version.
>>
>> ~$ python --version
>> Python 2.7.10
>>
>> ~$ brew unlink python && brew link --overwrite python3
>> Unlinking /usr/local/Cellar/python/3.7.0. .. 25 symlinks
>> removed
>> Linking /usr/local/Cellar/python/3.7.0. .. 25 symlinks
>> created
>>
>> ~$ python --version
>> Python 2.7.10
>>
>> 2. Then I tried to update /pip/, uninstall and re-install /pyignite/
>>
>> ~$ pip install -U pip
>> -bash: /Library/Frameworks/Python.framework/Versions/3.7/bin/pip: No
>> such file or directory
>> ~$ pip3 install -U pip
>> Requirement already up-to-date: pip in /Library/Frameworks/Python.fra
>> mework/Versions/3.7/lib/python3.7/site-packages (18.0)
>>
>> ~$ pip3 uninstall pyignite
>> Uninstalling pyignite-0.3.0:
>>Would remove:
>>  /Library/Frameworks/Python.framework/Versions/3.7/lib/pytho
>> n3.7/site-packages/pyignite-0.3.0.dist-info/*
>>  /Library/Frameworks/Python.framework/Versions/3.7/lib/pytho
>> n3.7/site-packages/pyignite/*
>> Proceed (y/n)? y
>>Successfully uninstalled pyignite-0.3.0
>>
>> ~$ pip3 install pyignite
>> Collecting pyignite
>>Using cached https://files.pythonhosted.org
>> /packages/f1/0f/5669cd63fb37fa2025110f61598450567d04a72c8cf5
>> b76bb0ca20c21734/pyignite-0.3.0-py3-none-any.whl
>> Requirement already satisfied: attrs==18.1.0 in
>> /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages
>> (from pyignite) (18.1.0)
>> Requirement already satisfied: typing==3.6.4 in
>> /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages
>> (from pyignite) (3.6.4)
>> Installing collected packages: pyignite
>> Successfully 

Re: Python thin client installation instructions

[Dmitry Melnichuk]

Prachi,

I feel your struggle. It is easier for end user to perceive Python 2 and 
Python 3 as different languages, not as versions of one language. They 
usually installed alongside each other; their updates are handled 
separately. On most systems they have their respective shell commands: 
`python2` and `python3`.


Shell command `python` can be viewed as an alias of either `python2` or 
`python3`. I use an Arch Linux derivative, where `python` is `python3`. 
Most other GNU/Linux OSes use `python` as an alias of `python2`. I am 
not sure about MacOS. On Windows the latest Python distribution 
installed overrule PATH environment variables, so it impossible to 
predict the “default” Python version (2 or 3).


Luckily, virtualenv was introduced to leverage all these issues. It is 
able to handle multiple isolated Python environments, where the `python` 
command is set upon the creation of the environment, while the 
environment-specific package dependencies are handled transparently with 
pip.


But the use of pyignite should not be limited to virtualenv. There are 
many cases when the use of virtualenv is discouraged or even impossible. 
For example, when deploying Python app into an OS-level container or 
similar isolating environment, virtualenv would be just a useless 
overhead. There are also non-standard Python distributions (used mostly 
on Windows) that do not support virtualenv.


I am sorry, that users who are not proficient in Python can have so many 
problems with following my documentation. But still it seems obvious for 
me, that all the details of organizing user's own Python environment are 
out of pyignite documentation's scope. The only thing I can suggest to 
improve my documentation in this regard is putting a big bold foreword 
like this:


  It is assumed in this document that you know how to install
  and use Python 3 on your system. Please consult your OS manual pages
  or documentations of your specific Python 3 distribution regarding
  the details of organizing your Python 3 environment. The use of
  virualenv for development with pyignite is highly recommended.

But, frankly, I have not seen such disclaimers in the wild and not sure 
if it would be useful. It is very vague and do not cover any of the 
potential pitfalls.


I am sorry for giving such a lengthy explanation here, though I've been 
asked a very specific question. I understand you may not have time to 
invest in learning virtualenv. If so, you did everything right, just use 
`python3` command for launching examples:


```
$ python3 get_and_put.py
```

On 9/21/18 10:34 AM, Prachi Garg wrote:

Hi Dmitry,

Sorry, I am not familiar with Python.

So there are more issues...

1. The version on my mac remains 2.7.10 even though I tried to link to 
the new version.


~$ python --version
Python 2.7.10

~$ brew unlink python && brew link --overwrite python3
Unlinking /usr/local/Cellar/python/3.7.0. .. 25 symlinks 
removed
Linking /usr/local/Cellar/python/3.7.0. .. 25 symlinks 
created


~$ python --version
Python 2.7.10

2. Then I tried to update /pip/, uninstall and re-install /pyignite/

~$ pip install -U pip
-bash: /Library/Frameworks/Python.framework/Versions/3.7/bin/pip: No 
such file or directory

~$ pip3 install -U pip
Requirement already up-to-date: pip in 
/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages 
(18.0)


~$ pip3 uninstall pyignite
Uninstalling pyignite-0.3.0:
   Would remove:
 
/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/pyignite-0.3.0.dist-info/*
 
/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/pyignite/*

Proceed (y/n)? y
   Successfully uninstalled pyignite-0.3.0

~$ pip3 install pyignite
Collecting pyignite
   Using cached 
https://files.pythonhosted.org/packages/f1/0f/5669cd63fb37fa2025110f61598450567d04a72c8cf5b76bb0ca20c21734/pyignite-0.3.0-py3-none-any.whl
Requirement already satisfied: attrs==18.1.0 in 
/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages 
(from pyignite) (18.1.0)
Requirement already satisfied: typing==3.6.4 in 
/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages 
(from pyignite) (3.6.4)

Installing collected packages: pyignite
Successfully installed pyignite-0.3.0


How can I fix this?

On Wed, Sep 19, 2018 at 6:43 PM, Dmitry Melnichuk 
mailto:dmitry.melnic...@nobitlost.com>> 
wrote:


Prachi,

This line in your message

> Requirement already satisfied: pyignite in
> ./Downloads/ignite-python/modules/platforms/python (0.3.1)

looks like you already did an installation of pyignite in this
environment before (maybe with "pip install -e ") from 'Downloads' folder, then delete or move downloaded
copy, and than tried to install pyignite again, this time from PyPI
("pip install ").

pip does not work this way. You should either undo the previous
install ("pip 

Re: Python thin client installation instructions

[Prachi Garg]

Hi Dmitry,

Sorry, I am not familiar with Python.

So there are more issues...

1. The version on my mac remains 2.7.10 even though I tried to link to the
new version.

~$ python --version
Python 2.7.10

~$ brew unlink python && brew link --overwrite python3
Unlinking /usr/local/Cellar/python/3.7.0... 25 symlinks removed
Linking /usr/local/Cellar/python/3.7.0... 25 symlinks created

~$ python --version
Python 2.7.10

2. Then I tried to update *pip*, uninstall and re-install *pyignite*

~$ pip install -U pip
-bash: /Library/Frameworks/Python.framework/Versions/3.7/bin/pip: No such
file or directory
~$ pip3 install -U pip
Requirement already up-to-date: pip in
/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages
(18.0)

~$ pip3 uninstall pyignite
Uninstalling pyignite-0.3.0:
  Would remove:

/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/pyignite-0.3.0.dist-info/*

/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/pyignite/*
Proceed (y/n)? y
  Successfully uninstalled pyignite-0.3.0

~$ pip3 install pyignite
Collecting pyignite
  Using cached
https://files.pythonhosted.org/packages/f1/0f/5669cd63fb37fa2025110f61598450567d04a72c8cf5b76bb0ca20c21734/pyignite-0.3.0-py3-none-any.whl
Requirement already satisfied: attrs==18.1.0 in
/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages
(from pyignite) (18.1.0)
Requirement already satisfied: typing==3.6.4 in
/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages
(from pyignite) (3.6.4)
Installing collected packages: pyignite
Successfully installed pyignite-0.3.0


How can I fix this?

On Wed, Sep 19, 2018 at 6:43 PM, Dmitry Melnichuk <
dmitry.melnic...@nobitlost.com> wrote:

> Prachi,
>
> This line in your message
>
> > Requirement already satisfied: pyignite in
> > ./Downloads/ignite-python/modules/platforms/python (0.3.1)
>
> looks like you already did an installation of pyignite in this environment
> before (maybe with "pip install -e ") from
> 'Downloads' folder, then delete or move downloaded copy, and than tried to
> install pyignite again, this time from PyPI ("pip install ").
>
> pip does not work this way. You should either undo the previous install
> ("pip uninstall "), use "--update" argument ("pip install
> --update "), or even better − use virtualenv to create a
> disposable Python environment for every experiment. I provided a link to
> virtualenv manual in the README file and in docs, in the 'Basics → Testing'
> section.
>
> > Also, the installation instruction you have provided are for unix users.
> > What are the installation instructions for Windows users?
>
> I tried to be OS-agnostic in the docs. Please tell me, what part of my
> instructions does not work on Windows.
>
> On 9/20/18 7:32 AM, Prachi Garg wrote:
>
>> Hi Dmitry,
>>
>> I tried to follow the instructions for the Python thin client
>> installation [1].
>>
>> ~$ pip install pyignite
>> Requirement already satisfied: pyignite in 
>> ./Downloads/ignite-python/modules/platforms/python
>> (0.3.1)
>> Requirement already satisfied: typing==3.6.4 in
>> /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages
>> (from pyignite) (3.6.4)
>> Requirement already satisfied: attrs==18.1.0 in
>> /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages
>> (from pyignite) (18.1.0)
>>
>> But when I try to run an example, I get an error.
>>
>> ~/Downloads/ignite-python/modules/platforms/python/examples$ python
>> get_and_put.py
>> Traceback (most recent call last):
>>File "get_and_put.py", line 16, in 
>>  from pyignite import Client
>> ImportError: No module named pyignite
>>
>>
>> What else need to be done? I am documenting the instructions on readme.io
>> , but I need to be able to run a few examples first.
>>
>> Also, the installation instruction you have provided are for unix users.
>> What are the installation instructions for Windows users?
>>
>> [1] https://apache-ignite-binary-protocol-client.readthedocs.io/
>> en/latest/readme.html#installation
>>
>
>

Re: Python thin client installation instructions

[Dmitry Melnichuk]

Prachi,

This line in your message

> Requirement already satisfied: pyignite in
> ./Downloads/ignite-python/modules/platforms/python (0.3.1)

looks like you already did an installation of pyignite in this 
environment before (maybe with "pip install -e ") 
from 'Downloads' folder, then delete or move downloaded copy, and than 
tried to install pyignite again, this time from PyPI ("pip install 
").


pip does not work this way. You should either undo the previous install 
("pip uninstall "), use "--update" argument ("pip install 
--update "), or even better − use virtualenv to create a 
disposable Python environment for every experiment. I provided a link to 
virtualenv manual in the README file and in docs, in the 'Basics → 
Testing' section.


> Also, the installation instruction you have provided are for unix users.
> What are the installation instructions for Windows users?

I tried to be OS-agnostic in the docs. Please tell me, what part of my 
instructions does not work on Windows.


On 9/20/18 7:32 AM, Prachi Garg wrote:

Hi Dmitry,

I tried to follow the instructions for the Python thin client 
installation [1].


~$ pip install pyignite
Requirement already satisfied: pyignite in 
./Downloads/ignite-python/modules/platforms/python (0.3.1)
Requirement already satisfied: typing==3.6.4 in 
/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages 
(from pyignite) (3.6.4)
Requirement already satisfied: attrs==18.1.0 in 
/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages 
(from pyignite) (18.1.0)


But when I try to run an example, I get an error.

~/Downloads/ignite-python/modules/platforms/python/examples$ python 
get_and_put.py

Traceback (most recent call last):
   File "get_and_put.py", line 16, in 
     from pyignite import Client
ImportError: No module named pyignite


What else need to be done? I am documenting the instructions on 
readme.io , but I need to be able to run a few 
examples first.


Also, the installation instruction you have provided are for unix users. 
What are the installation instructions for Windows users?


[1] 
https://apache-ignite-binary-protocol-client.readthedocs.io/en/latest/readme.html#installation

Re: Python thin client

[Prachi Garg]

Hi Dmitry,

Not sure if you are aware but all documentation for the thin clients will
be moved to readme.io. Here is the ticket for Python thin clients -
https://issues.apache.org/jira/browse/IGNITE-9522

I am already working on it. So if you make any changes to the docs in your
repo, please let me know so that I don't miss bringing them over to
readme.io

-Prachi

On Tue, Sep 18, 2018 at 4:08 AM, Igor Sapego  wrote:

> Great job.
>
> Best Regards,
> Igor
>
>
> On Tue, Sep 18, 2018 at 11:35 AM Dmitry Melnichuk <
> dmitry.melnic...@nobitlost.com> wrote:
>
> > Igor,
> >
> > All examples are in 'ignite/modules/platforms/python/examples'.
> >
> > I put examples in separate Python files mostly to be able to
> > automatically confirm their operability. All the lengthy explanations
> > and cross-references are in the main documentation:
> >
> >
> > https://apache-ignite-binary-protocol-client.readthedocs.
> io/en/latest/examples.html
> >
> > To make it easier for end users to navigate in pyignite directories, I
> > added a small README file to the 'examples' directory with a short
> > description and a link to the docs:
> >
> >
> > https://github.com/nobitlost/ignite/blob/ignite-7782/
> modules/platforms/python/examples/readme.md
> >
> > If you think this README is lacking something regardless of the main
> > pyignite docs, please let me know.
> >
> > On 9/17/18 8:59 PM, Igor Sapego wrote:
> > > Dmitry,
> > >
> > > Sorry, I was not clear enough. What I mean is that Ignite distributed
> > > by both source and binary releases. Binary releases contain platforms
> > > code, which is needed to write your own application in the language,
> > > but does not contain developer stuff, such as tests, documentation
> > > generating scripts, etc.
> > >
> > > Of course, it is more common to use package managers when
> > > developing your application, and of course, we are going to support
> > > this approach. But still, we provide a way for a user to get any client
> > > without any package manager.
> > >
> > > I like the idea of supplying whl package in a binary release, though it
> > > looks like it's going to take more effort to implement it. But I
> believe
> > > except for the whl package, we will need to supply examples and
> > > instructions, how user can run them.
> > >
> > > What do you think?
> > >
> > > Best Regards,
> > > Igor
> > >
> > >
> > > On Sat, Sep 15, 2018 at 7:03 AM Dmitry Melnichuk <
> > > dmitry.melnic...@nobitlost.com> wrote:
> > >
> > >> Igor,
> > >>
> > >> I am in doubt here because I am not fully comprehend the meaning of
> > >> "binary release". But if it is somehow related to the "distribution"
> > >> thing, I would dare to suggest the following options:
> > >>
> > >> 1. Copy nothing. Just do
> > >>
> > >> ```
> > >> $ python setup.py bdist_wheel
> > >> $ twine upload dist/*
> > >> ```
> > >>
> > >> during the build process (or separately) and let PyPI handle the
> > >> distribution.
> > >>
> > >> This is the most natural and user-friendly way of distributing Python
> > >> packages. End user might only do
> > >>
> > >> ```
> > >> $ pip install pyignite
> > >> ```
> > >>
> > >> as it is suggested by my readme file.
> > >>
> > >> 2. Supply the wheel package. It is the file 'pyignite-*.whl' from
> 'dist'
> > >> directory, that should appear there as the "python setup.py
> bdist_wheel"
> > >> command finishes. Actually, it can be combined with the first option.
> > >>
> > >> The wheel can then be installed by the end user:
> > >>
> > >> ```
> > >> $ pip install pyignite-*.whl
> > >> ```
> > >>
> > >> 3. Supply the following files:
> > >>
> > >> ignite/modules/platforms/python/pyignite/**
> > >> ignite/modules/platforms/python/requirements/**
> > >> ignite/modules/platforms/python/LICENSE
> > >> ignite/modules/platforms/python/README.md
> > >> ignite/modules/platforms/python/setup.py
> > >>
> > >> (** stands for "all the files and sub-folders recursively, starting
> from
> > >> this folder".)
> > >>
> > >> It is not uncommon or wrong to distribute Python programs as text
> > >> without prior packaging, but, in my personal experience, this is a way
> > >> more suitable for one-time scripts or proprietary programs. For
> example,
> > >> most of Python web apps relies on git for deployment, without any
> > >> packaging subsystem.
> > >>
> > >> Here's a few words about wheels:
> > >>
> > >> https://wheel.readthedocs.io/
> > >>
> > >> Here's about uploading to PyPI with twine:
> > >>
> > >>
> > >>
> > https://packaging.python.org/tutorials/packaging-projects/#
> uploading-the-distribution-archives
> > >>
> > >> On 9/14/18 9:05 PM, Igor Sapego wrote:
> > >>> Ok, good.
> > >>>
> > >>> Now, what is about installation? Which directories/files
> > >>> need to be copied to ignite's binary release?
> > >>>
> > >>> Best Regards,
> > >>> Igor
> > >>>
> > >>
> > >
> >
> >
>

Re: Python thin client

[Igor Sapego]

Great job.

Best Regards,
Igor


On Tue, Sep 18, 2018 at 11:35 AM Dmitry Melnichuk <
dmitry.melnic...@nobitlost.com> wrote:

> Igor,
>
> All examples are in 'ignite/modules/platforms/python/examples'.
>
> I put examples in separate Python files mostly to be able to
> automatically confirm their operability. All the lengthy explanations
> and cross-references are in the main documentation:
>
>
> https://apache-ignite-binary-protocol-client.readthedocs.io/en/latest/examples.html
>
> To make it easier for end users to navigate in pyignite directories, I
> added a small README file to the 'examples' directory with a short
> description and a link to the docs:
>
>
> https://github.com/nobitlost/ignite/blob/ignite-7782/modules/platforms/python/examples/readme.md
>
> If you think this README is lacking something regardless of the main
> pyignite docs, please let me know.
>
> On 9/17/18 8:59 PM, Igor Sapego wrote:
> > Dmitry,
> >
> > Sorry, I was not clear enough. What I mean is that Ignite distributed
> > by both source and binary releases. Binary releases contain platforms
> > code, which is needed to write your own application in the language,
> > but does not contain developer stuff, such as tests, documentation
> > generating scripts, etc.
> >
> > Of course, it is more common to use package managers when
> > developing your application, and of course, we are going to support
> > this approach. But still, we provide a way for a user to get any client
> > without any package manager.
> >
> > I like the idea of supplying whl package in a binary release, though it
> > looks like it's going to take more effort to implement it. But I believe
> > except for the whl package, we will need to supply examples and
> > instructions, how user can run them.
> >
> > What do you think?
> >
> > Best Regards,
> > Igor
> >
> >
> > On Sat, Sep 15, 2018 at 7:03 AM Dmitry Melnichuk <
> > dmitry.melnic...@nobitlost.com> wrote:
> >
> >> Igor,
> >>
> >> I am in doubt here because I am not fully comprehend the meaning of
> >> "binary release". But if it is somehow related to the "distribution"
> >> thing, I would dare to suggest the following options:
> >>
> >> 1. Copy nothing. Just do
> >>
> >> ```
> >> $ python setup.py bdist_wheel
> >> $ twine upload dist/*
> >> ```
> >>
> >> during the build process (or separately) and let PyPI handle the
> >> distribution.
> >>
> >> This is the most natural and user-friendly way of distributing Python
> >> packages. End user might only do
> >>
> >> ```
> >> $ pip install pyignite
> >> ```
> >>
> >> as it is suggested by my readme file.
> >>
> >> 2. Supply the wheel package. It is the file 'pyignite-*.whl' from 'dist'
> >> directory, that should appear there as the "python setup.py bdist_wheel"
> >> command finishes. Actually, it can be combined with the first option.
> >>
> >> The wheel can then be installed by the end user:
> >>
> >> ```
> >> $ pip install pyignite-*.whl
> >> ```
> >>
> >> 3. Supply the following files:
> >>
> >> ignite/modules/platforms/python/pyignite/**
> >> ignite/modules/platforms/python/requirements/**
> >> ignite/modules/platforms/python/LICENSE
> >> ignite/modules/platforms/python/README.md
> >> ignite/modules/platforms/python/setup.py
> >>
> >> (** stands for "all the files and sub-folders recursively, starting from
> >> this folder".)
> >>
> >> It is not uncommon or wrong to distribute Python programs as text
> >> without prior packaging, but, in my personal experience, this is a way
> >> more suitable for one-time scripts or proprietary programs. For example,
> >> most of Python web apps relies on git for deployment, without any
> >> packaging subsystem.
> >>
> >> Here's a few words about wheels:
> >>
> >> https://wheel.readthedocs.io/
> >>
> >> Here's about uploading to PyPI with twine:
> >>
> >>
> >>
> https://packaging.python.org/tutorials/packaging-projects/#uploading-the-distribution-archives
> >>
> >> On 9/14/18 9:05 PM, Igor Sapego wrote:
> >>> Ok, good.
> >>>
> >>> Now, what is about installation? Which directories/files
> >>> need to be copied to ignite's binary release?
> >>>
> >>> Best Regards,
> >>> Igor
> >>>
> >>
> >
>
>

Re: Python thin client

[Dmitry Melnichuk]

Igor,

All examples are in 'ignite/modules/platforms/python/examples'.

I put examples in separate Python files mostly to be able to 
automatically confirm their operability. All the lengthy explanations 
and cross-references are in the main documentation:


https://apache-ignite-binary-protocol-client.readthedocs.io/en/latest/examples.html

To make it easier for end users to navigate in pyignite directories, I 
added a small README file to the 'examples' directory with a short 
description and a link to the docs:


https://github.com/nobitlost/ignite/blob/ignite-7782/modules/platforms/python/examples/readme.md

If you think this README is lacking something regardless of the main 
pyignite docs, please let me know.


On 9/17/18 8:59 PM, Igor Sapego wrote:

Dmitry,

Sorry, I was not clear enough. What I mean is that Ignite distributed
by both source and binary releases. Binary releases contain platforms
code, which is needed to write your own application in the language,
but does not contain developer stuff, such as tests, documentation
generating scripts, etc.

Of course, it is more common to use package managers when
developing your application, and of course, we are going to support
this approach. But still, we provide a way for a user to get any client
without any package manager.

I like the idea of supplying whl package in a binary release, though it
looks like it's going to take more effort to implement it. But I believe
except for the whl package, we will need to supply examples and
instructions, how user can run them.

What do you think?

Best Regards,
Igor


On Sat, Sep 15, 2018 at 7:03 AM Dmitry Melnichuk <
dmitry.melnic...@nobitlost.com> wrote:


Igor,

I am in doubt here because I am not fully comprehend the meaning of
"binary release". But if it is somehow related to the "distribution"
thing, I would dare to suggest the following options:

1. Copy nothing. Just do

```
$ python setup.py bdist_wheel
$ twine upload dist/*
```

during the build process (or separately) and let PyPI handle the
distribution.

This is the most natural and user-friendly way of distributing Python
packages. End user might only do

```
$ pip install pyignite
```

as it is suggested by my readme file.

2. Supply the wheel package. It is the file 'pyignite-*.whl' from 'dist'
directory, that should appear there as the "python setup.py bdist_wheel"
command finishes. Actually, it can be combined with the first option.

The wheel can then be installed by the end user:

```
$ pip install pyignite-*.whl
```

3. Supply the following files:

ignite/modules/platforms/python/pyignite/**
ignite/modules/platforms/python/requirements/**
ignite/modules/platforms/python/LICENSE
ignite/modules/platforms/python/README.md
ignite/modules/platforms/python/setup.py

(** stands for "all the files and sub-folders recursively, starting from
this folder".)

It is not uncommon or wrong to distribute Python programs as text
without prior packaging, but, in my personal experience, this is a way
more suitable for one-time scripts or proprietary programs. For example,
most of Python web apps relies on git for deployment, without any
packaging subsystem.

Here's a few words about wheels:

https://wheel.readthedocs.io/

Here's about uploading to PyPI with twine:


https://packaging.python.org/tutorials/packaging-projects/#uploading-the-distribution-archives

On 9/14/18 9:05 PM, Igor Sapego wrote:

Ok, good.

Now, what is about installation? Which directories/files
need to be copied to ignite's binary release?

Best Regards,
Igor

Re: Python thin client

[Igor Sapego]

Dmitry,

Sorry, I was not clear enough. What I mean is that Ignite distributed
by both source and binary releases. Binary releases contain platforms
code, which is needed to write your own application in the language,
but does not contain developer stuff, such as tests, documentation
generating scripts, etc.

Of course, it is more common to use package managers when
developing your application, and of course, we are going to support
this approach. But still, we provide a way for a user to get any client
without any package manager.

I like the idea of supplying whl package in a binary release, though it
looks like it's going to take more effort to implement it. But I believe
except for the whl package, we will need to supply examples and
instructions, how user can run them.

What do you think?

Best Regards,
Igor


On Sat, Sep 15, 2018 at 7:03 AM Dmitry Melnichuk <
dmitry.melnic...@nobitlost.com> wrote:

> Igor,
>
> I am in doubt here because I am not fully comprehend the meaning of
> "binary release". But if it is somehow related to the "distribution"
> thing, I would dare to suggest the following options:
>
> 1. Copy nothing. Just do
>
> ```
> $ python setup.py bdist_wheel
> $ twine upload dist/*
> ```
>
> during the build process (or separately) and let PyPI handle the
> distribution.
>
> This is the most natural and user-friendly way of distributing Python
> packages. End user might only do
>
> ```
> $ pip install pyignite
> ```
>
> as it is suggested by my readme file.
>
> 2. Supply the wheel package. It is the file 'pyignite-*.whl' from 'dist'
> directory, that should appear there as the "python setup.py bdist_wheel"
> command finishes. Actually, it can be combined with the first option.
>
> The wheel can then be installed by the end user:
>
> ```
> $ pip install pyignite-*.whl
> ```
>
> 3. Supply the following files:
>
> ignite/modules/platforms/python/pyignite/**
> ignite/modules/platforms/python/requirements/**
> ignite/modules/platforms/python/LICENSE
> ignite/modules/platforms/python/README.md
> ignite/modules/platforms/python/setup.py
>
> (** stands for "all the files and sub-folders recursively, starting from
> this folder".)
>
> It is not uncommon or wrong to distribute Python programs as text
> without prior packaging, but, in my personal experience, this is a way
> more suitable for one-time scripts or proprietary programs. For example,
> most of Python web apps relies on git for deployment, without any
> packaging subsystem.
>
> Here's a few words about wheels:
>
> https://wheel.readthedocs.io/
>
> Here's about uploading to PyPI with twine:
>
>
> https://packaging.python.org/tutorials/packaging-projects/#uploading-the-distribution-archives
>
> On 9/14/18 9:05 PM, Igor Sapego wrote:
> > Ok, good.
> >
> > Now, what is about installation? Which directories/files
> > need to be copied to ignite's binary release?
> >
> > Best Regards,
> > Igor
> >
>

Re: Python thin client

[Dmitry Melnichuk]

Igor,

I am in doubt here because I am not fully comprehend the meaning of 
"binary release". But if it is somehow related to the "distribution" 
thing, I would dare to suggest the following options:


1. Copy nothing. Just do

```
$ python setup.py bdist_wheel
$ twine upload dist/*
```

during the build process (or separately) and let PyPI handle the 
distribution.


This is the most natural and user-friendly way of distributing Python 
packages. End user might only do


```
$ pip install pyignite
```

as it is suggested by my readme file.

2. Supply the wheel package. It is the file 'pyignite-*.whl' from 'dist' 
directory, that should appear there as the "python setup.py bdist_wheel" 
command finishes. Actually, it can be combined with the first option.


The wheel can then be installed by the end user:

```
$ pip install pyignite-*.whl
```

3. Supply the following files:

ignite/modules/platforms/python/pyignite/**
ignite/modules/platforms/python/requirements/**
ignite/modules/platforms/python/LICENSE
ignite/modules/platforms/python/README.md
ignite/modules/platforms/python/setup.py

(** stands for "all the files and sub-folders recursively, starting from 
this folder".)


It is not uncommon or wrong to distribute Python programs as text 
without prior packaging, but, in my personal experience, this is a way 
more suitable for one-time scripts or proprietary programs. For example, 
most of Python web apps relies on git for deployment, without any 
packaging subsystem.


Here's a few words about wheels:

https://wheel.readthedocs.io/

Here's about uploading to PyPI with twine:

https://packaging.python.org/tutorials/packaging-projects/#uploading-the-distribution-archives

On 9/14/18 9:05 PM, Igor Sapego wrote:

Ok, good.

Now, what is about installation? Which directories/files
need to be copied to ignite's binary release?

Best Regards,
Igor

Re: Python thin client

[Igor Sapego]

Ok, good.

Now, what is about installation? Which directories/files
need to be copied to ignite's binary release?

Best Regards,
Igor


On Fri, Sep 14, 2018 at 4:51 AM Dmitry Melnichuk <
dmitry.melnic...@nobitlost.com> wrote:

> Igor,
>
> The commented code (lines 95-96) gives an error if executed. The error
> is stated just below, in lines 98-100. It is explained here:
>
>
> https://apache-ignite-binary-protocol-client.readthedocs.io/en/latest/examples.html#create
>
> I found out by trial and error that a cache, created with SQL DDL
> statement (`CREATE TABLE`), can be deleted only with SQL DDL statement
> (`DROP TABLE`), whereas a table, created with a binary protocol
> operation (`OP_CACHE_CREATE_*` or `OP_CACHE_GET_OR_CREATE_*`) can be
> deleted only with binary protocol operation (`OP_CACHE_DESTROY`). I miss
> this fact in Ignite documentation.
>
> In this particular part of the example I try to stress this out with
> regard to the cache created in the beginning of the example. The cache
> behaves like an SQL table, but can not be dropped. You need to destroy
> it instead (line 102).
>
> I would not go into such depths at all, but the examples are designed to
> be runnable in automated environments, and thus must have some cleanup
> code. And since the cleanup here is not absolutely trivial, I thought I
> must explain it.
>
> I also could handle an error instead of commenting the erroneous code, like
>
> ```
> any_error = None
> try:
>  DROP_QUERY = 'DROP TABLE Student'
>  client.sql(DROP_QUERY)
> except Exception as e:
>  any_error = e
> print(any_error)
>
> # pyignite.exceptions.SQLError: class
> org.apache.ignite.IgniteCheckedException:
> # Only cache created with CREATE TABLE may be removed with DROP TABLE
> # [cacheName=SQL_PUBLIC_STUDENT]
>
> but it would complicate the cleanup part of the example to the point it
> is lost any exemplariness. So I decided to simply use comments.
>
> On 9/14/18 2:48 AM, Igor Sapego wrote:
> > Ok, now everything's running.
> >
> > API looks good to me. I have a single question about example code:
> > What these comments are for - [1]?
> >
> > [1] -
> >
> https://github.com/nobitlost/ignite/blob/ignite-7782/modules/platforms/python/examples/create_binary.py#L95
> >
> > Best Regards,
> > Igor
> >
> >
> > On Thu, Sep 13, 2018 at 12:52 AM Dmitry Melnichuk <
> > dmitry.melnic...@nobitlost.com> wrote:
> >
> >> Igor,
> >>
> >> Yes, it's my bad, sorry. Just merged the Ignite master with my branch.
> >>
> >> On 9/12/18 8:47 PM, Igor Sapego wrote:
> >>> Pavel,
> >>> Yes, I did. I tried completely clean environment, followed the same
> >>> steps and got the same error. Then I removed attr, and out of sudden
> >>> everything started working.
> >>>
> >>> Dmitry,
> >>> Thanks, now it's more clear:
> >>> Handshake error: Unsupported version. Server expects binary protocol
> >>> version 1.1.0. Client provides 1.2.0.
> >>>
> >>> Why do you use version 1.2.0, but have outdated server code? I
> >>> propose you to merge with or rebase onto Ignite's master branch.
> >>>
> >>> Best Regards,
> >>> Igor
> >>>
> >>>
> >>> On Tue, Sep 11, 2018 at 11:21 PM Dmitry Melnichuk <
> >>> dmitry.melnic...@nobitlost.com> wrote:
> >>>
>  Igor,
> 
>  I have just commited an improvment to the HandshakeError message
>  generation algorithm. I hope it is now easier to understand what
> expects
>  what in case of binary protocol version mismatch.
> 
>  Thank you for pointing this out.
> 
>  On 9/12/18 2:13 AM, Igor Sapego wrote:
> > I managed to start tests, and now I'm getting the following message:
> >
> > pyignite.exceptions.HandshakeError: Handshake error: Unsupported
> > version. Expected protocol version: 1.1.0.
> >
> > It would be useful to print "Unexpected version" itself, because I
> can
> > not understand what is the issue.
> >
> > Best Regards,
> > Igor
> 
> >>>
> >>
> >>
> >
>
>

Re: Python thin client

[Dmitry Melnichuk]

Igor,

The commented code (lines 95-96) gives an error if executed. The error 
is stated just below, in lines 98-100. It is explained here:


https://apache-ignite-binary-protocol-client.readthedocs.io/en/latest/examples.html#create

I found out by trial and error that a cache, created with SQL DDL 
statement (`CREATE TABLE`), can be deleted only with SQL DDL statement 
(`DROP TABLE`), whereas a table, created with a binary protocol 
operation (`OP_CACHE_CREATE_*` or `OP_CACHE_GET_OR_CREATE_*`) can be 
deleted only with binary protocol operation (`OP_CACHE_DESTROY`). I miss 
this fact in Ignite documentation.


In this particular part of the example I try to stress this out with 
regard to the cache created in the beginning of the example. The cache 
behaves like an SQL table, but can not be dropped. You need to destroy 
it instead (line 102).


I would not go into such depths at all, but the examples are designed to 
be runnable in automated environments, and thus must have some cleanup 
code. And since the cleanup here is not absolutely trivial, I thought I 
must explain it.


I also could handle an error instead of commenting the erroneous code, like

```
any_error = None
try:
DROP_QUERY = 'DROP TABLE Student'
client.sql(DROP_QUERY)
except Exception as e:
any_error = e
print(any_error)

# pyignite.exceptions.SQLError: class 
org.apache.ignite.IgniteCheckedException:

# Only cache created with CREATE TABLE may be removed with DROP TABLE
# [cacheName=SQL_PUBLIC_STUDENT]

but it would complicate the cleanup part of the example to the point it 
is lost any exemplariness. So I decided to simply use comments.


On 9/14/18 2:48 AM, Igor Sapego wrote:

Ok, now everything's running.

API looks good to me. I have a single question about example code:
What these comments are for - [1]?

[1] -
https://github.com/nobitlost/ignite/blob/ignite-7782/modules/platforms/python/examples/create_binary.py#L95

Best Regards,
Igor


On Thu, Sep 13, 2018 at 12:52 AM Dmitry Melnichuk <
dmitry.melnic...@nobitlost.com> wrote:


Igor,

Yes, it's my bad, sorry. Just merged the Ignite master with my branch.

On 9/12/18 8:47 PM, Igor Sapego wrote:

Pavel,
Yes, I did. I tried completely clean environment, followed the same
steps and got the same error. Then I removed attr, and out of sudden
everything started working.

Dmitry,
Thanks, now it's more clear:
Handshake error: Unsupported version. Server expects binary protocol
version 1.1.0. Client provides 1.2.0.

Why do you use version 1.2.0, but have outdated server code? I
propose you to merge with or rebase onto Ignite's master branch.

Best Regards,
Igor


On Tue, Sep 11, 2018 at 11:21 PM Dmitry Melnichuk <
dmitry.melnic...@nobitlost.com> wrote:


Igor,

I have just commited an improvment to the HandshakeError message
generation algorithm. I hope it is now easier to understand what expects
what in case of binary protocol version mismatch.

Thank you for pointing this out.

On 9/12/18 2:13 AM, Igor Sapego wrote:

I managed to start tests, and now I'm getting the following message:

pyignite.exceptions.HandshakeError: Handshake error: Unsupported
version. Expected protocol version: 1.1.0.

It would be useful to print "Unexpected version" itself, because I can
not understand what is the issue.

Best Regards,
Igor

Re: Python thin client

[Igor Sapego]

Ok, now everything's running.

API looks good to me. I have a single question about example code:
What these comments are for - [1]?

[1] -
https://github.com/nobitlost/ignite/blob/ignite-7782/modules/platforms/python/examples/create_binary.py#L95

Best Regards,
Igor


On Thu, Sep 13, 2018 at 12:52 AM Dmitry Melnichuk <
dmitry.melnic...@nobitlost.com> wrote:

> Igor,
>
> Yes, it's my bad, sorry. Just merged the Ignite master with my branch.
>
> On 9/12/18 8:47 PM, Igor Sapego wrote:
> > Pavel,
> > Yes, I did. I tried completely clean environment, followed the same
> > steps and got the same error. Then I removed attr, and out of sudden
> > everything started working.
> >
> > Dmitry,
> > Thanks, now it's more clear:
> > Handshake error: Unsupported version. Server expects binary protocol
> > version 1.1.0. Client provides 1.2.0.
> >
> > Why do you use version 1.2.0, but have outdated server code? I
> > propose you to merge with or rebase onto Ignite's master branch.
> >
> > Best Regards,
> > Igor
> >
> >
> > On Tue, Sep 11, 2018 at 11:21 PM Dmitry Melnichuk <
> > dmitry.melnic...@nobitlost.com> wrote:
> >
> >> Igor,
> >>
> >> I have just commited an improvment to the HandshakeError message
> >> generation algorithm. I hope it is now easier to understand what expects
> >> what in case of binary protocol version mismatch.
> >>
> >> Thank you for pointing this out.
> >>
> >> On 9/12/18 2:13 AM, Igor Sapego wrote:
> >>> I managed to start tests, and now I'm getting the following message:
> >>>
> >>> pyignite.exceptions.HandshakeError: Handshake error: Unsupported
> >>> version. Expected protocol version: 1.1.0.
> >>>
> >>> It would be useful to print "Unexpected version" itself, because I can
> >>> not understand what is the issue.
> >>>
> >>> Best Regards,
> >>> Igor
> >>
> >
>
>

Re: Python thin client

[Dmitry Melnichuk]

Igor,

Yes, it's my bad, sorry. Just merged the Ignite master with my branch.

On 9/12/18 8:47 PM, Igor Sapego wrote:

Pavel,
Yes, I did. I tried completely clean environment, followed the same
steps and got the same error. Then I removed attr, and out of sudden
everything started working.

Dmitry,
Thanks, now it's more clear:
Handshake error: Unsupported version. Server expects binary protocol
version 1.1.0. Client provides 1.2.0.

Why do you use version 1.2.0, but have outdated server code? I
propose you to merge with or rebase onto Ignite's master branch.

Best Regards,
Igor


On Tue, Sep 11, 2018 at 11:21 PM Dmitry Melnichuk <
dmitry.melnic...@nobitlost.com> wrote:


Igor,

I have just commited an improvment to the HandshakeError message
generation algorithm. I hope it is now easier to understand what expects
what in case of binary protocol version mismatch.

Thank you for pointing this out.

On 9/12/18 2:13 AM, Igor Sapego wrote:

I managed to start tests, and now I'm getting the following message:

pyignite.exceptions.HandshakeError: Handshake error: Unsupported
version. Expected protocol version: 1.1.0.

It would be useful to print "Unexpected version" itself, because I can
not understand what is the issue.

Best Regards,
Igor

Re: Python thin client

[Igor Sapego]

Pavel,
Yes, I did. I tried completely clean environment, followed the same
steps and got the same error. Then I removed attr, and out of sudden
everything started working.

Dmitry,
Thanks, now it's more clear:
Handshake error: Unsupported version. Server expects binary protocol
version 1.1.0. Client provides 1.2.0.

Why do you use version 1.2.0, but have outdated server code? I
propose you to merge with or rebase onto Ignite's master branch.

Best Regards,
Igor


On Tue, Sep 11, 2018 at 11:21 PM Dmitry Melnichuk <
dmitry.melnic...@nobitlost.com> wrote:

> Igor,
>
> I have just commited an improvment to the HandshakeError message
> generation algorithm. I hope it is now easier to understand what expects
> what in case of binary protocol version mismatch.
>
> Thank you for pointing this out.
>
> On 9/12/18 2:13 AM, Igor Sapego wrote:
> > I managed to start tests, and now I'm getting the following message:
> >
> > pyignite.exceptions.HandshakeError: Handshake error: Unsupported
> > version. Expected protocol version: 1.1.0.
> >
> > It would be useful to print "Unexpected version" itself, because I can
> > not understand what is the issue.
> >
> > Best Regards,
> > Igor
>

Re: Python thin client

[Dmitry Melnichuk]

Igor,

I have just commited an improvment to the HandshakeError message 
generation algorithm. I hope it is now easier to understand what expects 
what in case of binary protocol version mismatch.


Thank you for pointing this out.

On 9/12/18 2:13 AM, Igor Sapego wrote:

I managed to start tests, and now I'm getting the following message:

pyignite.exceptions.HandshakeError: Handshake error: Unsupported
version. Expected protocol version: 1.1.0.

It would be useful to print "Unexpected version" itself, because I can
not understand what is the issue.

Best Regards,
Igor

Re: Python thin client

[Pavel Petroshenko]

Hi Igor,

Did you have to do anything special to make the tests eventually run?

p.

On Tue, Sep 11, 2018 at 9:13 AM, Igor Sapego  wrote:

> I managed to start tests, and now I'm getting the following message:
>
> pyignite.exceptions.HandshakeError: Handshake error: Unsupported
> version. Expected protocol version: 1.1.0.
>
> It would be useful to print "Unexpected version" itself, because I can
> not understand what is the issue.
>
> Best Regards,
> Igor
>
>
> On Tue, Sep 11, 2018 at 10:34 AM Dmitry Melnichuk <
> dmitry.melnic...@nobitlost.com> wrote:
>
> > Igor,
> >
> > I literally followed the steps you describe, but unfortunately could not
> > reproduce the error.
> >
> > The only clue I got is that your site-packages already have the newer
> > version of attrs (18.2.0 against 18.1.0 as of pyignite requirements).
> > But this should not be an issue, since pytest-runner in this command
> > creates its own test environment, independent of the one it runs into.
> > It worked for me when I installed `attrs==18.2.0` locally and run tests
> > − everything went smooth.
> >
> > You can try uninstalling or downgrading your local attrs with
> >
> > ```
> > $ pip3 uninstall attrs
> > ```
> >
> > but I don't think it will actually help. Maybe it will raise another
> > error, so we could dig deeper into the problem.
> >
> > Alternatively, you can give me more details to recreate it (OS, Python
> > and pip versions). I'm not ruling out a bug in setuptools.
> >
> > On 9/11/18 2:13 AM, Igor Sapego wrote:
> > > Guys, I've cloned your repository, run pip3 install -e .
> > > then run pip3 install -r requirements/* over all the requirements,
> > > and finally run python ./setup.py pytest, but get the following output:
> > >
> > > running pytest
> > > Searching for attrs==18.1.0
> > > Best match: attrs 18.1.0
> > >
> > > Using /home/isapego/.local/lib/python3.6/site-packages
> > > running egg_info
> > > writing pyignite.egg-info/PKG-INFO
> > > writing dependency_links to pyignite.egg-info/dependency_links.txt
> > > writing requirements to pyignite.egg-info/requires.txt
> > > writing top-level names to pyignite.egg-info/top_level.txt
> > > reading manifest file 'pyignite.egg-info/SOURCES.txt'
> > > writing manifest file 'pyignite.egg-info/SOURCES.txt'
> > > running build_ext
> > > Traceback (most recent call last):
> > >File "./setup.py", line 98, in 
> > >  'Operating System :: OS Independent',
> > >File
> > >
> > "/home/isapego/.local/lib/python3.6/site-packages/
> setuptools/__init__.py",
> > > line 140, in setup
> > >  return distutils.core.setup(**attrs)
> > >File "/usr/lib/python3.6/distutils/core.py", line 148, in setup
> > >  dist.run_commands()
> > >File "/usr/lib/python3.6/distutils/dist.py", line 955, in
> run_commands
> > >  self.run_command(cmd)
> > >File "/usr/lib/python3.6/distutils/dist.py", line 974, in
> run_command
> > >  cmd_obj.run()
> > >File "/home/isapego/.local/lib/python3.6/site-packages/ptr.py",
> line
> > 175,
> > > in run
> > >  with self.project_on_sys_path():
> > >File "/usr/lib/python3.6/contextlib.py", line 81, in __enter__
> > >  return next(self.gen)
> > >File
> > >
> > "/home/isapego/.local/lib/python3.6/site-packages/
> setuptools/command/test.py",
> > > line 166, in project_on_sys_path
> > >  require('%s==%s' % (ei_cmd.egg_name, ei_cmd.egg_version))
> > >File
> > >
> > "/home/isapego/.local/lib/python3.6/site-packages/pkg_
> resources/__init__.py",
> > > line 895, in require
> > >  needed = self.resolve(parse_requirements(requirements))
> > >File
> > >
> > "/home/isapego/.local/lib/python3.6/site-packages/pkg_
> resources/__init__.py",
> > > line 786, in resolve
> > >  raise VersionConflict(dist, req).with_context(dependent_req)
> > > pkg_resources.ContextualVersionConflict: (attrs 18.2.0
> > > (/home/isapego/.local/lib/python3.6/site-packages),
> > > Requirement.parse('attrs==18.1.0'), {'pyignite'})
> > >
> > > What am I doing wrong?
> > >
> > > Best Regards,
> > > Igor
> > >
> >
>

Re: Python thin client

[Igor Sapego]

I managed to start tests, and now I'm getting the following message:

pyignite.exceptions.HandshakeError: Handshake error: Unsupported
version. Expected protocol version: 1.1.0.

It would be useful to print "Unexpected version" itself, because I can
not understand what is the issue.

Best Regards,
Igor


On Tue, Sep 11, 2018 at 10:34 AM Dmitry Melnichuk <
dmitry.melnic...@nobitlost.com> wrote:

> Igor,
>
> I literally followed the steps you describe, but unfortunately could not
> reproduce the error.
>
> The only clue I got is that your site-packages already have the newer
> version of attrs (18.2.0 against 18.1.0 as of pyignite requirements).
> But this should not be an issue, since pytest-runner in this command
> creates its own test environment, independent of the one it runs into.
> It worked for me when I installed `attrs==18.2.0` locally and run tests
> − everything went smooth.
>
> You can try uninstalling or downgrading your local attrs with
>
> ```
> $ pip3 uninstall attrs
> ```
>
> but I don't think it will actually help. Maybe it will raise another
> error, so we could dig deeper into the problem.
>
> Alternatively, you can give me more details to recreate it (OS, Python
> and pip versions). I'm not ruling out a bug in setuptools.
>
> On 9/11/18 2:13 AM, Igor Sapego wrote:
> > Guys, I've cloned your repository, run pip3 install -e .
> > then run pip3 install -r requirements/* over all the requirements,
> > and finally run python ./setup.py pytest, but get the following output:
> >
> > running pytest
> > Searching for attrs==18.1.0
> > Best match: attrs 18.1.0
> >
> > Using /home/isapego/.local/lib/python3.6/site-packages
> > running egg_info
> > writing pyignite.egg-info/PKG-INFO
> > writing dependency_links to pyignite.egg-info/dependency_links.txt
> > writing requirements to pyignite.egg-info/requires.txt
> > writing top-level names to pyignite.egg-info/top_level.txt
> > reading manifest file 'pyignite.egg-info/SOURCES.txt'
> > writing manifest file 'pyignite.egg-info/SOURCES.txt'
> > running build_ext
> > Traceback (most recent call last):
> >File "./setup.py", line 98, in 
> >  'Operating System :: OS Independent',
> >File
> >
> "/home/isapego/.local/lib/python3.6/site-packages/setuptools/__init__.py",
> > line 140, in setup
> >  return distutils.core.setup(**attrs)
> >File "/usr/lib/python3.6/distutils/core.py", line 148, in setup
> >  dist.run_commands()
> >File "/usr/lib/python3.6/distutils/dist.py", line 955, in run_commands
> >  self.run_command(cmd)
> >File "/usr/lib/python3.6/distutils/dist.py", line 974, in run_command
> >  cmd_obj.run()
> >File "/home/isapego/.local/lib/python3.6/site-packages/ptr.py", line
> 175,
> > in run
> >  with self.project_on_sys_path():
> >File "/usr/lib/python3.6/contextlib.py", line 81, in __enter__
> >  return next(self.gen)
> >File
> >
> "/home/isapego/.local/lib/python3.6/site-packages/setuptools/command/test.py",
> > line 166, in project_on_sys_path
> >  require('%s==%s' % (ei_cmd.egg_name, ei_cmd.egg_version))
> >File
> >
> "/home/isapego/.local/lib/python3.6/site-packages/pkg_resources/__init__.py",
> > line 895, in require
> >  needed = self.resolve(parse_requirements(requirements))
> >File
> >
> "/home/isapego/.local/lib/python3.6/site-packages/pkg_resources/__init__.py",
> > line 786, in resolve
> >  raise VersionConflict(dist, req).with_context(dependent_req)
> > pkg_resources.ContextualVersionConflict: (attrs 18.2.0
> > (/home/isapego/.local/lib/python3.6/site-packages),
> > Requirement.parse('attrs==18.1.0'), {'pyignite'})
> >
> > What am I doing wrong?
> >
> > Best Regards,
> > Igor
> >
>

Re: Python thin client

[Dmitry Melnichuk]

Igor,

I literally followed the steps you describe, but unfortunately could not 
reproduce the error.


The only clue I got is that your site-packages already have the newer 
version of attrs (18.2.0 against 18.1.0 as of pyignite requirements). 
But this should not be an issue, since pytest-runner in this command 
creates its own test environment, independent of the one it runs into. 
It worked for me when I installed `attrs==18.2.0` locally and run tests 
− everything went smooth.


You can try uninstalling or downgrading your local attrs with

```
$ pip3 uninstall attrs
```

but I don't think it will actually help. Maybe it will raise another 
error, so we could dig deeper into the problem.


Alternatively, you can give me more details to recreate it (OS, Python 
and pip versions). I'm not ruling out a bug in setuptools.


On 9/11/18 2:13 AM, Igor Sapego wrote:

Guys, I've cloned your repository, run pip3 install -e .
then run pip3 install -r requirements/* over all the requirements,
and finally run python ./setup.py pytest, but get the following output:

running pytest
Searching for attrs==18.1.0
Best match: attrs 18.1.0

Using /home/isapego/.local/lib/python3.6/site-packages
running egg_info
writing pyignite.egg-info/PKG-INFO
writing dependency_links to pyignite.egg-info/dependency_links.txt
writing requirements to pyignite.egg-info/requires.txt
writing top-level names to pyignite.egg-info/top_level.txt
reading manifest file 'pyignite.egg-info/SOURCES.txt'
writing manifest file 'pyignite.egg-info/SOURCES.txt'
running build_ext
Traceback (most recent call last):
   File "./setup.py", line 98, in 
 'Operating System :: OS Independent',
   File
"/home/isapego/.local/lib/python3.6/site-packages/setuptools/__init__.py",
line 140, in setup
 return distutils.core.setup(**attrs)
   File "/usr/lib/python3.6/distutils/core.py", line 148, in setup
 dist.run_commands()
   File "/usr/lib/python3.6/distutils/dist.py", line 955, in run_commands
 self.run_command(cmd)
   File "/usr/lib/python3.6/distutils/dist.py", line 974, in run_command
 cmd_obj.run()
   File "/home/isapego/.local/lib/python3.6/site-packages/ptr.py", line 175,
in run
 with self.project_on_sys_path():
   File "/usr/lib/python3.6/contextlib.py", line 81, in __enter__
 return next(self.gen)
   File
"/home/isapego/.local/lib/python3.6/site-packages/setuptools/command/test.py",
line 166, in project_on_sys_path
 require('%s==%s' % (ei_cmd.egg_name, ei_cmd.egg_version))
   File
"/home/isapego/.local/lib/python3.6/site-packages/pkg_resources/__init__.py",
line 895, in require
 needed = self.resolve(parse_requirements(requirements))
   File
"/home/isapego/.local/lib/python3.6/site-packages/pkg_resources/__init__.py",
line 786, in resolve
 raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.ContextualVersionConflict: (attrs 18.2.0
(/home/isapego/.local/lib/python3.6/site-packages),
Requirement.parse('attrs==18.1.0'), {'pyignite'})

What am I doing wrong?

Best Regards,
Igor

Re: Python thin client

[Igor Sapego]

Guys, I've cloned your repository, run pip3 install -e .
then run pip3 install -r requirements/* over all the requirements,
and finally run python ./setup.py pytest, but get the following output:

running pytest
Searching for attrs==18.1.0
Best match: attrs 18.1.0

Using /home/isapego/.local/lib/python3.6/site-packages
running egg_info
writing pyignite.egg-info/PKG-INFO
writing dependency_links to pyignite.egg-info/dependency_links.txt
writing requirements to pyignite.egg-info/requires.txt
writing top-level names to pyignite.egg-info/top_level.txt
reading manifest file 'pyignite.egg-info/SOURCES.txt'
writing manifest file 'pyignite.egg-info/SOURCES.txt'
running build_ext
Traceback (most recent call last):
  File "./setup.py", line 98, in 
'Operating System :: OS Independent',
  File
"/home/isapego/.local/lib/python3.6/site-packages/setuptools/__init__.py",
line 140, in setup
return distutils.core.setup(**attrs)
  File "/usr/lib/python3.6/distutils/core.py", line 148, in setup
dist.run_commands()
  File "/usr/lib/python3.6/distutils/dist.py", line 955, in run_commands
self.run_command(cmd)
  File "/usr/lib/python3.6/distutils/dist.py", line 974, in run_command
cmd_obj.run()
  File "/home/isapego/.local/lib/python3.6/site-packages/ptr.py", line 175,
in run
with self.project_on_sys_path():
  File "/usr/lib/python3.6/contextlib.py", line 81, in __enter__
return next(self.gen)
  File
"/home/isapego/.local/lib/python3.6/site-packages/setuptools/command/test.py",
line 166, in project_on_sys_path
require('%s==%s' % (ei_cmd.egg_name, ei_cmd.egg_version))
  File
"/home/isapego/.local/lib/python3.6/site-packages/pkg_resources/__init__.py",
line 895, in require
needed = self.resolve(parse_requirements(requirements))
  File
"/home/isapego/.local/lib/python3.6/site-packages/pkg_resources/__init__.py",
line 786, in resolve
raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.ContextualVersionConflict: (attrs 18.2.0
(/home/isapego/.local/lib/python3.6/site-packages),
Requirement.parse('attrs==18.1.0'), {'pyignite'})

What am I doing wrong?

Best Regards,
Igor


On Wed, Sep 5, 2018 at 3:19 AM Dmitriy Setrakyan 
wrote:

> Got it, sounds good!
>
> On Tue, Sep 4, 2018 at 10:54 AM, Dmitry Melnichuk <
> dmitry.melnic...@nobitlost.com> wrote:
>
> > Dmitriy,
> >
> > It would be quite messy to implement with Python modular system.
> >
> > First of all, Python 2 and Python 3 are different languages with a small
> > common subset of syntax rules. That's why what we see in a stack trace
> is a
> > syntax error, and not a “missing feature” error.
> >
> > Second, there is no single entry point in Python code. User is allowed to
> > import any name, from any module, in any order. In fact the module is run
> > when it first discovered by CPython during any `import` operation, and
> that
> > is how the imported entities are created and initialized: by the chain of
> > imports.
> >
> > It means for us, that implementing even a simple compatibility message in
> > Python 2 requires any module in our program (or at least all the modules,
> > that represent the public API of our library) to consist entirely of a
> > valid Python 2 code.
> >
> > It can be achieved by writing stubs with a version check, putting said
> > stubs in place of real modules, and proxying all the calls through the
> > conditional imports. It would take a small effort once, but make code
> less
> > readable and harder to maintain for the rest of its life cycle. Should
> we,
> > for example, provide two testing environments − for the main program and
> > for Python 2-compatible stubs?
> >
> > As far as I know, no Python developer is making such efforts nowadays.
> > There are some projects with a long history, that achieve
> 2/3-compatibility
> > through the use of restricted syntax and external packages like `six`, or
> > simply support two separate versions. Most of the new projects are
> creating
> > with the latest Python 3, pip and virtualenv in mind.
> >
> > I took the idea of my `setup.py` solution from the Django project, which
> > is dropped Python 2 support not long ago. Its setup relies on
> `setuptools`
> > 9+ option, or otherwise displays a simple banner; the banner is likely to
> > be buried under the further cryptic output of old setuptools, but it is
> > better than nothing.
> >
> >
> > On 9/5/18 2:21 AM, Dmitriy Setrakyan wrote:
> >
> >> Dmitriy,
> >>
> >> setuptools sounds like an installation step. Does it make sense to add a
> >> check during startup of a client?
> >>
> >> D.
> >>
> >> On Tue, Sep 4, 2018 at 7:25 AM, Dmitry Melnichuk <
> >> dmitry.melnic...@nobitlost.com> wrote:
> >>
> >> Nikolay,
> >>>
> >>> There is indeed a feature in `setuptools` I just learned about, which
> >>> would help in this case (and I believe the case you demonstrated can be
> >>> quite typical, thank you for pointing it out). It gives user a clever
> >>> message in the end of a stack trace like
> >>>
> >>> 

Re: Python thin client

[Dmitriy Setrakyan]

Got it, sounds good!

On Tue, Sep 4, 2018 at 10:54 AM, Dmitry Melnichuk <
dmitry.melnic...@nobitlost.com> wrote:

> Dmitriy,
>
> It would be quite messy to implement with Python modular system.
>
> First of all, Python 2 and Python 3 are different languages with a small
> common subset of syntax rules. That's why what we see in a stack trace is a
> syntax error, and not a “missing feature” error.
>
> Second, there is no single entry point in Python code. User is allowed to
> import any name, from any module, in any order. In fact the module is run
> when it first discovered by CPython during any `import` operation, and that
> is how the imported entities are created and initialized: by the chain of
> imports.
>
> It means for us, that implementing even a simple compatibility message in
> Python 2 requires any module in our program (or at least all the modules,
> that represent the public API of our library) to consist entirely of a
> valid Python 2 code.
>
> It can be achieved by writing stubs with a version check, putting said
> stubs in place of real modules, and proxying all the calls through the
> conditional imports. It would take a small effort once, but make code less
> readable and harder to maintain for the rest of its life cycle. Should we,
> for example, provide two testing environments − for the main program and
> for Python 2-compatible stubs?
>
> As far as I know, no Python developer is making such efforts nowadays.
> There are some projects with a long history, that achieve 2/3-compatibility
> through the use of restricted syntax and external packages like `six`, or
> simply support two separate versions. Most of the new projects are creating
> with the latest Python 3, pip and virtualenv in mind.
>
> I took the idea of my `setup.py` solution from the Django project, which
> is dropped Python 2 support not long ago. Its setup relies on `setuptools`
> 9+ option, or otherwise displays a simple banner; the banner is likely to
> be buried under the further cryptic output of old setuptools, but it is
> better than nothing.
>
>
> On 9/5/18 2:21 AM, Dmitriy Setrakyan wrote:
>
>> Dmitriy,
>>
>> setuptools sounds like an installation step. Does it make sense to add a
>> check during startup of a client?
>>
>> D.
>>
>> On Tue, Sep 4, 2018 at 7:25 AM, Dmitry Melnichuk <
>> dmitry.melnic...@nobitlost.com> wrote:
>>
>> Nikolay,
>>>
>>> There is indeed a feature in `setuptools` I just learned about, which
>>> would help in this case (and I believe the case you demonstrated can be
>>> quite typical, thank you for pointing it out). It gives user a clever
>>> message in the end of a stack trace like
>>>
>>> UnsupportedPythonVersion: pyignite requires Python '>=3.4' but the
 running Python is 2.7.15

>>>
>>> This feature is not 100% bullet-proof, and it will not help users who
>>> will
>>> try to install my client other way than with `pip` or `setup.py`.
>>> It will also be less helpful with old versions of `pip` (before 9.0).
>>> However, it should cover most situations.
>>>
>>> On 9/4/18 7:15 PM, Nikolay Izhikov wrote:
>>>
>>> Hello, Dmitry.

 I understand that for experienced Python developer it obvious from
 stack trace I send.

 But can we check python version on startup? And print big fat error
 message "You are using wrong python version".



>>>  From my experience, there are some tickets in Ignite that should be
 implemented in various thin clients. It a very trivial changes, but
 lack of testability makes this task harder then steel.

 I think a .Net DEVNOTES are very good example.

 Please, be gentle with your fellow contributors and make DEVNOTES as
 clear as possible.


>>>
>>
>

Re: Python thin client

[Dmitry Melnichuk]

Dmitriy,

It would be quite messy to implement with Python modular system.

First of all, Python 2 and Python 3 are different languages with a small 
common subset of syntax rules. That's why what we see in a stack trace 
is a syntax error, and not a “missing feature” error.


Second, there is no single entry point in Python code. User is allowed 
to import any name, from any module, in any order. In fact the module is 
run when it first discovered by CPython during any `import` operation, 
and that is how the imported entities are created and initialized: by 
the chain of imports.


It means for us, that implementing even a simple compatibility message 
in Python 2 requires any module in our program (or at least all the 
modules, that represent the public API of our library) to consist 
entirely of a valid Python 2 code.


It can be achieved by writing stubs with a version check, putting said 
stubs in place of real modules, and proxying all the calls through the 
conditional imports. It would take a small effort once, but make code 
less readable and harder to maintain for the rest of its life cycle. 
Should we, for example, provide two testing environments − for the main 
program and for Python 2-compatible stubs?


As far as I know, no Python developer is making such efforts nowadays. 
There are some projects with a long history, that achieve 
2/3-compatibility through the use of restricted syntax and external 
packages like `six`, or simply support two separate versions. Most of 
the new projects are creating with the latest Python 3, pip and 
virtualenv in mind.


I took the idea of my `setup.py` solution from the Django project, which 
is dropped Python 2 support not long ago. Its setup relies on 
`setuptools` 9+ option, or otherwise displays a simple banner; the 
banner is likely to be buried under the further cryptic output of old 
setuptools, but it is better than nothing.


On 9/5/18 2:21 AM, Dmitriy Setrakyan wrote:

Dmitriy,

setuptools sounds like an installation step. Does it make sense to add a
check during startup of a client?

D.

On Tue, Sep 4, 2018 at 7:25 AM, Dmitry Melnichuk <
dmitry.melnic...@nobitlost.com> wrote:


Nikolay,

There is indeed a feature in `setuptools` I just learned about, which
would help in this case (and I believe the case you demonstrated can be
quite typical, thank you for pointing it out). It gives user a clever
message in the end of a stack trace like


UnsupportedPythonVersion: pyignite requires Python '>=3.4' but the
running Python is 2.7.15


This feature is not 100% bullet-proof, and it will not help users who will
try to install my client other way than with `pip` or `setup.py`.
It will also be less helpful with old versions of `pip` (before 9.0).
However, it should cover most situations.

On 9/4/18 7:15 PM, Nikolay Izhikov wrote:


Hello, Dmitry.

I understand that for experienced Python developer it obvious from
stack trace I send.

But can we check python version on startup? And print big fat error
message "You are using wrong python version".





 From my experience, there are some tickets in Ignite that should be
implemented in various thin clients. It a very trivial changes, but
lack of testability makes this task harder then steel.

I think a .Net DEVNOTES are very good example.

Please, be gentle with your fellow contributors and make DEVNOTES as
clear as possible.

Re: Python thin client

[Dmitriy Setrakyan]

Dmitriy,

setuptools sounds like an installation step. Does it make sense to add a
check during startup of a client?

D.

On Tue, Sep 4, 2018 at 7:25 AM, Dmitry Melnichuk <
dmitry.melnic...@nobitlost.com> wrote:

> Nikolay,
>
> There is indeed a feature in `setuptools` I just learned about, which
> would help in this case (and I believe the case you demonstrated can be
> quite typical, thank you for pointing it out). It gives user a clever
> message in the end of a stack trace like
>
> > UnsupportedPythonVersion: pyignite requires Python '>=3.4' but the
> > running Python is 2.7.15
>
> This feature is not 100% bullet-proof, and it will not help users who will
> try to install my client other way than with `pip` or `setup.py`.
> It will also be less helpful with old versions of `pip` (before 9.0).
> However, it should cover most situations.
>
> On 9/4/18 7:15 PM, Nikolay Izhikov wrote:
>
>> Hello, Dmitry.
>>
>> I understand that for experienced Python developer it obvious from
>> stack trace I send.
>>
>> But can we check python version on startup? And print big fat error
>> message "You are using wrong python version".
>>
> >
>
>> From my experience, there are some tickets in Ignite that should be
>> implemented in various thin clients. It a very trivial changes, but
>> lack of testability makes this task harder then steel.
>>
>> I think a .Net DEVNOTES are very good example.
>>
>> Please, be gentle with your fellow contributors and make DEVNOTES as
>> clear as possible.
>>
>

Re: Python thin client

[Dmitry Melnichuk]

Nikolay,

There is indeed a feature in `setuptools` I just learned about, which 
would help in this case (and I believe the case you demonstrated can be 
quite typical, thank you for pointing it out). It gives user a clever 
message in the end of a stack trace like


> UnsupportedPythonVersion: pyignite requires Python '>=3.4' but the
> running Python is 2.7.15

This feature is not 100% bullet-proof, and it will not help users who 
will try to install my client other way than with `pip` or `setup.py`.

It will also be less helpful with old versions of `pip` (before 9.0).
However, it should cover most situations.

On 9/4/18 7:15 PM, Nikolay Izhikov wrote:

Hello, Dmitry.

I understand that for experienced Python developer it obvious from
stack trace I send.

But can we check python version on startup? And print big fat error
message "You are using wrong python version".

>

From my experience, there are some tickets in Ignite that should be
implemented in various thin clients. It a very trivial changes, but
lack of testability makes this task harder then steel.

I think a .Net DEVNOTES are very good example.

Please, be gentle with your fellow contributors and make DEVNOTES as
clear as possible.

Re: Python thin client

[Nikolay Izhikov]

Hello, Dmitry.

I understand that for experienced Python developer it obvious from stack trace 
I send.

But can we check python version on startup?
And print big fat error message "You are using wrong python version".

From my experience, there are some tickets in Ignite that should be implemented 
in various thin clients.
It a very trivial changes, but lack of testability makes this task harder then 
steel.

I think a .Net DEVNOTES are very good example.

Please, be gentle with your fellow contributors and make DEVNOTES as clear as 
possible.

В Пн, 03/09/2018 в 17:07 +1000, Dmitry Melnichuk пишет:
> Hello, Nikolay!
> 
> Thank you for your interest in Python thin client.
> 
> The traceback suggests that you using Python 2.7. Unfortunately, my 
> client supports only Python versions 3.4 and later.
> 
> Since you are using the latest Ubuntu OS, chances are you already have a 
> recent Python 3 installed. Try `pip3`.
> 
> On 9/3/18 4:25 PM, Nikolay Izhikov wrote:
> > Hello, Dmitry.
> > 
> > I tried to build your lib locally and it failed.
> > Error message and pip version are below.
> > 
> > Seems, we have to fix developer instructions.
> > Do we need specific version of pip or something?
> > I tried to use default versions.
> > I using Ubuntu Linux.
> > 
> > dragon:~/src/ignite/modules/platforms/python:[IGNITE-7782]$ pip install -v 
> > -e .
> > Obtaining file:///home/dragon/src/ignite/modules/platforms/python
> >Running setup.py 
> > (path:/home/dragon/src/ignite/modules/platforms/python/setup.py) egg_info 
> > for package from file:///home/dragon/src/ignite/modules/platforms/python
> >  Running command python setup.py egg_info
> >  Traceback (most recent call last):
> >File "", line 1, in 
> >File "/home/dragon/src/ignite/modules/platforms/python/setup.py", 
> > line 20
> >  def is_a_requirement(line: str) -> bool:
> >   ^
> >  SyntaxError: invalid syntax
> > Cleaning up...
> > Command "python setup.py egg_info" failed with error code 1 in 
> > /home/dragon/src/ignite/modules/platforms/python/
> > Exception information:
> > Traceback (most recent call last):
> >File "/usr/lib/python2.7/dist-packages/pip/basecommand.py", line 215, in 
> > main
> >  status = self.run(options, args)
> >File "/usr/lib/python2.7/dist-packages/pip/commands/install.py", line 
> > 353, in run
> >  wb.build(autobuilding=True)
> >File "/usr/lib/python2.7/dist-packages/pip/wheel.py", line 749, in build
> >  self.requirement_set.prepare_files(self.finder)
> >File "/usr/lib/python2.7/dist-packages/pip/req/req_set.py", line 380, in 
> > prepare_files
> >  ignore_dependencies=self.ignore_dependencies))
> >File "/usr/lib/python2.7/dist-packages/pip/req/req_set.py", line 518, in 
> > _prepare_file
> >  abstract_dist.prep_for_dist()
> >File "/usr/lib/python2.7/dist-packages/pip/req/req_set.py", line 129, in 
> > prep_for_dist
> >  self.req_to_install.run_egg_info()
> >File "/usr/lib/python2.7/dist-packages/pip/req/req_install.py", line 
> > 439, in run_egg_info
> >  command_desc='python setup.py egg_info')
> >File "/usr/lib/python2.7/dist-packages/pip/utils/__init__.py", line 725, 
> > in call_subprocess
> >  % (command_desc, proc.returncode, cwd))
> > InstallationError: Command "python setup.py egg_info" failed with error 
> > code 1 in /home/dragon/src/ignite/modules/platforms/python/
> > dragon:~/src/ignite/modules/platforms/python:[IGNITE-7782]$ apt-cache 
> > policy python-pip
> > python-pip:
> >Установлен: 9.0.1-2.3~ubuntu1
> >Кандидат:   9.0.1-2.3~ubuntu1
> >Таблица версий:
> >   *** 9.0.1-2.3~ubuntu1 500
> >  500 http://ru.archive.ubuntu.com/ubuntu bionic-updates/universe 
> > amd64 Packages
> >  500 http://ru.archive.ubuntu.com/ubuntu bionic-updates/universe 
> > i386 Packages
> >  100 /var/lib/dpkg/status
> >   9.0.1-2 500
> >  500 http://ru.archive.ubuntu.com/ubuntu bionic/universe amd64 
> > Packages
> >  500 http://ru.archive.ubuntu.com/ubuntu bionic/universe i386 
> > Packages
> > dragon:~/src/ignite/modules/platforms/python:[IGNITE-7782]$ uname -a
> > Linux newDragon 4.15.0-33-generic #36-Ubuntu SMP Wed Aug 15 16:00:05 UTC 
> > 2018 x86_64 x86_64 x86_64 GNU/Linux
> > 

signature.asc
Description: This is a digitally signed message part

Re: Python thin client

[Dmitry Melnichuk]

Hello, Nikolay!

Thank you for your interest in Python thin client.

The traceback suggests that you using Python 2.7. Unfortunately, my 
client supports only Python versions 3.4 and later.


Since you are using the latest Ubuntu OS, chances are you already have a 
recent Python 3 installed. Try `pip3`.


On 9/3/18 4:25 PM, Nikolay Izhikov wrote:

Hello, Dmitry.

I tried to build your lib locally and it failed.
Error message and pip version are below.

Seems, we have to fix developer instructions.
Do we need specific version of pip or something?
I tried to use default versions.
I using Ubuntu Linux.

dragon:~/src/ignite/modules/platforms/python:[IGNITE-7782]$ pip install -v -e .
Obtaining file:///home/dragon/src/ignite/modules/platforms/python
   Running setup.py 
(path:/home/dragon/src/ignite/modules/platforms/python/setup.py) egg_info for 
package from file:///home/dragon/src/ignite/modules/platforms/python
 Running command python setup.py egg_info
 Traceback (most recent call last):
   File "", line 1, in 
   File "/home/dragon/src/ignite/modules/platforms/python/setup.py", line 20
 def is_a_requirement(line: str) -> bool:
  ^
 SyntaxError: invalid syntax
Cleaning up...
Command "python setup.py egg_info" failed with error code 1 in 
/home/dragon/src/ignite/modules/platforms/python/
Exception information:
Traceback (most recent call last):
   File "/usr/lib/python2.7/dist-packages/pip/basecommand.py", line 215, in main
 status = self.run(options, args)
   File "/usr/lib/python2.7/dist-packages/pip/commands/install.py", line 353, 
in run
 wb.build(autobuilding=True)
   File "/usr/lib/python2.7/dist-packages/pip/wheel.py", line 749, in build
 self.requirement_set.prepare_files(self.finder)
   File "/usr/lib/python2.7/dist-packages/pip/req/req_set.py", line 380, in 
prepare_files
 ignore_dependencies=self.ignore_dependencies))
   File "/usr/lib/python2.7/dist-packages/pip/req/req_set.py", line 518, in 
_prepare_file
 abstract_dist.prep_for_dist()
   File "/usr/lib/python2.7/dist-packages/pip/req/req_set.py", line 129, in 
prep_for_dist
 self.req_to_install.run_egg_info()
   File "/usr/lib/python2.7/dist-packages/pip/req/req_install.py", line 439, in 
run_egg_info
 command_desc='python setup.py egg_info')
   File "/usr/lib/python2.7/dist-packages/pip/utils/__init__.py", line 725, in 
call_subprocess
 % (command_desc, proc.returncode, cwd))
InstallationError: Command "python setup.py egg_info" failed with error code 1 
in /home/dragon/src/ignite/modules/platforms/python/
dragon:~/src/ignite/modules/platforms/python:[IGNITE-7782]$ apt-cache policy 
python-pip
python-pip:
   Установлен: 9.0.1-2.3~ubuntu1
   Кандидат:   9.0.1-2.3~ubuntu1
   Таблица версий:
  *** 9.0.1-2.3~ubuntu1 500
 500 http://ru.archive.ubuntu.com/ubuntu bionic-updates/universe amd64 
Packages
 500 http://ru.archive.ubuntu.com/ubuntu bionic-updates/universe i386 
Packages
 100 /var/lib/dpkg/status
  9.0.1-2 500
 500 http://ru.archive.ubuntu.com/ubuntu bionic/universe amd64 Packages
 500 http://ru.archive.ubuntu.com/ubuntu bionic/universe i386 Packages
dragon:~/src/ignite/modules/platforms/python:[IGNITE-7782]$ uname -a
Linux newDragon 4.15.0-33-generic #36-Ubuntu SMP Wed Aug 15 16:00:05 UTC 2018 
x86_64 x86_64 x86_64 GNU/Linux

Re: Python thin client

[Nikolay Izhikov]

Hello, Dmitry.

I tried to build your lib locally and it failed.
Error message and pip version are below.

Seems, we have to fix developer instructions.
Do we need specific version of pip or something? 
I tried to use default versions.
I using Ubuntu Linux.

dragon:~/src/ignite/modules/platforms/python:[IGNITE-7782]$ pip install -v -e .
Obtaining file:///home/dragon/src/ignite/modules/platforms/python
  Running setup.py 
(path:/home/dragon/src/ignite/modules/platforms/python/setup.py) egg_info for 
package from file:///home/dragon/src/ignite/modules/platforms/python
Running command python setup.py egg_info
Traceback (most recent call last):
  File "", line 1, in 
  File "/home/dragon/src/ignite/modules/platforms/python/setup.py", line 20
def is_a_requirement(line: str) -> bool:
 ^
SyntaxError: invalid syntax
Cleaning up...
Command "python setup.py egg_info" failed with error code 1 in 
/home/dragon/src/ignite/modules/platforms/python/
Exception information:
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/pip/basecommand.py", line 215, in main
status = self.run(options, args)
  File "/usr/lib/python2.7/dist-packages/pip/commands/install.py", line 353, in 
run
wb.build(autobuilding=True)
  File "/usr/lib/python2.7/dist-packages/pip/wheel.py", line 749, in build
self.requirement_set.prepare_files(self.finder)
  File "/usr/lib/python2.7/dist-packages/pip/req/req_set.py", line 380, in 
prepare_files
ignore_dependencies=self.ignore_dependencies))
  File "/usr/lib/python2.7/dist-packages/pip/req/req_set.py", line 518, in 
_prepare_file
abstract_dist.prep_for_dist()
  File "/usr/lib/python2.7/dist-packages/pip/req/req_set.py", line 129, in 
prep_for_dist
self.req_to_install.run_egg_info()
  File "/usr/lib/python2.7/dist-packages/pip/req/req_install.py", line 439, in 
run_egg_info
command_desc='python setup.py egg_info')
  File "/usr/lib/python2.7/dist-packages/pip/utils/__init__.py", line 725, in 
call_subprocess
% (command_desc, proc.returncode, cwd))
InstallationError: Command "python setup.py egg_info" failed with error code 1 
in /home/dragon/src/ignite/modules/platforms/python/
dragon:~/src/ignite/modules/platforms/python:[IGNITE-7782]$ apt-cache policy 
python-pip
python-pip:
  Установлен: 9.0.1-2.3~ubuntu1
  Кандидат:   9.0.1-2.3~ubuntu1
  Таблица версий:
 *** 9.0.1-2.3~ubuntu1 500
500 http://ru.archive.ubuntu.com/ubuntu bionic-updates/universe amd64 
Packages
500 http://ru.archive.ubuntu.com/ubuntu bionic-updates/universe i386 
Packages
100 /var/lib/dpkg/status
 9.0.1-2 500
500 http://ru.archive.ubuntu.com/ubuntu bionic/universe amd64 Packages
500 http://ru.archive.ubuntu.com/ubuntu bionic/universe i386 Packages
dragon:~/src/ignite/modules/platforms/python:[IGNITE-7782]$ uname -a
Linux newDragon 4.15.0-33-generic #36-Ubuntu SMP Wed Aug 15 16:00:05 UTC 2018 
x86_64 x86_64 x86_64 GNU/Linux

В Пн, 03/09/2018 в 16:10 +1000, Dmitry Melnichuk пишет:
> Hello, Igniters!
> 
> Please review my work on Ignite thin client library written in Python 3.
> 
> Pull request:
> https://github.com/apache/ignite/pull/4278
> 
> Jira issue with initial proposal:
> https://issues.apache.org/jira/browse/IGNITE-7782
> 
> The documentation is temporarily available at:
> https://apache-ignite-binary-protocol-client.readthedocs.io/
> 
> It covers installation, requirements, API specification, coding 
> examples, instructions on how to run tests and build the documentation 
> itself.
> 
> Dmitry

signature.asc
Description: This is a digitally signed message part