<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>Hi, couple of notes here on annotations.<br>
</p>
<p>The general policy for annotation use is that annotations cannot
be used to alter semantics of a program. Does @CodeReflection
changes semantics? The jury is out, I believe. On the one hand, a
method annotated with @CodeReflection has bytecode like any other
method. On the other hand, such a method will return something
meaningful when the impl of that method is inspected using code
reflection. Is that an acceptable semantics change? My feeling
here is that it is. Because the kind of semantics change brought
by this annotation is a reflective one - not too different from
e.g. asking if a method has an annotation (which of course will
only return true if the annotation is present - is that a
semantics change? Well no).<br>
</p>
<p>Now, with that out of the way, the use you describe of
@CodeReflection paired with functional interface might work, yes.
But there's another issue here, one of trust boundaries: are we ok
with a library single handedly decide for all its clients as to
whether the lambdas passed into it must be reflectable? This is a
bit of a shaky territory, and one where there's many similarities
with how we approached serializable lambdas back in Java 8. Where
we ended up back then was:</p>
<p>* if a library just takes Function<T, R>, a lambda is not
serializable. A client must opt in (with a cast - e.g. Function
& Serializable)<br>
* if the library takes a SerializableFunction<T, R> where
this extends Serializable, no opt in is required.</p>
<p>This behavior was deemed acceptable for Java 8, so it does create
some kind of precedent for Babylon.</p>
<p>Now, the difference is that serialization of lambda expression is
generally not very encouraged, even by our own docs [1]. This is
mainly due to the fact that serializing a lambda expression would
unavoidably expose some compiler artifacts (pretty much in the
same way as serializing an inner class would). So there was a sort
of incentive to make serializable lambdas explicit and... well,
not that pretty.<br>
</p>
<p>But with code reflection, the situation is a bit different: code
reflection is about persisting the IR of a computation in a way
that reflect the structure of source code it comes from. And this
kind of "serialization" is less dirty than the classic one. So
there might be an argument here that, perhaps, some of the
constraints around explicit-ness and opt-in might be relaxed,
eventually.</p>
<p>All that said, in a way we're arguing about "syntax" in a way.
Eventually, there needs to be a way to pass a lambda where a
reflectable functional interface is expected. Currently, this is
done with the same approach as serializable lambdas which, while
heavy-handed, it is at least consistent with other similar choices
we made in the past. We might improve this, which will result in a
slightly different syntax to achieve the same goal, but I don't
think the specific syntax we use to denote reflectable lambdas is
too important at this stage of the project?</p>
<p>Cheers<br>
Maurizio<br>
</p>
<p>[1] -
<a class="moz-txt-link-freetext" href="https://docs.oracle.com/javase/tutorial/java/javaOO/nested.html#serialization">https://docs.oracle.com/javase/tutorial/java/javaOO/nested.html#serialization</a><br>
</p>
<div class="moz-cite-prefix">On 09/05/2024 11:54, Konstantin Triger
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAGKqGx+gp6MCD3-FJsXUwvpsah6c5fi0yfONwR8gKzE8mn1SPg@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">Hey Maurizio,</div>
<div dir="ltr"><br>
</div>
<div>If we are in agreement that using wildcards is not an
important case, I'm not sure I understand why this does
not slot well into the existing type system. Potentially
I'm missing something.</div>
<div>On the other hand, something like: <span style="background-color:rgb(238,238,238)">method(@CodeReflection
Function<T, R> f)</span> is another option that
won't suffer from compiler issues, but per Paul might not
be clear/secure enough.</div>
<div><br>
</div>
<div>I just want to say that Quotable is also far from
being a perfect solution (personally, I think it is worse
than the 2 above). Seems that it was chosen due to
similarity to Serializable case and because it already
exists. But "Serializable" is an old solution, that
was introduced before annotations, not sure the same
design would be done today.</div>
<div><br>
</div>
<div>P.S. I'm raising the above as my personal thoughts. I'm
not part of the Babylon team and will totally understand
if the above will be completely ignored.</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Kosta</div>
<div><br>
</div>
</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, May 9, 2024 at 2:46 AM
Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com" moz-do-not-send="true" class="moz-txt-link-freetext">maurizio.cimadamore@oracle.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p><br>
</p>
<div>On 08/05/2024 22:56, Konstantin Triger wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">Hi Maurizio,
<div><br>
</div>
<div>Looking on this, I'm wondering how important
is this case: <span style="color:rgb(51,51,51);font-family:Consolas,Inconsolata,Courier,monospace;font-size:11.05px;background-color:rgb(248,248,248)">Quoted<Function<?,
?>> f = (Integer i) -> </span><span style="font-family:Consolas,Inconsolata,Courier,monospace;font-size:11.05px;color:rgb(221,17,68)">""</span><span style="color:rgb(51,51,51);font-family:Consolas,Inconsolata,Courier,monospace;font-size:11.05px;background-color:rgb(248,248,248)">;</span></div>
<div>The "practical" case is something like:
<T, R> RETURN_TYPE
method(Quoted<Function<T, R>> f).</div>
<div>Which should compile well because of
inference.</div>
<div>And if someone insists on working with
wildcards, so he has an option.</div>
</div>
</div>
</div>
</div>
</blockquote>
<p>The specific case per se is not important. But if Babylon
needs more help from the language, I think whatever
feature we add needs to slot it correctly into the
existing type system/inference machinery. The
Quoted<T> idea at the moment seems more a case of a
square peg in a round hole - but that's not to say that,
maybe, we'll come up with some clever idea to rescue that
approach.</p>
<p>Maurizio<br>
</p>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div><br>
</div>
<div>Kosta</div>
</div>
</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, May 8, 2024 at
3:19 PM Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">maurizio.cimadamore@oracle.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div>
<p style="margin:0px 0px 1.2em">On 06/05/2024
18:50, Paul Sandoz wrote:</p>
<div>
<blockquote type="cite">
<pre><blockquote type="cite" style="color:rgb(140,140,140)"><pre>Just wanted to mention that there might be alternative implementations addressing this requirement.
1. Structural quoting (a la C#) - derives from the variable type, e.g. Quoted<T>. So, the user understands that the lambda body will be accessible.
</pre></blockquote><pre>There are some challenges with Java’s type system, which is why we embedded up where we are with the current approaches. Maurizio is better able than I to describe these challenges.</pre></pre>
</blockquote>
</div>
<p style="margin:0px 0px 1.2em">Hi,<br>
we have explored approaches such as <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline">Quoted<T></code>
(where <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline">T</code>
is a functional interface) early on. And found
them a bad fit for Java. The main issue we faced
is that being a functional interface, as per
today’s JLS, is a predicate on class
declarations not types (there was some intense
discussion on this point during Java 8). But
here we have something that can be treated as a
functional interface or not, precisely depending
on its type (e.g. the type parameter). E.g. a <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline">Quotable<T></code>
is a functional interface or not depending on <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline">T</code>.
This is a pretty deep big departure from how the
spec currently deal with functional interfaces.</p>
<p style="margin:0px 0px 1.2em">One possibility
would be for the compiler/spec to ignore the <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline">Quoted<T></code>,
and just focus on the inner <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline">T</code>,
and then add the quoting back, after
type-checking. But doing so leads to (bad) edge
cases. For instance, Java 8 supports a form of
inference of the target type from the explicit
lambda parameter types, in this case:</p>
<pre style="font-family:Consolas,Inconsolata,Courier,monospace;font-size:1em;line-height:1.2em;margin:1.2em 0px"><code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;white-space:pre-wrap;overflow:auto;border-radius:3px;border:1px solid rgb(204,204,204);padding:0.5em;color:rgb(51,51,51);background:rgb(248,248,248);display:block">Function<?, ?> f = (Integer i) -> <span style="color:rgb(221,17,68)">""</span>;
</code></pre>
<p style="margin:0px 0px 1.2em">In this case, the
type of the lambda expression is not just <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline">Function<?, ?></code>
(the target type), but <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline">Function<Integer,Object></code>.
That is, the compiler tries to get rid of the
wildcards before attempting to type-check the
lambda expression (this step is performed to
avoid wildcards popping up when checking the
lambda body). But with quoting, this won’t
compose well - e.g.:</p>
<pre style="font-family:Consolas,Inconsolata,Courier,monospace;font-size:1em;line-height:1.2em;margin:1.2em 0px"><code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;white-space:pre-wrap;overflow:auto;border-radius:3px;border:1px solid rgb(204,204,204);padding:0.5em;color:rgb(51,51,51);background:rgb(248,248,248);display:block">Quoted<Function<?, ?>> f = (Integer i) -> <span style="color:rgb(221,17,68)">""</span>;
</code></pre>
<p style="margin:0px 0px 1.2em">Will give an
error:</p>
<pre style="font-family:Consolas,Inconsolata,Courier,monospace;font-size:1em;line-height:1.2em;margin:1.2em 0px"><code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;background-color:rgb(248,248,248);white-space:pre-wrap;overflow:auto;border-radius:3px;border:1px solid rgb(204,204,204);padding:0.5em 0.7em;display:block">error: incompatible types: Quoted<Function<Integer, Object>> cannot be converted to Quoted<Function<?, ?>>
Quoted<Function<?, ?>> f = (Integer i) -> “”;
^
</code></pre>
<p style="margin:0px 0px 1.2em">That is, the
functional interface type inferred by the
compiler (by dropping wildcards) is now
incompatible with the target type (because of
the way in which generics type-argument
containment rules work). To make things work,
the client would need at least to do this:</p>
<pre style="font-family:Consolas,Inconsolata,Courier,monospace;font-size:1em;line-height:1.2em;margin:1.2em 0px"><code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;background-color:rgb(248,248,248);white-space:pre-wrap;overflow:auto;border-radius:3px;border:1px solid rgb(204,204,204);padding:0.5em 0.7em;display:block">Quoted<? extends Function<?, ?>> f = (Integer i) -> “”;
</code></pre>
<p style="margin:0px 0px 1.2em">Overall it felt
like we were pushing against the physics of the
language here. Serializable lambdas (with all
their limitations) were a strong precedent to
build on top of, which didn’t suffer from any of
the limitations described above.</p>
<p style="margin:0px 0px 1.2em">Maurizio</p>
<div title="MDH:PGRpdiBjbGFzcz0ibWFya2Rvd24taGVyZS13cmFwcGVyIiBkYXRhLW1kLXVybD0iIiBzdHlsZT0i
IiBtYXJrZG93bi1oZXJlLXdyYXBwZXItY29udGVudC1tb2RpZmllZD0idHJ1ZSI+PHAgc3R5bGU9
Im1hcmdpbjogMHB4IDBweCAxLjJlbSAhaW1wb3J0YW50OyI+T24gMDYvMDUvMjAyNCAxODo1MCwg
UGF1bCBTYW5kb3ogd3JvdGU6PC9wPgo8cCBzdHlsZT0ibWFyZ2luOiAwcHggMHB4IDEuMmVtICFp
bXBvcnRhbnQ7Ij48L3A+PGRpdiBjbGFzcz0ibWFya2Rvd24taGVyZS1leGNsdWRlIj48cD48L3A+
PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2l0ZT0ibWlkOkU0QjVDRDJGLTNBM0UtNDhGQS05NkY2
LTBGNzREMURGMjMyMkBvcmFjbGUuY29tIj48cHJlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIHN0
eWxlPSJjb2xvcjogIzhjOGM4YzsiPjxwcmUgY2xhc3M9Im1vei1xdW90ZS1wcmUiIHdyYXA9IiI+
SnVzdCB3YW50ZWQgdG8gbWVudGlvbiB0aGF0IHRoZXJlIG1pZ2h0IGJlIGFsdGVybmF0aXZlIGlt
cGxlbWVudGF0aW9ucyBhZGRyZXNzaW5nIHRoaXMgcmVxdWlyZW1lbnQuCjEuIFN0cnVjdHVyYWwg
cXVvdGluZyAoYSBsYSBDIykgLSBkZXJpdmVzIGZyb20gdGhlIHZhcmlhYmxlIHR5cGUsIGUuZy4g
UXVvdGVkJmx0O1QmZ3Q7LiBTbywgdGhlIHVzZXIgdW5kZXJzdGFuZHMgdGhhdCB0aGUgbGFtYmRh
IGJvZHkgd2lsbCBiZSBhY2Nlc3NpYmxlLgo8L3ByZT48L2Jsb2NrcXVvdGU+PHByZSBjbGFzcz0i
bW96LXF1b3RlLXByZSIgd3JhcD0iIj5UaGVyZSBhcmUgc29tZSBjaGFsbGVuZ2VzIHdpdGggSmF2
YeKAmXMgdHlwZSBzeXN0ZW0sIHdoaWNoIGlzIHdoeSB3ZSBlbWJlZGRlZCB1cCB3aGVyZSB3ZSBh
cmUgd2l0aCB0aGUgY3VycmVudCBhcHByb2FjaGVzLiBNYXVyaXppbyBpcyBiZXR0ZXIgYWJsZSB0
aGFuIEkgdG8gZGVzY3JpYmUgdGhlc2UgY2hhbGxlbmdlcy48L3ByZT48L3ByZT48L2Jsb2NrcXVv
dGU+PHA+PC9wPjwvZGl2PjxwIHN0eWxlPSJtYXJnaW46IDBweCAwcHggMS4yZW0gIWltcG9ydGFu
dDsiPjwvcD5IaSw8YnI+d2UgaGF2ZSBleHBsb3JlZCBhcHByb2FjaGVzIHN1Y2ggYXMgYFF1b3Rl
ZCZsdDtUJmd0O2AgKHdoZXJlIGBUYCBpcyBhIGZ1bmN0aW9uYWwgaW50ZXJmYWNlKSBlYXJseSBv
bi4gQW5kIGZvdW5kIHRoZW0gYSBiYWQgZml0IGZvciBKYXZhLiBUaGUgbWFpbiBpc3N1ZSB3ZSBm
YWNlZCBpcyB0aGF0IGJlaW5nIGEgZnVuY3Rpb25hbCBpbnRlcmZhY2UsIGFzIHBlciB0b2RheeKA
mXMgSkxTLCBpcyBhIHByZWRpY2F0ZSBvbiBjbGFzcyBkZWNsYXJhdGlvbnMgbm90IHR5cGVzICh0
aGVyZSB3YXMgc29tZSBpbnRlbnNlIGRpc2N1c3Npb24gb24gdGhpcyBwb2ludCBkdXJpbmcgSmF2
YSA4KS4gQnV0IGhlcmUgd2UgaGF2ZSBzb21ldGhpbmcgdGhhdCBjYW4gYmUgdHJlYXRlZCBhcyBh
IGZ1bmN0aW9uYWwgaW50ZXJmYWNlIG9yIG5vdCwgcHJlY2lzZWx5IGRlcGVuZGluZyBvbiBpdHMg
dHlwZSAoZS5nLiB0aGUgdHlwZSBwYXJhbWV0ZXIpLiBFLmcuIGEgYFF1b3RhYmxlJmx0O1QmZ3Q7
YCBpcyBhIGZ1bmN0aW9uYWwgaW50ZXJmYWNlIG9yIG5vdCBkZXBlbmRpbmcgb24gYFRgLiBUaGlz
IGlzIGEgcHJldHR5IGRlZXAgYmlnIGRlcGFydHVyZSBmcm9tIGhvdyB0aGUgc3BlYyBjdXJyZW50
bHkgZGVhbCB3aXRoIGZ1bmN0aW9uYWwgaW50ZXJmYWNlcy48YnI+PGJyPk9uZSBwb3NzaWJpbGl0
eSB3b3VsZCBiZSBmb3IgdGhlIGNvbXBpbGVyL3NwZWMgdG8gaWdub3JlIHRoZSBgUXVvdGVkJmx0
O1QmZ3Q7YCwgYW5kIGp1c3QgZm9jdXMgb24gdGhlIGlubmVyIGBUYCwgYW5kIHRoZW4gYWRkIHRo
ZSBxdW90aW5nIGJhY2ssIGFmdGVyIHR5cGUtY2hlY2tpbmcuIEJ1dCBkb2luZyBzbyBsZWFkcyB0
byAoYmFkKSBlZGdlIGNhc2VzLiBGb3IgaW5zdGFuY2UsIEphdmEgOCBzdXBwb3J0cyBhIGZvcm0g
b2YgaW5mZXJlbmNlIG9mIHRoZSB0YXJnZXQgdHlwZSBmcm9tIHRoZSBleHBsaWNpdCBsYW1iZGEg
cGFyYW1ldGVyIHR5cGVzLCBpbiB0aGlzIGNhc2U6PGJyPjxicj5gYGBqYXZhPGJyPkZ1bmN0aW9u
Jmx0Oz8sID8mZ3Q7IGYgPSAoSW50ZWdlciBpKSAtJmd0OyAiIjs8YnI+YGBgPGJyPjxicj5JbiB0
aGlzIGNhc2UsIHRoZSB0eXBlIG9mIHRoZSBsYW1iZGEgZXhwcmVzc2lvbiBpcyBub3QganVzdCBg
RnVuY3Rpb24mbHQ7PywgPyZndDtgICh0aGUgdGFyZ2V0IHR5cGUpLCBidXQgYEZ1bmN0aW9uJmx0
O0ludGVnZXIsT2JqZWN0Jmd0O2AuIFRoYXQgaXMsIHRoZSBjb21waWxlciB0cmllcyB0byBnZXQg
cmlkIG9mIHRoZSB3aWxkY2FyZHMgYmVmb3JlIGF0dGVtcHRpbmcgdG8gdHlwZS1jaGVjayB0aGUg
bGFtYmRhIGV4cHJlc3Npb24gKHRoaXMgc3RlcCBpcyBwZXJmb3JtZWQgdG8gYXZvaWQgd2lsZGNh
cmRzIHBvcHBpbmcgdXAgd2hlbiBjaGVja2luZyB0aGUgbGFtYmRhIGJvZHkpLiBCdXQgd2l0aCBx
dW90aW5nLCB0aGlzIHdvbuKAmXQgY29tcG9zZSB3ZWxsIC0gZS5nLjo8YnI+PGJyPmBgYGphdmE8
YnI+UXVvdGVkJmx0O0Z1bmN0aW9uJmx0Oz8sID8mZ3Q7Jmd0OyBmID0gKEludGVnZXIgaSkgLSZn
dDsgIiI7PGJyPmBgYDxicj48YnI+V2lsbCBnaXZlIGFuIGVycm9yOjxicj48YnI+YGBgPGJyPmVy
cm9yOiBpbmNvbXBhdGlibGUgdHlwZXM6IFF1b3RlZCZsdDtGdW5jdGlvbiZsdDtJbnRlZ2VyLCBP
YmplY3QmZ3Q7Jmd0OyBjYW5ub3QgYmUgY29udmVydGVkIHRvIFF1b3RlZCZsdDtGdW5jdGlvbiZs
dDs/LCA/Jmd0OyZndDs8YnI+IFF1b3RlZCZsdDtGdW5jdGlvbiZsdDs/LCA/Jmd0OyZndDsgZiA9
IChJbnRlZ2VyIGkpIC0mZ3Q7IOKAnOKAnTsgPGJyPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgXjxicj5gYGA8YnI+
PGJyPlRoYXQgaXMsIHRoZSBmdW5jdGlvbmFsIGludGVyZmFjZSB0eXBlIGluZmVycmVkIGJ5IHRo
ZSBjb21waWxlciAoYnkgZHJvcHBpbmcgd2lsZGNhcmRzKSBpcyBub3cgaW5jb21wYXRpYmxlIHdp
dGggdGhlIHRhcmdldCB0eXBlLiBUbyBtYWtlIHRoaW5ncyB3b3JrLCB0aGUgY2xpZW50IHdvdWxk
IG5lZWQgYXQgbGVhc3QgdG8gZG8gdGhpczo8YnI+PGJyPmBgYDxicj5RdW90ZWQmbHQ7PyBleHRl
bmRzIEZ1bmN0aW9uJmx0Oz8sID8mZ3Q7Jmd0OyBmID0gKEludGVnZXIgaSkgLSZndDsg4oCc4oCd
Ozxicj5gYGA8YnI+PGJyPk92ZXJhbGwgaXQgZmVsdCBsaWtlIHdlIHdlcmUgcHVzaGluZyBhZ2Fp
bnN0IHRoZSBwaHlzaWNzIG9mIHRoZSBsYW5ndWFnZSBoZXJlLiBTZXJpYWxpemFibGUgbGFtYmRh
cyAod2l0aCBhbGwgdGhlaXIgbGltaXRhdGlvbnMpIHdlcmUgYSBzdHJvbmcgcHJlY2VkZW50IHRv
IGJ1aWxkIG9uIHRvcCBvZiwgd2hpY2ggZGlkbuKAmXQgc3VmZmVyIGZyb20gYW55IG9mIHRoZSBs
aW1pdGF0aW9ucyBkZXNjcmliZWQgYWJvdmUuPGJyPuKAizxicj48L2Rpdj4=" style="height:0px;width:0px;max-height:0px;max-width:0px;overflow:hidden;font-size:0em;padding:0px;margin:0px"></div>
</div>
</div>
</blockquote>
</div>
<br clear="all">
<div><br>
</div>
<span class="gmail_signature_prefix">-- </span><br>
<div dir="ltr" class="gmail_signature">
<div dir="ltr">Regards,<br>
Konstantin Triger<br>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
<br clear="all">
<div><br>
</div>
<span class="gmail_signature_prefix">-- </span><br>
<div dir="ltr" class="gmail_signature">
<div dir="ltr">Regards,<br>
Konstantin Triger<br>
</div>
</div>
</blockquote>
</body>
</html>