<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le ven. 19 juin 2020 à 16:16, Marcel Taeumel <<a href="mailto:marcel.taeumel@hpi.de">marcel.taeumel@hpi.de</a>> a écrit :<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 id="gmail-m_5957770884654581966__MailbirdStyleContent" style="font-size:10pt;font-family:Arial;color:rgb(0,0,0)">

                                        <div><span style="font-size:13.3333px">> </span><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px">Err, I move this thread to Opensmalltalk VM dev, because it is not Squeak </span><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px">specific! </span></div><div><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px">Absolutely. :-)</span></div><div><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px"><br></span></div><div><span style="font-size:13.3333px">(On a side note: I think that ExternalData should always have a pointer type in its "type" field unless "handle" is a ByteArray instead of ExternalAddress)</span><div style="font-size:13.3333px"><br></div></div></div></blockquote><div>Let me disagree here...</div><div>The type should better describe the contents of the handle (be it an ExternalAddress or a zone of object memory (ByteArray)).</div><div>Typically, if you have an external (global) variable of type foo (extern foo my_var;) then the natural type is foo.</div><div>Having foo*, would mean that we handle an array of foo*, or a pointer to foo* (foo**).<br></div><div>This way, we make no difference between type surrogates (ExternalStruct/ExternalTypeAlias) and other atomic cases.<br></div><div><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 id="gmail-m_5957770884654581966__MailbirdStyleContent" style="font-size:10pt;font-family:Arial;color:rgb(0,0,0)"><div><div style="font-size:13.3333px"></div><div style="font-size:13.3333px">(On another side note: I also think that "handle" in ExternalData should never ever be an atomic Smalltalk object (Integer or Float) but always either ByteArray or ExternalAddress. ... which makes it different from what "handle" can be in ExternalStructs that represent type aliases. :-)<br><div><br></div></div></div></div></blockquote><div>Yes!</div><div>It could be an ExternalAddress, or a zone of object memory (ByteArray) or an Alien as we may want to support that too.</div><div>I'd be inclined to support doubleByte, word, and doubleWord arrays if the size of atomic type matches</div><div>(Typically passing a DoubleByteArray, WordArray, a Float32Array, a Float64Array to a short */int */float*/double*).</div><div><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 id="gmail-m_5957770884654581966__MailbirdStyleContent" style="font-size:10pt;font-family:Arial;color:rgb(0,0,0)"><div><div style="font-size:13.3333px"><div></div><div>Best,</div><div>Marcel</div></div></div><div></div>

                                        <blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-top:20px;margin-left:0px;padding-left:10px;min-width:500px">

                        <p style="color:rgb(170,170,170);margin-top:10px">Am 19.06.2020 16:03:10 schrieb Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>>:</p><div style="font-family:Arial,Helvetica,sans-serif"> Err, I move this thread to Opensmalltalk VM dev, because it is not Squeak

specific!

<br>

<br>

<br>

<br>Le ven. 19 juin 2020 à 15:10, Nicolas Cellier <><br><a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>> a écrit :

<br>

<br>> Hi Marcel,

> thanks for your vote. Anyone else?

<br>>

<br>> Le ven. 19 juin 2020 à 09:30, Marcel Taeumel <u></u> a

<br>> écrit :

<br>>

<br>>> Hi Nicolas, hi all! :-)

<br>>>

>> > Type alias are subclasses of ExternalStructure.

<br>>>

<br>>> And with it, they get their own instance of ExternalType, which is

>> managed in the classVar StructTypes. Let's call them struct type.

<br>>>

>> > Now we have another mean by adding a class side method in ExternalType.

<br>>>

<br>>> That kind of aliasing is for compile-time type referencing only -- such

<br>>> as in FFI calls (i.e. <u></u> pragmas) or struct-field definitions

<br>>> (i.e. #fields). (And soon <u></u> if I have the first version of

<br>>> FFI-Callback to show you :)

<br>>>

