Mail Archives: geda-user/2016/10/07/14:15:11
This is a cryptographically signed message in MIME format.
--------------ms040201040603040609040401
Content-Type: multipart/alternative;
boundary="------------96955411A521CB110C484C44"
This is a multi-part message in MIME format.
--------------96955411A521CB110C484C44
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Thank you for comments. I made new patch which accepted your proposal=20
and added some more changes. See=20
https://bugs.launchpad.net/pcb/+bug/1631059
Comments in text...
> On 07.10.2016 16:41, Chad Parker (parker DOT charles AT gmail DOT com) [via=20
> geda-user AT delorie DOT com] wrote:
> Someone with more experience please correct me if I'm wrong, but I=20
> think that removing the text from the rtree is basically the entire=20
> point of EraseText. It removes the object from the rtree, and flags=20
> the area for being redrawn. If the object is removed from the rtree=20
> then it wont be found when drawing occurs, and so it wont be drawn.=20
> So, I'm not sure that commenting that line is the right thing to do.
>
EraseText also adds the bounding box of text to area to be redrawn, like =
any other Erase... functions. But only EraseText removes the entity from =
rtree, no other Erase... function does it. I think that major purpose of =
EraseText function should be to invalidate drawing area. Just for code=20
clarity.
> It looks like, in most cases, you can get away with commenting this=20
> line because almost all of the functions that call EraseText also try=20
> to remove the object from the rtree anyway, but not all of them. If=20
> you compile with debugging enabled, you get a failed assertion in when =
> you change text. Just put some text on an empty layout, put the arrow=20
> over it, hit n, input new text, hit enter, and crash.
>
Well, in that case it's better to add removal from rtree in function=20
ChangeTextName (done in new patch)... Then the use of EraseText /=20
DrawText function pairs and r_delete_entry / r_insert_entry pairs will=20
be more symmetrical and better understandable. The only other function=20
which needs the r_delete_entry to be added is RemoveText function. (done =
in new patch)
But other functions - like text move, rotate - use r_delete_entry and =20
r_insert_entry in pairs and r_delete_entry in EraseText is IMO redundant.=
I tested this time with debug turned on, no more assertions.
> I think maybe a the error is actually in EraseObject, which calls=20
> EraseText for both TEXT_TYPE and ELEMENTNAME_TYPE. This is problematic =
> for two reasons. First, if EraseObject is getting an element name,=20
> then as you noted, lptr will be pointing to an element not a layer=20
> (the result of SearchObjectByID), as you pointed out. Second, the text =
> types associated with element names are not stored in the layer rtree, =
> but rather in one of the PCB->Data rtrees.
>
> I think a better solution is that when EraseObject gets an=20
> ELEMENTNAME_TYPE, it should call EraseElementName instead of EraseText.=
>
That's good idea, but technically the EraseElementName calls DrawText=20
function to invalidate drawing area. DrawText does exactly the same as=20
EraseText function, except that r_delete_entry call. This does not look=20
like clear coding style.
So I agree that we should call the EraseElementName, which in turn can=20
call modified updated EraseText. (done in new patch)
> I pushed this fix to the repo home/cparker/LP1631059.
>
> This has highlighted a couple other problems though. When you undo=20
> changing the size of a text type (not an element name) it disappears.=20
> There's also an issue of UndoChangeSize using the Thickness parameter, =
> which is of type Coord, but for text objects, the Size parameter is of =
> type int. So there's still a mismatch there. Could be the cause and=20
> effect. I'll look into it a bit more later.
>
I did not notice that any text disappearing while undoing size change... =
but it disappears after undoing the text creation :)
For text objects the Scale parameter is used. It's type of int, but=20
sizeof(Coord) should be >=3D than sizeof(int). So for time being it shoul=
d=20
be OK to accept the type impurity without changing the data structures.
But it is very easy to extend the Undo data structure by new "Scale"=20
property to safely store the text Scale value. (done in new patch)
Milan
> --Chad
>
>
>
> On Thu, Oct 6, 2016 at 12:26 PM, Milan Prochac (milan AT prochac DOT sk=20
> <mailto:milan AT prochac DOT sk>) [via geda-user AT delorie DOT com=20
> <mailto:geda-user AT delorie DOT com>] <geda-user AT delorie DOT com=20
> <mailto:geda-user AT delorie DOT com>> wrote:
>
> On 06.10.2016 11:44, Richard Rasker (rasker AT linetec DOT nl
> <mailto:rasker AT linetec DOT nl>) [via geda-user AT delorie DOT com
> <mailto:geda-user AT delorie DOT com>] wrote:
>
> Hello,
>
> There appears to be a little segfault problem in PCB version
> 1.99z,
> build Sep 13 2016 at 08:12:51, used on Linux Mint 17.3 KDE:
>
> When I change the size of a RefDes text using the S key, and
> then try to
> undo this action using the U key, PCB crashes. This also
> happens when
> the resize action is followed by other actions; when subsequent=
ly
> undoing these using U, PCB crashes the moment that it tries to
> undo the
> RefDes text resize. As far as I can tell, this bug only
> pertains to
> Refdes text, not to other elements.
>
> It's not a big deal, but still a little annoying to have some
> minutes of
> work vanish when unthinkingly pressing the U key.
>
> Best regards,
>
> Richard Rasker
>
>
> Bug logged and patch provided here:
> https://bugs.launchpad.net/pcb/+bug/1631059
> <https://bugs.launchpad.net/pcb/+bug/1631059>
>
> Patch solves the issue (2 issues in fact), undo/redo works fine.
> But second pair of eyes should check if the patch has some
> unwanted side effects. More details on Launchpad.
>
> Milan
>
>
>
--------------96955411A521CB110C484C44
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Ty=
pe">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix"><br>
Thank you for comments. I made new patch which accepted your
proposal and added some more changes. See
<a class=3D"moz-txt-link-freetext" href=3D"https://bugs.launchpad.n=
et/pcb/+bug/1631059">https://bugs.launchpad.net/pcb/+bug/1631059</a> <br>=
<br>
Comments in text...<br>
<br>
</div>
<blockquote
cite=3D"mid:CAJZxidDmtWyBe+HSMG3ceAejG3czdMy24G+N+RGW+zNBKNLpJg AT mail DOT gmai=
l.com"
type=3D"cite">
<div dir=3D"ltr">
<div>On 07.10.2016 16:41, Chad Parker (<a class=3D"moz-txt-link-a=
bbreviated" href=3D"mailto:parker DOT charles AT gmail DOT com">parker DOT charles AT gmail=
=2Ecom</a>)
[via <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:geda-=
user AT delorie DOT com">geda-user AT delorie DOT com</a>] wrote:<br>
Someone with more experience please correct me if I'm wrong,
but I think that removing the text from the rtree is basically
the entire point of EraseText. It removes the object from the
rtree, and flags the area for being redrawn. If the object is
removed from the rtree then it wont be found when drawing
occurs, and so it wont be drawn. So, I'm not sure that
commenting that line is the right thing to do.<br>
<br>
</div>
</div>
</blockquote>
<br>
EraseText also adds the bounding box of text to area to be redrawn,
like any other Erase... functions. But only EraseText removes the
entity from rtree, no other Erase... function does it. I think that
major purpose of EraseText function should be to invalidate drawing
area. Just for code clarity.<br>
<br>
<br>
<blockquote
cite=3D"mid:CAJZxidDmtWyBe+HSMG3ceAejG3czdMy24G+N+RGW+zNBKNLpJg AT mail DOT gmai=
l.com"
type=3D"cite">
<div dir=3D"ltr">
<div>It looks like, in most cases, you can get away with
commenting this line because almost all of the functions that
call EraseText also try to remove the object from the rtree
anyway, but not all of them. If you compile with debugging
enabled, you get a failed assertion in when you change text.
Just put some text on an empty layout, put the arrow over it,
hit n, input new text, hit enter, and crash.<br>
<br>
</div>
</div>
</blockquote>
<br>
Well, in that case it's better to add removal from rtree=C2=A0 in
function ChangeTextName (done in new patch)... Then the use of
EraseText / DrawText function pairs and r_delete_entry /
r_insert_entry pairs will be more symmetrical and better
understandable. The only other function which needs the
r_delete_entry to be added is RemoveText function. (done in new
patch)<br>
<br>
But other functions - like text move, rotate - use r_delete_entry
and=C2=A0 r_insert_entry in pairs and r_delete_entry in EraseText is =
IMO
redundant.<br>
<br>
I tested this time with debug turned on, no more assertions.<br>
<br>
<blockquote
cite=3D"mid:CAJZxidDmtWyBe+HSMG3ceAejG3czdMy24G+N+RGW+zNBKNLpJg AT mail DOT gmai=
l.com"
type=3D"cite">
<div dir=3D"ltr">
<div>I think maybe a the error is actually in EraseObject, which
calls EraseText for both TEXT_TYPE and ELEMENTNAME_TYPE. This
is problematic for two reasons. First, if EraseObject is
getting an element name, then as you noted, lptr will be
pointing to an element not a layer (the result of
SearchObjectByID), as you pointed out. Second, the text types
associated with element names are not stored in the layer
rtree, but rather in one of the PCB->Data rtrees.<br>
<br>
</div>
<div>I think a better solution is that when EraseObject gets an
ELEMENTNAME_TYPE, it should call EraseElementName instead of
EraseText.<br>
<br>
</div>
</div>
</blockquote>
<br>
That's good idea, but technically the EraseElementName calls
DrawText function to invalidate drawing area. DrawText does exactly
the same as EraseText function, except that r_delete_entry call.
This does not look like clear coding style.<br>
<br>
So I agree that we should call the EraseElementName, which in turn
can call modified updated EraseText. (done in new patch)<br>
<br>
<blockquote
cite=3D"mid:CAJZxidDmtWyBe+HSMG3ceAejG3czdMy24G+N+RGW+zNBKNLpJg AT mail DOT gmai=
l.com"
type=3D"cite">
<div dir=3D"ltr">
<div>I pushed this fix to the repo home/cparker/LP1631059.<br>
<br>
</div>
<div>This has highlighted a couple other problems though. When
you undo changing the size of a text type (not an element
name) it disappears. There's also an issue of UndoChangeSize
using the Thickness parameter, which is of type Coord, but for
text objects, the Size parameter is of type int. So there's
still a mismatch there. Could be the cause and effect. I'll
look into it a bit more later.<br>
<br>
</div>
</div>
</blockquote>
<br>
I did not notice that any text disappearing while undoing size
change... but it disappears after undoing the text creation :)<br>
<br>
For text objects the Scale parameter is used.=C2=A0 It's type of int,=
but
sizeof(Coord) should be >=3D than sizeof(int). So for time being i=
t
should be OK to accept the type impurity without changing the data
structures. <br>
<br>
But it is very easy to extend the Undo data structure by new "Scale"
property to safely store the text Scale value. (done in new patch)<br=
>
<br>
Milan<br>
<br>
<br>
<br>
<blockquote
cite=3D"mid:CAJZxidDmtWyBe+HSMG3ceAejG3czdMy24G+N+RGW+zNBKNLpJg AT mail DOT gmai=
l.com"
type=3D"cite">
<div dir=3D"ltr">
<div>--Chad<br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
<div class=3D"gmail_extra"><br>
<div class=3D"gmail_quote">On Thu, Oct 6, 2016 at 12:26 PM, Milan=
Prochac (<a moz-do-not-send=3D"true"
href=3D"mailto:milan AT prochac DOT sk">milan AT prochac DOT sk</a>) [via <=
a
moz-do-not-send=3D"true" href=3D"mailto:geda-user AT delorie DOT com=
">geda-user AT delorie DOT com</a>]
<span dir=3D"ltr"><<a moz-do-not-send=3D"true"
href=3D"mailto:geda-user AT delorie DOT com" target=3D"_blank">ged=
a-user AT delorie DOT com</a>></span>
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"HOEnZb">
<div class=3D"h5">On 06.10.2016 11:44, Richard Rasker (<a
moz-do-not-send=3D"true" href=3D"mailto:rasker AT linetec.=
nl"
target=3D"_blank">rasker AT linetec DOT nl</a>) [via <a
moz-do-not-send=3D"true"
href=3D"mailto:geda-user AT delorie DOT com" target=3D"_blank"=
>geda-user AT delorie DOT com</a>]
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello,<br>
<br>
There appears to be a little segfault problem in PCB
version 1.99z,<br>
build Sep 13 2016 at 08:12:51, used on Linux Mint 17.3
KDE:<br>
<br>
When I change the size of a RefDes text using the S
key, and then try to<br>
undo this action using the U key, PCB crashes. This
also happens when<br>
the resize action is followed by other actions; when
subsequently<br>
undoing these using U, PCB crashes the moment that it
tries to undo the<br>
RefDes text resize. As far as I can tell, this bug
only pertains to<br>
Refdes text, not to other elements.<br>
<br>
It's not a big deal, but still a little annoying to
have some minutes of<br>
work vanish when unthinkingly pressing the U key.<br>
<br>
Best regards,<br>
<br>
Richard Rasker<br>
</blockquote>
<br>
</div>
</div>
Bug logged and patch provided here: <a
moz-do-not-send=3D"true"
href=3D"https://bugs.launchpad.net/pcb/+bug/1631059"
rel=3D"noreferrer" target=3D"_blank">https://bugs.launchpad=
=2Enet/pcb<wbr>/+bug/1631059</a><br>
<br>
Patch solves the issue (2 issues in fact), undo/redo works
fine. But second pair of eyes should check if the patch has
some unwanted side effects. More details on Launchpad.<br>
<br>
Milan<br>
<br>
<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<p><br>
</p>
</body>
</html>
--------------96955411A521CB110C484C44--
--------------ms040201040603040609040401
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
CtowggTwMIID2KADAgECAhBqqLAGfunD4XYlcEsP4ElzMA0GCSqGSIb3DQEBCwUAMHUxCzAJ
BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll
bnQgQ0EwHhcNMTYwMzA3MDEwODU2WhcNMTcwMzA3MDEwODU2WjA8MRkwFwYDVQQDDBBtaWxh
bkBwcm9jaGFjLnNrMR8wHQYJKoZIhvcNAQkBFhBtaWxhbkBwcm9jaGFjLnNrMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0mKGFeH4hukzo8EbR08H7ZFZ1uAI3mTA51yN6C/Q
R++4fhe2R6U1yGR2bQeWal47aLFt4bhUEED1cvU4GDT+tzJUeQMSghB1qwrPQfzJueT3ReYA
5uaym6q2tFR9qm5lhSWqac//+mPFThodIz7rMT4a5R2ZnQjBSiEOVP73Sf0jiD7ylNBqvkCd
hKFTSt7IkoRCkVE8o7KYEjzEhsSu1JAuCh8rYpz1vajpvO+H3FJyDXbHqCxH4MTmA1PMkObc
BPHnsA4NE9xJpghiqJWUyEmcrNSRikLgJY2o0bO2y7AZ8AfXGt1lCkcg2f879JxuswDYaQFH
rfPERgaIJ2OCLQIDAQABo4IBszCCAa8wDgYDVR0PAQH/BAQDAgSwMB0GA1UdJQQWMBQGCCsG
AQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQBZgVnt+lqmMtzm6Wfvlmr
aFGERzAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBvBggrBgEFBQcBAQRjMGEw
JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5BggrBgEFBQcwAoYtaHR0
cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEuY3J0MDgGA1UdHwQxMC8w
LaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGllbnQxLmNybDAbBgNVHREE
FDASgRBtaWxhbkBwcm9jaGFjLnNrMCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wu
Y29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIEMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAQEAcdXDR99mAwWbAilc
x4iAlxzxTpAFBwXjDbFUFuLXHtXUQjfQb6isV/A6HGhFfEeloJ/dl0hZNfn6ROken+Pv8UzA
sgbpjVQHVx334qK38Fbsoy/L991YYRyJGGl7OJYRs7SY8gJ+kVeC4pN6tdeACvmxdRYyA7r0
AjwhzCOpc449UQO2YQRZ6uzXvo3auQhkFQDCN6Gzn82fr5KRQ26fzUYOphHjkNTUHmYJRbjA
QPIJlYSoc9/Gayl3tHscOt8pSXsfJ2alDnD5Ww94E7corjF7kkPdHQvkvZY5Ux72B7eEbSm8
w+FnngjA2Jc7o25oU+weiVOeBGxjo+HlwjaqPzCCBeIwggPKoAMCAQICEGunin0K14jWUQr5
WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAw
NVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0
ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQD
ExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmvmCSsu1d52DXsCR58zJQbCtB2/A5uFqNx
WacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnmVkS6Iye8wUbYzMsDzgnpazlPg19dnSqf
hM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bG
WxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PIdopmykwvIjLPqbJK7yPwFZYekKE015Os
W6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuuN0jhrxK1ljz50hH23gA9cbMCAwEAAaOC
AWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQw
EgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0
c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEEWjBYMCQGCCsGAQUFBzABhhhodHRwOi8v
b2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKGJGh0dHA6Ly9haWEuc3RhcnRzc2wuY29t
L2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgw
FoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0gBDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUH
AgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAgEA
i+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY0JdOruKbrWDsXUsiI0j/7Crft9S5oxvP
iDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpFNjDmQbcM3yl3WFIRS4WhNrsOY14V7y2I
rUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhi
jixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p6q/CW+uVrZiSW57+q5an2P2i7hP85jQJ
cy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOvZ3UDsTDTagXpRDIKQLZo02wrlxY6iMFq
vlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOumZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e
0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0o
T+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO/ZskmSY8wtAk24orAc0vwXgYanqNsBX5
Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsNJQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5
Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPMMIIDyAIBATCBiTB1MQswCQYDVQQGEwJJ
TDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhBq
qLAGfunD4XYlcEsP4ElzMA0GCWCGSAFlAwQCAQUAoIICEzAYBgkqhkiG9w0BCQMxCwYJKoZI
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjEwMDcxODExNTlaMC8GCSqGSIb3DQEJBDEiBCBu
7u92WSRjUhnJiVbAKHYt9EGWjYA9usfw40UYHb1MRjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCG
SAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqG
SIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkw
dTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0
Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAx
IENsaWVudCBDQQIQaqiwBn7pw+F2JXBLD+BJczCBnAYLKoZIhvcNAQkQAgsxgYyggYkwdTEL
MAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29t
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENs
aWVudCBDQQIQaqiwBn7pw+F2JXBLD+BJczANBgkqhkiG9w0BAQEFAASCAQC9HI3hJS60vkKP
O5Y6V5x1zlBIEuj4NgigfuSZRgO/KemjGdS3MS46Nv8KDMtLTzW2/8HEjZwVlLiop+4J9kQg
vaKAG1N1oT89rqxexjePgcwSldhWjmldG8gSPu0j0bvQQSmG9ci9ZgAv9CqvtoC1xYYbO0eZ
3u4I1Awh1SXSFRlX+H7FZgjjAjuQndXbzxui8ElxUJdhCOF0coLuyraisr9tsQzVM2SSFn2C
3AZ7T5iZPidN6XfIvwP9dMvJWpDDTHWXEzEtA9z8MRu+AyCLTmI97OKvXRA89oFzpUbJQEF1
ySAqekcsWkPmHcoMp5KMF6FH9hLP6WHZmUKMQ3DYAAAAAAAA
--------------ms040201040603040609040401--
- Raw text -