Home » Modeling » OCL » Resolving oclIsTypeOf() across ecore package boundaries / Custom Ecore Metamodel Binding / Implement
| Resolving oclIsTypeOf() across ecore package boundaries / Custom Ecore Metamodel Binding / Implement [message #40767] |
Tue, 16 October 2007 03:52  |
|
This is a multi-part message in MIME format.
------=_NextPart_000_0016_01C80FFB.D5BEFA50
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
As part of an industry-related project I need to implement a type =
correspondence check between instances and types expressed as part of an =
ecore metamodel. They reside in different packages, and the ecore model =
is broken up into several resources. This is parallel to the =
type/instance relationship in the UML mm.
To follow this I am following Christian W. Damus's recipe posted in =
Eclipse Corner:
http://www.eclipse.org/articles/article.php?file=3DArticle-E MF-Codegen-wi=
th-OCL/index.html
Consequently I am using the OCL console to edit my statements, Ecore =
annotations to store them within the model and a modified template =
process to embed them in the source code as Validators.
My problem is that I cannot author type compliance statements of the =
following form:
package instances
context VectorInstance
inv typeCompliance:
self.type.oclIsTypeOf(designtime::types::structures::Vector)
inv memberCompliance:
self.members.types =3D =
self.type-> oclAsType(designtime::types::structures::Vector).contentType
endpackage
This fails because the namespace reference for the types package fails =
to resolve.
This is seems to be due to the fact that (quote)
http://help.eclipse.org/help33/index.jsp?topic=3D/org.eclips e.ocl.doc/ref=
erences/overview/targetMetamodels.html
"By default, the Ecore environment uses the static EPackage registry to =
look up package names."
However...
" It can also be supplied with an alternative package registry (for =
example, one local to a ResourceSet) but it will always use the static =
registry as a backup."
The namespace-addressing problem I have described should be fairly =
common, as the necessity to address types occurs whenever a sub-type =
distinction is necessary.
Here are my questions:
1) Is there a generator-property that addresses this problem of =
resolving elements in other Ecore packages within OCL by configuration? =
If so, where is it and what is the reuired setting?
2) If the solution is not that simple, could the Eclipse Corner recipe =
be updated by the authors to address this issue?
3) Failing 1) and 2) where do I have to alter the OCL Console code and =
the Eclipse Corner recipe code to fix this myself.
Please help. I would hate to abandon OCL just because I am dealing with =
a realistically-sized metamodel and industrial requirements. This would =
be a watershed for all my critics that say that 'in a real case, you go =
back to hacking Java...'
------=_NextPart_000_0016_01C80FFB.D5BEFA50
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.6000.16544" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>As part of an =
industry-related project I need=20
to implement a type correspondence check between instances and =
types=20
expressed as part of an ecore metamodel. They reside in different =
packages,=20
and the ecore model is broken up into several resources. This is =
parallel to the=20
type/instance relationship in the UML mm.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>To follow this I am following Christian =
W. Damus's=20
recipe posted in Eclipse Corner:</FONT></DIV>
<DIV><A=20
href=3D" http://www.eclipse.org/articles/article.php?file=3DArticle-E MF-Co=
degen-with-OCL/index.html"><FONT=20
face=3DArial=20
size=3D2> http://www.eclipse.org/articles/article.php?file=3DArticle-E MF-C=
odegen-with-OCL/index.html</FONT></A></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Consequently I am using the OCL console =
to edit my=20
statements, Ecore annotations to store them within the model and a =
modified=20
template process to embed them in the source code as =
Validators.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>My <STRONG>problem</STRONG> is that I =
cannot author=20
<STRONG>type compliance statements</STRONG> of the following =
form:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3D"Courier New" size=3D2>package instances</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT> </DIV>
<DIV><FONT face=3D"Courier New" size=3D2>context =
VectorInstance</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT> </DIV>
<DIV><FONT face=3D"Courier New" size=3D2>inv =
typeCompliance:</FONT></DIV>
<DIV><FONT face=3D"Courier New"=20
size=3D2>self.type.oclIsTypeOf(<STRONG>designtime::types::structures:: </S=
TRONG>Vector)</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT> </DIV>
<DIV><FONT face=3D"Courier New" size=3D2>inv =
memberCompliance:</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>self.members.types =3D=20
self.type->oclAsType(<STRONG>designtime::types::structures:: </STRONG>V=
ector).contentType</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT> </DIV>
<DIV><FONT face=3D"Courier New" size=3D2>endpackage</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>This <STRONG>fails because the =
namespace=20
reference for the <FONT face=3D"Courier New">types</FONT> package fails =
to=20
resolve</STRONG>.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>This is seems to be due to the fact =
that=20
(quote)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>
<DIV><A=20
href=3D" http://help.eclipse.org/help33/index.jsp?topic=3D/org.eclips e.ocl=
..doc/references/overview/targetMetamodels.html"><FONT=20
face=3DArial=20
size=3D2> http://help.eclipse.org/help33/index.jsp?topic=3D/org.eclips e.oc=
l.doc/references/overview/targetMetamodels.html</FONT></A> </DIV></FONT></=
DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>"<FONT face=3D"Times New Roman" =
size=3D3>By default,=20
the Ecore environment uses the static <EM class=3DCodeName>EPackage</EM> =
registry=20
to look up package names."</FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>However...</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>"<FONT face=3D"Times New Roman" =
size=3D3> It can also=20
be supplied with an alternative package registry (for example, one local =
to a=20
<EM class=3DCodeName>ResourceSet</EM>) but it will always use the static =
registry=20
as a backup."</FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>The namespace-addressing problem I have =
described=20
should be fairly common, as the necessity to address types occurs =
whenever a=20
sub-type distinction is necessary.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Here are my =
questions:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>1) Is there a generator-property that =
addresses=20
this problem of resolving elements in other Ecore packages within OCL by =
configuration? If so, where is it and what is the reuired =
setting?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>2) If the solution is not that simple, =
could the=20
Eclipse Corner recipe be updated by the authors to address this=20
issue?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>3) Failing 1) and 2) where do I have to =
alter the=20
OCL Console code and the Eclipse Corner recipe code to fix this=20
myself.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Please help. I would hate to abandon =
OCL just=20
because I am dealing with a realistically-sized metamodel and industrial =
requirements. This would be a watershed for all my critics that say that =
'in a=20
real case, you go back to hacking Java...'</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV></BODY></HTML>
------=_NextPart_000_0016_01C80FFB.D5BEFA50--
|
|
|
| Re: Resolving oclIsTypeOf() across ecore package boundaries / Custom Ecore Metamodel Binding / Imple [message #40924 is a reply to message #40767] |
Tue, 16 October 2007 19:38  |
Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Jörn,
I can do the following:
1. launch a run-time workbench
2. open the Interactive OCL Console
3. open an Ecore model
4. select some EClass in the Ecore model
5. input the following OCL expression:
extlibrary::BookCategory.allInstances()
6. the expected results (Mystery, Biography, ScienceFiction) are displayed
(this is with the org.eclipse.emf.examples.library plug-in installed)
So, perhaps the problem is somehow specific to your metamodel?
I see that you have a qualified path name of multiple segments. Is this
implemented as nested EPackages? Is it registered on the
org.eclipse.emf.ecore.generated_package extension point? That should make
it available in the global package registry. Do references to
designtime::types::structures::Vector resolve correctly in the OCL console
in the context of an editor on an instance of the designtime metamodel?
Concerning your question (1), there is no code-generation support for OCL in
EMF as such. However, it does generate a plugin.xml file that registers
the package on the generated_package extension point.
HTH,
Christian
Jörn Guy Süß wrote:
> As part of an industry-related project I need to implement a type
> correspondence check between instances and types expressed as part of an
> ecore metamodel. They reside in different packages, and the ecore model is
> broken up into several resources. This is parallel to the type/instance
> relationship in the UML mm.
>
> To follow this I am following Christian W. Damus's recipe posted in
> Eclipse Corner:
>
http://www.eclipse.org/articles/article.php?file=Article-EMF -Codegen-with-OCL/index.html
>
> Consequently I am using the OCL console to edit my statements, Ecore
> annotations to store them within the model and a modified template process
> to embed them in the source code as Validators.
>
> My problem is that I cannot author type compliance statements of the
> following form:
>
> package instances
>
> context VectorInstance
>
> inv typeCompliance:
> self.type.oclIsTypeOf(designtime::types::structures::Vector)
>
> inv memberCompliance:
> self.members.types =
> self.type-> oclAsType(designtime::types::structures::Vector).contentType
>
> endpackage
>
> This fails because the namespace reference for the types package fails to
> resolve.
>
> This is seems to be due to the fact that (quote)
>
http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse. ocl.doc/references/overview/targetMetamodels.html
>
> "By default, the Ecore environment uses the static EPackage registry to
> look up package names."
>
> However...
>
> " It can also be supplied with an alternative package registry (for
> example, one local to a ResourceSet) but it will always use the static
> registry as a backup."
>
> The namespace-addressing problem I have described should be fairly common,
> as the necessity to address types occurs whenever a sub-type distinction
> is necessary.
>
> Here are my questions:
>
> 1) Is there a generator-property that addresses this problem of resolving
> elements in other Ecore packages within OCL by configuration? If so, where
> is it and what is the reuired setting? 2) If the solution is not that
> simple, could the Eclipse Corner recipe be updated by the authors to
> address this issue? 3) Failing 1) and 2) where do I have to alter the OCL
> Console code and the Eclipse Corner recipe code to fix this myself.
>
> Please help. I would hate to abandon OCL just because I am dealing with a
> realistically-sized metamodel and industrial requirements. This would be a
> watershed for all my critics that say that 'in a real case, you go back to
> hacking Java...'
|
|
|
| Re: Resolving oclIsTypeOf() across ecore package boundaries / Custom Ecore Metamodel Binding / Imple [message #40955 is a reply to message #40924] |
Tue, 16 October 2007 23:51 |
|
This is a multi-part message in MIME format.
------=_NextPart_000_0014_01C810A3.5CE19360
Content-Type: multipart/alternative;
boundary="----=_NextPart_001_0015_01C810A3.5CE19360"
------=_NextPart_001_0015_01C810A3.5CE19360
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: quoted-printable
You are describing a special case. In it, there are no nested =
subpackages and no cross-references among ecore resources. Attached I =
provide you with a minimal test in the form of an EMF project. It =
consists of two ecore files, the linking genmodel and the rose model =
they were generated from. In the test, here::there::Monster lives in a =
nested package in here.ecore, and andeverywhere::CookieMonster lives in =
andeverywhere.ecore and extends Monster. Now for the test, try the OCL =
console in context CookieMonster (i.e. Ecore Editor focussed on =
CookieMonster class and set to M1) It fails with a lookup error. =20
Evaluating:
self.oclIsKindOf(here::there::Monster)
Results:
ERROR in (enumerationOrClassLiteralExpCS): (Unknown type ([here, there, =
Monster]))
This is what I need to fix inorder to build my project. This will also =
need to work in context of the generated statements based on the recipe. =
I.e. fixes have to be made to the OCL console and generator.
"Christian W. Damus" <cdamus@ca.ibm.com> wrote in message =
news:ff3408$4e6$1@build.eclipse.org...
> Hi, J=C3=B6rn,
>=20
> I can do the following:
>=20
> 1. launch a run-time workbench
> 2. open the Interactive OCL Console
> 3. open an Ecore model
> 4. select some EClass in the Ecore model
> 5. input the following OCL expression:
>=20
> extlibrary::BookCategory.allInstances()
>=20
> 6. the expected results (Mystery, Biography, ScienceFiction) are =
displayed
>=20
> (this is with the org.eclipse.emf.examples.library plug-in installed)
>=20
> So, perhaps the problem is somehow specific to your metamodel?
>=20
> I see that you have a qualified path name of multiple segments. Is =
this
> implemented as nested EPackages? Is it registered on the
> org.eclipse.emf.ecore.generated_package extension point? That should =
make
> it available in the global package registry. Do references to
> designtime::types::structures::Vector resolve correctly in the OCL =
console
> in the context of an editor on an instance of the designtime =
metamodel?
>=20
> Concerning your question (1), there is no code-generation support for =
OCL in
> EMF as such. However, it does generate a plugin.xml file that =
registers
> the package on the generated_package extension point.
>=20
> HTH,
>=20
> Christian
>=20
>=20
> J=C3=B6rn Guy S=C3=BC=C3=9F wrote:
>=20
>> As part of an industry-related project I need to implement a type
>> correspondence check between instances and types expressed as part of =
an
>> ecore metamodel. They reside in different packages, and the ecore =
model is
>> broken up into several resources. This is parallel to the =
type/instance
>> relationship in the UML mm.
>>=20
>> To follow this I am following Christian W. Damus's recipe posted in
>> Eclipse Corner:
>>
> =
http://www.eclipse.org/articles/article.php?file=3DArticle-E MF-Codegen-wi=
th-OCL/index.html
>>=20
>> Consequently I am using the OCL console to edit my statements, Ecore
>> annotations to store them within the model and a modified template =
process
>> to embed them in the source code as Validators.
>>=20
>> My problem is that I cannot author type compliance statements of the
>> following form:
>>=20
>> package instances
>>=20
>> context VectorInstance
>>=20
>> inv typeCompliance:
>> self.type.oclIsTypeOf(designtime::types::structures::Vector)
>>=20
>> inv memberCompliance:
>> self.members.types =3D
>> =
self.type-> oclAsType(designtime::types::structures::Vector).contentType
>>=20
>> endpackage
>>=20
>> This fails because the namespace reference for the types package =
fails to
>> resolve.
>>=20
>> This is seems to be due to the fact that (quote)
>>
> =
http://help.eclipse.org/help33/index.jsp?topic=3D/org.eclips e.ocl.doc/ref=
erences/overview/targetMetamodels.html
>>=20
>> "By default, the Ecore environment uses the static EPackage registry =
to
>> look up package names."
>>=20
>> However...
>>=20
>> " It can also be supplied with an alternative package registry (for
>> example, one local to a ResourceSet) but it will always use the =
static
>> registry as a backup."
>>=20
>> The namespace-addressing problem I have described should be fairly =
common,
>> as the necessity to address types occurs whenever a sub-type =
distinction
>> is necessary.
>>=20
>> Here are my questions:
>>=20
>> 1) Is there a generator-property that addresses this problem of =
resolving
>> elements in other Ecore packages within OCL by configuration? If so, =
where
>> is it and what is the reuired setting? 2) If the solution is not that
>> simple, could the Eclipse Corner recipe be updated by the authors to
>> address this issue? 3) Failing 1) and 2) where do I have to alter the =
OCL
>> Console code and the Eclipse Corner recipe code to fix this myself.
>>=20
>> Please help. I would hate to abandon OCL just because I am dealing =
with a
>> realistically-sized metamodel and industrial requirements. This would =
be a
>> watershed for all my critics that say that 'in a real case, you go =
back to
>> hacking Java...'
>
------=_NextPart_001_0015_01C810A3.5CE19360
Content-Type: text/html;
charset="utf-8"
Content-Transfer-Encoding: quoted-printable
=EF=BB=BF<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8">
<META content=3D"MSHTML 6.00.6000.16544" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV>You are describing a special case. In it, there are no nested =
subpackages=20
and no cross-references among ecore resources. Attached I provide =
you with=20
a minimal test in the form of an EMF project. It consists of two ecore =
files,=20
the linking genmodel and the rose model they were generated from. In the =
test,=20
here::there::Monster lives in a nested package in here.ecore, and=20
andeverywhere::CookieMonster lives in andeverywhere.ecore and extends =
Monster.=20
Now for the test, try the OCL console in <STRONG>context=20
CookieMonster</STRONG> (i.e. Ecore Editor focussed on CookieMonster =
class and=20
set to M1) It fails with a lookup error. </DIV>
<DIV><B><FONT size=3D2><B><FONT size=3D2><B><FONT size=3D2>
<P align=3Dleft><FONT size=3D3>Evaluating:</FONT></P></B>
<P align=3Dleft><FONT =
size=3D3>self.oclIsKindOf(here::there::Monster)</FONT></P >
<P align=3Dleft><FONT size=3D3></FONT></P><B>
<P align=3Dleft><FONT size=3D3>Results:</FONT></P></B></FONT><FONT =
color=3D#c00000=20
size=3D3>
<P>ERROR in (enumerationOrClassLiteralExpCS): (Unknown type ([here, =
there,=20
Monster]))</P></FONT></B></FONT><FONT color=3D#c00000=20
size=3D2></FONT></B></FONT><FONT color=3D#c00000 size=3D2></FONT><FONT=20
size=3D1></DIV></FONT>
<DIV>This is what I need to fix inorder to build my project. This will =
also need=20
to work in context of the generated statements based on the recipe. I.e. =
fixes=20
have to be made to the OCL console and generator.</DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV>"Christian W. Damus" <<A=20
href=3D"mailto:cdamus@ca.ibm.com">cdamus@ca.ibm.com</A>> wrote in =
message <A=20
href=3D"news:ff3408$4e6$1@build.eclipse.org">news:ff3408$4e6$1@build.ecli=
pse.org</A>...</DIV>>=20
Hi, J=C3=B6rn,<BR>> <BR>> I can do the following:<BR>> =
<BR>> 1.=20
launch a run-time workbench<BR>> 2. open the Interactive OCL=20
Console<BR>> 3. open an Ecore model<BR>> 4. select =
some EClass=20
in the Ecore model<BR>> 5. input the following OCL =
expression:<BR>>=20
<BR>> =
extlibrary::BookCategory.allInstances()<BR>>=20
<BR>> 6. the expected results (Mystery, Biography, =
ScienceFiction) are=20
displayed<BR>> <BR>> (this is with the =
org.eclipse.emf.examples.library=20
plug-in installed)<BR>> <BR>> So, perhaps the problem is somehow =
specific=20
to your metamodel?<BR>> <BR>> I see that you have a qualified path =
name of=20
multiple segments. Is this<BR>> implemented as nested =
EPackages? =20
Is it registered on the<BR>> org.eclipse.emf.ecore.generated_package=20
extension point? That should make<BR>> it available in the =
global=20
package registry. Do references to<BR>>=20
designtime::types::structures::Vector resolve correctly in the OCL=20
console<BR>> in the context of an editor on an instance of the =
designtime=20
metamodel?<BR>> <BR>> Concerning your question (1), there is no=20
code-generation support for OCL in<BR>> EMF as such. However, =
it does=20
generate a plugin.xml file that registers<BR>> the package on the=20
generated_package extension point.<BR>> <BR>> HTH,<BR>> =
<BR>>=20
Christian<BR>> <BR>> <BR>> J=C3=B6rn Guy S=C3=BC=C3=9F =
wrote:<BR>> <BR>>> As=20
part of an industry-related project I need to implement a =
type<BR>>>=20
correspondence check between instances and types expressed as part of=20
an<BR>>> ecore metamodel. They reside in different packages, and =
the ecore=20
model is<BR>>> broken up into several resources. This is parallel =
to the=20
type/instance<BR>>> relationship in the UML mm.<BR>>> =
<BR>>>=20
To follow this I am following Christian W. Damus's recipe posted =
in<BR>>>=20
Eclipse Corner:<BR>>><BR>> <A=20
href=3D" http://www.eclipse.org/articles/article.php?file=3DArticle-E MF-Co=
degen-with-OCL/index.html">http://www.eclipse.org/articles/article.php?fi=
le=3DArticle-EMF-Codegen-with-OCL/index.html</A><BR>>>=20
<BR>>> Consequently I am using the OCL console to edit my =
statements,=20
Ecore<BR>>> annotations to store them within the model and a =
modified=20
template process<BR>>> to embed them in the source code as=20
Validators.<BR>>> <BR>>> My problem is that I cannot author =
type=20
compliance statements of the<BR>>> following form:<BR>>>=20
<BR>>> package instances<BR>>> <BR>>> context=20
VectorInstance<BR>>> <BR>>> inv typeCompliance:<BR>>>=20
self.type.oclIsTypeOf(designtime::types::structures::Vector) <BR>>> =
<BR>>> inv memberCompliance:<BR>>> self.members.types =
=3D<BR>>>=20
self.type->oclAsType(designtime::types::structures::V ector).contentTyp=
e<BR>>>=20
<BR>>> endpackage<BR>>> <BR>>> This fails because the=20
namespace reference for the types package fails to<BR>>>=20
resolve.<BR>>> <BR>>> This is seems to be due to the fact =
that=20
(quote)<BR>>><BR>> <A=20
href=3D" http://help.eclipse.org/help33/index.jsp?topic=3D/org.eclips e.ocl=
..doc/references/overview/targetMetamodels.html">http://help.eclipse.org/h=
elp33/index.jsp?topic=3D/org.eclipse.ocl.doc/references/over view/targetMe=
tamodels.html</A><BR>>>=20
<BR>>> "By default, the Ecore environment uses the static EPackage =
registry to<BR>>> look up package names."<BR>>> <BR>>> =
However...<BR>>> <BR>>> " It can also be supplied with an=20
alternative package registry (for<BR>>> example, one local to a=20
ResourceSet) but it will always use the static<BR>>> registry as a =
backup."<BR>>> <BR>>> The namespace-addressing problem I =
have=20
described should be fairly common,<BR>>> as the necessity to =
address types=20
occurs whenever a sub-type distinction<BR>>> is =
necessary.<BR>>>=20
<BR>>> Here are my questions:<BR>>> <BR>>> 1) Is there =
a=20
generator-property that addresses this problem of resolving<BR>>> =
elements=20
in other Ecore packages within OCL by configuration? If so, =
where<BR>>> is=20
it and what is the reuired setting? 2) If the solution is not =
that<BR>>>=20
simple, could the Eclipse Corner recipe be updated by the authors =
to<BR>>>=20
address this issue? 3) Failing 1) and 2) where do I have to alter the=20
OCL<BR>>> Console code and the Eclipse Corner recipe code to fix =
this=20
myself.<BR>>> <BR>>> Please help. I would hate to abandon =
OCL just=20
because I am dealing with a<BR>>> realistically-sized metamodel =
and=20
industrial requirements. This would be a<BR>>> watershed for all =
my=20
critics that say that 'in a real case, you go back to<BR>>> =
hacking=20
Java...'<BR>></BODY></HTML>
------=_NextPart_001_0015_01C810A3.5CE19360--
------=_NextPart_000_0014_01C810A3.5CE19360
Content-Type: application/x-zip-compressed;
name="OCL does not resolve across packages.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="OCL does not resolve across packages.zip"
UEsDBBQAAAAIAFVEUTceoSaq+wAAALkCAAAtAAAAT0NMIGRvZXMgbm90IHJl c29sdmUgYWNyb3Nz
IHBhY2thZ2VzLy5wcm9qZWN0vVLLTsMwEDyDxD9YuZOUGwc3lSjqiZdU+ABj L8bF8VpeJ+LzsZ0E
FFWVOCBuO+MZzWi9fPPZWTZAIINuXV3Vq4qBk6iM0+vq5Xl3eV1t2otz7gMe QMZbIBmMj0md2DPu
RAft4/aOKQRiDiMLQGgHYEIGJGJeyA+hgXhTpNkjsevAxZY385TZKYAKaBbo tTdW7T3IjCa4TVbh
VGGmGhh0DdIaT1AfVKwlhjSIQRQDhJ8KySGC7nM2TbhZErw5SvlVrldQ3wtn 3oDizf/G7uU7dOJP
QidmXnnKi33611E9gtPbHt9zgaI75cmVn2yvjXs4MsxzTvy+heXpfQFQSwME FAAAAAgAVURRN5cC
saW2AAAAKwEAAC8AAABPQ0wgZG9lcyBub3QgcmVzb2x2ZSBhY3Jvc3MgcGFj a2FnZXMvLmNsYXNz
cGF0aH2P3QsBQRTFnyn/wzbv7qKUh12SVlEolleNmdsaxp1tPsR/7ztSvJ1z +t3uOUnvdNDREa1T
hlLWhAaLkISRioqULfNhvcN63Vo1EZo7V3K/vZrK2yF5e472imTKnBUsuoUP Gf8mhaEXaWwBKLQq
HcJOetA8kNhev8N4nq0Hs2neH02zefzNKfJoiWuQuAkFBPW8RAsLz0lyK1eT /FxiPG4tsnoT2v8K
meDL4F+dNorucBJ/rr4AUEsDBBQAAgAAAPJNUTcAAAAAAAAAAAAAAAApAAAA T0NMIGRvZXMgbm90
IHJlc29sdmUgYWNyb3NzIHBhY2thZ2VzL3NyYy9QSwMEFAACAAAA8k1RNwAA AAAAAAAAAAAAACsA
AABPQ0wgZG9lcyBub3QgcmVzb2x2ZSBhY3Jvc3MgcGFja2FnZXMvbW9kZWwv UEsDBBQAAAAIAIBE
UTeJvoJ3twEAAO0DAAA7AAAAT0NMIGRvZXMgbm90IHJlc29sdmUgYWNyb3Nz IHBhY2thZ2VzL21v
ZGVsL2V4YW1wbGUuZ2VubW9kZWydk09r3DAQxe+BfAehnmttFgrFrDeETTcJ ZNs9pNBDLoo8qxWR
NEZS9s+371i2Q5xsKFQnS5rfm/dGeHZ5cJbtIESDvuIXxYQz8Apr43XFfz8s v37nl/Pzs5kG77AG
W96AX7Uf7OBM+QpOCTw/Y7RIz8eSLiu+Takphdjv9wU6XWDQ4s/qjvclg+Ko DpQ1TYRcC24jppPJ
VAwtOcvAtQmgEoZjxcWvxT2rESLzmFiAiHYHTKqAMbJGqmepIYoYVG8u82v7 oo2/u6440S1MbI92
5AD2/X5KBxX/cZCuscCZcQ2GBKEVIJuvlsluMdwVJAN9T4XEGekV3MOujfut HbLC5hiM3qalAVvH
im+kJWTeMrMNBjC6Cz2/LR8TuOYROgOFq+1MjCoyQ+Nc975ZE2BjDhW/hUCG axMbjPLJwjrgztQQ
lrKfXwovVACK1HqYXoOgIh99EZ0fUvcQE9Q3J3o8bHOTJxnHEv/u20m363MD ImWt+VDbxlxYGSM5
yCV5c4oRK/TkOXAxZBAfQnSTE/r9yalZXvmani8c99v/Gap8S3+Y7iehTkJi gfhsYJzufYa8H/+v
dPoXUEsDBBQAAAAIAFVEUTegPq1l+gAAANcBAAA1AAAAT0NMIGRvZXMgbm90 IHJlc29sdmUgYWNy
b3NzIHBhY2thZ2VzL21vZGVsL2hlcmUuZWNvcmV1kUFrwyAcxe+FfgfxXk2z y5CkPYwWCi2UdYVd
nfsnlUUN6pbs209t0i3QefS99+P5LNa9atAXWCeNLvGSZBiBFuZd6rrE55ft 4hGvV/NZAcJYYJsj
Fx+8BtQryW6pPKTmMxROgGnHgljii/cto7TrOmJUTYyt6ethh0eLm1q6h+TI s2wZbPuTuIDiC6md
51rAhJ6aTMIgGtk6SARQVaTkdBNtGGmuohnsCNHu/Ly7xWlUCAxed7RQyX7w r2KggNPnW3t9tRto
Psn3SNT/zyP+lxq5Tw13TlYyrIjCHMx/t4E97JzEsf3BhB3AYnptRP9Win9D p58Trn4AUEsDBBQA
AAAIAIBEUTcGjfv6/QAAALYBAAA+AAAAT0NMIGRvZXMgbm90IHJlc29sdmUg YWNyb3NzIHBhY2th
Z2VzL21vZGVsL2FuZGV2ZXJ5d2hlcmUuZWNvcmVdkEGLwjAQhe+C/yFkzza1 e1lCqwdREFaQVWGv
IU7bYJOUpLup/36nxRayuSXzvTcvL9/2uiG/4LyypqDrJKUEjLR3ZaqC3q6H 1QfdbpaLHKR1wPdn
IR+iAtJrxWdVhqrlguBBM+M5Dgtad13LGQshJFZXiXUV+z4d6YT4GAnvI5Gl 6Rqxz4usQYuVMr4T
RkLkPiaJxCAb1XoYHUCXg0vG9gNGiREaYWHugHGfoQY3uRl/+zrOPixCEnip /dlBqfr/DpvBIodd
I7xXpcIiCP6Id88Wl72qGodTgJ21DwUnix8ChxVfflpwV8Q9JpgXvjHWDTc2 gWyonsXd49MfUEsD
BBQAAgAAAPJNUTcAAAAAAAAAAAAAAAApAAAAT0NMIGRvZXMgbm90IHJlc29s dmUgYWNyb3NzIHBh
Y2thZ2VzL2V0Yy9QSwMEFAAAAAgAs0xRN0G1579pBgAAEScAADQAAABPQ0wg ZG9lcyBub3QgcmVz
b2x2ZSBhY3Jvc3MgcGFja2FnZXMvZXRjL2V4YW1wbGUubWRs7VpbU9s4FH42 M/wHj5/ItMs4dkgC
T4VAu8yWyxDa3X3yKLaSqMiW15KB9NfvkSU7jmOnCSSddrd5KZwjnU/nqk+h +3sHbPQF+8K8xQLR
/T0TPo844YRF8kej01Uy7ykhQmApNKw7xrHZO+wd2o7dOXRtu22pVf4UJUMs sp12a39vvzB/jjmZ
RKb1kU2Ij6j5meAnvYlwL42I2nR/9+mikFKGAhwsSP9JSWCqj2F1eu0jd2D3 bfusp20FeIxSKrjU
59C5bH/PSMhkKq5QMiERHPDQObLhA3KKx3ViwWItXRCPmBAsnK/P5FIRowm+ gehRFC9s8CmJL30W
fUQjTHnuj4FSwe4gLl9xIeIRiu/ZhwS8zEUT+OUv7XK7qwV/lwXawfcsEnOv 5W+gk6syhHyDrYVj
5BdC656EmJvX+Mm8YyGKLL1mxGgR7fenH4cXWk6gVIjPl+RpFIDzJMIVORcJ ecDLdnxGWaLt5+fS
znhKlwWhJQMzZU9XmHOI8HUagh9aNqCI85vxjXI6j1nEBBKqhA3rU0TGBAdW S5VIwpjwUo59xLEX
I/8BTM7DltnzBkjgCUtmpvUJKn0AK/OCNZoq8Fgq8XPMEjGA0CeMgv42HUGg pGZC2QjKvlTkBlWt
4IUsyKrigBIuTNkKXoLHOMGRjz0pa5UWxwnmOFLerdqjo5m7BW5IL84JmiQo NK0rRLIsN7kz6GVa
QQTFubbY85WxcF5PMnFGiJ69KZbdZRpO3z0qhE8kEFNY57S7aiWDHiSR95zn PBfMCgEROOTavPIv
UMf2pEZFBD6lbPp5uhrTWBk7jVnsb5xFno74jMPBpKUBC2MWQX4WgNIaoFNr kwqoZLPq3RSWNmbz
wnZPO5m22a+NTrLyKKI4S91h2j3bbavSWnWazY6zfB6ob+gOgRNlre4knb7t 9I4tWUYlvHW7q6X2
bb7tG4lEUWBiuEBmT6tS2r6w246725SaUMvsgWBzIZI1h3EGdvv4vVLzNMaJ L7fjApBE4ApcGBIt
wVTFaEri+vRdllbflVY35vEMYnHa13kG/JgSnGT6csufnMh4npwI9c9ydaQN 1fHSPG9hZGdpWHtg
n1380AO7tsZkZqDO5I+WWcnXYiecnFSq0XzXzpI3lBQAhi5KRAgxHoIOMzGL 8ZxlwSIoC8gBPxXA
Q0apwDW6G6hcRRnmusvIp2mA67ZpVd0uyvyCexx0up23Zs/tqjEzlgwtD9Qi TzPqmZqxFlczGtma
0cjXjEbGZjRyNqOWtRmreBvEQ5LeitOXUBcZGS623yJoBOFlJWHo5Er5QjSd nvvW7B73WoU6kmfn
OmCFtFzHbt8p5F9SLsh4Vjl5+YDVqaeQCHB3j4sZtJZhSSI/n4Zp8zTUJ1DP KNVLhm45nWB14uoz
oLVxs9QON/Od8/O0iNvv/GqRjVrEqW8R96gH0ewcbdIiTruzSYu8tDf0pbrU G47rvLw3NGFQ3QE1
7yoiUhR5qepqjlRmD/BIx7r28gFU5hM64DKYubt2q/IOmb8FijQO09FQiRoe B2bT4yCezvj678Ni
9QvZxhULUoq99R+I3Z/kgRgnzIfhBTlLUl+kSemtf6tUmK9IxZl0SC7k1+f4 MQ9oJXja0Dx65zim
bBaWc92IcL4cyLrtP1hMYaoLkrH8eQy0TH6zld8HRQUWN4Q3xNXwFbosEIzR Ikyn18NLc/DmjXnx
KIPxJxL+VPP2CIXzgf87CQIc3cPWTPeIaIrLY761NuLg5mrZvPZ3dhksmbd6 fbdrd91e33olSH47
eOqOrwLVh7EZsB5xEfIeBuQfJAoU2jpwK/AaABcRcZSGWl5Gg4JubcN8gn2W BLUA7a0AhNmYrAVw
tgJAIri6JJmpxXC3ghEQHq/G6WwFx2d+UcpVhKOtIABnQ/X2u1uxD/dmTmgq 9nvbKSf0XGu9vxXr
BxHQjVYtwLH+ZuNV4+MDjiS3x8vTo5aqbWz/AUZTzWQqjS0z8+TVQClczctA lvV6y/pPabsxPsU0
lm+QaLI7+0DoBX4WuwGY04Td2A8olb/v6PDz2VMx3doWEyjezt+FDey6nXfV Y7tug29U6dayXez7
le3/QbbVg/u3YYz9/0S+x4Ti3Q1bSkYJSma7Mf7r+m+0L7P6k5IL6u8qq99r RNyiBIXfZTjs2KPt
fT3zmfAU0aFIA8JegNNa8U3fIPvPAP8CUEsDBBQAAgAAAPJNUTcAAAAAAAAA AAAAAAApAAAAT0NM
IGRvZXMgbm90IHJlc29sdmUgYWNyb3NzIHBhY2thZ2VzL2Jpbi9QSwECFAAU AAAACABVRFE3HqEm
qvsAAAC5AgAALQAAAAAAAAAAAAIAAAAAAAAAT0NMIGRvZXMgbm90IHJlc29s dmUgYWNyb3NzIHBh
Y2thZ2VzLy5wcm9qZWN0UEsBAhQAFAAAAAgAVURRN5cCsaW2AAAAKwEAAC8A AAAAAAAAAAACAAAA
RgEAAE9DTCBkb2VzIG5vdCByZXNvbHZlIGFjcm9zcyBwYWNrYWdlcy8uY2xh c3NwYXRoUEsBAhQA
FAACAAAA8k1RNwAAAAAAAAAAAAAAACkAAAAAAAAAAAAQAAAASQIAAE9DTCBk b2VzIG5vdCByZXNv
bHZlIGFjcm9zcyBwYWNrYWdlcy9zcmMvUEsBAhQAFAACAAAA8k1RNwAAAAAA AAAAAAAAACsAAAAA
AAAAAAAQAAAAkAIAAE9DTCBkb2VzIG5vdCByZXNvbHZlIGFjcm9zcyBwYWNr YWdlcy9tb2RlbC9Q
SwECFAAUAAAACACARFE3ib6Cd7cBAADtAwAAOwAAAAAAAAAAAIAAAADZAgAA T0NMIGRvZXMgbm90
IHJlc29sdmUgYWNyb3NzIHBhY2thZ2VzL21vZGVsL2V4YW1wbGUuZ2VubW9k ZWxQSwECFAAUAAAA
CABVRFE3oD6tZfoAAADXAQAANQAAAAAAAAAAAIAAAADpBAAAT0NMIGRvZXMg bm90IHJlc29sdmUg
YWNyb3NzIHBhY2thZ2VzL21vZGVsL2hlcmUuZWNvcmVQSwECFAAUAAAACACA RFE3Bo37+v0AAAC2
AQAAPgAAAAAAAAAAAIAAAAA2BgAAT0NMIGRvZXMgbm90IHJlc29sdmUgYWNy b3NzIHBhY2thZ2Vz
L21vZGVsL2FuZGV2ZXJ5d2hlcmUuZWNvcmVQSwECFAAUAAIAAADyTVE3AAAA AAAAAAAAAAAAKQAA
AAAAAAAAABAAAACPBwAAT0NMIGRvZXMgbm90IHJlc29sdmUgYWNyb3NzIHBh Y2thZ2VzL2V0Yy9Q
SwECFAAUAAAACACzTFE3QbXnv2kGAAARJwAANAAAAAAAAAAAAIAAAADWBwAA T0NMIGRvZXMgbm90
IHJlc29sdmUgYWNyb3NzIHBhY2thZ2VzL2V0Yy9leGFtcGxlLm1kbFBLAQIU ABQAAgAAAPJNUTcA
AAAAAAAAAAAAAAApAAAAAAAAAAAAEAAAAJEOAABPQ0wgZG9lcyBub3QgcmVz b2x2ZSBhY3Jvc3Mg
cGFja2FnZXMvYmluL1BLBQYAAAAACgAKALADAADYDgAAAAA=
------=_NextPart_000_0014_01C810A3.5CE19360--
|
|
|
| Re: Resolving oclIsTypeOf() across ecore package boundaries / Custom Ecore Metamodel Binding / Imple [message #40987 is a reply to message #40924] |
Wed, 17 October 2007 01:05 |
|
To answer the questions in detail:
Is this (qualified path name of multiple segments) implemented as nested
EPackages?
Yes, it is modelled as nested EPackages
Is it (the set of packages) registered on the
org.eclipse.emf.ecore.generated_package extension point?
Yes, each package is registered.
Do references to designtime::types::structures::Vector resolve correctly in
the OCL console
in the context of an editor on an instance of the designtime metamodel?
No, they do not resolve. They produce the type resolution error
described in the other post. However, navigation to these features works. It
is only type navigation statements that fail.
"Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
news:ff3408$4e6$1@build.eclipse.org...
> Hi, J
|
|
|
| Re: Resolving oclIsTypeOf() across ecore package boundaries / Custom Ecore Metamodel Binding / Imple [message #41049 is a reply to message #40955] |
Wed, 17 October 2007 14:30 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Jörn,
Thanks for the attachment. With that, I was able to generate the code and
make the following conclusions:
- EMF does not generate EPackages that have no EClassifiers, as is the
case with the "here" package. Thus, it is not present in the EPackage
registry for the OCL parser to find when looking up "here::there". See
https://bugs.eclipse.org/bugs/show_bug.cgi?id=142856 for details
- if the OCL parser (the Ecore environment implementation) cannot find
the package in the registry, it tries again looking for packages by
nsPrefix for precisely this problem of classifierless parent packages.
When I tried your attached example, this actually caused the parser to
find "here::there" and successfully parse a reference to
"here::there::Monster". The parser will look for the nsPrefix that
EMF supplies by default (which you may change), which in this case
is "here.there".
Actually, one other step helped me to successfully parse: causing the
"here::there" and "andanywhere" EPackages to load by creating/loading
instance models.
The OCL parser can only find EPackages in the registry that have already
been initialized. It doesn't resolve EPackage.Descriptors because this
will load unwanted plug-ins having EPackages that don't match, and because
it assumes that if the package isn't already resolved we won't have an
instance model on which to parse OCL expressions, anyway.
In your application, this assumption isn't good. You can work around it by:
- forcibly initializing the EPackages required before doing any OCL, for
example by accessing the DesigntimePackage.eINSTANCE field
- since you probably have custom (short) nsPrefixes for your packages,
you can do what OCL does, itself, for the root "ocl" EPackage that has
no classifiers: have one or all of the subpackages create and register
it so that it is as though bugzilla 142856 were implemented
Note that it would be difficult for the OCL parser to find the right
EPackage.Descriptor in the registry in order to load the EPackage that it
is looking for. The descriptor only knows (by its key in the map) the
namespace URI, which doesn't, in general, bear any resemblance to the
EPackage name. Perhaps if EMF were to enhance the generated_package
extension point to include the qualified package name in addition to the
Java interface name, the descriptor could then have this information. Of
course, that wouldn't help with extant packages until they are regenerated
....
HTH,
Christian
Jörn Guy Süß wrote:
> You are describing a special case. In it, there are no nested subpackages
> and no cross-references among ecore resources. Attached I provide you with
> a minimal test in the form of an EMF project. It consists of two ecore
> files, the linking genmodel and the rose model they were generated from.
> In the test, here::there::Monster lives in a nested package in here.ecore,
> and andeverywhere::CookieMonster lives in andeverywhere.ecore and extends
> Monster. Now for the test, try the OCL console in context CookieMonster
> (i.e. Ecore Editor focussed on CookieMonster class and set to M1) It fails
> with a lookup error. Evaluating:
>
> self.oclIsKindOf(here::there::Monster)
>
>
> Results:
>
> ERROR in (enumerationOrClassLiteralExpCS): (Unknown type ([here, there,
> Monster]))
>
> This is what I need to fix inorder to build my project. This will also
> need to work in context of the generated statements based on the recipe.
> I.e. fixes have to be made to the OCL console and generator.
-----8<-----
|
|
|
| Re: Resolving oclIsTypeOf() across ecore package boundaries / Custom Ecore Metamodel Binding / Imple [message #41173 is a reply to message #41049] |
Thu, 18 October 2007 03:24 |
|
Still unable to get a positive parse using the OCL console. Steps tried:
1) Created a dynamic instance of Monster and Cookie Monster. Saved these
instance files in the workspace
2) Focussed Ecore Editor on CookieMonster class and set to M1. Repeated
Scenario
Same failure.
Is it necessary for me to generate the source of the model or does the OCL
console also work in reflective mode, i.e. in absence of generated code? For
all other statements, this seems to hold...
I have generated the model code, makes no difference...
Could you post a compiled version of the OCL console somewhere, so I can
start from an asserted and unaltered state?
Thanks for looking into it, JG
"Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
news:ff569v$sh3$1@build.eclipse.org...
> Hi, J
|
|
| |
| Re: Resolving oclIsTypeOf() across ecore package boundaries / Custom Ecore Metamodel Binding / Imple [message #41327 is a reply to message #41173] |
Thu, 18 October 2007 15:23 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
--nextPart1267212.eHulEQdGCd
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8Bit
Hi, JG,
See some comments in-line, below.
Jrn Guy S wrote:
> Still unable to get a positive parse using the OCL console. Steps tried:
>
> 1) Created a dynamic instance of Monster and Cookie Monster. Saved these
> instance files in the workspace
> 2) Focussed Ecore Editor on CookieMonster class and set to M1. Repeated
> Scenario
>
> Same failure.
>
> Is it necessary for me to generate the source of the model or does the OCL
> console also work in reflective mode, i.e. in absence of generated code?
> For all other statements, this seems to hold...
> I have generated the model code, makes no difference...
No, this is not necessary. Find attached a JUnit plug-in test project that
demonstrates how to use dynamic EMF with the OCL parser/interpreter. This
test loads the monster models into a resource set's local package registry,
creates dynamic instances of them, and parses qualified references to the
Monster and CookieMonster types in the context of some other metamodel (in
this test, Ecore).
Run the included launch configuration to check it out.
The trick with dynamic EMF is that none of the packages will be registered
in the global EPackage registry, because that is normally only done for
generated static APIs using the extension point.
> Could you post a compiled version of the OCL console somewhere, so I can
> start from an asserted and unaltered state?
The OCL console example is available as a binary on the download page. Just
take the mdt-ocl-examples-<buildid>.zip file. Or, install the
org.eclipse.emf.ocl.examples feature from the MDT update site.
> Thanks for looking into it, JG
>
-----8<-----
--nextPart1267212.eHulEQdGCd
Content-Type: application/x-zip; name="ocl-with-dynamic-emf.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="ocl-with-dynamic-emf.zip"
UEsDBBQACAAIAEtaUjcAAAAAAAAAAAAAAAAfAAAAb2NsLndpdGguZHluYW1p Yy5lbWYvLmNsYXNz
cGF0aJ2QQUsDMRCFzxX6H5bcO2sFwcOuRWSFFlqlXXuVNBm2o+kknSRi/73V WhShHrzNG7557zHV
6G3jileUSJ5rNYRzVSAbb4m7Wj22d4MrNbrun1XG6RiDTuu96H0r5CS74oXY 1iqKUcXH8jCWp0nj
+Uh66QCNoxARnm0CpzOb9T4dJvPm6fZ+1t6MZ828/M0RJxTWDiyucgeZvi5R YJE0Wy12OW13AcvJ
xaIZDOHyH4WCRTBeEAS3mQTtg8sdcfzLyucUcjq6rYg/4ar8+cB3UEsHCGNz zMDOAAAAdgEAAFBL
AwQUAAgACABLWlI3AAAAAAAAAAAAAAAAHQAAAG9jbC53aXRoLmR5bmFtaWMu ZW1mLy5wcm9qZWN0
vZJNSgQxEIXXCt5h6L2J7lxkekDFnSKMHiBWanpqyB9JetTbm8S00jSCC3FX 71W9fCEpsXkzenXE
EMnZdXfJLroVWnCK7LDunp/uzq+6TX92KnxwB4R0ixEC+ZSns3sirDTYO9Ds ldKeqfesCRianeC1
VWbAGYM29YJPVXHbgbEKPlMvI2m19QhFNXmTo9Kq6kzYMDAETT4iO6jEwIVc yKOsAQzfV8gJGYax
sGPTfG4IvqD8iusVsntpaYcxXf8vdgt7NPJPoM2Znjzz0hiwTX+KBf5RjwPZ h9os9Dr0U2D2PXaR
mepC/NqF+ap9AFBLBwjC0uEd7gAAAKkCAABQSwMEFAAIAAgAS1pSNwAAAAAA AAAAAAAAADkAAABv
Y2wud2l0aC5keW5hbWljLmVtZi8uc2V0dGluZ3Mvb3JnLmVjbGlwc2UuamR0 LmNvcmUucHJlZnOt
WMFuGzkMvRfIPxjo3UiKbrtbwAfHdlAXrRM0RnOWJc6MGo00pSSn3q/fp7Hj OItFO1L2EtiT4RPJ
Rz5Sfr1u4uhahtHFn6OL8w9v3304/2u0mK9Hb87P35+9Iml052ncMVXEZCX5 8ZbYa2cnF2evHNfj
x1e+qzCWjgl/2k4bYnxQVJMda2u0pU+eL3eB0sMJWbExpIYCBME1hRsjQuW4 nVyM/xhqGW30pD47
KcwEMXjiLf3etu2MFoh1yEmKNrEepwBXsd0QT3AssQi/PeZgmFz7JlinhGTa ehdZ0pXOMOzY4Zx2
LKx1QQTQeBs74qUNxJVAxA+Crbb1YByPlIalIht0pRE9MTsebB2D27ifOG+i a4tXhhoqApmy9z/X
4xPTpZ0fvpCapbJU2g+qy//AumvIXqMzWCs484T7hULjVD6y9hLsiprU18fO y42U2i7sbsEytaAn
M8NkY1tKayWMCQ27WDcz4Snz5EoEYa67lFRhFuncoXJxRNBk1MeeiNyzNc68 ESxaQkNcumhVbtZ7
CLO7RGPfr1yYJTGhAIAVpCv9JxvQ8UYrUPFUCFlsNL3xTATZ9E7lnq9teoQi x7dVapqGWKOyj5px
KPEiWKSGFii12wcN/zLZ0lZptFlINa7lVGI4+UyIZ/JbVDJtH/2dDs3MWR84 yuB4hQLKTUirvX8m
HdOjRue6tEc6yBG9FOcWfCNJh6mfGZV1i6oCR1NA1bYXomyEZZrHUoNnhh3S vC31xS5+omjRoPpv
Unu4z6hlxnaQlxobjXnqxzxbdxwTN0LeQ+LnVIloQlkfdY9qdZLhPH86B0t8 QgPppPjCXDpnSNgX
IIY0OYRZvSBNLB7Wu46Kxx+TgnwLG5ITs4agfHkO+I6kPhkHe3m4SsMle577 E4n6SpI0aiA3IB+7
tML6u72Zzx2LfmdDQ0c3Fm00JaoQQMq/cpIbSbQy8UEqEXzdpc21oJ3BrpMx lSepRdp1isZbtI2w
Cmk8pHXt7qnAFUspp4J3C5O98ZxYp4SU1Gq0PyJUDZuP6gu0aBjuL0tzvCjQ PGtscA8QTEldQZX8
EmtppYmK5k5iPUoEnqw2eTX9y2Oe7+TZPbvHxvBxnD20DvdOsSFTaNpfWYtM j81ZRNnR+v8m6Qic
aEkjvb+WILrpBmuTkKGQoGe4T3RjTZCMx6WorLdYwr5Qf6fP5GELl7j2U657 eVoR7pfCDy6i/b1+
/+PDP1BLBwjY14T1lQMAAKARAABQSwMEFAAIAAgAS1pSNwAAAAAAAAAAAAAA ACkAAABvY2wud2l0
aC5keW5hbWljLmVtZi9NRVRBLUlORi9NQU5JRkVTVC5NRk2OPQ+CMBRFd35F 42ZiGyG6YFzUOhjR
RBMXJywPfaYfWIrCvxesGJe33HPufUmqMYfS0RPYEo2OScjGwaLSmQSafMNf FvXJLlUQE16nqpBA
TE72yy15obuRVaNThYLwZN3Dx0ZdjEThJSMk60iWeZKBynvy/4n2jQM8KrRA fdqq9srulUY3mV28
8PTCfHCedMZo2t3hYBR8WBASixJYNwnCWOh3vsUZr0FUri3g+onWaAXaxWQT HTkN2TR4A1BLBwiQ
PJ7DvQAAAB0BAABQSwMEFAAIAAgAS1pSNwAAAAAAAAAAAAAAADoAAABvY2wu d2l0aC5keW5hbWlj
LmVtZi9SdW4gT0NMLXdpdGgtRHluYW1pYy1FTUYgVGVzdHMubGF1bmNopVZR b9owEH6ftP+Aor7i
bGof9lBWRZB1tCVEIVSatikyzhFcHDtyHBiq+O9zAoU0C2no3vBx933f+S53 vr75E7POCmRKBe8Z
n9EnowOciJDyqGdM/W/dL8bN148frhnOOFn0BZ/TKJNYafeO2iTQM4SMEBBG kxRQEgLKKLrLOFUP
pQgjh5gJwQBzSylJZ5mCzhI2PQMnCfAQYRmlRmeFWaYhlczAMPOYVPvy6N8Q Rkmh4RBSVfGUS0Ay
44rGgIiQoCBV5UizQVO6JNosD+hzzFJojMiUiDUuscKwJo03gh4xoyFWUMdX ewMaT+k/cHKIaHAm
CyBLOMr66Ywd+3eTsCL5feXaJlPErOtq2OjPRNQ6a1IoehCV0l88r4Vcpgkm EDBBtiaKQWF9n9hE
CcsiylOz2h55Q5j6R7fokyadIcxxxlTrvCgnLAthnOQaMWvb0+ztrJBZiO0e 7Ds4RlNVAStnG8Is
i4p80chyXXsQePZkPPX6duBa/veJ8YJhcyU3L+ymIAytqVqgcMNxTAmCeL7j M18R/p8C/4drn1Bw
dYqt/tpPEO6mi81XVAoeA1ePWFI8Y9B62JSBn0K1Hyz9seNbQ8f2DjC90zf2 tuIj8L1tu97UcYbO
bWD5vtf646iH8+2J71gju82cOI0Q3A+dQe2oPfoxgUOQu8PVGSy7xaL9dHMM naIj3iP2CON641vP
GgWWdzsd2Y4/OcB1Rdq5eFZ61YBCIt12uuuSYZ0bsCSLoyk/aSNnRxNn2/eq urP7/uuanm6ZM9FL
H3SgmR6Hg1Jn1izofITMIF/PDKd6lqiFK8WK6gI20Oex+5fCAfsSXTZFSBFm RNUrYVjNhYyRZm2A
UBDnnlDZRi/1CBYihu0vUn6X7E+Ictr0/en1STRf+x2fpTDYLYMzV2M10JKA z6J1cAzhnWefw+hW
7r7EY9Y85rT9L1BLBwi3YaJbxQIAAAwKAABQSwMEFAAIAAgAS1pSNwAAAAAA AAAAAAAAAEkAAABv
Y2wud2l0aC5keW5hbWljLmVtZi9iaW4vb2NsL3dpdGgvZHluYW1pYy9lbWYv VGVzdE9DTHdpdGhE
eW5hbWljRU1GLmNsYXNznVf5exPHGX7H19ryJlCHy+AmQAhI8rFJISG1KQSM DE7kA9s4QFpgLY/k
xdLK7K5s3Cu90qRpmza97yO970JjsEKbJr2b3nfaX/sH9D9o+86uLB+SbLd6 Hu3szM585/sd89K/
n3sewD34h4YqgWg2kTZmLG/CGJ+1zYyVMGQmaYxI1xvojqv148FyrK9HQ43A xkvmtGmkTTtlDIxd
kglPQB+Mnz7R23+hb+B4LC7QFF/cMuw5lp3qErilO2u7nml7o2Y6J+vRINBi kHWHYtFRYN2hWGey
4zJtCFTzq8DmeNZJGTKRtqZcqQ4YFIv0GoatlG16OUcKPFZuz6Fli4qwTGQd acQGzcSkmZJdlb53
p03XtZKWdLqiwa+EfLDT18gxLdvjxsOUqW5CpqekI7C75ETwRcl10n/j7sk1 N1VUYZmIa0unZKtx
XElXtVUg6Ug3m3MS0hgqvAxLj6c0jzjgkkBkvQfVqYzirQxx+6oaKFgkstlJ S/YtHKg7ZNmWd5je
D0dGKXU3wRBCNVp0bEOzwIa4Zcv+XGZMOiPmWFoqtGUTZnrUdCw1LyzWeBOW 62u7bnBTmE2JrJ20
UsTUEisINA/lbM/KyFHLtUj9qG1nPdOzKLLPnQpeylFo45hMUrcuDXcJ7F/D WlZmKr3U1r2ch7AH
LQ0QCOt4BZrqERXYu1qMTEhHdviEQ2hDh4Z2gTtWMk5kM3SHkfOstHF6qFeH gbsFtiYcaXpyMG16
FDozmM6lLJufBe4Ll4bvuVLvryDb1YhX4YCG/SqhrBthOu7FfQKNKektrAr0 hddkVkaeSmhsxP3o
1PBqgX3rPKKjC4cCoRhDnrQ9+vmu8OomiMUt1yOzw3hAwxGBXWtu1nEUx4jz lILY5nBvJL4ysRJJ
xxlCq6exRnSjR8cJJfIG0ooN58amgk+u8gkd/iAeIlD5rXBkSKbI35kVaC2j 1XLyexY2dylGfTr6
MSBQT2L9rg+XTeFIKV4acQrDGoYqGr2EvI4RnKY1pnK0xv3hUluUrpQxWD0e FjBWCxnTHpfT0pmd
WYydepxlyipkIKXlIzpei9cJ3KrMuZhqBQ6WCY2KBlySozVcYLVbbZ+KelPH ZmypR8IvlkuyovpI
VG7FFg0pgfby+T6mnjF72nKydoag7TETXtaZDSEJSyXPS0yHpZFVyduR0RDS sDVkBG4rU111ZDHF
ILHlTK9f11XkdoVLalGpQCsstlDRlZKOjhAaFWNGRw7TRHSQpooVUWBPuPR8 SXFVxK7ouBUbGvB6
vFHDG4j1Cqqr54L6cYvmNtOujjdhC0ERGzj2YKx7pBGP4q0a3iKwcy3WOt6G twuE3ELyuOIHdxnw
jtbjMXZOhpeZMpLZbMeVjKWS+OM6nsC7VF30Fe+x0tIPs3vXBb1ySfndOt6D 9xLNAcXFPBtfO8+u
P80qi79Px23Y1ICn8UENH2AXtIrFC2DQ8SF8mM2c7O0fHjna3x2jgythdMkx KvY0PqrjY/h40VSx
hW50V+WkVjC+StOf1PEpfJoZxxwfr+CicyF8Fp/X8DkKVZ5gkM3V62m+6XgG X2ALE8gjcKRiuAXd
z1piUjhHtV6aylWDkwz9nWv1tEzNXnH3xmXJzl/aIafZfquISqR73Ycse3wg eaHYfIViVxJyyu9s
NHyTgb9ok+IXkl3S8qhOiln3O2xUXJlOdmQXyYYV085OLxgKPCIqlK7quIbv FYO7155WzZtN1+0t
i/IydXGuTCiubHtVHrmhYx555qmA1amcDMpeuWqykp6/2cfKTR3fxw/oCDc3 pkq3qnq9CwXbx0Ch
+v8QL2p4gXAqS0vHj/Bj4oOW8oG6O7ySQgnJEH6Kn2v4mcCWwOBJx8zImawz aRx1XekwT/4Cv2Qe
Mf1Z7HKO2YtVd30FlA12KFG0V7lrS8lVQqD2cmDErRUMRlGXd+SzUwtd+eHy R9Z3zVGXmF3l4Lus
VtbjjwIdJVhcFgmdncuORGiFYT+LqWwrsL3s9aBDmY+G7rVt6fiCqdCsXyiY Gl5ePeEVIpRHFooM
djFnVvMmrmE7alHHmcZZFer5Zx3kXPfnt/DPUlacb+Sf9wP/nQnXH9k5+ONW f6zhXl6X+NzOmcFR
cKyN3sCOq/62V/JZ5y9uw+186sEG3IGdHGloHq7C7sKuOzmSkPgPCddyjEVv Ys/ZG9g7h33RZ7Gv
KVIzj9aaPO6pRrw1j4PUK4/XVOEFdPe15RFbMu9XB/I4yW4kj7j/HKzGw8XV dn+1fXG1abQy8c6a
4rnmGv+gGvyT7U1n8jindp2fw8Voc03T2OJ8nAokzxbP3sDEPCbncDnKpcvX 4c5hhm8z1zCbx5ur
EPXleMc83pnHk1WYw1NceMoX5Rren8dHBPL4RJUvb7DMl4vz+Ezp6nhxddER NnbwuZcej9DLUXo2
Qn9G6ckIWtDKrqANh+jFIdyNCexnWjvA7ms/HI4ux1neop7kNecZXlyucueL OIKX8QD+yRvGv3iF
EHTANvSIDpwQx3HSd/iBwJEFh7eICL5IJNEdohlfwpcp2SHRgK/wrZq0b+Kr fFOo+hqBUY2vFzD2
jSJEvhVAhCeqfUx3Kfs1fTuP7yqTPxtXhm29jut9RWPU1OXxXDXaigt5PF/F bP0TZZhq3zC7GQpA
nKz6yCRO4wwQr0MIYxgHOXby0qCU2RmwLCizgeZ6Cb/yQ+BO/Bq/oTK/LWA8 WPkdVwR+/z+p8odV
VKldrypnyOosmZyhkI9QmPNU5QJVOU9VLv7fqlThTz6W/oy/cGzi2yneYv5a p3rfv+HvdQ3/BVBL
Bwj7aPlRLAgAAPITAABQSwMEFAAIAAgAS1pSNwAAAAAAAAAAAAAAACUAAABv Y2wud2l0aC5keW5h
bWljLmVtZi9idWlsZC5wcm9wZXJ0aWVzK84vLUpO1dNTsFUoLkrW5+XKLy0p KC0BCyRl5gEFgKRe
Zl5yTmlKajFQ0Nc1xFHX089NXyeGl0sBFehhEcvNT0nNARoDAFBLBwie0gk+ RgAAAGkAAABQSwME
FAAIAAgAS1pSNwAAAAAAAAAAAAAAAC4AAABvY2wud2l0aC5keW5hbWljLmVt Zi9tb2RlbC9hbmRl
dmVyeXdoZXJlLmVjb3JlXZBBi8IwEIXvgv8hZM82tXtZQqsHURBWkFVhryFO 22CTlKS7qf9+p8UW
srkl8703Ly/f9rohv+C8sqag6ySlBIy0d2Wqgt6uh9UH3W6WixykdcD3ZyEf ogLSa8VnVYaq5YLg
QTPjOQ4LWnddyxkLISRWV4l1Ffs+HemE+BgJ7yORpekasc+LrEGLlTK+E0ZC 5D4micQgG9V6GB1A
l4NLxvYDRokRGmFh7oBxn6EGN7kZf/s6zj4sQhJ4qf3ZQan6/w6bwSKHXSO8 V6XCIgj+iHfPFpe9
qhqHU4CdtQ8FJ4sfAocVX35acFfEPSaYF74x1g03NoFsqJ7F3ePTH1BLBwgG jfv6/QAAALYBAABQ
SwMEFAAIAAgAS1pSNwAAAAAAAAAAAAAAACsAAABvY2wud2l0aC5keW5hbWlj LmVtZi9tb2RlbC9l
eGFtcGxlLmdlbm1vZGVsjZNPaxsxEMXvgXwHoZ67cg2FsngdilMngbj1IYUe clG0Y1lE0iyS4j/f
vrPa3ZB1HFqdVtL83rw3YmdXB2fZDkI06Cv+pZhwBl5hbbyu+O+H5edv/Gp+ eTHT4B3WYMsb8Kv2
gx2cKV/BKYGXF4wW6flY0mXFtyk1pRD7/b5ApwsMWvxZ3fG+ZFAc1YGypomQ a8FtxHQymYqhJWcZ
uDYBVMJwrLj4tbhnNUJkHhMLENHugEkVMEbWSPUsNUQRg+rNZX5tX7Txd9cV J7qFie3RjhzAvt9P
6aDiPw7SNRY4M67BkCC0AmTz1TLZLYa7gmSg76mQOCO9gnvYtXG/tkNW2ByD 0du0NGDrWPGNtITM
W2a2wQBGd6Hnt+VjAtc8QmegcLWdiVFFZmic6943awJszKHitxDIcG1ig1E+ WVgH3JkawlL280vh
hQpAkVoP02sQVOSjT6LzQ+oeYoL65kyPh21u8iTjWOLffTvpdn1sQKSsNR9q 25gLK2MkB7kkb84x
YoWePAcuhgziXYhuckKfnpyb5Xdf0/OF4/7/wp1kkm/pd9P9INRZSCwQnw2M 051myPvx/0qnfwFQ
SwcIib6Cd7gBAADtAwAAUEsDBBQACAAIAEtaUjcAAAAAAAAAAAAAAAAlAAAA b2NsLndpdGguZHlu
YW1pYy5lbWYvbW9kZWwvaGVyZS5lY29yZXWRQWvDIBzF74V+B/FeTbPLkKQ9 jBYKLZR1hV2d+yeV
RQ3qluzbT23SLdB59L334/ks1r1q0BdYJ40u8ZJkGIEW5l3qusTnl+3iEa9X 81kBwlhgmyMXH7wG
1CvJbqk8pOYzFE6AaceCWOKL9y2jtOs6YlRNjK3p62GHR4ubWrqH5MizbBls +5O4gOILqZ3nWsCE
nppMwiAa2TpIBFBVpOR0E20Yaa6iGewI0e78vLvFaVQIDF53tFDJfvCvYqCA 0+dbe321G2g+yfdI
1P/PI/6XGrlPDXdOVjKsiMIczH+3gT3snMSx/cGEHcBiem1E/1aKf0OnnxOu fgBQSwcIoD6tZfoA
AADXAQAAUEsDBBQACAAIAEtaUjcAAAAAAAAAAAAAAABIAAAAb2NsLndpdGgu ZHluYW1pYy5lbWYv
c3JjL29jbC93aXRoL2R5bmFtaWMvZW1mL1Rlc3RPQ0x3aXRoRHluYW1pY0VN Ri5qYXZhvVfbkto4
EH2fqvkHlZ9MLSv28jYks5sQzy67zEDm8pwSpgEFWXIkGWZqa/89LcvGNtgz 5FKhKDBS9+nL6W6J
lMUbtgKiYkF33K7p4kmyhMcUkuXw/Oz8jCep0pZ8zCS3dKlZAjulN/SNMaBt XULpFYVY8NSAU6ax
ShIlaWa5oA+342GnIMRKA41GghlzmhRfctAvis58aC/Kuc8rFluln06SPRFX g1GZjoHeFg9frHAH
9mQdlBJ1xTH+fkk5pyYP6QGf2qVdXUxHk+7N9xl05c1te0sjJY3VjMuOgCrJ 3J1IbrlWMgFpnyXG
qa1BpKCdj3/nT01JX7ZvYYmobTv3YHwRn5+l2VzwmMSuwIhbR0jXEe98Q0TX V+S/8zOCr1TzLbNA
jGUWNZZcMkHurOZyRWaTh7/GNx+up++iCXlNgkFbYw0StQAxCIYer4mKZl+V tdsntYLvkz/a3lVu
/cql6+XhEabPzqsWvArgkqzLHB77VSsuok1emm3bxGLq8EcrhrdOEmdxb+Zg M1Zqw+G6IeI///Q8
Flqerq3iC1SRS77KNNR8DHslXe7lHEY6JOzIQZOEvWElVj0NBkQotiB2DSRY g4aA5KRVEvuAsQcR
2lmgK7Dlcogzj8YaMLKZYBYdT2YiW3GJ62GF4l6NmvnJm/PtEPSJ1Rn0iq+a p2WFECc826zQg7Bc
6zmXnC/IrMUeMmHP/Qp/aQWwFULx5ISju2yeeolW9UamNKy4Y4twa/bAppl9 B1Hs3Obi+glx08yG
Nas3xmUHwy3W6hafB7FtKLYFpoNiJhewxUm2a+X6u1PcMHcy1w2tryH9ZdZO zfehK428H24+k3+1
IVlatH69ZIoRkUeYb/ZIneLaGAuDYlYEdTONKVJHaXO8gTaqawadru9njhuu 1Q7OXrSGSxRnzRgx
mMRCcXOn42QLO/Pcq9v2gxmh3Xnia24/1MNjQWqKQni0Yf3SQicco2LC0Gj6 9p9odN8b5tGsQIJ2
p5/X8adgnpCu8HMXCMvHPSmvIZVIcQqUXePFWxrnigtwVRMMbJIOlkrRx4QH jdALqIPaZotFWL+6
URjf3N2/uRlFBXI0nX+EGM+BL8By96BCPSwq8GvVGwW4B/m/cZ65W8bxaQZb JjLHbyzG5l8uF9Pl
hwIndF2g1Q779TGG1HIl66dcdZI7IsvH12VNeM/Gcss0Z9IejKjAgFi6K1Vp NB/MFxfWf5WRdHRE
fg08vl1ckk9uo1G3uWhYOdjZYm4wl3MA27bo6Z/LJV50lyFzZdfErFUmFiRh Nl7XcPwfFcryr+hT
hrUfttNosvkEWy/8tU9+7/WbycmjwKYSrqJa1b+Z4sbc+bFEN2bixUXDkx9J uJLiKWe9g+nvx/Fv
38wxvj8DUEsHCETKRYoOBAAAPA8AAFBLAQIUABQACAAIAEtaUjdjc8zAzgAA AHYBAAAfAAAAAAAA
AAAAAAAAAAAAAABvY2wud2l0aC5keW5hbWljLmVtZi8uY2xhc3NwYXRoUEsB AhQAFAAIAAgAS1pS
N8LS4R3uAAAAqQIAAB0AAAAAAAAAAAAAAAAAGwEAAG9jbC53aXRoLmR5bmFt aWMuZW1mLy5wcm9q
ZWN0UEsBAhQAFAAIAAgAS1pSN9jXhPWVAwAAoBEAADkAAAAAAAAAAAAAAAAA VAIAAG9jbC53aXRo
LmR5bmFtaWMuZW1mLy5zZXR0aW5ncy9vcmcuZWNsaXBzZS5qZHQuY29yZS5w cmVmc1BLAQIUABQA
CAAIAEtaUjeQPJ7DvQAAAB0BAAApAAAAAAAAAAAAAAAAAFAGAABvY2wud2l0 aC5keW5hbWljLmVt
Zi9NRVRBLUlORi9NQU5JRkVTVC5NRlBLAQIUABQACAAIAEtaUje3YaJbxQIA AAwKAAA6AAAAAAAA
AAAAAAAAAGQHAABvY2wud2l0aC5keW5hbWljLmVtZi9SdW4gT0NMLXdpdGgt RHluYW1pYy1FTUYg
VGVzdHMubGF1bmNoUEsBAhQAFAAIAAgAS1pSN/to+VEsCAAA8hMAAEkAAAAA AAAAAAAAAAAAkQoA
AG9jbC53aXRoLmR5bmFtaWMuZW1mL2Jpbi9vY2wvd2l0aC9keW5hbWljL2Vt Zi9UZXN0T0NMd2l0
aER5bmFtaWNFTUYuY2xhc3NQSwECFAAUAAgACABLWlI3ntIJPkYAAABpAAAA JQAAAAAAAAAAAAAA
AAA0EwAAb2NsLndpdGguZHluYW1pYy5lbWYvYnVpbGQucHJvcGVydGllc1BL AQIUABQACAAIAEta
UjcGjfv6/QAAALYBAAAuAAAAAAAAAAAAAAAAAM0TAABvY2wud2l0aC5keW5h bWljLmVtZi9tb2Rl
bC9hbmRldmVyeXdoZXJlLmVjb3JlUEsBAhQAFAAIAAgAS1pSN4m+gne4AQAA 7QMAACsAAAAAAAAA
AAAAAAAAJhUAAG9jbC53aXRoLmR5bmFtaWMuZW1mL21vZGVsL2V4YW1wbGUu Z2VubW9kZWxQSwEC
FAAUAAgACABLWlI3oD6tZfoAAADXAQAAJQAAAAAAAAAAAAAAAAA3FwAAb2Ns LndpdGguZHluYW1p
Yy5lbWYvbW9kZWwvaGVyZS5lY29yZVBLAQIUABQACAAIAEtaUjdEykWKDgQA ADwPAABIAAAAAAAA
AAAAAAAAAIQYAABvY2wud2l0aC5keW5hbWljLmVtZi9zcmMvb2NsL3dpdGgv ZHluYW1pYy9lbWYv
VGVzdE9DTHdpdGhEeW5hbWljRU1GLmphdmFQSwUGAAAAAAsACwAGBAAACB0A AAAA
--nextPart1267212.eHulEQdGCd--
|
|
|
Goto Forum:
Current Time: Fri Apr 19 15:54:54 GMT 2024
Powered by FUDForum. Page generated in 0.02234 seconds |
] 
Search
Help
Register
Login
Home