<br>>> Because those aliases become fully transparent after compiling the method

<br>>> for the FFI call into an instance of ExternalLibraryFunction and after

<br>>> compiling the field specs of external structures into compiledSpec for

<br>>> struct types.

<br>>>

<br>>> For example, on my machine in 32-bit Squeak, a 'size_t' becomes a 'long',

<br>>> which is Squeak FFI term for 'int'. :-) See #ffiLongVsInt. And 'int32_t'

<br>>> also becomes a 'long'. So, it just translates C vocabulary into Squeak FFI

>> vocabulary. Nothing more. Nothing less.

<br>>>

<br>>> Having that, please do not use class-side methods in ExternalType to

>> alias a (complex) struct type. Use them only for renaming atomic types.

>> Please. We may want to add checks to enforce that.

<br>>>

<br>>> I suppose that this discussion focuses on type aliases that are

<br>>> represented as subclasses of ExternalStructure (or ExternalTypeAlias) and

<br>>> thus get their own struct type. So, let's ignore this other mechanism for

<br>>> now.

<br>>>

<br>>> > This has one advantage: type safety. You cannot pass a Foo to a

>> function expecting a Bar, even if they both alias int...

<br>>>

<br>>> Yes! So, we are now talking about type aliases to atomic types. The

<br>>> struct type you get when aliasing a 'char' as Foo, for example, looks like

<br>>> this:

<br>>>

<br>>> (...forgive my "creative" representation of WordArray here...)

<br>>>

<br>>> compiledSpec: 0A 04 00 01

<br>>> referentClass: Foo

<br>>>

>> How does the atomic type for 'char' look like?

<br>>>

<br>>> compiledSpec: 0A 04 00 01

<br>>> referentClass: nil

<br>>>

<br>>> Consequently, argument coercing will fail if you pass a 'char' when a

<br>>> 'Foo' is expected. Because the referentClass does not match --- even if the

>> compiledSpec does match.

<br>>>

<br>>> > But this has one major drawback: with current FFI, you cannot pass a

<br>>> Smalltalk Integer, to a method expecting a Bar, even if Bar is an alias for

>> an integer type...

<br>>>

<br>>> That's correct. If the origin of such an argument is from within the

<br>>> image, you have to wrap it. But when returned from another call ... well

<br>>> ... that wrapping should have happened in the plugin ... But read on! :-)

<br>>>

<br>>> > FFI plugin is clever enough to recognize an atomic type alias and

>> simply return a Smalltalk Integer...

>> > So it's not Bar all the way down, I have to manually wrap Bar...

<br>>> > This is not consistent.

<br>>>

<br>>> Uhh! That's a bug. The FFI Plugin must take a look at referentClass

>> because it does so for argument coercing.

<br>>>

<br>>> Now I understand why the code generation of struct-field accessors was so

<br>>> apparently broken for me. I changed that so that having an alias type as

<br>>> part of a larger struct will automatically wrap that for you into the alias

<br>>> structure. :-) Even if you are just aliasing a plain 'int' ... or 'long'

<br>>> ... Ha ha. ;-) #ffiLongVsInt.

<br>>>

>> It should be "Bar all the way down". Definitely.

<br>>>

<br>>> > If we return an int, we must accept an int, otherwise, we cannot chain

<br>>> FFI calls...

<br>>>

<br>>> Well, not for type aliases. I would like keep the path of type safety

>> here, you mentioned above.

<br>>>

<br>>> Just fix the FFI plugin to respect referentClass when packaging the

<br>>> return value.

<br>>>

<br>>> > I could use the lightweight alias instead, [...]

<br>>>

<br>>> Please don't. See above. Those "lightweight alias" are for renaming

<br>>> atomic types only. Let's keep it simple and try to address you concern here

<br>>> with struct types and ExternalTypeAlias. :-)

<br>>>

<br>>> > there was another usage where it was convenient to use

<br>>> ExternalTypeAlias: enum.

