From: Eric W. <ewm...@gm...> - 2014-04-15 21:31:21
|
I am trying to get == to work as one might intuitively/naturally expect in Lua. Here is a real example: local a, b = chipmunk.cpArbiterGetShapes(arbiter) if (b == s_playerFeet) or (a == s_playerFeet) then s_playerData.canJump = true; end In C, cpArbiterGetShapes returns pointers to cpShape* instances. They are equal if the pointers are equal. It is unfortunate that the SWIG implementation always creates a new userdata wrapper instead of keeping a map of existing userdata's in the system and reusing them. This has unfortunate side effects of breaking the == operator as well as creating extra garbage that needs to be collected. But the fix for that is a discussion I'll save for another day. The easy fix for == is to simply define a default __eq metamethod that compares the underlying pointers. I think this is always the correct default behavior because the == is pretty much useless otherwise because whether you get distinct userdata wrappers for a pointer is a SWIG implementation in my opinion. I propose that the __eq metamethod be added to the default userdata setup. I noticed there is already a function called SWIG_Lua_equal that has the correct implementation, so essentially, we need a forward declaration (because it is declared too far down) and in SWIG_Lua_class_register_instance, add the line: SWIG_Lua_add_function(L,"__eq",SWIG_Lua_equal); (And while I'm here, I'll also propose modifying the __tostring implementation to also print the underlying userdata->ptr address because this information was really useful for debugging the above problem.) The one caveat is that the documentation claims this is supposed to work: %extend Complex { const char *__str__() { static char tmp[1024]; sprintf(tmp,"Complex(%g,%g)", $self->re(),$self->im()); return tmp; } bool operator==(const Complex& c) { return ($self->re()==c.re() && $self->im()==c.im();} }; However I tried it and on the operator== part, SWIG errors out with: Error: Syntax error in input(3). (I changed Complex to cpShape for my case.) I have successfully been using %extend like so up until this point so I know the basic %extend works: %extend cpShape { ~cpShape() { cpShapeFree($self); } } So I claim operator== is broken and may have never worked. I could not find any test cases of this. Ideally, a user could supply this and override the default __eq behavior as the documentation suggests. But currently I'm focused on the 80% case. And right now I think not providing the pointer comparison default is wrong. And since the %extend case doesn't work, we don't even have a 20% case right. Thanks, Eric -- Beginning iPhone Games Development http://playcontrol.net/iphonegamebook/ |
From: William S F. <ws...@fu...> - 2014-04-22 18:26:21
|
On 15/04/14 22:31, Eric Wing wrote: > I am trying to get == to work as one might intuitively/naturally expect in Lua. > > Here is a real example: > local a, b = chipmunk.cpArbiterGetShapes(arbiter) > if (b == s_playerFeet) or (a == s_playerFeet) then > s_playerData.canJump = true; > end > > In C, cpArbiterGetShapes returns pointers to cpShape* instances. They > are equal if the pointers are equal. It is unfortunate that the SWIG > implementation always creates a new userdata wrapper instead of > keeping a map of existing userdata's in the system and reusing them. > This has unfortunate side effects of breaking the == operator as well > as creating extra garbage that needs to be collected. But the fix for > that is a discussion I'll save for another day. > > The easy fix for == is to simply define a default __eq metamethod that > compares the underlying pointers. I think this is always the correct > default behavior because the == is pretty much useless otherwise > because whether you get distinct userdata wrappers for a pointer is a > SWIG implementation in my opinion. > > I propose that the __eq metamethod be added to the default userdata > setup. I noticed there is already a function called SWIG_Lua_equal > that has the correct implementation, so essentially, we need a forward > declaration (because it is declared too far down) and in > SWIG_Lua_class_register_instance, add the line: > > SWIG_Lua_add_function(L,"__eq",SWIG_Lua_equal); > > (And while I'm here, I'll also propose modifying the __tostring > implementation to also print the underlying userdata->ptr address > because this information was really useful for debugging the above > problem.) > > > The one caveat is that the documentation claims this is supposed to work: > %extend Complex { > const char *__str__() { > static char tmp[1024]; > sprintf(tmp,"Complex(%g,%g)", $self->re(),$self->im()); > return tmp; > } > bool operator==(const Complex& c) > { return ($self->re()==c.re() && $self->im()==c.im();} > }; > > However I tried it and on the operator== part, SWIG errors out with: > Error: Syntax error in input(3). > > (I changed Complex to cpShape for my case.) > I have successfully been using %extend like so up until this point so > I know the basic %extend works: > %extend cpShape { > ~cpShape() { > cpShapeFree($self); > } > } > > So I claim operator== is broken and may have never worked. I could not > find any test cases of this. > > Ideally, a user could supply this and override the default __eq > behavior as the documentation suggests. But currently I'm focused on > the 80% case. And right now I think not providing the pointer > comparison default is wrong. And since the %extend case doesn't work, > we don't even have a 20% case right. > Can you look at https://github.com/swig/swig/pull/159. I think this should fix your problems. Please advise whether or not it does. William |
From: Olly B. <ol...@su...> - 2014-04-28 01:19:21
|
Eric Wing <ewm...@gm...> writes: > The one caveat is that the documentation claims this is supposed to work: > %extend Complex { > const char *__str__() { > static char tmp[1024]; > sprintf(tmp,"Complex(%g,%g)", $self->re(),$self->im()); > return tmp; > } > bool operator==(const Complex& c) > { return ($self->re()==c.re() && $self->im()==c.im();} > }; > > However I tried it and on the operator== part, SWIG errors out with: > Error: Syntax error in input(3). There's just a missing ")" before the ";" in the penultimate line of code. I've pushed a fix to git (c6bff43). > Ideally, a user could supply this and override the default __eq > behavior as the documentation suggests. But currently I'm focused on > the 80% case. And right now I think not providing the pointer > comparison default is wrong. And since the %extend case doesn't work, > we don't even have a 20% case right. The %extend case should works if you fix that typo. Cheers, Olly |
From: Eric W. <ewm...@gm...> - 2014-05-03 09:46:28
|
I finally looked over this and gave it a shot. I think there is a regression. This broke my previously working code. In SWIG_Lua_get_ingeritable_metamethods, my program fails at the assert( !lua_isnil(L,-1) ); I don't think this patch fixes my fundamental problem unfortunately. I assume this will fix the extend case with custom == operators. However, upon further reflection, I am even more convinced that the base case with no custom overrides needs to be handled. In my case, I am binding pure C, no C++. And I suspect this patch might have overlooked that base case. What I want is a simple C pointer equality check and I believe this should be the default because scriptors don't know how SWIG is implemented, nor should they. If the Lua SWIG backend were implemented differently, the same C pointer pushed through the Lua bridge would reuse the same userdata object instead of creating a new, unique userdata (which is why equality currently fails in SWIG). I believe that this is a SWIG implementation detail and the default behavior should hide this by providing a default _eq handler that compares the underlying ((swig_lua_userdata*)(userData))->ptr. If the user supplies an %extend for the ==, then that new definition should be respected. But in the default case, then the C pointer equality implementation should be used. (I can't think of a single good reason not to do this. As I said, the way it works now doesn't do what people expect and is an artifact of a SWIG/Lua implementation detail that should be hidden.) Can we come up with a way to: 1) Fix my regression problem 2) How to incorporate my default _eq implementation into the newer/fancier code base Thanks, Eric On 4/27/14, Olly Betts <ol...@su...> wrote: > Eric Wing <ewm...@gm...> writes: >> The one caveat is that the documentation claims this is supposed to work: >> %extend Complex { >> const char *__str__() { >> static char tmp[1024]; >> sprintf(tmp,"Complex(%g,%g)", $self->re(),$self->im()); >> return tmp; >> } >> bool operator==(const Complex& c) >> { return ($self->re()==c.re() && $self->im()==c.im();} >> }; >> >> However I tried it and on the operator== part, SWIG errors out with: >> Error: Syntax error in input(3). > > There's just a missing ")" before the ";" in the penultimate line of code. > I've pushed a fix to git (c6bff43). > >> Ideally, a user could supply this and override the default __eq >> behavior as the documentation suggests. But currently I'm focused on >> the 80% case. And right now I think not providing the pointer >> comparison default is wrong. And since the %extend case doesn't work, >> we don't even have a 20% case right. > > The %extend case should works if you fix that typo. > > Cheers, > Olly > > > ------------------------------------------------------------------------------ > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE > Instantly run your Selenium tests across 300+ browser/OS combos. Get > unparalleled scalability from the best Selenium testing platform available. > Simple to use. Nothing to install. Get started now for free." > http://p.sf.net/sfu/SauceLabs > _______________________________________________ > Swig-devel mailing list > Swi...@li... > https://lists.sourceforge.net/lists/listinfo/swig-devel > -- Beginning iPhone Games Development http://playcontrol.net/iphonegamebook/ |
From: Artem S. <v.f...@gm...> - 2014-05-05 07:23:10
|
Hi. Eric, could you please provide the code that causes assertion failure ? I will solve this problem and incorporate the code into tests. The patch was not intended to implement suggested default __eq handler. I have no objections to that (actually, I don't have any vote in this matter), it just wasn't in the scope of the patch. Thanks, Artem. On 3 May 2014 13:46, Eric Wing <ewm...@gm...> wrote: > I finally looked over this and gave it a shot. I think there is a > regression. This broke my previously working code. > > In SWIG_Lua_get_ingeritable_metamethods, my program fails at the > assert( !lua_isnil(L,-1) ); > > > I don't think this patch fixes my fundamental problem unfortunately. I > assume this will fix the extend case with custom == operators. > However, upon further reflection, I am even more convinced that the > base case with no custom overrides needs to be handled. > > In my case, I am binding pure C, no C++. And I suspect this patch > might have overlooked that base case. > > What I want is a simple C pointer equality check and I believe this > should be the default because scriptors don't know how SWIG is > implemented, nor should they. If the Lua SWIG backend were implemented > differently, the same C pointer pushed through the Lua bridge would > reuse the same userdata object instead of creating a new, unique > userdata (which is why equality currently fails in SWIG). I believe > that this is a SWIG implementation detail and the default behavior > should hide this by providing a default _eq handler that compares the > underlying ((swig_lua_userdata*)(userData))->ptr. > > If the user supplies an %extend for the ==, then that new definition > should be respected. But in the default case, then the C pointer > equality implementation should be used. (I can't think of a single > good reason not to do this. As I said, the way it works now doesn't do > what people expect and is an artifact of a SWIG/Lua implementation > detail that should be hidden.) > > > Can we come up with a way to: > 1) Fix my regression problem > 2) How to incorporate my default _eq implementation into the > newer/fancier code base > > Thanks, > Eric > > > > > On 4/27/14, Olly Betts <ol...@su...> wrote: > > Eric Wing <ewm...@gm...> writes: > >> The one caveat is that the documentation claims this is supposed to > work: > >> %extend Complex { > >> const char *__str__() { > >> static char tmp[1024]; > >> sprintf(tmp,"Complex(%g,%g)", $self->re(),$self->im()); > >> return tmp; > >> } > >> bool operator==(const Complex& c) > >> { return ($self->re()==c.re() && $self->im()==c.im();} > >> }; > >> > >> However I tried it and on the operator== part, SWIG errors out with: > >> Error: Syntax error in input(3). > > > > There's just a missing ")" before the ";" in the penultimate line of > code. > > I've pushed a fix to git (c6bff43). > > > >> Ideally, a user could supply this and override the default __eq > >> behavior as the documentation suggests. But currently I'm focused on > >> the 80% case. And right now I think not providing the pointer > >> comparison default is wrong. And since the %extend case doesn't work, > >> we don't even have a 20% case right. > > > > The %extend case should works if you fix that typo. > > > > Cheers, > > Olly > > > > > > > ------------------------------------------------------------------------------ > > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE > > Instantly run your Selenium tests across 300+ browser/OS combos. Get > > unparalleled scalability from the best Selenium testing platform > available. > > Simple to use. Nothing to install. Get started now for free." > > http://p.sf.net/sfu/SauceLabs > > _______________________________________________ > > Swig-devel mailing list > > Swi...@li... > > https://lists.sourceforge.net/lists/listinfo/swig-devel > > > > > -- > Beginning iPhone Games Development > http://playcontrol.net/iphonegamebook/ > > > ------------------------------------------------------------------------------ > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE > Instantly run your Selenium tests across 300+ browser/OS combos. Get > unparalleled scalability from the best Selenium testing platform available. > Simple to use. Nothing to install. Get started now for free." > http://p.sf.net/sfu/SauceLabs > _______________________________________________ > Swig-devel mailing list > Swi...@li... > https://lists.sourceforge.net/lists/listinfo/swig-devel > -- Sincerely yours, Artem Serebriyskiy |
From: William S F. <ws...@fu...> - 2014-05-09 07:12:53
|
I'd like to these Lua regressions fixed in the next few days so that we can release 3.0.1. Eric, have you got the example code for Artem? William On 05/05/14 08:22, Artem Serebriyskiy wrote: > Hi. > > Eric, could you please provide the code that causes assertion failure ? > I will solve this problem and incorporate the code into tests. > > The patch was not intended to implement suggested default __eq handler. > I have no objections to that (actually, I don't have any vote in this > matter), it just wasn't in the scope of the patch. > > Thanks, > Artem. > > > On 3 May 2014 13:46, Eric Wing <ewm...@gm... > <mailto:ewm...@gm...>> wrote: > > I finally looked over this and gave it a shot. I think there is a > regression. This broke my previously working code. > > In SWIG_Lua_get_ingeritable_metamethods, my program fails at the > assert( !lua_isnil(L,-1) ); > > > I don't think this patch fixes my fundamental problem unfortunately. I > assume this will fix the extend case with custom == operators. > However, upon further reflection, I am even more convinced that the > base case with no custom overrides needs to be handled. > > In my case, I am binding pure C, no C++. And I suspect this patch > might have overlooked that base case. > > What I want is a simple C pointer equality check and I believe this > should be the default because scriptors don't know how SWIG is > implemented, nor should they. If the Lua SWIG backend were implemented > differently, the same C pointer pushed through the Lua bridge would > reuse the same userdata object instead of creating a new, unique > userdata (which is why equality currently fails in SWIG). I believe > that this is a SWIG implementation detail and the default behavior > should hide this by providing a default _eq handler that compares the > underlying ((swig_lua_userdata*)(userData))->ptr. > > If the user supplies an %extend for the ==, then that new definition > should be respected. But in the default case, then the C pointer > equality implementation should be used. (I can't think of a single > good reason not to do this. As I said, the way it works now doesn't do > what people expect and is an artifact of a SWIG/Lua implementation > detail that should be hidden.) > > > Can we come up with a way to: > 1) Fix my regression problem > 2) How to incorporate my default _eq implementation into the > newer/fancier code base > > Thanks, > Eric > > > > > On 4/27/14, Olly Betts <ol...@su... <mailto:ol...@su...>> wrote: > > Eric Wing <ewm...@gm... <mailto:ewm...@gm...>> writes: > >> The one caveat is that the documentation claims this is supposed > to work: > >> %extend Complex { > >> const char *__str__() { > >> static char tmp[1024]; > >> sprintf(tmp,"Complex(%g,%g)", $self->re(),$self->im()); > >> return tmp; > >> } > >> bool operator==(const Complex& c) > >> { return ($self->re()==c.re <http://c.re>() && > $self->im()==c.im <http://c.im>();} > >> }; > >> > >> However I tried it and on the operator== part, SWIG errors out with: > >> Error: Syntax error in input(3). > > > > There's just a missing ")" before the ";" in the penultimate line > of code. > > I've pushed a fix to git (c6bff43). > > > >> Ideally, a user could supply this and override the default __eq > >> behavior as the documentation suggests. But currently I'm focused on > >> the 80% case. And right now I think not providing the pointer > >> comparison default is wrong. And since the %extend case doesn't > work, > >> we don't even have a 20% case right. > > > > The %extend case should works if you fix that typo. > > > > Cheers, > > Olly > > > > > > > ------------------------------------------------------------------------------ > > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For > FREE > > Instantly run your Selenium tests across 300+ browser/OS combos. Get > > unparalleled scalability from the best Selenium testing platform > available. > > Simple to use. Nothing to install. Get started now for free." > > http://p.sf.net/sfu/SauceLabs > > _______________________________________________ > > Swig-devel mailing list > > Swi...@li... > <mailto:Swi...@li...> > > https://lists.sourceforge.net/lists/listinfo/swig-devel > > > > > -- > Beginning iPhone Games Development > http://playcontrol.net/iphonegamebook/ > > ------------------------------------------------------------------------------ > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE > Instantly run your Selenium tests across 300+ browser/OS combos. Get > unparalleled scalability from the best Selenium testing platform > available. > Simple to use. Nothing to install. Get started now for free." > http://p.sf.net/sfu/SauceLabs > _______________________________________________ > Swig-devel mailing list > Swi...@li... > <mailto:Swi...@li...> > https://lists.sourceforge.net/lists/listinfo/swig-devel > > > > > -- > Sincerely yours, > Artem Serebriyskiy |
From: Eric W. <ewm...@gm...> - 2014-05-12 19:34:40
|
Yes, I'm trying to get Artem the information as we speak. Thanks, Eric On 5/9/14, William S Fulton <ws...@fu...> wrote: > I'd like to these Lua regressions fixed in the next few days so that we > can release 3.0.1. Eric, have you got the example code for Artem? > > William > > On 05/05/14 08:22, Artem Serebriyskiy wrote: >> Hi. >> >> Eric, could you please provide the code that causes assertion failure ? >> I will solve this problem and incorporate the code into tests. >> >> The patch was not intended to implement suggested default __eq handler. >> I have no objections to that (actually, I don't have any vote in this >> matter), it just wasn't in the scope of the patch. >> >> Thanks, >> Artem. >> >> >> On 3 May 2014 13:46, Eric Wing <ewm...@gm... >> <mailto:ewm...@gm...>> wrote: >> >> I finally looked over this and gave it a shot. I think there is a >> regression. This broke my previously working code. >> >> In SWIG_Lua_get_ingeritable_metamethods, my program fails at the >> assert( !lua_isnil(L,-1) ); >> >> >> I don't think this patch fixes my fundamental problem unfortunately. >> I >> assume this will fix the extend case with custom == operators. >> However, upon further reflection, I am even more convinced that the >> base case with no custom overrides needs to be handled. >> >> In my case, I am binding pure C, no C++. And I suspect this patch >> might have overlooked that base case. >> >> What I want is a simple C pointer equality check and I believe this >> should be the default because scriptors don't know how SWIG is >> implemented, nor should they. If the Lua SWIG backend were >> implemented >> differently, the same C pointer pushed through the Lua bridge would >> reuse the same userdata object instead of creating a new, unique >> userdata (which is why equality currently fails in SWIG). I believe >> that this is a SWIG implementation detail and the default behavior >> should hide this by providing a default _eq handler that compares the >> underlying ((swig_lua_userdata*)(userData))->ptr. >> >> If the user supplies an %extend for the ==, then that new definition >> should be respected. But in the default case, then the C pointer >> equality implementation should be used. (I can't think of a single >> good reason not to do this. As I said, the way it works now doesn't >> do >> what people expect and is an artifact of a SWIG/Lua implementation >> detail that should be hidden.) >> >> >> Can we come up with a way to: >> 1) Fix my regression problem >> 2) How to incorporate my default _eq implementation into the >> newer/fancier code base >> >> Thanks, >> Eric >> >> >> >> >> On 4/27/14, Olly Betts <ol...@su... <mailto:ol...@su...>> >> wrote: >> > Eric Wing <ewm...@gm... <mailto:ewm...@gm...>> >> writes: >> >> The one caveat is that the documentation claims this is supposed >> to work: >> >> %extend Complex { >> >> const char *__str__() { >> >> static char tmp[1024]; >> >> sprintf(tmp,"Complex(%g,%g)", $self->re(),$self->im()); >> >> return tmp; >> >> } >> >> bool operator==(const Complex& c) >> >> { return ($self->re()==c.re <http://c.re>() && >> $self->im()==c.im <http://c.im>();} >> >> }; >> >> >> >> However I tried it and on the operator== part, SWIG errors out >> with: >> >> Error: Syntax error in input(3). >> > >> > There's just a missing ")" before the ";" in the penultimate line >> of code. >> > I've pushed a fix to git (c6bff43). >> > >> >> Ideally, a user could supply this and override the default __eq >> >> behavior as the documentation suggests. But currently I'm focused >> on >> >> the 80% case. And right now I think not providing the pointer >> >> comparison default is wrong. And since the %extend case doesn't >> work, >> >> we don't even have a 20% case right. >> > >> > The %extend case should works if you fix that typo. >> > >> > Cheers, >> > Olly >> > >> > >> > >> >> ------------------------------------------------------------------------------ >> > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For >> FREE >> > Instantly run your Selenium tests across 300+ browser/OS combos. >> Get >> > unparalleled scalability from the best Selenium testing platform >> available. >> > Simple to use. Nothing to install. Get started now for free." >> > http://p.sf.net/sfu/SauceLabs >> > _______________________________________________ >> > Swig-devel mailing list >> > Swi...@li... >> <mailto:Swi...@li...> >> > https://lists.sourceforge.net/lists/listinfo/swig-devel >> > >> >> >> -- >> Beginning iPhone Games Development >> http://playcontrol.net/iphonegamebook/ >> >> >> ------------------------------------------------------------------------------ >> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For >> FREE >> Instantly run your Selenium tests across 300+ browser/OS combos. Get >> unparalleled scalability from the best Selenium testing platform >> available. >> Simple to use. Nothing to install. Get started now for free." >> http://p.sf.net/sfu/SauceLabs >> _______________________________________________ >> Swig-devel mailing list >> Swi...@li... >> <mailto:Swi...@li...> >> https://lists.sourceforge.net/lists/listinfo/swig-devel >> >> >> >> >> -- >> Sincerely yours, >> Artem Serebriyskiy > > -- Beginning iPhone Games Development http://playcontrol.net/iphonegamebook/ |
From: William S F. <ws...@fu...> - 2014-05-22 06:24:54
|
Artem/Eric, any progress? This is blocking the new release which I would like to do this weekend. William On 12/05/14 20:34, Eric Wing wrote: > Yes, I'm trying to get Artem the information as we speak. > > Thanks, > Eric > > On 5/9/14, William S Fulton <ws...@fu...> wrote: >> I'd like to these Lua regressions fixed in the next few days so that we >> can release 3.0.1. Eric, have you got the example code for Artem? >> >> William >> >> On 05/05/14 08:22, Artem Serebriyskiy wrote: >>> Hi. >>> >>> Eric, could you please provide the code that causes assertion failure ? >>> I will solve this problem and incorporate the code into tests. >>> >>> The patch was not intended to implement suggested default __eq handler. >>> I have no objections to that (actually, I don't have any vote in this >>> matter), it just wasn't in the scope of the patch. >>> >>> Thanks, >>> Artem. >>> >>> >>> On 3 May 2014 13:46, Eric Wing <ewm...@gm... >>> <mailto:ewm...@gm...>> wrote: >>> >>> I finally looked over this and gave it a shot. I think there is a >>> regression. This broke my previously working code. >>> >>> In SWIG_Lua_get_ingeritable_metamethods, my program fails at the >>> assert( !lua_isnil(L,-1) ); >>> >>> >>> I don't think this patch fixes my fundamental problem unfortunately. >>> I >>> assume this will fix the extend case with custom == operators. >>> However, upon further reflection, I am even more convinced that the >>> base case with no custom overrides needs to be handled. >>> >>> In my case, I am binding pure C, no C++. And I suspect this patch >>> might have overlooked that base case. >>> >>> What I want is a simple C pointer equality check and I believe this >>> should be the default because scriptors don't know how SWIG is >>> implemented, nor should they. If the Lua SWIG backend were >>> implemented >>> differently, the same C pointer pushed through the Lua bridge would >>> reuse the same userdata object instead of creating a new, unique >>> userdata (which is why equality currently fails in SWIG). I believe >>> that this is a SWIG implementation detail and the default behavior >>> should hide this by providing a default _eq handler that compares the >>> underlying ((swig_lua_userdata*)(userData))->ptr. >>> >>> If the user supplies an %extend for the ==, then that new definition >>> should be respected. But in the default case, then the C pointer >>> equality implementation should be used. (I can't think of a single >>> good reason not to do this. As I said, the way it works now doesn't >>> do >>> what people expect and is an artifact of a SWIG/Lua implementation >>> detail that should be hidden.) >>> >>> >>> Can we come up with a way to: >>> 1) Fix my regression problem >>> 2) How to incorporate my default _eq implementation into the >>> newer/fancier code base >>> >>> Thanks, >>> Eric >>> >>> >>> >>> >>> On 4/27/14, Olly Betts <ol...@su... <mailto:ol...@su...>> >>> wrote: >>> > Eric Wing <ewm...@gm... <mailto:ewm...@gm...>> >>> writes: >>> >> The one caveat is that the documentation claims this is supposed >>> to work: >>> >> %extend Complex { >>> >> const char *__str__() { >>> >> static char tmp[1024]; >>> >> sprintf(tmp,"Complex(%g,%g)", $self->re(),$self->im()); >>> >> return tmp; >>> >> } >>> >> bool operator==(const Complex& c) >>> >> { return ($self->re()==c.re <http://c.re>() && >>> $self->im()==c.im <http://c.im>();} >>> >> }; >>> >> >>> >> However I tried it and on the operator== part, SWIG errors out >>> with: >>> >> Error: Syntax error in input(3). >>> > >>> > There's just a missing ")" before the ";" in the penultimate line >>> of code. >>> > I've pushed a fix to git (c6bff43). >>> > >>> >> Ideally, a user could supply this and override the default __eq >>> >> behavior as the documentation suggests. But currently I'm focused >>> on >>> >> the 80% case. And right now I think not providing the pointer >>> >> comparison default is wrong. And since the %extend case doesn't >>> work, >>> >> we don't even have a 20% case right. >>> > >>> > The %extend case should works if you fix that typo. >>> > >>> > Cheers, >>> > Olly >>> > >>> > >>> > >>> >>> ------------------------------------------------------------------------------ >>> > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For >>> FREE >>> > Instantly run your Selenium tests across 300+ browser/OS combos. >>> Get >>> > unparalleled scalability from the best Selenium testing platform >>> available. >>> > Simple to use. Nothing to install. Get started now for free." >>> > http://p.sf.net/sfu/SauceLabs >>> > _______________________________________________ >>> > Swig-devel mailing list >>> > Swi...@li... >>> <mailto:Swi...@li...> >>> > https://lists.sourceforge.net/lists/listinfo/swig-devel >>> > >>> >>> >>> -- >>> Beginning iPhone Games Development >>> http://playcontrol.net/iphonegamebook/ >>> >>> >>> ------------------------------------------------------------------------------ >>> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For >>> FREE >>> Instantly run your Selenium tests across 300+ browser/OS combos. Get >>> unparalleled scalability from the best Selenium testing platform >>> available. >>> Simple to use. Nothing to install. Get started now for free." >>> http://p.sf.net/sfu/SauceLabs >>> _______________________________________________ >>> Swig-devel mailing list >>> Swi...@li... >>> <mailto:Swi...@li...> >>> https://lists.sourceforge.net/lists/listinfo/swig-devel >>> >>> >>> >>> >>> -- >>> Sincerely yours, >>> Artem Serebriyskiy >> >> > > |
From: Olly B. <ol...@su...> - 2014-05-22 07:02:50
|
On Thu, May 22, 2014 at 07:24:37AM +0100, William S Fulton wrote: > Artem/Eric, any progress? This is blocking the new release which I > would like to do this weekend. There's a PR for this in github: https://github.com/swig/swig/pull/176 It could do with a tweak to work with pre-C99 C compilers, but otherwise looks OK to me. I also checked it with Xapian's Lua bindings. William said it needed a testcase adding in that PR, though the patch seems to contain one already. Cheers, Olly |
From: William S F. <ws...@fu...> - 2014-05-22 06:56:51
|
On 22/05/14 07:46, Olly Betts wrote: > On Thu, May 22, 2014 at 07:24:37AM +0100, William S Fulton wrote: >> Artem/Eric, any progress? This is blocking the new release which I >> would like to do this weekend. > > There's a PR for this in github: > > https://github.com/swig/swig/pull/176 > > It could do with a tweak to work with pre-C99 C compilers, but otherwise > looks OK to me. I also checked it with Xapian's Lua bindings. > > William said it needed a testcase adding in that PR, though the patch > seems to contain one already. Good news, yes I see that now, I must have missed it before. Sounds like the patch only requires a few minor tweaks then. William |
From: Artem S. <v.f...@gm...> - 2014-05-22 09:25:09
|
Hi. Just to clarify - I did not intend for this patch to make it into 3.0.1. It is not a bugfix, it is a new functionality. As such it is a potential point for regression. Bugfix for "operator== not working" part is already merged. Olly, William, is it true that SWIG must support pedantic C89 ? Because there is already a lot of code in luarun.swg that doesn't follow C89 rules, especially the 'variable at the beginning of the block' rule. Most of that code is - alas - mine. On 22 May 2014 10:56, William S Fulton <ws...@fu...> wrote: > On 22/05/14 07:46, Olly Betts wrote: > >> On Thu, May 22, 2014 at 07:24:37AM +0100, William S Fulton wrote: >> >>> Artem/Eric, any progress? This is blocking the new release which I >>> would like to do this weekend. >>> >> >> There's a PR for this in github: >> >> https://github.com/swig/swig/pull/176 >> >> It could do with a tweak to work with pre-C99 C compilers, but otherwise >> looks OK to me. I also checked it with Xapian's Lua bindings. >> >> William said it needed a testcase adding in that PR, though the patch >> seems to contain one already. >> > Good news, yes I see that now, I must have missed it before. Sounds like > the patch only requires a few minor tweaks then. > > William > > -- Sincerely yours, Artem Serebriyskiy |
From: Eric W. <ewm...@gm...> - 2014-05-22 21:35:50
|
Hi, I have written more tests for the default __eq operator. They are simple, but it is a pretty simple feature. My environment is not setup well to directly run SWIG tests (I don't have a system-wide Lua install for one reason because I always embed), so I wrote and ran the tests manually. I'm hoping you guys can just copy/paste and drop in for me. Two files: equality.i and equality.lua ============= File: equality.i ============= %module equality %inline %{ typedef struct Point { double x; double y; } Point; static const Point s_zeroPoint = { 0.0, 0.0 }; /* stack version */ Point MakePoint(double x, double y) { Point new_point = {x, y}; return new_point; } /* pointer version */ Point* CreatePoint(double x, double y) { Point* new_point = (Point*)malloc(sizeof(Point)); new_point->x=x; new_point->y=y; return new_point; } void DestroyPoint(Point* p) { free(p); } const Point* GetZeroPointPtr() { return &s_zeroPoint; } Point GetZeroPointCopy() { return s_zeroPoint; } void PrintPoint(Point p) { printf("{ %lf, %lf }\n", p.x, p.y); } %} ============= File: equality.lua ============= -- The Lua/SWIG backend implementation has an unfortunate implementation detail such that -- the same underlying C pointer can get multiple/different userdata wrappers. -- This can cause confusion with things like equality, memory ownership, and attributes tied to userdata and not the C-ptr. -- We can solve the equality comparison problem with a default __eq metamethod that compares (by default) the underlying C-ptr instead of comparing userdata addresses. -- That is what this test does. -- SWIG currently will create 2 different userdata wrappers for the same underlying C-ptr. -- (If they are the same, then SWIG has been improved. -- Thus I don't want to due an assertion check that these userdata's are different. -- The rest of the equality test should still hold up if this is improved.) zeroPoint1 = equality.s_zeroPoint; zeroPoint2 = equality.s_zeroPoint; if tostring(zeroPoint1) ~= tostring(zeroPoint2) then print("Due to current SWIG implementation details, the userdata values are different for the same C-ptr") print("zeroPoint1 " , zeroPoint1) print("zeroPoint2 " , zeroPoint2) else print("Somebody improved SWIG to keep C-ptr/userdata mappings 1-to-1. Yay!") end -- Test to make sure an object is still equal to itself assert(zeroPoint1 == zeroPoint1) assert(zeroPoint2 == zeroPoint2) -- Now test that the __eq override is working correctly assert(zeroPoint1 == zeroPoint2) -- This is another way to get the same zero point pointer zeroPoint3 = equality.GetZeroPointPtr() assert(zeroPoint1 == zeroPoint3) assert(zeroPoint2 == zeroPoint3) -- Now create a different object so we can do some negative tests -- These are comparing underlying C-ptrs, not the x,y values, so they should fail. differentZeroPoint3 = equality.MakePoint(0.0, 0.0) assert(zeroPoint1 ~= differentZeroPoint3) assert(zeroPoint2 ~= differentZeroPoint3) assert(zeroPoint3 ~= differentZeroPoint3) differentZeroPoint4 = equality.CreatePoint(0.0, 0.0) assert(zeroPoint1 ~= differentZeroPoint4) assert(zeroPoint2 ~= differentZeroPoint4) assert(zeroPoint3 ~= differentZeroPoint4) assert(differentZeroPoint3 ~= differentZeroPoint4) differentZeroPoint5 = equality.GetZeroPointCopy() assert(zeroPoint1 ~= differentZeroPoint5) assert(zeroPoint2 ~= differentZeroPoint5) assert(zeroPoint3 ~= differentZeroPoint5) assert(differentZeroPoint3 ~= differentZeroPoint5) assert(differentZeroPoint4 ~= differentZeroPoint5) print("All equality tests passed") Thanks, Eric -- Beginning iPhone Games Development http://playcontrol.net/iphonegamebook/ |
From: Eric W. <ewm...@gm...> - 2014-05-22 21:40:06
|
> Olly, William, is it true that SWIG must support pedantic C89 ? Because > there is already a lot of code in luarun.swg that doesn't follow C89 rules, > especially the 'variable at the beginning of the block' rule. Most of that > code is - alas - mine. C89 is needed to support Visual Studio because they still drag their feet after 25 years. This is a constant sore point for me. Thanks, Eric -- Beginning iPhone Games Development http://playcontrol.net/iphonegamebook/ |
From: Vadim Z. <vz...@ze...> - 2014-05-22 23:45:56
|
On Thu, 22 May 2014 14:39:59 -0700 Eric Wing <ewm...@gm...> wrote: EW> > Olly, William, is it true that SWIG must support pedantic C89 ? Because EW> > there is already a lot of code in luarun.swg that doesn't follow C89 rules, EW> > especially the 'variable at the beginning of the block' rule. Most of that EW> > code is - alas - mine. EW> EW> C89 is needed to support Visual Studio because they still drag their EW> feet after 25 years. This is a constant sore point for me. In practice, this can be almost always easily worked around by compiling C code as C++ (using /TP compiler option or just renaming the file to have .cpp extension). In SWIG case I really wish the entire code base could move to C++ anyhow, so I'd serious consider doing this instead of sticking to C89. Regards, VZ |
From: Artem S. <v.f...@gm...> - 2014-05-16 09:28:51
|
Hi. Eric, I have added the requested default __eq implementation. See pull request https://github.com/swig/swig/pull/176. Please test it and tell me if it works as you wanted it too. I would also appreciate if you add some more complicated test cases to this issue. Regarding your question about variable life time and garbage collection: 1. There is no predefined SWIG table where you could store userdata. 2. If your inter-objects relations are simple( class Parent has pointer to class Child ), you may try to add a table as uservalue<http://www.lua.org/manual/5.2/manual.html#lua_setuservalue>to Parent instance and add Child instances to it). 3. However if Parent actually manages Child itself (e.g. has smart pointer inside) you could order SWIG to disown objects of type Child. 4. I sincerely suggest you to redirect this question to William :) I may know some part of Lua module internals, but I lack knowledge of SWIG itself. William, I think issue with assertions should be considered resolved. It was caused by incompatibility between modules generated with pre-patched SWIG and modules generated with post-patched SWIG. The only solution will be to recompile all modules with upcoming SWIG 3.0.1. On 16 May 2014 04:53, Eric Wing <ewm...@gm...> wrote: > Hi Artem, > Just a quick update. I figured out my memory reference association > feature which *I think* plugs all the crash causes in my program. > > So far, so good. I haven't seen any crashes which suggests that I was > just unlucky and the additional crashes I saw were not a result of a > bug in your patch. > > However, if you have that __eq fix I need, that would really help me > test better. Right now, my program has a ton of temporary hacks to > workaround the missing __eq so I could be missing things. > > Thanks, > Eric > > > On 5/12/14, Eric Wing <ewm...@gm...> wrote: > > On 5/12/14, Artem Serebriyskiy <v.f...@gm...> wrote: > >> Hi Eric. > >> > >> Assertions going away is what I sincerely hoped for ) > >> > >> Increased rate in garbage collector's failures is actually a bad sign - > >> my > >> changes might have broken it. If you could confirm or refute this issue > I > >> would be grateful. (Hint - the most probable cause is wrong destructor > >> being called or destructor not called at all). I dont ask you to solve > >> issue, mind you, just confirm that it arises due to SWIG error :) > > > > I will continue to look into this. Unfortunately, I know there are a > > few areas where my memory management causes problems. What concerns me > > is I'm seeing crashes in areas that should be working. I don't know if > > I'm getting unlucky (other stuff corrupting good stuff more often with > > your changes) or if there is a real problem. > > > > > > > >> I could implement __eq method in the way you requested. I am not sure it > >> will make into 3.0.1 though - it is up to William. Given my current > >> schedule, it will take 1-3 days at least. > > > > Thank you. That would be a big help. I'm not too concerned about > > 3.0.1. Unfortunately, I'm also limping along on the JavaScript branch > > so I'll be tied to unreleased versions for awhile. Also, I need my Lua > > 5.3 integer changes which haven't been reviewed yet. > > > > > > A minor digression... > > The memory problem I have is kind of a reference/ownership problem. > > There are several places in the APIs I'm dealing with where there are > > implicit dependencies on. Here's a more concrete example: > > > > In SDL, if I create a renderer (SDL_CreateRenderer) and then create a > > texture (SDL_CreateTextureFromSurface(renderer, bmp_surface)), the > > renderer must stay alive longer than the texture. > > > > Similarly, in Chipmunk, if I create a body (cpBodyNew) and add it to a > > space (cpSpaceNew), the body can't be collected before it is removed > > from the space. > > > > In garbage collection, the order of destruction of objects isn't > > guaranteed. So I need a way to express this relationship and keep a > > reference between the objects. > > > > This pattern is unfortunately coming up a lot for me. I would really > > like a more general way of dealing with this, so I've been thinking > > about trying to modify SWIG to help me here. (Maybe a %feature?) I > > haven't figured out yet how to do that, but the first thing I need is > > a place to store this information. One idea is the Lua registry, but > > I'm wondering if there is a better place, like in a pre-existing SWIG > > userdata table I can add stuff too. > > > > Do you have any recommendations since you know SWIG/Lua backend much > > better than me? > > > > Thanks, > > Eric > > > > > -- > Beginning iPhone Games Development > http://playcontrol.net/iphonegamebook/ > -- Sincerely yours, Artem Serebriyskiy |
From: Eric W. <ewm...@gm...> - 2014-05-19 11:45:07
|
Hi Artem, I finally did a bunch of testing. This is working really well for me. Thank you! I will try to come up with some simple tests that can be added to SWIG for this. Thanks, Eric On 5/16/14, Artem Serebriyskiy <v.f...@gm...> wrote: > Hi. > > Eric, > I have added the requested default __eq implementation. See pull request > https://github.com/swig/swig/pull/176. Please test it and tell me if it > works as you wanted it too. I would also appreciate if you add some more > complicated test cases to this issue. > > Regarding your question about variable life time and garbage collection: > 1. There is no predefined SWIG table where you could store userdata. > 2. If your inter-objects relations are simple( class Parent has pointer > to class Child ), you may try to add a table as > uservalue<http://www.lua.org/manual/5.2/manual.html#lua_setuservalue>to > Parent instance and add Child instances to it). > 3. However if Parent actually manages Child itself (e.g. has smart > pointer inside) you could order SWIG to disown objects of type Child. > 4. I sincerely suggest you to redirect this question to William :) I may > know some part of Lua module internals, but I lack knowledge of SWIG > itself. > > William, > I think issue with assertions should be considered resolved. It was caused > by incompatibility between modules generated with pre-patched SWIG and > modules generated with post-patched SWIG. The only solution will be to > recompile all modules with upcoming SWIG 3.0.1. > > > On 16 May 2014 04:53, Eric Wing <ewm...@gm...> wrote: > >> Hi Artem, >> Just a quick update. I figured out my memory reference association >> feature which *I think* plugs all the crash causes in my program. >> >> So far, so good. I haven't seen any crashes which suggests that I was >> just unlucky and the additional crashes I saw were not a result of a >> bug in your patch. >> >> However, if you have that __eq fix I need, that would really help me >> test better. Right now, my program has a ton of temporary hacks to >> workaround the missing __eq so I could be missing things. >> >> Thanks, >> Eric >> >> >> On 5/12/14, Eric Wing <ewm...@gm...> wrote: >> > On 5/12/14, Artem Serebriyskiy <v.f...@gm...> wrote: >> >> Hi Eric. >> >> >> >> Assertions going away is what I sincerely hoped for ) >> >> >> >> Increased rate in garbage collector's failures is actually a bad sign >> >> - >> >> my >> >> changes might have broken it. If you could confirm or refute this >> >> issue >> I >> >> would be grateful. (Hint - the most probable cause is wrong destructor >> >> being called or destructor not called at all). I dont ask you to solve >> >> issue, mind you, just confirm that it arises due to SWIG error :) >> > >> > I will continue to look into this. Unfortunately, I know there are a >> > few areas where my memory management causes problems. What concerns me >> > is I'm seeing crashes in areas that should be working. I don't know if >> > I'm getting unlucky (other stuff corrupting good stuff more often with >> > your changes) or if there is a real problem. >> > >> > >> > >> >> I could implement __eq method in the way you requested. I am not sure >> >> it >> >> will make into 3.0.1 though - it is up to William. Given my current >> >> schedule, it will take 1-3 days at least. >> > >> > Thank you. That would be a big help. I'm not too concerned about >> > 3.0.1. Unfortunately, I'm also limping along on the JavaScript branch >> > so I'll be tied to unreleased versions for awhile. Also, I need my Lua >> > 5.3 integer changes which haven't been reviewed yet. >> > >> > >> > A minor digression... >> > The memory problem I have is kind of a reference/ownership problem. >> > There are several places in the APIs I'm dealing with where there are >> > implicit dependencies on. Here's a more concrete example: >> > >> > In SDL, if I create a renderer (SDL_CreateRenderer) and then create a >> > texture (SDL_CreateTextureFromSurface(renderer, bmp_surface)), the >> > renderer must stay alive longer than the texture. >> > >> > Similarly, in Chipmunk, if I create a body (cpBodyNew) and add it to a >> > space (cpSpaceNew), the body can't be collected before it is removed >> > from the space. >> > >> > In garbage collection, the order of destruction of objects isn't >> > guaranteed. So I need a way to express this relationship and keep a >> > reference between the objects. >> > >> > This pattern is unfortunately coming up a lot for me. I would really >> > like a more general way of dealing with this, so I've been thinking >> > about trying to modify SWIG to help me here. (Maybe a %feature?) I >> > haven't figured out yet how to do that, but the first thing I need is >> > a place to store this information. One idea is the Lua registry, but >> > I'm wondering if there is a better place, like in a pre-existing SWIG >> > userdata table I can add stuff too. >> > >> > Do you have any recommendations since you know SWIG/Lua backend much >> > better than me? >> > >> > Thanks, >> > Eric >> > >> >> >> -- >> Beginning iPhone Games Development >> http://playcontrol.net/iphonegamebook/ >> > > > > -- > Sincerely yours, > Artem Serebriyskiy > -- Beginning iPhone Games Development http://playcontrol.net/iphonegamebook/ |
From: William S F. <ws...@fu...> - 2014-05-23 00:03:55
|
On 23/05/14 00:45, Vadim Zeitlin wrote: > On Thu, 22 May 2014 14:39:59 -0700 Eric Wing <ewm...@gm...> wrote: > > EW> > Olly, William, is it true that SWIG must support pedantic C89 ? Because > EW> > there is already a lot of code in luarun.swg that doesn't follow C89 rules, > EW> > especially the 'variable at the beginning of the block' rule. Most of that > EW> > code is - alas - mine. > EW> > EW> C89 is needed to support Visual Studio because they still drag their > EW> feet after 25 years. This is a constant sore point for me. > > In practice, this can be almost always easily worked around by compiling C > code as C++ (using /TP compiler option or just renaming the file to have .cpp > extension). In SWIG case I really wish the entire code base could move to > C++ anyhow, so I'd serious consider doing this instead of sticking to C89. > The problem is the generated wrappers, not the SWIG source. SWIG's generated wrappers try and use a lowest common denominator code for maximum portability. I'm afraid that compiling C code as C++ doesn't always work. It has been a recent source of headaches for the Octave and Javascript generators which have C++ apis instead of C and so the output is compiled as C++. William |
From: Artem S. <v.f...@gm...> - 2014-05-23 11:34:48
|
Currently SWIG tests run C compiler without '-ansi -pedantic', so no checks for C89-compatibility. May be it should be added ? On 23 May 2014 04:03, William S Fulton <ws...@fu...> wrote: > On 23/05/14 00:45, Vadim Zeitlin wrote: > > On Thu, 22 May 2014 14:39:59 -0700 Eric Wing <ewm...@gm...> > wrote: > > > > EW> > Olly, William, is it true that SWIG must support pedantic C89 ? > Because > > EW> > there is already a lot of code in luarun.swg that doesn't follow > C89 rules, > > EW> > especially the 'variable at the beginning of the block' rule. Most > of that > > EW> > code is - alas - mine. > > EW> > > EW> C89 is needed to support Visual Studio because they still drag their > > EW> feet after 25 years. This is a constant sore point for me. > > > > In practice, this can be almost always easily worked around by > compiling C > > code as C++ (using /TP compiler option or just renaming the file to have > .cpp > > extension). In SWIG case I really wish the entire code base could move to > > C++ anyhow, so I'd serious consider doing this instead of sticking to > C89. > > > The problem is the generated wrappers, not the SWIG source. SWIG's > generated wrappers try and use a lowest common denominator code for > maximum portability. I'm afraid that compiling C code as C++ doesn't > always work. It has been a recent source of headaches for the Octave and > Javascript generators which have C++ apis instead of C and so the output > is compiled as C++. > > William > > > > ------------------------------------------------------------------------------ > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE > Instantly run your Selenium tests across 300+ browser/OS combos. > Get unparalleled scalability from the best Selenium testing platform > available > Simple to use. Nothing to install. Get started now for free." > http://p.sf.net/sfu/SauceLabs > _______________________________________________ > Swig-devel mailing list > Swi...@li... > https://lists.sourceforge.net/lists/listinfo/swig-devel > -- Sincerely yours, Artem Serebriyskiy |
From: William S F. <ws...@fu...> - 2014-05-24 13:31:28
|
I've added some stricter compile flags for compiling the examples on Travis. See https://github.com/swig/swig/commit/8350288a6b40a4a17a73998f40134778dcfb1a73 I couldn't use -pedantic on all languages due to problems in headers and due to numerous instances of: warning: ISO C forbids conversion of object pointer to function pointer type [-pedantic] I've used "-Werror -fdiagnostics-show-option -Wno-long-long -Wreturn-type" and one of -std=gnu89 or -std=c++98 and sometimes -pedantic - see .travis.yml. It think we could change gnu89 to c89 in some languages which have compliant headers. Patches to add in stricter warnings are welcome. William On 23/05/14 12:34, Artem Serebriyskiy wrote: > Currently SWIG tests run C compiler without '-ansi -pedantic', so no > checks for C89-compatibility. May be it should be added ? > > > On 23 May 2014 04:03, William S Fulton <ws...@fu... > <mailto:ws...@fu...>> wrote: > > On 23/05/14 00:45, Vadim Zeitlin wrote: > > On Thu, 22 May 2014 14:39:59 -0700 Eric Wing <ewm...@gm... > <mailto:ewm...@gm...>> wrote: > > > > EW> > Olly, William, is it true that SWIG must support pedantic > C89 ? Because > > EW> > there is already a lot of code in luarun.swg that doesn't > follow C89 rules, > > EW> > especially the 'variable at the beginning of the block' > rule. Most of that > > EW> > code is - alas - mine. > > EW> > > EW> C89 is needed to support Visual Studio because they still > drag their > > EW> feet after 25 years. This is a constant sore point for me. > > > > In practice, this can be almost always easily worked around by > compiling C > > code as C++ (using /TP compiler option or just renaming the file > to have .cpp > > extension). In SWIG case I really wish the entire code base could > move to > > C++ anyhow, so I'd serious consider doing this instead of > sticking to C89. > > > The problem is the generated wrappers, not the SWIG source. SWIG's > generated wrappers try and use a lowest common denominator code for > maximum portability. I'm afraid that compiling C code as C++ doesn't > always work. It has been a recent source of headaches for the Octave and > Javascript generators which have C++ apis instead of C and so the output > is compiled as C++. > > William > > > ------------------------------------------------------------------------------ > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE > Instantly run your Selenium tests across 300+ browser/OS combos. > Get unparalleled scalability from the best Selenium testing platform > available > Simple to use. Nothing to install. Get started now for free." > http://p.sf.net/sfu/SauceLabs > _______________________________________________ > Swig-devel mailing list > Swi...@li... > <mailto:Swi...@li...> > https://lists.sourceforge.net/lists/listinfo/swig-devel > > > > > -- > Sincerely yours, > Artem Serebriyskiy |