From: Rob S. <rob...@si...> - 2007-05-02 19:28:27
|
I just moved up from 1.3.29 to 1.3.31 and now the virtual functions in my Director classes are stuck in infinite recursion loops. Looking at the generated wrapper code, I don't see the swig_up static data member or the get_swig_up() member functions on the Directors. What's wrong? -- Rob Stewart rob...@si... Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer; |
From: William S F. <ws...@fu...> - 2007-05-03 09:33:35
|
Rob Stewart <robert.stewart <at> sig.com> writes: > > I just moved up from 1.3.29 to 1.3.31 and now the virtual > functions in my Director classes are stuck in infinite recursion > loops. Looking at the generated wrapper code, I don't see the > swig_up static data member or the get_swig_up() member functions > on the Directors. What's wrong? Read the CHANGES file (09/13/2006) for an explanation of the change. You shouldn't be getting recursive calls, but as you are, please post a comple standalone example demonstrating the problem and I'll take a look. William |
From: Rob S. <rob...@si...> - 2007-05-10 17:54:15
|
From: William S Fulton <ws...@fu...> > Rob Stewart <robert.stewart <at> sig.com> writes: > > > I just moved up from 1.3.29 to 1.3.31 and now the virtual > > functions in my Director classes are stuck in infinite recursion > > loops. Looking at the generated wrapper code, I don't see the > > swig_up static data member or the get_swig_up() member functions > > on the Directors. What's wrong? > > Read the CHANGES file (09/13/2006) for an explanation of the change. You > shouldn't be getting recursive calls, but as you are, please post a comple > standalone example demonstrating the problem and I'll take a look. I've found what leads to the problem. I've attached a tarball with code that illustrates the issue. Run build.sh (after adjusting the shell variables at the top) to build the module. (That was easier than trying to set up a makefile since I could just copy, paste, and edit the commands our build system already computed.) Once you build the module, just run "python example.py." The key characteristics are: - virtual function in C++ base class - director for C++ derivate - Python derivate with no "override" for the virtual function When the virtual function is called, the director's override calls the default proxy implementation which calls the wrapper of the virtual function. The wrapper makes a polymorphic call to that virtual function so the director's override is called again. -- Rob Stewart rob...@si... Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer; ===File example.tgz=== wµh0Þ²ZûHÖê6 û´FÇx¼ÜÑEÁ#>TÓ/ ãô+Ý'±`.iT-d78ÎqõS\l*¹Ç¹=ù1§Á,é]{º ÐK,ÆïQ*Ä 8áANxm5Oø¨~zƼ¦½o))ûª@=S$j)ßJØF9¹*Oîcº?ÜÁ®Êª ÿ°jÖ |
From: Stewart, R. <Rob...@si...> - 2008-01-18 21:52:13
|
From: swi...@li...=20 > [mailto:swi...@li...] On Behalf Of=20 > Rob Stewart > Sent: Thursday, May 10, 2007 1:50 PM >=20 > From: William S Fulton <ws...@fu...> > > Rob Stewart <robert.stewart <at> sig.com> writes: > >=20 > > > I just moved up from 1.3.29 to 1.3.31 and now the virtual > > > functions in my Director classes are stuck in infinite recursion > > > loops. Looking at the generated wrapper code, I don't see the > > > swig_up static data member or the get_swig_up() member functions > > > on the Directors. What's wrong? > >=20 > > Read the CHANGES file (09/13/2006) for an explanation of=20 > the change. You > > shouldn't be getting recursive calls, but as you are,=20 > please post a comple > > standalone example demonstrating the problem and I'll take a look. >=20 > I've found what leads to the problem. I've attached a tarball > with code that illustrates the issue. Run build.sh (after > adjusting the shell variables at the top) to build the module. > (That was easier than trying to set up a makefile since I could > just copy, paste, and edit the commands our build system already > computed.) Once you build the module, just run "python > example.py." >=20 > The key characteristics are: >=20 > - virtual function in C++ base class > - director for C++ derivate > - Python derivate with no "override" for the virtual function >=20 > When the virtual function is called, the director's override > calls the default proxy implementation which calls the wrapper of > the virtual function. The wrapper makes a polymorphic call to > that virtual function so the director's override is called again. Has there been any progress on this? _____ Rob Stewart rob...@si... Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer; IMPORTANT: The information contained in this email and/or its = attachments is confidential. If you are not the intended recipient, = please notify the sender immediately by reply and immediately delete = this message and all its attachments. Any review, use, reproduction, = disclosure or dissemination of this message or any attachment by an = unintended recipient is strictly prohibited. Neither this message nor = any attachment is intended as or should be construed as an offer, = solicitation or recommendation to buy or sell any security or other = financial instrument. Neither the sender, his or her employer nor any = of their respective affiliates makes any warranties as to the = completeness or accuracy of any of the information contained herein or = that this message or any of its attachments is free of viruses. |
From: Stewart, R. <Rob...@si...> - 2007-05-24 16:55:52
|
From: swi...@li...=20 [mailto:swi...@li...] On Behalf Of=20 Rob Stewart > From: William S Fulton <ws...@fu...> > > Rob Stewart <robert.stewart <at> sig.com> writes: > >=20 > > > I just moved up from 1.3.29 to 1.3.31 and now the virtual > > > functions in my Director classes are stuck in infinite recursion > > > loops. Looking at the generated wrapper code, I don't see the > > > swig_up static data member or the get_swig_up() member functions > > > on the Directors. What's wrong? > >=20 > > Read the CHANGES file (09/13/2006) for an explanation of=20 > the change. You > > shouldn't be getting recursive calls, but as you are,=20 > please post a comple > > standalone example demonstrating the problem and I'll take a look. >=20 > I've found what leads to the problem. I've attached a tarball > with code that illustrates the issue. Run build.sh (after > adjusting the shell variables at the top) to build the module. > (That was easier than trying to set up a makefile since I could > just copy, paste, and edit the commands our build system already > computed.) Once you build the module, just run "python > example.py." >=20 > The key characteristics are: >=20 > - virtual function in C++ base class > - director for C++ derivate > - Python derivate with no "override" for the virtual function >=20 > When the virtual function is called, the director's override > calls the default proxy implementation which calls the wrapper of > the virtual function. The wrapper makes a polymorphic call to > that virtual function so the director's override is called again. Have you had a chance to look at this? Have you made any progress? _____ Rob IMPORTANT: The information contained in this email and/or its = attachments is confidential. If you are not the intended recipient, = please notify the sender immediately by reply and immediately delete = this message and all its attachments. Any review, use, reproduction, = disclosure or dissemination of this message or any attachment by an = unintended recipient is strictly prohibited. Neither this message nor = any attachment is intended as or should be construed as an offer, = solicitation or recommendation to buy or sell any security or other = financial instrument. Neither the sender, his or her employer nor any = of their respective affiliates makes any warranties as to the = completeness or accuracy of any of the information contained herein or = that this message or any of its attachments is free of viruses. |
From: William S F. <ws...@fu...> - 2007-05-24 22:00:25
|
Stewart, Robert wrote: > From: swi...@li... > [mailto:swi...@li...] On Behalf Of > Rob Stewart >> From: William S Fulton <ws...@fu...> >>> Rob Stewart <robert.stewart <at> sig.com> writes: >>> >>>> I just moved up from 1.3.29 to 1.3.31 and now the virtual >>>> functions in my Director classes are stuck in infinite recursion >>>> loops. Looking at the generated wrapper code, I don't see the >>>> swig_up static data member or the get_swig_up() member functions >>>> on the Directors. What's wrong? >>> Read the CHANGES file (09/13/2006) for an explanation of >> the change. You >>> shouldn't be getting recursive calls, but as you are, >> please post a comple >>> standalone example demonstrating the problem and I'll take a look. >> I've found what leads to the problem. I've attached a tarball >> with code that illustrates the issue. Run build.sh (after >> adjusting the shell variables at the top) to build the module. >> (That was easier than trying to set up a makefile since I could >> just copy, paste, and edit the commands our build system already >> computed.) Once you build the module, just run "python >> example.py." >> >> The key characteristics are: >> >> - virtual function in C++ base class >> - director for C++ derivate >> - Python derivate with no "override" for the virtual function >> >> When the virtual function is called, the director's override >> calls the default proxy implementation which calls the wrapper of >> the virtual function. The wrapper makes a polymorphic call to >> that virtual function so the director's override is called again. > > Have you had a chance to look at this? Have you made any progress? > Sorry, not yet. I've been rather bogged down as usual. No promises as to when, but it is my list. William |
From: Rob S. <rob...@si...> - 2007-05-03 15:12:35
|
From: William S Fulton <ws...@fu...> > Rob Stewart <robert.stewart <at> sig.com> writes: > > > I just moved up from 1.3.29 to 1.3.31 and now the virtual > > functions in my Director classes are stuck in infinite recursion > > loops. Looking at the generated wrapper code, I don't see the > > swig_up static data member or the get_swig_up() member functions > > on the Directors. What's wrong? > > Read the CHANGES file (09/13/2006) for an explanation of the change. You > shouldn't be getting recursive calls, but as you are, please post a comple > standalone example demonstrating the problem and I'll take a look. I found that after I posted, but of course it doesn't explain how it should work now. I'll work on a standalone example, but in the meantime, here's the wrapped function that triggers the loop: SWIGINTERN PyObject *_wrap_TSInstrumentData_markPrice(PyObject *SWIGUNUSEDPARM(self), PyObject *args) { PyObject *resultobj = 0; TSInstrumentData *arg1 = (TSInstrumentData *) 0 ; SAPrice *result = 0 ; void *argp1 = 0 ; int res1 = 0 ; PyObject * obj0 = 0 ; if (!PyArg_ParseTuple(args,(char *)"O:TSInstrumentData_markPrice",&obj0)) SWIG_fail; res1 = SWIG_ConvertPtr(obj0, &argp1,SWIGTYPE_p_TSInstrumentData, 0 | 0 ); if (!SWIG_IsOK(res1)) { SWIG_exception_fail(SWIG_ArgError(res1), "in method '" "TSInstrumentData_markPrice" "', argument " "1"" of type '" "TSInstrumentData const *""'"); } arg1 = reinterpret_cast< TSInstrumentData * >(argp1); { SAPrice const &_result_ref = ((TSInstrumentData const *)arg1)->markPrice(); result = (SAPrice *) &_result_ref; } resultobj = SWIG_NewPointerObj(SWIG_as_voidptr(result), SWIGTYPE_p_SAPrice, 0 | 0 ); return resultobj; fail: return NULL; } The calling sequence is that the Director's markPrice() is called from C++. That triggers the call into Python in case of an "override." The Python wrapper code invokes _wrap_TSInstrumentData_markPrice(), above, and the invocation of markPrice() therein is polymorhpic, so it starts the sequence again. -- Rob Stewart rob...@si... Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer; |
From: William S F. <ws...@fu...> - 2007-05-11 10:07:22
|
Rob Stewart <robert.stewart <at> sig.com> writes: > I've found what leads to the problem. I've attached a tarball > with code that illustrates the issue. The tarball does not appear as a valid file attachment. Try sending again. William |