>> > Indeed, I simply defined all enum symbols as class side method.

<br>>>

<br>>> I like that! It reads like a next step for ExternalPool. Once you have

<br>>> extracted the constant values from header files, and once you have those

<br>>> values for your platform in classVars in your external pool, use that pool

>> to define enums through ExternalStructure.

<br>>>

<br>>> Like this:

<br>>>

<br>>> ExternalTypeAlias subclass: #MyEnumBar

<br>>> instanceVariableNames: ''

<br>>> classVariableNames: ''

<br>>> poolDictionaries: 'HDF5Pool'

<br>>> category: 'HDF5'

<br>>>

<br>>> MyEnumBar class >> #poolFields

<br>>>    "

<br>>>    self defineFields.

<br>>>    "

<br>>>    ^ #(

<br>>>       (beg HDF5_BEG)

<br>>>       (mid HDF5_MID)

<br>>>       (end HDF5_END)

<br>>>    )

<br>>>

<br>>> Note that HDF5_BEG etc. are from the HDF5Pool, which is managed via

>> external-pool definitions. See class comment in ExternalPool to get started.

<br>>>

<br>>> Note that #poolFields would translate to class-side methods as you

<br>>> suggested.

<br>>>

>> > If I use a simpler alias, where are those ids going to?

<br>>>

<br>>> Please don't. See above. :-)

<br>>>

<br>>> > IMO we cannot keep status quo in the plugin, we gotta to make the

>> inputs/outputs behave consistently.

<br>>>

<br>>> Absolutely!

<br>>>

<br>>> > - should a function expecting an ExternalTypeAlias of atomic type

>> accept an immediate value of compatible type?

<br>>>

>> Considering type safety, I think not.

<br>>>

<br>>> Well ... since this is a convenience issue and thus not about saving

<br>>> run-time cost ... What about adding a callback into the image to react on

<br>>> FFIErrorCoercionFailed? Maybe the selector for such a callback could be

<br>>> stored in ExternalLibraryFunction since this is accessible to the plugin

<br>>> anyway?

<br>>>

<br>>> <u></u>

<br>>>

>> ... would it be possible? Like that #doesNotUnderstand: callback?

<br>>>

<br>>> I would love to do ad-hoc packaging of arguments. (Also thinking about

<br>>> FFI-Callback. But ignore me here :)

<br>>>

<br>>> > - should a function returning an ExternalTypeAlias of atomic type

>> instantiate the Alias?

<br>>>

>> Yes, please! See above.

<br>>>

<br>>> If you want to trade type safety in for a performance gain, just use a

<br>>> "lightweight alias" as explained above. And package that return value

<br>>> manually.

<br>>>

<br>>> Best,

<br>>> Marcel

<br>>>

<br>>> Am 18.06.2020 21:03:53 schrieb Nicolas Cellier <><br>>> <a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>>:

<br>>> Hi all,

<br>>> following the question of Marcel about usage of ExternalTypeAlias:

<br>>>

>> Type alias are subclasses of ExternalStructure.

<br>>> I used them in HDF5 because there was no other means to define an alias

>> at the time.

<br>>> Now we have another mean by adding a class side method in ExternalType (I

<br>>> would have rather imagined the usage of some annotation to get a

<br>>> declarative style)

<br>>>

<br>>> This has one advantage: type safety. You cannot pass a Foo to a function

>> expecting a Bar, even if they both alias int...

<br>>>

<br>>> But this has one major drawback: with current FFI, you cannot pass a

<br>>> Smalltalk Integer, to a method expecting a Bar, even if Bar is an alias for

>> an integer type...

<br>>>

>> Thus, you have to wrap every Bar argument into a Bar instance...

>> Gasp, this is going too far...

<br>>>

>> What about functions returning such alias?

<br>>> Function returning struct by value allocate a struct, but it's not the

<br>>> case here, FFI plugin is clever enough to recognize an atomic type alias

>> and simply return a Smalltalk Integer...

