Re: In SWIG Ruby, is there a way to disown all objects? I want to prevent any destructors from being called.
Brett Williams via Swig-user <[email protected]> Wed, 14 Feb 2024 15:59:02 -0700
| Newsgroups | gmane.comp.programming.swig |
|---|---|
| Message-ID | <CAGqoRfpTBF=v24yRm4UsZODqPLwUCh4bi=azD_Eytdsvi6unVQ@mail.gmail.com> |
--===============0684051080170142081==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256;
boundary="00000000000096b6010611606efa"
--00000000000096b6010611606efa
Content-Type: multipart/alternative; boundary="000000000000342c5506115f7727"
--000000000000342c5506115f7727
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thank you, William. I used the rename ignore method, and that solved the
issue.
Unfortunately for me, now I am still having a crash in the same place that
I was with SWIG 4.1.1. The seg fault happens in a slightly different line
(it is not deterministic) but seems to be due to a typemap which converts
an STL std::unordered_map to a Ruby hash. This typemap was written before
any significant STL support was added to SWIG. Has there been any change
in these calls in SWIG that might explain why this is an issue? In
particular, the SWIG_NewPointerObj function?
%define STRING_PTR_HASH_ADDOUTTYPEMAP(hashclassname, valueclassname)
%typemap(out) hashclassname &, const hashclassname & {
VALUE hsh =3D rb_hash_new();
hashclassname::iterator i =3D $1->begin(), iend =3D $1->end();
for ( ; i !=3D iend; i++ ) {
VALUE key =3D rb_str_new2(i->first.c_str());
VALUE val =3D SWIG_NewPointerObj((void *)i->second,
$descriptor(valueclassname *),0);
rb_hash_aset(hsh, key, val);
}
$result =3D hsh;
}
%enddef
On Wed, Feb 14, 2024 at 1:25=E2=80=AFAM William S Fulton <wsf@fultondesigns=
.co.uk>
wrote:
> %apply SWIGTYPE *DISOWN {SWIGTYPE *}
>
> will modify the default SWIGTYPE * typemaps to disown all pointer inputs.
> Do look carefully at a diff of the generated because it really will leak
> like crazy, but that seems to be what you want.
>
> You can also use the following to not create implicit default destructor
> wrappers. Explicitly defined destructors will still generate wrappers.
>
> %nodefaultdtor;
>
> You can ignore all destructors (implicit and explicit) using:
>
> %rename("$ignore", %$isdestructor) "";
>
> William
>
> On Tue, 13 Feb 2024 at 18:31, Brett Williams via Swig-user <
> [email protected]> wrote:
>
>> Hi all,
>>
>> I have a SWIG/Ruby application that is 23 years old (started with SWIG
>> 1.3). When upgrading to ruby 3.2, we started to see random seg faults
>> (using SWIG 4.1.1). With the release of 4.2.0 (where ruby 3.2 is now
>> supported), now there is an entirely different problem. It's an object
>> ownership issue that has existed since day one, but never mattered due t=
o
>> different GC schemes or less full featured swig support. (I am not 100%
>> certain why this has recently changed).
>>
>> For this application, all of the objects are stored in a hierarchy. I
>> never want ruby to call the destructor. This hasn't mattered for the la=
st
>> 23 years, but it seems to matter now.
>>
>> The simplest crash is due to the following:
>>
>> design =3D Design.new(SpecialObjMgr.new)
>>
>> The ObjMgr is just a proxy object which indicates what type of objects
>> are to be created (pure virtual methods, no data). The Design class kee=
ps
>> a copy of the object manager. So if Ruby garbage collects objmgr, seg
>> faults occur when the Design object tries to use it's ObjMgr pointer. I=
t's
>> a straightforward ownership problem very similar to the Zoo example in t=
he
>> SWIG Ruby docs. In this case, since no ruby variable refers to this
>> object, it gets swiftly and aggressively deleted. (That never used to
>> happen before).
>>
>> The solution provided by SWIG for this situation is:
>> %apply SWIGTYPE DISOWN
>>
>> Because of the particulars of this application, I want to know if there
>> is a way to essentially apply DISOWN behavior across the board. This wo=
uld
>> prevent the generation of free_Classname functions, for example. I am n=
ot
>> sure where else in this old code base I have a similar situation, but
>> because of the memory management philosophy in the project, I know I nev=
er
>> want the target language to delete objects.
>>
>> Any suggestions?
>> ReplyForward
>>
>> This electronic communication and the information and any files
>> transmitted with it, or attached to it, are confidential and are intende=
d
>> solely for the use of the individual or entity to whom it is addressed a=
nd
>> may contain information that is confidential, legally privileged, protec=
ted
>> by privacy laws, or otherwise restricted from disclosure to anyone else.=
If
>> you are not the intended recipient or the person responsible for deliver=
ing
>> the e-mail to the intended recipient, you are hereby notified that any u=
se,
>> copying, distributing, dissemination, forwarding, printing, or copying o=
f
>> this e-mail is strictly prohibited. If you received this e-mail in error=
,
>> please return the e-mail to the sender, delete it from your computer, an=
d
>> destroy any printed copy of it.
>> _______________________________________________
>> Swig-user mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/swig-user
>>
>
--=20
This electronic communication and the information and any files transmitted=
=20
with it, or attached to it, are confidential and are intended solely for=20
the use of the individual or entity to whom it is addressed and may contain=
=20
information that is confidential, legally privileged, protected by privacy=
=20
laws, or otherwise restricted from disclosure to anyone else. If you are=20
not the intended recipient or the person responsible for delivering the=20
e-mail to the intended recipient, you are hereby notified that any use,=20
copying, distributing, dissemination, forwarding, printing, or copying of=
=20
this e-mail is strictly prohibited. If you received this e-mail in error,=
=20
please return the e-mail to the sender, delete it from your computer, and=
=20
destroy any printed copy of it.
--000000000000342c5506115f7727
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif">Thank you, William.=C2=A0 I used the rename ignore meth=
od, and that solved the issue.=C2=A0=C2=A0</div><div class=3D"gmail_default=
" style=3D"font-family:arial,helvetica,sans-serif"><br></div><div class=3D"=
gmail_default" style=3D"font-family:arial,helvetica,sans-serif">Unfortunate=
ly for me, now I am still having a crash in the same place that I was with =
SWIG 4.1.1.=C2=A0 The seg fault happens in a slightly different line (it is=
not deterministic) but seems to be due to a typemap which converts an STL =
std::unordered_map to a Ruby hash.=C2=A0 This typemap was written before an=
y significant STL support was added to SWIG.=C2=A0 Has there been any chang=
e in these calls in SWIG that might explain why this is an issue?=C2=A0 In =
particular, the SWIG_NewPointerObj function?</div><div class=3D"gmail_defau=
lt" style=3D"font-family:arial,helvetica,sans-serif"><br></div><div class=
=3D"gmail_default" style=3D""><font face=3D"monospace">%define STRING_PTR_H=
ASH_ADDOUTTYPEMAP(hashclassname, valueclassname)<br>%typemap(out) hashclass=
name &, const hashclassname & {<br>=C2=A0 VALUE hsh =3D rb_hash_new=
();<br>=C2=A0 hashclassname::iterator i =3D $1->begin(), iend =3D $1->=
;end();<br>=C2=A0 for ( ; i !=3D iend; i++ ) {<br>=C2=A0 =C2=A0 VALUE key =
=3D rb_str_new2(i->first.c_str());<br>=C2=A0 =C2=A0 VALUE val =3D SWIG_N=
ewPointerObj((void *)i->second, $descriptor(valueclassname *),0);<br>=C2=
=A0 =C2=A0 rb_hash_aset(hsh, key, val);<br>=C2=A0 }<br>=C2=A0 $result =3D h=
sh;<br>}<br>%enddef</font><br></div><div class=3D"gmail_default" style=3D"f=
ont-family:arial,helvetica,sans-serif"><br></div><div class=3D"gmail_defaul=
t" style=3D"font-family:arial,helvetica,sans-serif"><br></div></div><br><di=
v class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Feb 1=
4, 2024 at 1:25=E2=80=AFAM William S Fulton <<a href=3D"mailto:wsf@fulto=
ndesigns.co.uk">[email protected]</a>> wrote:<br></div><blockquote=
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>%apply SWIGTYP=
E *DISOWN {SWIGTYPE *}<br><br></div><div>will modify the default SWIGTYPE *=
typemaps to disown all pointer inputs. Do look carefully at a diff of the =
generated because it really will leak like crazy, but that seems to be what=
you want.</div><div><br></div><div>You can also use the following to not c=
reate implicit default destructor wrappers. Explicitly defined destructors =
will still generate wrappers.<br></div><div><br></div><div>%nodefaultdtor;<=
br></div><div><br></div><div>You can ignore all destructors (implicit and e=
xplicit) using:</div><div><br></div><div>%rename("$ignore", %$isd=
estructor) "";</div><div></div><div><br></div><div>William<br></d=
iv></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_att=
r">On Tue, 13 Feb 2024 at 18:31, Brett Williams via Swig-user <<a href=
=3D"mailto:[email protected]" target=3D"_blank">swig-user@lis=
ts.sourceforge.net</a>> wrote:<br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);=
padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fo=
nt-family:arial,helvetica,sans-serif"><div style=3D"border-left:medium none=
;padding:0px;display:flex;font-family:"Google Sans",Roboto,Roboto=
Draft,Helvetica,Arial,sans-serif;font-size:medium"><div style=3D"margin:0px=
;min-width:0px;padding:0px 0px 20px;width:initial"><div><div id=3D"m_874711=
5512061323640m_-1183941025809487790m_7351075135099883139gmail-:u0d" style=
=3D"direction:ltr;margin:8px 0px 0px;padding:0px;font-size:0.875rem;overflo=
w-x:hidden"><div id=3D"m_8747115512061323640m_-1183941025809487790m_7351075=
135099883139gmail-:u0e" style=3D"direction:initial;font-variant-numeric:nor=
mal;font-variant-east-asian:normal;font-variant-alternates:normal;font-kern=
ing:auto;font-feature-settings:normal;font-stretch:normal;font-size:small;l=
ine-height:1.5;font-family:Arial,Helvetica,sans-serif;overflow:auto hidden"=
><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,h=
elvetica,sans-serif">Hi all,</div><div class=3D"gmail_default" style=3D"fon=
t-family:arial,helvetica,sans-serif"><br></div><div class=3D"gmail_default"=
style=3D"font-family:arial,helvetica,sans-serif">I have a SWIG/Ruby applic=
ation that is 23 years old (started with SWIG 1.3).=C2=A0 When upgrading to=
ruby 3.2, we started to see random seg faults (using SWIG 4.1.1).=C2=A0 Wi=
th the release of 4.2.0 (where ruby 3.2 is now supported), now there is an =
entirely different problem.=C2=A0 It's an object ownership issue that h=
as existed since day one, but never mattered due to different GC schemes or=
less full featured swig support.=C2=A0 (I am not 100% certain why this has=
recently changed).</div><div class=3D"gmail_default" style=3D"font-family:=
arial,helvetica,sans-serif"><br></div><div class=3D"gmail_default" style=3D=
"font-family:arial,helvetica,sans-serif">For this application, all of the o=
bjects are stored in a hierarchy.=C2=A0 I never want ruby to call the destr=
uctor.=C2=A0 This hasn't mattered for the last 23 years, but it seems t=
o matter now.</div><div class=3D"gmail_default" style=3D"font-family:arial,=
helvetica,sans-serif"><br></div><div class=3D"gmail_default" style=3D"font-=
family:arial,helvetica,sans-serif">The simplest crash is due to the followi=
ng:</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,=
sans-serif"><br></div><div class=3D"gmail_default"><font face=3D"monospace"=
>design =3D Design.new(</font><span style=3D"font-family:monospace">Special=
ObjMgr.new)</span><br></div><div class=3D"gmail_default" style=3D"font-fami=
ly:arial,helvetica,sans-serif"><br></div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif">The ObjMgr is just a proxy obje=
ct which indicates what type of objects are to be created (pure virtual met=
hods, no data).=C2=A0 The Design class keeps a copy of the object manager.=
=C2=A0 So if Ruby garbage collects objmgr, seg faults occur when the Design=
object tries to use it's ObjMgr pointer.=C2=A0 It's a straightforw=
ard ownership problem very similar to the Zoo example in the SWIG Ruby docs=
.=C2=A0 In this case, since no ruby variable refers to this object, it gets=
swiftly and aggressively deleted.=C2=A0 (That never used to happen before)=
.</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sa=
ns-serif"><br></div><div class=3D"gmail_default" style=3D"font-family:arial=
,helvetica,sans-serif">The solution provided by SWIG for this situation is:=
</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,san=
s-serif">%apply SWIGTYPE DISOWN</div><div class=3D"gmail_default" style=3D"=
font-family:arial,helvetica,sans-serif"><br></div><div class=3D"gmail_defau=
lt" style=3D"font-family:arial,helvetica,sans-serif">Because of the particu=
lars of this application, I want to know if there is a way to essentially a=
pply DISOWN behavior across the board.=C2=A0 This would prevent the generat=
ion of free_Classname functions, for example.=C2=A0 I am not sure where els=
e in this old code base I have a similar situation, but because of the memo=
ry management philosophy in the project, I know I never want the target lan=
guage to delete objects.<br></div><div class=3D"gmail_default" style=3D"fon=
t-family:arial,helvetica,sans-serif"><br></div><div class=3D"gmail_default"=
style=3D"font-family:arial,helvetica,sans-serif">Any suggestions?</div></d=
iv><div></div><div></div></div></div><div style=3D"padding:0px;width:auto;b=
ackground:rgb(242,242,242);margin:0px;border-bottom-left-radius:1px;border-=
bottom-right-radius:1px"></div></div></div><div style=3D"clear:both"></div>=
</div><div style=3D"font-size:0.875rem;padding:0px;width:auto;border-bottom=
-left-radius:0px;border-bottom-right-radius:0px;border-top:medium none;marg=
in:0px;background-image:initial;background-position:initial;background-size=
:initial;background-repeat:initial;background-origin:initial;background-cli=
p:initial;font-family:"Google Sans",Roboto,RobotoDraft,Helvetica,=
Arial,sans-serif"><div style=3D"border-top:0px none;padding:0px"><div style=
=3D"clear:both;margin:0px;padding:16px 0px;border-top:medium none"><div id=
=3D"m_8747115512061323640m_-1183941025809487790m_7351075135099883139gmail-:=
u0a"><table role=3D"presentation" style=3D"border-collapse:collapse"><tbody=
><tr><td style=3D"padding:0px 16px;vertical-align:top;width:44px"><img id=
=3D"m_8747115512061323640m_-1183941025809487790m_7351075135099883139gmail-:=
8e_874" name=3D"m_8747115512061323640_m_-1183941025809487790_m_735107513509=
9883139_:8e" style=3D"width: 40px; height: 40px; display: block; border-rad=
ius: 50%;"></td><td style=3D"padding:0px;width:655.992px"><div style=3D"box=
-sizing:border-box;border-radius:1px;padding:0px;border:medium none;margin:=
0px"><div style=3D"color:inherit;height:auto;padding:0px;display:flex;line-=
height:20px"><span id=3D"m_8747115512061323640m_-1183941025809487790m_73510=
75135099883139gmail-:u42" role=3D"link" style=3D"border:1px solid rgb(116,1=
19,117);display:inline-flex;font-size:0.875rem;background:none;border-radiu=
s:18px;box-sizing:border-box;color:rgb(68,71,70);height:36px;outline:none;p=
adding:0px 16px 0px 12px;min-width:104px;margin-right:8px">Reply</span><spa=
n id=3D"m_8747115512061323640m_-1183941025809487790m_7351075135099883139gma=
il-:u46" role=3D"link" style=3D"border:1px solid rgb(116,119,117);display:i=
nline-flex;font-size:0.875rem;background:none;border-radius:18px;box-sizing=
:border-box;color:rgb(68,71,70);height:36px;outline:none;padding:0px 16px 0=
px 12px;min-width:104px;margin-right:8px">Forward</span></div></div></td></=
tr></tbody></table></div></div></div></div></div></div>
<br>
<span style=3D"background-color:rgb(255,255,255)"><font size=3D"2">This ele=
ctronic communication and the information and any files transmitted with it=
, or attached to it, are confidential and are intended solely for the use o=
f the individual or entity to whom it is addressed and may contain informat=
ion that is confidential, legally privileged, protected by privacy laws, or=
otherwise restricted from disclosure to anyone else. If you are not the in=
tended recipient or the person responsible for delivering the e-mail to the=
intended recipient, you are hereby notified that any use, copying, distrib=
uting, dissemination, forwarding, printing, or copying of this e-mail is st=
rictly prohibited. If you received this e-mail in error, please return the =
e-mail to the sender, delete it from your computer, and destroy any printed=
copy of it.</font></span>_______________________________________________<b=
r>
Swig-user mailing list<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">Swig-u=
[email protected]</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/swig-user" rel=3D"n=
oreferrer" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/s=
wig-user</a><br>
</blockquote></div>
</blockquote></div>
<br>
<span style=3D"background-color:rgb(255,255,255)"><font size=3D"2">This ele=
ctronic communication and the information and any files transmitted with it=
, or attached to it, are confidential and are intended solely for the use o=
f the individual or entity to whom it is addressed and may contain informat=
ion that is confidential, legally privileged, protected by privacy laws, or=
otherwise restricted from disclosure to anyone else. If you are not the in=
tended recipient or the person responsible for delivering the e-mail to the=
intended recipient, you are hereby notified that any use, copying, distrib=
uting, dissemination, forwarding, printing, or copying of this e-mail is st=
rictly prohibited. If you received this e-mail in error, please return the =
e-mail to the sender, delete it from your computer, and destroy any printed=
copy of it.</font></span>
--000000000000342c5506115f7727--
--00000000000096b6010611606efa
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIIQcwYJKoZIhvcNAQcCoIIQZDCCEGACAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg
gg3KMIIFDTCCA/WgAwIBAgIQeEqpED+lv77edQixNJMdADANBgkqhkiG9w0BAQsFADBMMSAwHgYD
VQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UE
AxMKR2xvYmFsU2lnbjAeFw0yMDA5MTYwMDAwMDBaFw0yODA5MTYwMDAwMDBaMFsxCzAJBgNVBAYT
AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTEwLwYDVQQDEyhHbG9iYWxTaWduIEdDQyBS
MyBQZXJzb25hbFNpZ24gMiBDQSAyMDIwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA
vbCmXCcsbZ/a0fRIQMBxp4gJnnyeneFYpEtNydrZZ+GeKSMdHiDgXD1UnRSIudKo+moQ6YlCOu4t
rVWO/EiXfYnK7zeop26ry1RpKtogB7/O115zultAz64ydQYLe+a1e/czkALg3sgTcOOcFZTXk38e
aqsXsipoX1vsNurqPtnC27TWsA7pk4uKXscFjkeUE8JZu9BDKaswZygxBOPBQBwrA5+20Wxlk6k1
e6EKaaNaNZUy30q3ArEf30ZDpXyfCtiXnupjSK8WU2cK4qsEtj09JS4+mhi0CTCrCnXAzum3tgcH
cHRg0prcSzzEUDQWoFxyuqwiwhHu3sPQNmFOMwIDAQABo4IB2jCCAdYwDgYDVR0PAQH/BAQDAgGG
MGAGA1UdJQRZMFcGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNxQCAgYKKwYBBAGCNwoDBAYJ
KwYBBAGCNxUGBgorBgEEAYI3CgMMBggrBgEFBQcDBwYIKwYBBQUHAxEwEgYDVR0TAQH/BAgwBgEB
/wIBADAdBgNVHQ4EFgQUljPR5lgXWzR1ioFWZNW+SN6hj88wHwYDVR0jBBgwFoAUj/BLf6guRSSu
TVD6Y5qL3uLdG7wwegYIKwYBBQUHAQEEbjBsMC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC5nbG9i
YWxzaWduLmNvbS9yb290cjMwOwYIKwYBBQUHMAKGL2h0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5j
b20vY2FjZXJ0L3Jvb3QtcjMuY3J0MDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuZ2xvYmFs
c2lnbi5jb20vcm9vdC1yMy5jcmwwWgYDVR0gBFMwUTALBgkrBgEEAaAyASgwQgYKKwYBBAGgMgEo
CjA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzAN
BgkqhkiG9w0BAQsFAAOCAQEAdAXk/XCnDeAOd9nNEUvWPxblOQ/5o/q6OIeTYvoEvUUi2qHUOtbf
jBGdTptFsXXe4RgjVF9b6DuizgYfy+cILmvi5hfk3Iq8MAZsgtW+A/otQsJvK2wRatLE61RbzkX8
9/OXEZ1zT7t/q2RiJqzpvV8NChxIj+P7WTtepPm9AIj0Keue+gS2qvzAZAY34ZZeRHgA7g5O4TPJ
/oTd+4rgiU++wLDlcZYd/slFkaT3xg4qWDepEMjT4T1qFOQIL+ijUArYS4owpPg9NISTKa1qqKWJ
jFoyms0d0GwOniIIbBvhI2MJ7BSY9MYtWVT5jJO3tsVHwj4cp92CSFuGwunFMzCCA18wggJHoAMC
AQICCwQAAAAAASFYUwiiMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9v
dCBDQSAtIFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5
MDMxODEwMDAwMFoXDTI5MDMxODEwMDAwMFowTDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENB
IC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24xEzARBgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMJXaQeQZ4Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0E
XyTLLkvhYIJG4VKrDIFHcGzdZNHr9SyjD4I9DCuul9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+J
J5U4nwbXPsnLJlkNc96wyOkmDoMVxu9bi9IEYMpJpij2aTv2y8gokeWdimFXN6x0FNx04Druci8u
nPvQu7/1PQDhBjPogiuuU6Y6FnOM3UEOIDrAtKeh6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTv
riBJ/K1AFUjRAjFhGV64l++td7dkmnq/X8ET75ti+w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGj
QjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5N
UPpjmove4t0bvDANBgkqhkiG9w0BAQsFAAOCAQEAS0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigH
M8pr5nS5ugAtrqQK0/Xx8Q+Kv3NnSoPHRHt44K9ubG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmU
Y/vcU2hnVj6DuM81IcPJaP7O2sJTqsyQiunwXUaMld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V
14qWtNPeTCekTBtzc3b0F5nCH3oO4y0IrQocLP88q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcy
a5QBqJnnLDMfOjsl0oZAzjsshnjJYS8Uuu7bVW/fhO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/
XzCCBVIwggQ6oAMCAQICDFInb3eMcQ3Y+ImrdTANBgkqhkiG9w0BAQsFADBbMQswCQYDVQQGEwJC
RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTExMC8GA1UEAxMoR2xvYmFsU2lnbiBHQ0MgUjMg
UGVyc29uYWxTaWduIDIgQ0EgMjAyMDAeFw0yMjA5MTAxMDEyMzlaFw0yNTA5MTAxMDEyMzlaMIGS
MQswCQYDVQQGEwJJTjESMBAGA1UECBMJS2FybmF0YWthMRIwEAYDVQQHEwlCYW5nYWxvcmUxFjAU
BgNVBAoTDUJyb2FkY29tIEluYy4xFzAVBgNVBAMTDkJyZXR0IFdpbGxpYW1zMSowKAYJKoZIhvcN
AQkBFhticmV0dC53aWxsaWFtc0Bicm9hZGNvbS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
ggEKAoIBAQCv8QKYJhW9RgHi8lJ1ScZxuCS2mdaFbhpUJtDKs+AHqAFlGRLR5EyyPNWPf87FTe9a
9HuLB2H/F26MLQhbV5jWeiyKUihCT1H/4MH3opmMZ8tuxW84BH290XBN0zIFU4okX6U7BQTSy9dB
63uQEnheyA6qDKCzwIFcZ5BhB4I/vUrGLCkNoY1AtTCd9XIzd1XFuZjlxFRKkwz7IM71/VVE8Kxs
4BwfcXrcOHDqkmYJ9+tRdh5z4a5am3zvkkf/8xitTAmrOtFUalVu28OMo7kXOQqWviBuqVBFJxXF
HPFHmG2ceeeBKYpH34sTLysqxfk1lPEJoKUJClxi07oy6WjFAgMBAAGjggHcMIIB2DAOBgNVHQ8B
Af8EBAMCBaAwgaMGCCsGAQUFBwEBBIGWMIGTME4GCCsGAQUFBzAChkJodHRwOi8vc2VjdXJlLmds
b2JhbHNpZ24uY29tL2NhY2VydC9nc2djY3IzcGVyc29uYWxzaWduMmNhMjAyMC5jcnQwQQYIKwYB
BQUHMAGGNWh0dHA6Ly9vY3NwLmdsb2JhbHNpZ24uY29tL2dzZ2NjcjNwZXJzb25hbHNpZ24yY2Ey
MDIwME0GA1UdIARGMEQwQgYKKwYBBAGgMgEoCjA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5n
bG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzAJBgNVHRMEAjAAMEkGA1UdHwRCMEAwPqA8oDqGOGh0
dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NnY2NyM3BlcnNvbmFsc2lnbjJjYTIwMjAuY3JsMCYG
A1UdEQQfMB2BG2JyZXR0LndpbGxpYW1zQGJyb2FkY29tLmNvbTATBgNVHSUEDDAKBggrBgEFBQcD
BDAfBgNVHSMEGDAWgBSWM9HmWBdbNHWKgVZk1b5I3qGPzzAdBgNVHQ4EFgQUZvdpTndIe+snTdqo
sH9aP+XT5j4wDQYJKoZIhvcNAQELBQADggEBAFMqTVylT9uYo/zt8vdgXsXVDFtQDeOaL5X6jmsP
qGe6NRAWUKIIr1qDy3uIDfIUtq4VCRKDUnuFfOyAGVl/FmsOiRWNCYvURSd+zYLgefAKdm3ryyL/
2TWUsuKs+uSQaIvaxbXTp9Y5qr2DVdHqw4oxjdfndv4ux+w0J84UjN9ue7oWg8vzGtT/tfJF7iv9
xcCRMfdClC++kxuH/iIKKSY6ElgBPBb1WcqNiiDUCYhk6BjAjXQnDa5XeBJGKyvAphxeZHagSyZz
GcmF+OOAzjdqzfWGT0jdULDJlWSebZ37s6mYkU85YQa7T9aAh3ogw1COMU5GvotgwYl9XKJtKeIx
ggJtMIICaQIBATBrMFsxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTEw
LwYDVQQDEyhHbG9iYWxTaWduIEdDQyBSMyBQZXJzb25hbFNpZ24gMiBDQSAyMDIwAgxSJ293jHEN
2PiJq3UwDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIHIdSO3k7OdyGtTrMIUhQUm7
SUSZu11yBQ8jGrXvwDceMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X
DTI0MDIxNTAwMDg1MFowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEW
MAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCG
SAFlAwQCATANBgkqhkiG9w0BAQEFAASCAQAyMFexiUWtI+ozRLVENeezcMNRth52WUeFAhDApTRb
R9VcWmPXj585Es2LBD8hYcF9Y52YV7xLgVHMYVDP8ep3ke5IJHh459xnQ1Qms7SJ1ui8Hhrq/aaR
JB7G6ivgxDGCb49T+ti3Wy/eyqNOglSOgls8h3PdaTrVbTrD0CN7pLq6IwIcA2Ut+DcQ1+o0KWsG
ygD6VxpbN33z2w5XSaS7W4kAfVlZoA9dPW4RPJB7GkENZrA2j6ENgLjHPH716rWstEf/5BC+fDjm
iL2mcgDuP3NqpozcI99OohyG8jMXjeizciO/0S5N1ffmjf+j+pwDF1pQ2rvYDw4MpVRZwoN4
--00000000000096b6010611606efa--
--===============0684051080170142081==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
--===============0684051080170142081==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Swig-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/swig-user
--===============0684051080170142081==--