>> So it's not Bar all the way down, I have to manually wrap Bar...

>> This is not consistent.

<br>>> If we return an int, we must accept an int, otherwise, we cannot chain

<br>>> FFI calls...

<br>>>

<br>>> I could use the lightweight alias instead, but there was another usage

>> where it was convenient to use ExternalTypeAlias: enum.

<br>>> Indeed, I simply defined all enum symbols as class side method. For

<br>>> example for enum bar { beg=0, mid=1, end=2 }; I simply create a type Bar

>> aliasing int and having class side methods beg ^0, mid ^1, end ^2.

>> This way, I normally can pass a Bar mid to an external function.

<br>>> (currently, we must defne mid ^Bar new value: 1; yourself)

<br>>>

>> If I use a simpler alias, where are those ids going to?

<br>>>

<br>>> IMO we cannot keep statu quo in the plugin, we gotta to make the

>> inputs/outputs behave consistently.

<br>>>  The choice is this one:

<br>>> - should a function expecting an ExternalTypeAlias of atomic type accept

<br>>> an immediate value of compatible type? (the permissive implementation)

<br>>> - should a function returning an ExternalTypeAlias of atomic type

<br>>> instantiate the Alias? (the typesafe implementation, with higher runtime

<br>>> cost due to pressure on GC)

<br>>>

<br>>>

<br>>>

<br>>>

<br><div dir="ltr"><div>Err, I move this thread to Opensmalltalk VM dev, because it is not Squeak specific!</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le ven. 19 juin 2020 à 15:10, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex;min-width:500px"><div dir="ltr"><div>Hi Marcel,</div><div>thanks for your vote. Anyone else?<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le ven. 19 juin 2020 à 09:30, Marcel Taeumel <<a href="mailto:marcel.taeumel@hpi.de" target="_blank">marcel.taeumel@hpi.de</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex;min-width:500px"><div><div id="gmail-m_5957770884654581966gmail-m_-4730415257224521194gmail-m_-6005643300885061035__MailbirdStyleContent" style="font-size:10pt;font-family:Arial;color:rgb(0,0,0)">

<br>                                        <div>Hi Nicolas, hi all! :-)</div><div><br></div><div>> Type alias are subclasses of ExternalStructure.</div><div><br></div><div>And with it, they get their own instance of ExternalType, which is managed in the classVar StructTypes. Let's call them struct type.</div><div><br></div><div>> Now we have another mean by adding a class side method in ExternalType.</div><div><br></div><div>That kind of aliasing is for compile-time type referencing only -- such as in FFI calls (i.e. <apicall:...> pragmas) or struct-field definitions (i.e. #fields). (And soon <callback: ...> if I have the first version of FFI-Callback to show you :)</div><div><br></div><div>Because those aliases become fully transparent after compiling the method for the FFI call into an instance of ExternalLibraryFunction and after compiling the field specs of external structures into compiledSpec for struct types. </div><div><br></div><div>For example, on my machine in 32-bit Squeak, a 'size_t' becomes a 'long', which is Squeak FFI term for 'int'. :-) See #ffiLongVsInt. And 'int32_t' also becomes a 'long'. So, it just translates C vocabulary into Squeak FFI vocabulary. Nothing more. Nothing less.</div><div><br></div><div>Having that, please do not use class-side methods in ExternalType to alias a (complex) struct type. Use them only for renaming atomic types. Please. We may want to add checks to enforce that.</div><div><br></div><div>I suppose that this discussion focuses on type aliases that are represented as subclasses of ExternalStructure (or ExternalTypeAlias) and thus get their own struct type. So, let's ignore this other mechanism for now.</div><div><br></div><div>> This has one advantage: type safety. You cannot pass a Foo to a function expecting a Bar, even if they both alias int...</div><div><br></div><div>Yes! So, we are now talking about type aliases to atomic types. The struct type you get when aliasing a 'char' as Foo, for example, looks like this:</div><div><br></div><div>(...forgive my "creative" representation of WordArray here...)</div><div><br></div><div>compiledSpec: 0A 04 00 01</div><div>referentClass: Foo</div><div><br></div><div>How does the atomic type for 'char' look like?</div><div><br></div><div>compiledSpec: 0A 04 00 01</div><div>referentClass: nil</div><div><br></div><div>Consequently, argument coercing will fail if you pass a 'char' when a 'Foo' is expected. Because the referentClass does not match --- even if the compiledSpec does match.</div><div><br></div><div>> But this has one major drawback: with current FFI, you cannot pass a Smalltalk Integer, to a method expecting a Bar, even if Bar is an alias for an integer type...</div><div><br></div><div>That's correct. If the origin of such an argument is from within the image, you have to wrap it. But when returned from another call ... well ... that wrapping should have happened in the plugin ... But read on! :-)</div><div><br></div><div>> FFI plugin is clever enough to recognize an atomic type alias and simply return a Smalltalk Integer...</div><div>> So it's not Bar all the way down, I have to manually wrap Bar...</div><div>> This is not consistent.</div><div><br></div><div>Uhh! That's a bug. The FFI Plugin must take a look at referentClass because it does so for argument coercing.</div><div><br></div><div>Now I understand why the code generation of struct-field accessors was so apparently broken for me. I changed that so that having an alias type as part of a larger struct will automatically wrap that for you into the alias structure. :-) Even if you are just aliasing a plain 'int' ... or 'long' ... Ha ha. ;-) #ffiLongVsInt.</div><div><br></div><div>It should be "Bar all the way down". Definitely.</div><div><br></div><div>> If we return an int, we must accept an int, otherwise, we cannot chain FFI calls...</div><div><br></div><div>Well, not for type aliases. I would like keep the path of type safety here, you mentioned above.</div><div><br></div><div>Just fix the FFI plugin to respect referentClass when packaging the return value.</div><div><br></div><div>> I could use the lightweight alias instead, [...]</div><div><br></div><div>Please don't. See above. Those "lightweight alias" are for renaming atomic types only. Let's keep it simple and try to address you concern here with struct types and ExternalTypeAlias. :-)</div><div><br></div><div>> there was another usage where it was convenient to use ExternalTypeAlias: enum.</div><div>> Indeed, I simply defined all enum symbols as class side method. </div><div><br></div><div>I like that! It reads like a next step for ExternalPool. Once you have extracted the constant values from header files, and once you have those values for your platform in classVars in your external pool, use that pool to define enums through ExternalStructure.</div><div><br></div><div>Like this:</div><div><br></div><div>ExternalTypeAlias subclass: #MyEnumBar</div><div><span style="white-space:pre-wrap">  </span>instanceVariableNames: ''</div><div><span style="white-space:pre-wrap">        </span>classVariableNames: ''</div><div><span style="white-space:pre-wrap">   </span>poolDictionaries: 'HDF5Pool'</div><div><span style="white-space:pre-wrap">     </span>category: 'HDF5'</div><div><br></div><div>MyEnumBar class >> #poolFields</div><div>   "</div><div>   self defineFields.</div><div>   "</div><div>   ^ #(</div><div>      (beg HDF5_BEG)</div><div>      (mid HDF5_MID)</div><div>      (end HDF5_END)</div><div>   )</div><div><br></div><div>Note that HDF5_BEG etc. are from the HDF5Pool, which is managed via external-pool definitions. See class comment in ExternalPool to get started.</div><div><br></div><div>Note that #poolFields would translate to class-side methods as you suggested.</div><div><br></div><div>> If I use a simpler alias, where are those ids going to?</div><div><br></div><div>Please don't. See above. :-)</div><div><br></div><div>> IMO we cannot keep status quo in the plugin, we gotta to make the inputs/outputs behave consistently.</div><div><br></div><div>Absolutely!</div><div><br></div><div>> - should a function expecting an ExternalTypeAlias of atomic type accept an immediate value of compatible type?</div><div><br></div><div>Considering type safety, I think not.</div><div><br></div><div>Well ... since this is a convenience issue and thus not about saving run-time cost ... What about adding a callback into the image to react on FFIErrorCoercionFailed? Maybe the selector for such a callback could be stored in ExternalLibraryFunction since this is accessible to the plugin anyway?</div><div><br></div><div><apicall: void 'foo' (MyInt YourInt in) ifFailCoerceVia: #wrapInt: ></div><div><br></div><div>... would it be possible? Like that #doesNotUnderstand: callback?</div><div><br></div><div>I would love to do ad-hoc packaging of arguments. (Also thinking about FFI-Callback. But ignore me here :)</div><div><br></div><div>> - should a function returning an ExternalTypeAlias of atomic type instantiate the Alias?</div><div><br></div><div>Yes, please! See above.</div><div><br></div><div>If you want to trade type safety in for a performance gain, just use a "lightweight alias" as explained above. And package that return value manually.</div><div><br></div><div>Best,</div><div>Marcel</div><div></div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-top:20px;margin-left:0px;padding-left:10px;min-width:500px">

<br>                        <p style="color:rgb(170,170,170);margin-top:10px">Am 18.06.2020 21:03:53 schrieb Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>>:</p><div style="font-family:Arial,Helvetica,sans-serif">

<br><div dir="ltr"><div>Hi all,</div><div>following the question of Marcel about usage of ExternalTypeAlias:</div><div><br></div><div>Type alias are subclasses of ExternalStructure.<br></div><div>I used them in HDF5 because there was no other means to define an alias at the time.</div><div>Now we have another mean by adding a class side method in ExternalType (I would have rather imagined the usage of some annotation to get a declarative style)</div><div><br></div><div>This has one advantage: type safety. You cannot pass a Foo to a function expecting a Bar, even if they both alias int...</div><div><br></div><div>But this has one major drawback: with current FFI, you cannot pass a Smalltalk Integer, to a method expecting a Bar, even if Bar is an alias for an integer type...</div><div><br></div><div>Thus, you have to wrap every Bar argument into a Bar instance...<br></div><div>Gasp, this is going too far...</div><div><br></div><div>What about functions returning such alias?</div><div>Function returning struct by value allocate a struct, but it's not the case here, FFI plugin is clever enough to recognize an atomic type alias and simply return a Smalltalk Integer...</div><div>So it's not Bar all the way down, I have to manually wrap Bar...</div><div>This is not consistent.</div><div>If we return an int, we must accept an int, otherwise, we cannot chain FFI calls...</div><div><br></div><div>I could use the lightweight alias instead, but there was another usage where it was convenient to use ExternalTypeAlias: enum.</div><div>Indeed, I simply defined all enum symbols as class side method. For example for enum bar { beg=0, mid=1, end=2 }; I simply create a type Bar aliasing int and having class side methods beg ^0, mid ^1, end ^2.</div><div>This way, I normally can pass a Bar mid to an external function.</div><div>(currently, we must defne mid ^Bar new value: 1; yourself)<br></div><div><br></div><div>If I use a simpler alias, where are those ids going to?</div><div><br></div><div><div>IMO we cannot keep statu quo in the plugin, we gotta to make the inputs/outputs behave consistently.</div></div> The choice is this one:<br><div>- should a function expecting an ExternalTypeAlias of atomic type accept an immediate value of compatible type? (the permissive implementation)<br></div><div>- should a function returning an ExternalTypeAlias of atomic type instantiate the Alias? (the typesafe implementation, with higher runtime cost due to pressure on GC)<br></div><div><br></div><div><br></div></div>

<br></div></blockquote>

<br>                                        </div></div><br>

<br></blockquote></div>

<br></blockquote></div>

<br><u></u><u></u><u></u><u></u></div></blockquote></div></blockquote></div></div>