You can subscribe to this list here.
2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(64) |
Dec
(161) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
(376) |
Feb
(195) |
Mar
(127) |
Apr
(30) |
May
(79) |
Jun
(83) |
Jul
(42) |
Aug
(39) |
Sep
(82) |
Oct
(102) |
Nov
(229) |
Dec
(76) |
2007 |
Jan
(62) |
Feb
(29) |
Mar
(83) |
Apr
(92) |
May
(84) |
Jun
(58) |
Jul
(36) |
Aug
(63) |
Sep
(131) |
Oct
(160) |
Nov
(46) |
Dec
(67) |
2008 |
Jan
(72) |
Feb
(82) |
Mar
(124) |
Apr
(144) |
May
(73) |
Jun
(38) |
Jul
(101) |
Aug
(26) |
Sep
(96) |
Oct
(35) |
Nov
(53) |
Dec
(92) |
2009 |
Jan
(92) |
Feb
(48) |
Mar
(90) |
Apr
(50) |
May
(104) |
Jun
(110) |
Jul
(136) |
Aug
(99) |
Sep
(80) |
Oct
(38) |
Nov
(106) |
Dec
(48) |
2010 |
Jan
(33) |
Feb
(70) |
Mar
(41) |
Apr
(54) |
May
(97) |
Jun
(76) |
Jul
(61) |
Aug
(27) |
Sep
(64) |
Oct
(74) |
Nov
(35) |
Dec
(55) |
2011 |
Jan
(66) |
Feb
(113) |
Mar
(101) |
Apr
(71) |
May
(93) |
Jun
(36) |
Jul
(30) |
Aug
(55) |
Sep
(30) |
Oct
(51) |
Nov
(59) |
Dec
(43) |
2012 |
Jan
(59) |
Feb
(32) |
Mar
(232) |
Apr
(174) |
May
(142) |
Jun
(38) |
Jul
(127) |
Aug
(99) |
Sep
(32) |
Oct
(8) |
Nov
(28) |
Dec
(144) |
2013 |
Jan
(105) |
Feb
(25) |
Mar
(70) |
Apr
(69) |
May
(40) |
Jun
(33) |
Jul
(20) |
Aug
(31) |
Sep
(82) |
Oct
(42) |
Nov
(78) |
Dec
(72) |
2014 |
Jan
(62) |
Feb
(68) |
Mar
(39) |
Apr
(54) |
May
(90) |
Jun
(87) |
Jul
(42) |
Aug
(76) |
Sep
(44) |
Oct
(49) |
Nov
(5) |
Dec
(28) |
2015 |
Jan
(33) |
Feb
(13) |
Mar
(12) |
Apr
(17) |
May
(15) |
Jun
(22) |
Jul
(16) |
Aug
(27) |
Sep
(8) |
Oct
(9) |
Nov
(14) |
Dec
(9) |
2016 |
Jan
(22) |
Feb
(15) |
Mar
(6) |
Apr
(6) |
May
(22) |
Jun
(83) |
Jul
(5) |
Aug
(9) |
Sep
(13) |
Oct
|
Nov
(31) |
Dec
(18) |
2017 |
Jan
(9) |
Feb
(15) |
Mar
(11) |
Apr
(11) |
May
(9) |
Jun
(10) |
Jul
(2) |
Aug
(1) |
Sep
(5) |
Oct
(4) |
Nov
(3) |
Dec
(9) |
2018 |
Jan
(3) |
Feb
(6) |
Mar
(1) |
Apr
(3) |
May
(8) |
Jun
(2) |
Jul
(3) |
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
|
2019 |
Jan
(3) |
Feb
(19) |
Mar
(11) |
Apr
(9) |
May
(7) |
Jun
(14) |
Jul
(1) |
Aug
(7) |
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
(3) |
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
(7) |
Jul
|
Aug
(3) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
2021 |
Jan
(8) |
Feb
(1) |
Mar
(11) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(2) |
Sep
(4) |
Oct
(9) |
Nov
(14) |
Dec
|
2022 |
Jan
(1) |
Feb
(5) |
Mar
(2) |
Apr
|
May
|
Jun
(3) |
Jul
(2) |
Aug
|
Sep
(7) |
Oct
(9) |
Nov
(5) |
Dec
(1) |
2023 |
Jan
(2) |
Feb
|
Mar
|
Apr
(2) |
May
(6) |
Jun
(1) |
Jul
|
Aug
(4) |
Sep
(4) |
Oct
|
Nov
(2) |
Dec
(5) |
2024 |
Jan
(11) |
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
From: Robin D. <ro...@al...> - 2006-01-20 02:26:31
|
Marcelo Matus wrote: > Please try the CVS version, there are some critical fixes for the > runtime library + the import > mechanism. If that doesn't fix the problem, we will need you to try to > reproduce the problem > with a small example we can play with here. Something like the attached should show it. (Not completely tested, but I verified that the code has the same "feature" I was seeing in the debugger earlier.) The wrap file for mod1 gets these lines: static swig_cast_info _swigc__p_A[] = { {&_swigt__p_A, 0, 0, 0}, {&_swigt__p_B, _p_BTo_p_A, 0, 0},{0, 0, 0, 0}}; static swig_cast_info _swigc__p_B[] = { {&_swigt__p_B, 0, 0, 0},{0, 0, 0, 0}}; static swig_cast_info _swigc__p_C[] = { {&_swigt__p_C, 0, 0, 0},{0, 0, 0, 0}}; And the mod2 wrapper gets these lines: static swig_cast_info _swigc__p_A[] = { {&_swigt__p_A, 0, 0, 0}, {&_swigt__p_B, _p_BTo_p_A, 0, 0}, {&_swigt__p_C, _p_CTo_p_A, 0, 0}, {&_swigt__p_D, _p_DTo_p_A, 0, 0},{0, 0, 0, 0}}; static swig_cast_info _swigc__p_B[] = { {&_swigt__p_B, 0, 0, 0}, {&_swigt__p_C, _p_CTo_p_B, 0, 0}, {&_swigt__p_D, _p_DTo_p_B, 0, 0},{0, 0, 0, 0}}; static swig_cast_info _swigc__p_C[] = { {&_swigt__p_C, 0, 0, 0}, {&_swigt__p_D, _p_DTo_p_C, 0, 0},{0, 0, 0, 0}}; static swig_cast_info _swigc__p_D[] = { {&_swigt__p_D, 0, 0, 0},{0, 0, 0, 0}}; When mod2 is imported and SWIG_InstallModule runs it doesn't add the converter for C to the list of typecasts for A because swig is already aware of the C type. -- Robin Dunn Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython! |
From: Marcelo M. <mm...@ac...> - 2006-01-20 00:50:33
|
I tested swig-CVS is solaris using the native cc/CC compilers: - swig compiles with no problem - swig runs the check-python-test-suite as usual, ie, some tests don't=20 compile due to the compiler's template limitations. The rest is ok. Marcelo William S Fulton wrote: > > Marcelo Matus wrote: > >> For that reason is 'disabled' unless you use --with-rxspencer. Is=20 >> there for >> the people who want to try it, but is willing to take some extra effor= t, >> such as installing the library and recompiling swig. >> >> The problem is that the CVS version is kind of difficult to=20 >> grab/compile/test >> from the Windows world, and people just wait for oficial release to te= st >> swig. >> all=20 > > Are you thinking that the windows release should have this library=20 > compiled in then? > >> And as in this feature we need a lot of feedback and ideas, I think >> is better to give it a little more exposure than just been in CVS. >> >> Marcelo >> > > I'm also not sure about this change just before release. If this=20 > library has to be specifically installed at configure time and it=20 > doesn't come with big distributions, it means few people are going to=20 > use it and if it is going to be replaced in the next version of SWIG=20 > with something else, then I can't see the point of putting it in,=20 > especially if we are going to start working on the next version in a=20 > few weeks time. Or have we chosen this as the definitive regex library=20 > for the future now? > > Personally, I think we should concentrate on fixing the current=20 > problems that are preventing release before working on new features.=20 > Right now I have plenty of new things I'd like to work on, but instead=20 > have been concentrating on the drudge work getting SWIG to work again=20 > on multiple platforms :(. The Windows problems are holding up the=20 > release and there seem to be too many of them for the amount of free=20 > time I have. Has anyone had a chance to test on any platforms other=20 > than linux, eg Solaris? > > I was also wondering about the simple renaming mechanism that has=20 > recently gone in and how it fits in with the regex handling? Does it=20 > provide something that regex won't handle or is it complementary in=20 > some way? > > William > > >> >> Jason Stewart wrote: >> >>> Hi Marcelo, >>> >>> On 1/17/06, Marcelo Matus <mm...@ac...> wrote: >>> =20 >>> >>>> I think it is important to have this initial implementation out=20 >>>> with the >>>> next release >>>> to let people try it, test it and see how it fit with the %rename >>>> directive, and if more >>>> options are needed. >>>> =20 >>> >>> >>> This is a pretty major 'feature' that's going in awfully late in the >>> release, don't you think? We haven't had a lot of time to test it out. >>> Isn't it likely to generate a lot of issues? >>> >>> Cheers, jas. >>> >>> >>> ------------------------------------------------------- >>> This SF.net email is sponsored by: Splunk Inc. Do you grep through=20 >>> log files >>> for problems? Stop! Download the new AJAX search engine that makes >>> searching your log files as easy as surfing the web. DOWNLOAD SPLUN= K! >>> http://sel.as-us.falkag.net/sel?cmd=FFk&kid=103432&bid#0486&dat=12164= 2 >>> _______________________________________________ >>> Swig-devel mailing list >>> Swi...@li... >>> https://lists.sourceforge.net/lists/listinfo/swig-devel >>> >>> =20 >>> >> >> >> >> ------------------------------------------------------- >> This SF.net email is sponsored by: Splunk Inc. Do you grep through=20 >> log files >> for problems? Stop! Download the new AJAX search engine that makes >> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK= ! >> http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=103432&bid#0486&dat=121642 >> _______________________________________________ >> Swig-devel mailing list >> Swi...@li... >> https://lists.sourceforge.net/lists/listinfo/swig-devel >> > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log=20 > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat= =3D121642 > _______________________________________________ > Swig-devel mailing list > Swi...@li... > https://lists.sourceforge.net/lists/listinfo/swig-devel |
From: Marcelo M. <mm...@ac...> - 2006-01-19 23:27:30
|
Kevin Ruland wrote: > Marcelo Matus wrote: > >>> Excellent. I did have to stub the %set_constant method because >>> PHP's constant mechanism is type specific. I'm going to leave the >>> current implementation in place. BTW - the current PHP code >>> generator uses "consttab" typemaps - not the constcode typemaps used >>> in UTL. >> >> >> the consttab is really fragile, for that reason in the UTL we use >> the constcode. but, the >> transition is easy, in the current php module you must have some code >> that does the >> translation from consttab to real "const code", either inside >> php4.cxx or in the *.g files. > > > php4.cxx might be handling consttab differently than other modules. I > don't really know. Depending on the type of the constant, you need to > use different PHP methods to declare/define the constant. For > example, the const int a = 42; becomes: > > REGISTER_LONG_CONSTANT("a",42, 0, CONST_CS | CONST_PERSISTENT); > > There are different calls for DOUBLE and STRING constants as well. > > Is there a way to do this with the UTL? if you look at the php/const.i file, the last type has the code needed to define %set_constant, ie: %typemap(consttab) SWIGTYPE *, SWIGTYPE &, SWIGTYPE [] { // This actually registers it as a global variable and constant. I don't like it, but I can't figure out // the zend_constant code... zval *z_var; MAKE_STD_ZVAL(z_var); SWIG_SetPointerZval(z_var, (void*)$value, $1_descriptor, 0); //zend_hash_add(&EG(symbol_table), "$1", strlen("$1")+1, (void *)&z_var,sizeof(zval *), NULL); zend_constant c; c.value = *z_var; zval_copy_ctor(&c.value); size_t len = strlen("$1"); c.name = zend_strndup( "$1", len ); c.name_len = len+1; c.flags = CONST_CS | CONST_PERSISTENT; c.module_number = module_number; zend_register_constant( &c TSRMLS_CC ); } is just matter of replace zval *z_var; MAKE_STD_ZVAL(z_var); SWIG_SetPointerZval(z_var, (void*)$value, $1_descriptor, 0); with the proper argument I guess. Marcelo >>> >>> But this does bring up another question. The SWIG_AsVal( unsigned >>> long ) is identical in implemenation to SWIG_AsVal( long ) (PHP >>> doesn't have the unsigned distinction.) What magic incantation can >>> I use in order to not repeat the fragment? I'm trying this: >>> >>> %fragment( SWIG_AsVal_frag(unsigned long), "header", >>> fragment=SWIG_AsVal_frag(long) { >>> %define_as(SWIG_AsVal_dec(unsigned long), SWIG_AsVal_dec(long) >>> } >>> >> >> except you need to check for the sign. remember that php could not >> support the type, but C++ >> does it. So, just copy the same fragment for 'long' you have and add >> an extra line for checking >> if the number is possitive or not. >> >> > Yes, I thought of this just after sending the email. They are > different because of the little cast needed. > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 > _______________________________________________ > Swig-devel mailing list > Swi...@li... > https://lists.sourceforge.net/lists/listinfo/swig-devel |
From: Kevin R. <kr...@ku...> - 2006-01-19 22:42:39
|
Marcelo Matus wrote: >> Excellent. I did have to stub the %set_constant method because PHP's >> constant mechanism is type specific. I'm going to leave the current >> implementation in place. BTW - the current PHP code generator uses >> "consttab" typemaps - not the constcode typemaps used in UTL. > > the consttab is really fragile, for that reason in the UTL we use the > constcode. but, the > transition is easy, in the current php module you must have some code > that does the > translation from consttab to real "const code", either inside php4.cxx > or in the *.g files. php4.cxx might be handling consttab differently than other modules. I don't really know. Depending on the type of the constant, you need to use different PHP methods to declare/define the constant. For example, the const int a = 42; becomes: REGISTER_LONG_CONSTANT("a",42, 0, CONST_CS | CONST_PERSISTENT); There are different calls for DOUBLE and STRING constants as well. Is there a way to do this with the UTL? >> >> But this does bring up another question. The SWIG_AsVal( unsigned >> long ) is identical in implemenation to SWIG_AsVal( long ) (PHP >> doesn't have the unsigned distinction.) What magic incantation can I >> use in order to not repeat the fragment? I'm trying this: >> >> %fragment( SWIG_AsVal_frag(unsigned long), "header", >> fragment=SWIG_AsVal_frag(long) { >> %define_as(SWIG_AsVal_dec(unsigned long), SWIG_AsVal_dec(long) >> } >> > > except you need to check for the sign. remember that php could not > support the type, but C++ > does it. So, just copy the same fragment for 'long' you have and add > an extra line for checking > if the number is possitive or not. > > Yes, I thought of this just after sending the email. They are different because of the little cast needed. |
From: Marcelo M. <mm...@ac...> - 2006-01-19 22:36:57
|
Please try the CVS version, there are some critical fixes for the runtime library + the import mechanism. If that doesn't fix the problem, we will need you to try to reproduce the problem with a small example we can play with here. thanks, Marcelo Robin Dunn wrote: > Hi, > > I'm upgrading from 1.3.24 to 1.3.27 and have run into a problem with > the new runtime, specifically, I think, with the initialization of the > type info structures. > > Here is the situation: In the _core module I have these classes, > along with a bunch of other stuff: > > class wxObject > class wxEvtHandler : public wxObject > class wxWindow : public wxEvtHandler > > In the _windows module I have this: > > class wxFrame : public wxWindow > > And I have added code to the _core.py module to always import > _windows.py, so both of them are always imported together along with a > few others. (I had to split the "core" into multiple modules because > of the large size of the generated source code files.) > > Now here is the problem. In the _core module there is a method that > returns a wxFrame*, so there is a _swigt__p_wxFrame and > _swigc__p_wxFrame generated for it, but since swig doesn't know about > how it fits in the heirarchy it doesn't specify any typecast functions > for it in _core. In 1.3.24 this didn't cause a problem because it > would get updated when the _windows module was imported. Now > SWIG_InitializeModule is making the assumption that if there is > already a known swig_type for a cast that it doesn't need to update > the type's cast list with that particular cast. So in this case I end > up with the casts for wxEvtHandler not having an entry for wxFrame, > and so calling a function that takes a wxEvtHandler and passing a > wxFrame results in a TypeError. > > So I guess my questions are, is this a known problem? Is there a > convenient workaround? Is there a fix already in CVS? > > I guess that this is case #2 in the comment before the > SWIG_InitializeModule function, but instead of just ignoring the new > cast info as it says I think that there should be the possibility of > updating the cast info because what is already there may be > incomplete. Thoughts? > |
From: Marcelo M. <mm...@ac...> - 2006-01-19 22:35:25
|
Kevin Ruland wrote: > Marcelo Matus wrote: > >> Kevin Ruland wrote: >> >>> >>> Marcelo, >>> >>> Thanks for the help. I have much of it working but not quite >>> completely. There are a couple of things I'd like a little help >>> on. Sorry if some of these seem to ramble a little. >>> >>> 1. I've defined a few fragments to do the underlying conversion. >>> One such example is SWIG_AsVal_long. I had to define it like this: >>> >>> %fragment("SWIG_AsVal_long","header") { >>> SWIGINTERN int >>> SWIG_AsVal_long(zval **obj, long* val) >>> { >>> convert_to_long_ex( obj ); >>> if ( val ) *val = Z_LVAL_PP( obj ); >>> return SWIG_OK; >>> } >>> } >> >> >> ok, the comments: >> >> 1.- in the fragment, the first argument is a string, the fragment >> name, so, you can use >> as you have: >> >> %fragment("SWIG_AsVal_long","header") >> >> or the more portable way: >> >> %fragment(SWIG_AsVal(long),"header") >> >> note that in the second case you don't put the quotes "" since >> SWIG_AsVal(long) is a macro >> that will expand to "SWIG_AsVal_long". This is more portable since in >> the case of std::string, for >> example, SWIG_AsVal(std::string) will expand to something like >> "SWIG_AsVal_std_string", ie >> it will create a valid C id for use as the fragment name, which >> corresponds to the method name. >> >> so, if is not working, maybe you didn't include the swigmacros.swg >> when needed. > > > This was the problem. I didn't notice ruby pulling it in until I did > a bunch of grepping. > >> >> I would try to copy the file structure from ruby. Just look at each >> filename that starts >> as rubyxxx.swg, change it to php4xxx.swg, and follows what it is >> included or >> defined in each file. >> >> So start with ruby.swg, which tells which file will be included, and >> from there >> create a php4.swg and just keep filling/translating the different >> files you find. >> std_string.i also, but not all the others std_xxx.i. >> > Doing this now. > >> 2.- The method seems to always return SWIG_OK, ie, it never complains >> about passing something that is not a long value. Usually, as you can >> see in >> the other languages you have something like: >> >> %fragment(SWIG_AsVal(long),"header") { >> SWIGINTERN int >> SWIG_AsVal_long(zval **obj, long* val) >> { >> if (<obj is a long>) { >> convert_to_long_ex( obj ); >> if ( val ) *val = Z_LVAL_PP( obj ); >> return SWIG_OK; >> } else { >> return SWIG_ERROR; >> } >> } >> } >> >> From here >> >> http://www.dynamicwebpages.de/php/zend.arguments.access.php >> >> it seems you can check the type before forcing the conversion. Or if >> the conversion fails, >> you can maybe detect the event. >> > Yes, I was silently casting every time. I've rewritten the method > slightly to only coerce if necessary and to return the proper value. > > This brings up another question. I noticed a SWIG_CanCastAsInteger > fragment, which does some epsilon test before converting a double to > an integer. PHP does not support unsigned longs or maybe unsigned > ints (depending on the platform's relative size of long and unsigned > int). Are there any helpers to test relative size of the values and > some mechanism to indicate overflow (both positive and negative)? that is done automatically, when you provide the 'long/unsigned long' methods. the UTL generates all the 'int', unsiged int, short, unsigned short, via the '%numeric_slong/%numeric_ulong macros. check the Lib/typemaps/primtypes.swg and fragments.swg to see how is done. > >> >>> 2. What is the %implicitconv_flag? >>> >> is used to implement the new implicit conversion mechanism. Leave it >> alone for a while >> until you finish a working first implementation. But for the records, >> it allows you to do >> something like this, assume you have: >> >> struct A { A(int); >> }; >> int get( const A& a); >> >> then in C++ you can all: >> >> int b = get(1); and C++ translates that to: >> >> int b = get(A(1)); >> >> ie, it calls the implicit conversion between 'int' and 'A' provided >> by the constructor 'A(int)'. >> >> Right now the changes needed to support this (in SWIG_ConvertPtr) are >> only implemented >> for python. >> >>> 3. PHP has a wierd problem. I had to define SWIG_Object to be zval >>> ** because that's the type used for passing arguments into and >>> return values out of php extension functions. Since SWIG_Object is >>> the return value from internal functions like SWIG_From_long, I am >>> faced with an additional memory allocation. SWIG_From_long looks >>> like this: >>> >>> %fragment("SWIG_From_long","header") { >>> SWIGINTERNINLINE zval ** >>> SWIG_From_long( long val ) >>> { >>> zval **o = (zval**) emalloc(sizeof(zval**)); >>> MAKE_STD_ZVAL(*o); >>> ZVAL_LONG(*o,val); >>> return o; >>> } >>> } >>> >>> But eventually this emalloc needs to be efree'd before the wrapped >>> method exits. I noticed that the %set_output and %append_output >>> functions are called when returning values. I've slipped the efree >>> into these two methods. What I don't know is if these two methods >>> are always called with the return value of the SWIG_From_XXX methods. >> >> >> The UTL uses always either %set_output, %append_output or >> %set_constant to finish a typemap, >> so you can put it there with no problems. Other languages, as >> Tcl/Perl, also need to put some >> "finishing" code in there, and the mechanism is working fine with them. >> > Excellent. I did have to stub the %set_constant method because PHP's > constant mechanism is type specific. I'm going to leave the current > implementation in place. BTW - the current PHP code generator uses > "consttab" typemaps - not the constcode typemaps used in UTL. the consttab is really fragile, for that reason in the UTL we use the constcode. but, the transition is easy, in the current php module you must have some code that does the translation from consttab to real "const code", either inside php4.cxx or in the *.g files. >>> >>> Another idea I have is to not allocate a zval ** but instead use an >>> abusive cast. The SWIG_From_long method would then look like this: >>> >>> %fragment("SWIG_From_long","header") { >>> SWIGINTERNINLINE zval ** >>> SWIG_From_long( long val ) >>> { >>> zval *o; >>> MAKE_STD_ZVAL(o); >>> ZVAL_LONG(o,val); >>> return %static_cast(zval**,o); >>> } >>> } >>> >>> And the %set_output and %append_output would then undo the cast. >>> This a better solution because it eliminates an unnecessary >>> malloc/free, but in turn looks quite a bit uglier because of the >>> casts. Of course, it also requires that %set_output and >>> %append_output are always called. >>> >> >> you can also explore with something like this: >> >> %fragment(SWIG_From(long),"header") { >> %define_as (SWIG_From(long)(val), ZVAL_LONG(o,val)) >> } >> >> which is similar to what we have in some cases in python: >> >> %fragment(SWIG_From_frag(long),"header") { >> %define_as(SWIG_From_dec(long), PyInt_FromLong) >> } >> >> but you need to be sure to use consistent name 'o' and 'val' everywhere. >> > I gave this a shot, but it didn't quite work. I seemed to be missing > a variable. > > But this does bring up another question. The SWIG_AsVal( unsigned > long ) is identical in implemenation to SWIG_AsVal( long ) (PHP > doesn't have the unsigned distinction.) What magic incantation can I > use in order to not repeat the fragment? I'm trying this: > > %fragment( SWIG_AsVal_frag(unsigned long), "header", > fragment=SWIG_AsVal_frag(long) { > %define_as(SWIG_AsVal_dec(unsigned long), SWIG_AsVal_dec(long) > } > except you need to check for the sign. remember that php could not support the type, but C++ does it. So, just copy the same fragment for 'long' you have and add an extra line for checking if the number is possitive or not. > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 > _______________________________________________ > Swig-devel mailing list > Swi...@li... > https://lists.sourceforge.net/lists/listinfo/swig-devel |
From: Robin D. <ro...@al...> - 2006-01-19 22:23:41
|
Hi, I'm upgrading from 1.3.24 to 1.3.27 and have run into a problem with the new runtime, specifically, I think, with the initialization of the type info structures. Here is the situation: In the _core module I have these classes, along with a bunch of other stuff: class wxObject class wxEvtHandler : public wxObject class wxWindow : public wxEvtHandler In the _windows module I have this: class wxFrame : public wxWindow And I have added code to the _core.py module to always import _windows.py, so both of them are always imported together along with a few others. (I had to split the "core" into multiple modules because of the large size of the generated source code files.) Now here is the problem. In the _core module there is a method that returns a wxFrame*, so there is a _swigt__p_wxFrame and _swigc__p_wxFrame generated for it, but since swig doesn't know about how it fits in the heirarchy it doesn't specify any typecast functions for it in _core. In 1.3.24 this didn't cause a problem because it would get updated when the _windows module was imported. Now SWIG_InitializeModule is making the assumption that if there is already a known swig_type for a cast that it doesn't need to update the type's cast list with that particular cast. So in this case I end up with the casts for wxEvtHandler not having an entry for wxFrame, and so calling a function that takes a wxEvtHandler and passing a wxFrame results in a TypeError. So I guess my questions are, is this a known problem? Is there a convenient workaround? Is there a fix already in CVS? I guess that this is case #2 in the comment before the SWIG_InitializeModule function, but instead of just ignoring the new cast info as it says I think that there should be the possibility of updating the cast info because what is already there may be incomplete. Thoughts? -- Robin Dunn Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython! |
From: Kevin R. <kr...@ku...> - 2006-01-19 22:08:49
|
Marcelo Matus wrote: > Kevin Ruland wrote: > >> >> Marcelo, >> >> Thanks for the help. I have much of it working but not quite >> completely. There are a couple of things I'd like a little help on. >> Sorry if some of these seem to ramble a little. >> >> 1. I've defined a few fragments to do the underlying conversion. One >> such example is SWIG_AsVal_long. I had to define it like this: >> >> %fragment("SWIG_AsVal_long","header") { >> SWIGINTERN int >> SWIG_AsVal_long(zval **obj, long* val) >> { >> convert_to_long_ex( obj ); >> if ( val ) *val = Z_LVAL_PP( obj ); >> return SWIG_OK; >> } >> } > > ok, the comments: > > 1.- in the fragment, the first argument is a string, the fragment > name, so, you can use > as you have: > > %fragment("SWIG_AsVal_long","header") > > or the more portable way: > > %fragment(SWIG_AsVal(long),"header") > > note that in the second case you don't put the quotes "" since > SWIG_AsVal(long) is a macro > that will expand to "SWIG_AsVal_long". This is more portable since in > the case of std::string, for > example, SWIG_AsVal(std::string) will expand to something like > "SWIG_AsVal_std_string", ie > it will create a valid C id for use as the fragment name, which > corresponds to the method name. > > so, if is not working, maybe you didn't include the swigmacros.swg > when needed. This was the problem. I didn't notice ruby pulling it in until I did a bunch of grepping. > > I would try to copy the file structure from ruby. Just look at each > filename that starts > as rubyxxx.swg, change it to php4xxx.swg, and follows what it is > included or > defined in each file. > > So start with ruby.swg, which tells which file will be included, and > from there > create a php4.swg and just keep filling/translating the different > files you find. > std_string.i also, but not all the others std_xxx.i. > Doing this now. > 2.- The method seems to always return SWIG_OK, ie, it never complains > about passing something that is not a long value. Usually, as you can > see in > the other languages you have something like: > > %fragment(SWIG_AsVal(long),"header") { > SWIGINTERN int > SWIG_AsVal_long(zval **obj, long* val) > { > if (<obj is a long>) { > convert_to_long_ex( obj ); > if ( val ) *val = Z_LVAL_PP( obj ); > return SWIG_OK; > } else { > return SWIG_ERROR; > } > } > } > > From here > > http://www.dynamicwebpages.de/php/zend.arguments.access.php > > it seems you can check the type before forcing the conversion. Or if > the conversion fails, > you can maybe detect the event. > Yes, I was silently casting every time. I've rewritten the method slightly to only coerce if necessary and to return the proper value. This brings up another question. I noticed a SWIG_CanCastAsInteger fragment, which does some epsilon test before converting a double to an integer. PHP does not support unsigned longs or maybe unsigned ints (depending on the platform's relative size of long and unsigned int). Are there any helpers to test relative size of the values and some mechanism to indicate overflow (both positive and negative)? > >> 2. What is the %implicitconv_flag? >> > is used to implement the new implicit conversion mechanism. Leave it > alone for a while > until you finish a working first implementation. But for the records, > it allows you to do > something like this, assume you have: > > struct A { A(int); > }; > int get( const A& a); > > then in C++ you can all: > > int b = get(1); > and C++ translates that to: > > int b = get(A(1)); > > ie, it calls the implicit conversion between 'int' and 'A' provided by > the constructor 'A(int)'. > > Right now the changes needed to support this (in SWIG_ConvertPtr) are > only implemented > for python. > >> 3. PHP has a wierd problem. I had to define SWIG_Object to be zval >> ** because that's the type used for passing arguments into and return >> values out of php extension functions. Since SWIG_Object is the >> return value from internal functions like SWIG_From_long, I am faced >> with an additional memory allocation. SWIG_From_long looks like this: >> >> %fragment("SWIG_From_long","header") { >> SWIGINTERNINLINE zval ** >> SWIG_From_long( long val ) >> { >> zval **o = (zval**) emalloc(sizeof(zval**)); >> MAKE_STD_ZVAL(*o); >> ZVAL_LONG(*o,val); >> return o; >> } >> } >> >> But eventually this emalloc needs to be efree'd before the wrapped >> method exits. I noticed that the %set_output and %append_output >> functions are called when returning values. I've slipped the efree >> into these two methods. What I don't know is if these two methods >> are always called with the return value of the SWIG_From_XXX methods. > > The UTL uses always either %set_output, %append_output or > %set_constant to finish a typemap, > so you can put it there with no problems. Other languages, as > Tcl/Perl, also need to put some > "finishing" code in there, and the mechanism is working fine with them. > Excellent. I did have to stub the %set_constant method because PHP's constant mechanism is type specific. I'm going to leave the current implementation in place. BTW - the current PHP code generator uses "consttab" typemaps - not the constcode typemaps used in UTL. >> >> Another idea I have is to not allocate a zval ** but instead use an >> abusive cast. The SWIG_From_long method would then look like this: >> >> %fragment("SWIG_From_long","header") { >> SWIGINTERNINLINE zval ** >> SWIG_From_long( long val ) >> { >> zval *o; >> MAKE_STD_ZVAL(o); >> ZVAL_LONG(o,val); >> return %static_cast(zval**,o); >> } >> } >> >> And the %set_output and %append_output would then undo the cast. >> This a better solution because it eliminates an unnecessary >> malloc/free, but in turn looks quite a bit uglier because of the >> casts. Of course, it also requires that %set_output and >> %append_output are always called. >> > > you can also explore with something like this: > > %fragment(SWIG_From(long),"header") { > %define_as (SWIG_From(long)(val), ZVAL_LONG(o,val)) > } > > which is similar to what we have in some cases in python: > > %fragment(SWIG_From_frag(long),"header") { > %define_as(SWIG_From_dec(long), PyInt_FromLong) > } > > but you need to be sure to use consistent name 'o' and 'val' everywhere. > I gave this a shot, but it didn't quite work. I seemed to be missing a variable. But this does bring up another question. The SWIG_AsVal( unsigned long ) is identical in implemenation to SWIG_AsVal( long ) (PHP doesn't have the unsigned distinction.) What magic incantation can I use in order to not repeat the fragment? I'm trying this: %fragment( SWIG_AsVal_frag(unsigned long), "header", fragment=SWIG_AsVal_frag(long) { %define_as(SWIG_AsVal_dec(unsigned long), SWIG_AsVal_dec(long) } |
From: Marcelo M. <mm...@ac...> - 2006-01-19 20:32:49
|
Kevin Ruland wrote: > > Marcelo, > > Thanks for the help. I have much of it working but not quite > completely. There are a couple of things I'd like a little help on. > Sorry if some of these seem to ramble a little. > > 1. I've defined a few fragments to do the underlying conversion. One > such example is SWIG_AsVal_long. I had to define it like this: > > %fragment("SWIG_AsVal_long","header") { > SWIGINTERN int > SWIG_AsVal_long(zval **obj, long* val) > { > convert_to_long_ex( obj ); > if ( val ) *val = Z_LVAL_PP( obj ); > return SWIG_OK; > } > } ok, the comments: 1.- in the fragment, the first argument is a string, the fragment name, so, you can use as you have: %fragment("SWIG_AsVal_long","header") or the more portable way: %fragment(SWIG_AsVal(long),"header") note that in the second case you don't put the quotes "" since SWIG_AsVal(long) is a macro that will expand to "SWIG_AsVal_long". This is more portable since in the case of std::string, for example, SWIG_AsVal(std::string) will expand to something like "SWIG_AsVal_std_string", ie it will create a valid C id for use as the fragment name, which corresponds to the method name. so, if is not working, maybe you didn't include the swigmacros.swg when needed. I would try to copy the file structure from ruby. Just look at each filename that starts as rubyxxx.swg, change it to php4xxx.swg, and follows what it is included or defined in each file. So start with ruby.swg, which tells which file will be included, and from there create a php4.swg and just keep filling/translating the different files you find. std_string.i also, but not all the others std_xxx.i. 2.- The method seems to always return SWIG_OK, ie, it never complains about passing something that is not a long value. Usually, as you can see in the other languages you have something like: %fragment(SWIG_AsVal(long),"header") { SWIGINTERN int SWIG_AsVal_long(zval **obj, long* val) { if (<obj is a long>) { convert_to_long_ex( obj ); if ( val ) *val = Z_LVAL_PP( obj ); return SWIG_OK; } else { return SWIG_ERROR; } } } From here http://www.dynamicwebpages.de/php/zend.arguments.access.php it seems you can check the type before forcing the conversion. Or if the conversion fails, you can maybe detect the event. The main rules are, since SWIG_AsVal is using for checking the type (when val == 0), you should not force an operation that modifies the object type or the return value if val == 0. If you accept 'cast' conversions as part of the language, ie, you accept 1.0 as a long value, you should do something like in perl: %fragment(SWIG_AsVal_frag(bool),"header", fragment="SWIG_CanCastAsInteger") { SWIGINTERN int SWIG_AsVal_dec(bool)(SV *obj, bool* val) { if (obj == &PL_sv_yes) { if (val) *val = true; return SWIG_OK; } else if (obj == &PL_sv_no) { if (val) *val = false; return SWIG_OK; } else { if (val) *val = SvTRUE(obj) ? true: false; return SWIG_AddCast(SWIG_OK); } return SWIG_TypeError; } } in this case, when the object are the 'pure' bool values PL_sv_yes or PL_sv_no, we return SWIG_OK. If not, since any object in perl can be considered a boolean, we force a kind of conversion using SvTRUE(obj), but we return SWIG_AddCast(SWIG_OK) instead. This tell swig that is an acceptable type, but a casting conversion occurred. Then we can dispatch this methods, for example, properly: int foo(bool); -> always accepts anything int foo(double); -> only floats foo(1) -> foo(bool); foo(3.5) -> foo(double); foo("hello") -> foo(bool); that is of course, assuming your module support overloading. > > Instead of the much prettier (and consistent with the other 3 languages): > > %fragment(SWIG_AsVal_frag(long),"header") { > SWIGINTERN int > SWIG_AsVal_dec(long)(Tcl_Obj *obj, long* val) > { > ... } > > (from tcl). For some reason when I switch from "SWIG_AsVal_long" to > SWIG_AsVal_frag(long), swig complains about it with: > > Error: syntax error on input(1). > > Am I missing something? > yes, probably the inclusion of swigmacros.swg in the right place. See above. > 2. What is the %implicitconv_flag? > is used to implement the new implicit conversion mechanism. Leave it alone for a while until you finish a working first implementation. But for the records, it allows you to do something like this, assume you have: struct A { A(int); }; int get( const A& a); then in C++ you can all: int b = get(1); and C++ translates that to: int b = get(A(1)); ie, it calls the implicit conversion between 'int' and 'A' provided by the constructor 'A(int)'. Right now the changes needed to support this (in SWIG_ConvertPtr) are only implemented for python. > 3. PHP has a wierd problem. I had to define SWIG_Object to be zval ** > because that's the type used for passing arguments into and return > values out of php extension functions. Since SWIG_Object is the > return value from internal functions like SWIG_From_long, I am faced > with an additional memory allocation. SWIG_From_long looks like this: > > %fragment("SWIG_From_long","header") { > SWIGINTERNINLINE zval ** > SWIG_From_long( long val ) > { > zval **o = (zval**) emalloc(sizeof(zval**)); > MAKE_STD_ZVAL(*o); > ZVAL_LONG(*o,val); > return o; > } > } > > But eventually this emalloc needs to be efree'd before the wrapped > method exits. I noticed that the %set_output and %append_output > functions are called when returning values. I've slipped the efree > into these two methods. What I don't know is if these two methods are > always called with the return value of the SWIG_From_XXX methods. The UTL uses always either %set_output, %append_output or %set_constant to finish a typemap, so you can put it there with no problems. Other languages, as Tcl/Perl, also need to put some "finishing" code in there, and the mechanism is working fine with them. > > Another idea I have is to not allocate a zval ** but instead use an > abusive cast. The SWIG_From_long method would then look like this: > > %fragment("SWIG_From_long","header") { > SWIGINTERNINLINE zval ** > SWIG_From_long( long val ) > { > zval *o; > MAKE_STD_ZVAL(o); > ZVAL_LONG(o,val); > return %static_cast(zval**,o); > } > } > > And the %set_output and %append_output would then undo the cast. This > a better solution because it eliminates an unnecessary malloc/free, > but in turn looks quite a bit uglier because of the casts. Of course, > it also requires that %set_output and %append_output are always called. > you can also explore with something like this: %fragment(SWIG_From(long),"header") { %define_as (SWIG_From(long)(val), ZVAL_LONG(o,val)) } which is similar to what we have in some cases in python: %fragment(SWIG_From_frag(long),"header") { %define_as(SWIG_From_dec(long), PyInt_FromLong) } but you need to be sure to use consistent name 'o' and 'val' everywhere. > > > > > > > Marcelo Matus wrote: > >> alloc is an input/output parameter right now, but probably this will >> change in a near >> future and alloc will be only an input parameter. >> >> alloc as input parameter tells SWIG_AsCharPtrAndSize if you would >> like to get >> back a new allocated array (SWIG_NEWOBJ) or just a pointer to the >> original string >> (SWIG_OLDOBJ). If you pass '0', you really don't care if is a new or >> old object, >> and SWIG_AsCharPtrAndSize should decide the 'default' behavior. >> >> Note that what you ask for a SWIG_OLDOBJ, it is not necessary what >> you get, >> some languages still need to return a new allocated array, and that >> is almost >> always the case for wchar_t arrays. So, the alloc parameter is only >> saying what would >> you like. >> >> As an output parameter, alloc tells if the returned pointer is a new >> allocated array >> (SWIG_NEWOBJ) or just a pointer to an 'old' or language internal >> array (SWIG_OLDOBJ). >> Again, the returning value could be different for what you asked, for >> example if you >> ask for a SWIG_OLDOBJ, and that is not possible, you will get back a >> SWIG_NEWOBJ >> result. But if you ask for a SWIG_NEWOBJ, you always need to return a >> SWIG_NEWOBJ, >> making a new array copy if necessary (you can use the %new_copy_array >> macro to do >> that ,since in C you need to use malloc, in C++ new). >> >> that is the part that probably we will change soon, the alloc will be >> only an input parameter, >> and the output will be pass back in the return value as a mask, as is >> done now in the rest >> of the UTL. >> >> also look at the ruby/rubystrings.swg. tcl/tclstrings.swg and >> perl/perlstrings.swg >> which are clearer implementations, since with python we have to do a >> little more. >> > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 > _______________________________________________ > Swig-devel mailing list > Swi...@li... > https://lists.sourceforge.net/lists/listinfo/swig-devel |
From: Kevin R. <kr...@ku...> - 2006-01-19 19:34:09
|
Marcelo, Thanks for the help. I have much of it working but not quite completely. There are a couple of things I'd like a little help on. Sorry if some of these seem to ramble a little. 1. I've defined a few fragments to do the underlying conversion. One such example is SWIG_AsVal_long. I had to define it like this: %fragment("SWIG_AsVal_long","header") { SWIGINTERN int SWIG_AsVal_long(zval **obj, long* val) { convert_to_long_ex( obj ); if ( val ) *val = Z_LVAL_PP( obj ); return SWIG_OK; } } Instead of the much prettier (and consistent with the other 3 languages): %fragment(SWIG_AsVal_frag(long),"header") { SWIGINTERN int SWIG_AsVal_dec(long)(Tcl_Obj *obj, long* val) { ... } (from tcl). For some reason when I switch from "SWIG_AsVal_long" to SWIG_AsVal_frag(long), swig complains about it with: Error: syntax error on input(1). Am I missing something? 2. What is the %implicitconv_flag? 3. PHP has a wierd problem. I had to define SWIG_Object to be zval ** because that's the type used for passing arguments into and return values out of php extension functions. Since SWIG_Object is the return value from internal functions like SWIG_From_long, I am faced with an additional memory allocation. SWIG_From_long looks like this: %fragment("SWIG_From_long","header") { SWIGINTERNINLINE zval ** SWIG_From_long( long val ) { zval **o = (zval**) emalloc(sizeof(zval**)); MAKE_STD_ZVAL(*o); ZVAL_LONG(*o,val); return o; } } But eventually this emalloc needs to be efree'd before the wrapped method exits. I noticed that the %set_output and %append_output functions are called when returning values. I've slipped the efree into these two methods. What I don't know is if these two methods are always called with the return value of the SWIG_From_XXX methods. Another idea I have is to not allocate a zval ** but instead use an abusive cast. The SWIG_From_long method would then look like this: %fragment("SWIG_From_long","header") { SWIGINTERNINLINE zval ** SWIG_From_long( long val ) { zval *o; MAKE_STD_ZVAL(o); ZVAL_LONG(o,val); return %static_cast(zval**,o); } } And the %set_output and %append_output would then undo the cast. This a better solution because it eliminates an unnecessary malloc/free, but in turn looks quite a bit uglier because of the casts. Of course, it also requires that %set_output and %append_output are always called. Marcelo Matus wrote: > alloc is an input/output parameter right now, but probably this will > change in a near > future and alloc will be only an input parameter. > > alloc as input parameter tells SWIG_AsCharPtrAndSize if you would like > to get > back a new allocated array (SWIG_NEWOBJ) or just a pointer to the > original string > (SWIG_OLDOBJ). If you pass '0', you really don't care if is a new or > old object, > and SWIG_AsCharPtrAndSize should decide the 'default' behavior. > > Note that what you ask for a SWIG_OLDOBJ, it is not necessary what you > get, > some languages still need to return a new allocated array, and that is > almost > always the case for wchar_t arrays. So, the alloc parameter is only > saying what would > you like. > > As an output parameter, alloc tells if the returned pointer is a new > allocated array > (SWIG_NEWOBJ) or just a pointer to an 'old' or language internal > array (SWIG_OLDOBJ). > Again, the returning value could be different for what you asked, for > example if you > ask for a SWIG_OLDOBJ, and that is not possible, you will get back a > SWIG_NEWOBJ > result. But if you ask for a SWIG_NEWOBJ, you always need to return a > SWIG_NEWOBJ, > making a new array copy if necessary (you can use the %new_copy_array > macro to do > that ,since in C you need to use malloc, in C++ new). > > that is the part that probably we will change soon, the alloc will be > only an input parameter, > and the output will be pass back in the return value as a mask, as is > done now in the rest > of the UTL. > > also look at the ruby/rubystrings.swg. tcl/tclstrings.swg and > perl/perlstrings.swg > which are clearer implementations, since with python we have to do a > little more. > |
From: Marcelo M. <mm...@ac...> - 2006-01-19 18:18:41
|
William S Fulton wrote: > > Marcelo Matus wrote: > >> For that reason is 'disabled' unless you use --with-rxspencer. Is=20 >> there for >> the people who want to try it, but is willing to take some extra effor= t, >> such as installing the library and recompiling swig. >> >> The problem is that the CVS version is kind of difficult to=20 >> grab/compile/test >> from the Windows world, and people just wait for oficial release to te= st >> swig. >> all=20 > > Are you thinking that the windows release should have this library=20 > compiled in then? > >> And as in this feature we need a lot of feedback and ideas, I think >> is better to give it a little more exposure than just been in CVS. >> >> Marcelo >> > > I'm also not sure about this change just before release. If this=20 > library has to be specifically installed at configure time and it=20 > doesn't come with big distributions, it means few people are going to=20 > use it and if it is going to be replaced in the next version of SWIG=20 > with something else, then I can't see the point of putting it in,=20 > especially if we are going to start working on the next version in a=20 > few weeks time. Or have we chosen this as the definitive regex library=20 > for the future now? of course this solution is not a definitive one, and I bet the library=20 is not installed as default in many distributions, as seems to be the case for the other regexp libraries=20 proposed (pcre, boost, etc). I would like to have this test bed out for the next release for the=20 people who want to test it and contribute with ideas, and maybe test some large applications with it. So, it is not direct to use, it is disable by default, and you need to=20 install the rxspencer library, but with all, at least it will be a little much easier to compile than=20 getting the CVS version, which seems to be a recurrent issue for some users, And while the rxspencer is not necessary the final one to be used, it is=20 old enough to compile almost everywhere, there is a version for windows that is part=20 of cygwin, is posix, it compiles in any unix system with a simple C compiler, etc, e= tc. And between us, the implementation of the regexp was very simple after the modifications made to %rename, probably 50 lines in all, very well=20 isolated, and when disabled, it doesn't interfere with swig's compilation or execut= ion at all, the same as the 'popen/command' encoder. =20 > > Personally, I think we should concentrate on fixing the current=20 > problems that are preventing release before working on new features.=20 > Right now I have plenty of new things I'd like to work on, but instead=20 > have been concentrating on the drudge work getting SWIG to work again=20 > on multiple platforms :(. The Windows problems are holding up the=20 > release and there seem to be too many of them for the amount of free=20 > time I have. Has anyone had a chance to test on any platforms other=20 > than linux, eg Solaris? > I'll try to relog to the sourceforge cluster farm to recompile in there. > I was also wondering about the simple renaming mechanism that has=20 > recently gone in and how it fits in with the regex handling? Does it=20 > provide something that regex won't handle or is it complementary in=20 > some way? > is complementary, and a "simple" extension to %rename, but it covers a=20 lot of issues that we can't solve with the new rename. For example, if you have a library=20 with a prefix in C/C++, as GSL_, when you write a module, you would like to get ride of the=20 prefix, since already you have a module with that name: import GSL a =3D GSL.GSL_foo(1) with the new regexp you can rename all the methods doing this: %rename("%(rxspencer:[GSL_(.*)][@1])s",%$isfunction) ""; and you call them as: import GSL a =3D GSL.foo(1) > William > > >> >> Jason Stewart wrote: >> >>> Hi Marcelo, >>> >>> On 1/17/06, Marcelo Matus <mm...@ac...> wrote: >>> =20 >>> >>>> I think it is important to have this initial implementation out=20 >>>> with the >>>> next release >>>> to let people try it, test it and see how it fit with the %rename >>>> directive, and if more >>>> options are needed. >>>> =20 >>> >>> >>> This is a pretty major 'feature' that's going in awfully late in the >>> release, don't you think? We haven't had a lot of time to test it out. >>> Isn't it likely to generate a lot of issues? >>> >>> Cheers, jas. >>> >>> >>> ------------------------------------------------------- >>> This SF.net email is sponsored by: Splunk Inc. Do you grep through=20 >>> log files >>> for problems? Stop! Download the new AJAX search engine that makes >>> searching your log files as easy as surfing the web. DOWNLOAD SPLUN= K! >>> http://sel.as-us.falkag.net/sel?cmd=FFk&kid=103432&bid#0486&dat=12164= 2 >>> _______________________________________________ >>> Swig-devel mailing list >>> Swi...@li... >>> https://lists.sourceforge.net/lists/listinfo/swig-devel >>> >>> =20 >>> >> >> >> >> ------------------------------------------------------- >> This SF.net email is sponsored by: Splunk Inc. Do you grep through=20 >> log files >> for problems? Stop! Download the new AJAX search engine that makes >> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK= ! >> http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=103432&bid#0486&dat=121642 >> _______________________________________________ >> Swig-devel mailing list >> Swi...@li... >> https://lists.sourceforge.net/lists/listinfo/swig-devel >> > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log=20 > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat= =3D121642 > _______________________________________________ > Swig-devel mailing list > Swi...@li... > https://lists.sourceforge.net/lists/listinfo/swig-devel |
From: Mathieu B. <ma...@ar...> - 2006-01-19 18:08:17
|
On Thu, 19 Jan 2006, Jason Stewart wrote: > On 1/19/06, William S Fulton <ws...@fu...> wrote: > > Took a look. C++ code is being generated for C wrappers. Within any > > scope, gcc accepts declarations after code which seems just plain wrong > > to me. The -pedantic flag is needed to show the problem, eg it might be > > worth fixing all the problems with this: >=20 > Ah. Ok. So C++ standard doesn't accept that? Nice to know. Did it for > years with g++ and then with Java. Better stop. It's just the C standards up to and including C 1989. In C 1999 you can,=20 but VC++ doesn't support C 1999 (apparently). C++ has always accepted it=20 since 1983 or so. It's just that if you have C code that you really want=20 to compile in C mode for some reason, then the C mode of some compilers=20 requires that you do declarations the old way. Now, I'm not sure why the C mode is required... I don't know enough SWIG. _ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - t=E9l:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montr=E9al QC Canada |
From: Marcelo M. <mm...@ac...> - 2006-01-19 17:48:10
|
Jason Stewart wrote: >Hey All, > >On 1/19/06, William S Fulton <ws...@fu...> wrote: > > =20 > >>I'm also not sure about this change just before release. >> =20 >> > >I don't mean to be a wet blanket here - 'specially since Marcelo has >been doing so much work for the project. But it seems like a *lot* of >changes have been made in a short time - but not a lot of discussion >about the proposed changes before hand. > >A quick check through debian yields: > > * http://www.boost.org/libs/regex/ > > * libpcre3 > > * libtre4 > >as possibilities already part of the distro. > >I guess Marcelo is suggesting that we package the library as part of SWI= G? > >Cheers, jas. > > > =20 > yes, in the last thread about the regexp, we agreed that the final=20 implementation would probably require swig to ship the regexp library as part of the source=20 code, to simplify the building process. but since that would probably require a lot of changes in the building=20 system (autoconf/configure/makefiles), the election and inclusion of the final regexp library was posponed to=20 the next release. in the meantime, for the interested, the external rxspencer gives us a=20 simple test bed to test the %rename syntax and functionality. Marcelo >------------------------------------------------------- >This SF.net email is sponsored by: Splunk Inc. Do you grep through log f= iles >for problems? Stop! Download the new AJAX search engine that makes >searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >http://sel.as-us.falkag.net/sel?cmd=FFk&kid=103432&bid#0486&dat=121642 >_______________________________________________ >Swig-devel mailing list >Swi...@li... >https://lists.sourceforge.net/lists/listinfo/swig-devel > > =20 > |
From: Marcelo M. <mm...@ac...> - 2006-01-19 16:05:36
|
Jason Stewart wrote: >Hey, > >On 1/19/06, William S Fulton <ws...@fu...> wrote: > > =20 > >>Took a look. C++ code is being generated for C wrappers. Within any >>scope, gcc accepts declarations after code which seems just plain wrong >>to me. The -pedantic flag is needed to show the problem, eg it might be >>worth fixing all the problems with this: >> =20 >> > >Ah. Ok. So C++ standard doesn't accept that? Nice to know. Did it for >years with g++ and then with Java. Better stop. > > =20 > it is fine in C++, it is not in C. >>make -k check CFLAGS=3D'-Wall -pedantic -ansi -Wno-long-long' >>CXXFLAGS=3D'-Wall -pedantic -ansi -O2 -Wno-long-long' >> =20 >> > >OK. > >So I take it problem is fixed? > >Cheers, jas. > > =20 > I fixed them last night, I hope. >------------------------------------------------------- >This SF.net email is sponsored by: Splunk Inc. Do you grep through log f= iles >for problems? Stop! Download the new AJAX search engine that makes >searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >http://sel.as-us.falkag.net/sel?cmd=FFk&kid=103432&bid#0486&dat=121642 >_______________________________________________ >Swig-devel mailing list >Swi...@li... >https://lists.sourceforge.net/lists/listinfo/swig-devel > > =20 > |
From: Jason S. <jas...@gm...> - 2006-01-19 12:31:00
|
Hey All, On 1/19/06, William S Fulton <ws...@fu...> wrote: > I'm also not sure about this change just before release. I don't mean to be a wet blanket here - 'specially since Marcelo has been doing so much work for the project. But it seems like a *lot* of changes have been made in a short time - but not a lot of discussion about the proposed changes before hand. A quick check through debian yields: * http://www.boost.org/libs/regex/ * libpcre3 * libtre4 as possibilities already part of the distro. I guess Marcelo is suggesting that we package the library as part of SWIG? Cheers, jas. |
From: Jason S. <jas...@gm...> - 2006-01-19 12:18:29
|
Hey, On 1/19/06, William S Fulton <ws...@fu...> wrote: > Took a look. C++ code is being generated for C wrappers. Within any > scope, gcc accepts declarations after code which seems just plain wrong > to me. The -pedantic flag is needed to show the problem, eg it might be > worth fixing all the problems with this: Ah. Ok. So C++ standard doesn't accept that? Nice to know. Did it for years with g++ and then with Java. Better stop. > make -k check CFLAGS=3D'-Wall -pedantic -ansi -Wno-long-long' > CXXFLAGS=3D'-Wall -pedantic -ansi -O2 -Wno-long-long' OK. So I take it problem is fixed? Cheers, jas. |
From: Jason S. <jas...@gm...> - 2006-01-19 12:00:16
|
hey all, On 1/19/06, Amaury Forgeotdarc <Ama...@gl...> wrote: > I propose to use the 'diff -u' (unified) option, which give more compact > results. Looks good to me. There are actually some other nice options that could be used - especially when diffs get really large. If anyone's interested I could check what is being used on the apache mailing lists. There was a similar discussion there a year ago. Cheers, jas. |
From: Amaury F. <Ama...@gl...> - 2006-01-19 09:32:39
|
Hello, I don't know how many people have subscribed to the swig-cvs mailing list, which records any modification of the source code. I find it very useful, and IMO is the best way to follow the "bleeding edge" of Swig development. I have a suggestion for improving it: The diffs are sometimes long and difficult to read. By experience with other mailing lists (python-checkins, to name it),=20 I propose to use the 'diff -u' (unified) option, which give more compact results. For example, instead of: *************** *** 848,855 **** /* Now write a function to evaluate the variable */ =20 ! Printf(getf->def,"SWIGCLASS_STATIC int %s(pTHX_ SV *sv, MAGIC *mg) {\n", val_name); Printv(getf->code, tab4, "MAGIC_PPERL\n", - tab4, "mg =3D mg;\n", NIL); =20 --- 846,852 ---- /* Now write a function to evaluate the variable */ =20 ! Printf(getf->def,"SWIGCLASS_STATIC int %s(pTHX_ SV *sv, MAGIC *SWIGUNUSEDPARM(mg)) {\n", val_name); Printv(getf->code, tab4, "MAGIC_PPERL\n", NIL); Diff -u would have given: @@ -848,8 +846,7 @@ /* Now write a function to evaluate the variable */ =20 - Printf(getf->def,"SWIGCLASS_STATIC int %s(pTHX_ SV *sv, MAGIC *mg) {\n", val_name); + Printf(getf->def,"SWIGCLASS_STATIC int %s(pTHX_ SV *sv, MAGIC *SWIGUNUSEDPARM(mg)) {\n", val_name); Printv(getf->code, tab4, "MAGIC_PPERL\n", - tab4, "mg =3D mg;\n", NIL); I find this easier to read and understand. Do others have the same feeling? --=20 Amaury Forgeot d'Arc Ubix Development www.ubitrade.com |
From: Marcelo M. <mm...@ac...> - 2006-01-19 05:03:22
|
Oh no, that is no a change that need to be documented, it was an error. Now is fixed, thanks. John Lenz wrote: >Some change recently caused the chicken global_vars.cpptest to segfault >when running the test. Digging a little deeper, I see that the >feature:immutable flag is being set, and then chicken.cxx does not export >the code to set the variable. You can see it by the following short test >file > >%inline %{ >struct A {}; >const A *cap; >%} > >In older versions of SWIG, the feature:immutable flag would NOT be set on >the cap variable, but in the current CVS version of SWIG it is. I tried >to grep for places where the immutable flag is getting set, but... Note >that "const A *cap" means cap is a modifiable pointer to a constant object >A, wheras "A* const cap" is actually a constant pointer to a modifiable >object (and so the feature:immutable flag should really be set). > >"const A* const cap" is for a constant pointer to a constant object >(see http://www.google.com/search?q=const+pointer+c%2B%2B skip the first >two results) > >I also couldn't see any policy change in the CHANGES.current file >either... so if we are going to change this behavior, it should probably >be documented. > >John > > > >------------------------------------------------------- >This SF.net email is sponsored by: Splunk Inc. Do you grep through log files >for problems? Stop! Download the new AJAX search engine that makes >searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 >_______________________________________________ >Swig-devel mailing list >Swi...@li... >https://lists.sourceforge.net/lists/listinfo/swig-devel > > |
From: John L. <le...@cs...> - 2006-01-19 03:18:32
|
Some change recently caused the chicken global_vars.cpptest to segfault when running the test. Digging a little deeper, I see that the feature:immutable flag is being set, and then chicken.cxx does not export the code to set the variable. You can see it by the following short test file %inline %{ struct A {}; const A *cap; %} In older versions of SWIG, the feature:immutable flag would NOT be set on the cap variable, but in the current CVS version of SWIG it is. I tried to grep for places where the immutable flag is getting set, but... Note that "const A *cap" means cap is a modifiable pointer to a constant object A, wheras "A* const cap" is actually a constant pointer to a modifiable object (and so the feature:immutable flag should really be set). "const A* const cap" is for a constant pointer to a constant object (see http://www.google.com/search?q=const+pointer+c%2B%2B skip the first two results) I also couldn't see any policy change in the CHANGES.current file either... so if we are going to change this behavior, it should probably be documented. John |
From: William S F. <ws...@fu...> - 2006-01-18 21:20:18
|
Marcelo Matus wrote: > For that reason is 'disabled' unless you use --with-rxspencer. Is there for > the people who want to try it, but is willing to take some extra effort, > such as installing the library and recompiling swig. > > The problem is that the CVS version is kind of difficult to > grab/compile/test > from the Windows world, and people just wait for oficial release to test > swig. > all Are you thinking that the windows release should have this library compiled in then? > And as in this feature we need a lot of feedback and ideas, I think > is better to give it a little more exposure than just been in CVS. > > Marcelo > I'm also not sure about this change just before release. If this library has to be specifically installed at configure time and it doesn't come with big distributions, it means few people are going to use it and if it is going to be replaced in the next version of SWIG with something else, then I can't see the point of putting it in, especially if we are going to start working on the next version in a few weeks time. Or have we chosen this as the definitive regex library for the future now? Personally, I think we should concentrate on fixing the current problems that are preventing release before working on new features. Right now I have plenty of new things I'd like to work on, but instead have been concentrating on the drudge work getting SWIG to work again on multiple platforms :(. The Windows problems are holding up the release and there seem to be too many of them for the amount of free time I have. Has anyone had a chance to test on any platforms other than linux, eg Solaris? I was also wondering about the simple renaming mechanism that has recently gone in and how it fits in with the regex handling? Does it provide something that regex won't handle or is it complementary in some way? William > > Jason Stewart wrote: > >> Hi Marcelo, >> >> On 1/17/06, Marcelo Matus <mm...@ac...> wrote: >> >> >>> I think it is important to have this initial implementation out with the >>> next release >>> to let people try it, test it and see how it fit with the %rename >>> directive, and if more >>> options are needed. >>> >> >> This is a pretty major 'feature' that's going in awfully late in the >> release, don't you think? We haven't had a lot of time to test it out. >> Isn't it likely to generate a lot of issues? >> >> Cheers, jas. >> >> >> ------------------------------------------------------- >> This SF.net email is sponsored by: Splunk Inc. Do you grep through log >> files >> for problems? Stop! Download the new AJAX search engine that makes >> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >> http://sel.as-us.falkag.net/sel?cmdÿk&kid3432&bid#0486&dat1642 >> _______________________________________________ >> Swig-devel mailing list >> Swi...@li... >> https://lists.sourceforge.net/lists/listinfo/swig-devel >> >> >> > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=k&kid3432&bid#0486&dat1642 > _______________________________________________ > Swig-devel mailing list > Swi...@li... > https://lists.sourceforge.net/lists/listinfo/swig-devel > |
From: William S F. <ws...@fu...> - 2006-01-18 21:08:48
|
Jason Stewart wrote: > Hi William, > > On 1/14/06, William S Fulton <ws...@fu...> wrote: >>Perl is completely hosed with vc++7.1, I get this in every wrapper: >> >>Checking testcase typemap_subst under perl5 >>typemap_subst_wrap.c(893) : error C2275: 'IV' : illegal use of this type >>as an expression >> c:\Perl\lib\CORE\perl.h(1035) : see declaration of 'IV' >>typemap_subst_wrap.c(893) : error C2146: syntax error : missing ';' >>before identifier 'tmp' >>typemap_subst_wrap.c(893) : error C2144: syntax error : '<Unknown>' >>should be preceded by '<Unknown>' >>typemap_subst_wrap.c(893) : error C2144: syntax error : '<Unknown>' >>should be preceded by '<Unknown>' >>typemap_subst_wrap.c(893) : error C2143: syntax error : missing ';' >>before 'identifier' >>typemap_subst_wrap.c(893) : error C2065: 'tmp' : undeclared identifier >>make[2]: *** [perl5] Error 2 >>make[1]: *** [typemap_subst.ctest] Error 2 >> >> >>$ perl -v >> >>This is perl, v5.6.1 built for MSWin32-x86-multi-thread > > I could try and reproduce this with perl-5.6.1 on linux, but I have no > access to windows or vc++ so I can't be of much help there. > > What is the offending line in the .c file? Maybe that will shed some > light. What is the declaration in perl.h? What distribution of Perl > are you using? > > Cheers, jas. > Took a look. C++ code is being generated for C wrappers. Within any scope, gcc accepts declarations after code which seems just plain wrong to me. The -pedantic flag is needed to show the problem, eg it might be worth fixing all the problems with this: make -k check CFLAGS='-Wall -pedantic -ansi -Wno-long-long' CXXFLAGS='-Wall -pedantic -ansi -O2 -Wno-long-long' William |
From: Marcelo M. <mm...@ac...> - 2006-01-18 17:57:28
|
alloc is an input/output parameter right now, but probably this will change in a near future and alloc will be only an input parameter. alloc as input parameter tells SWIG_AsCharPtrAndSize if you would like to get back a new allocated array (SWIG_NEWOBJ) or just a pointer to the original string (SWIG_OLDOBJ). If you pass '0', you really don't care if is a new or old object, and SWIG_AsCharPtrAndSize should decide the 'default' behavior. Note that what you ask for a SWIG_OLDOBJ, it is not necessary what you get, some languages still need to return a new allocated array, and that is almost always the case for wchar_t arrays. So, the alloc parameter is only saying what would you like. As an output parameter, alloc tells if the returned pointer is a new allocated array (SWIG_NEWOBJ) or just a pointer to an 'old' or language internal array (SWIG_OLDOBJ). Again, the returning value could be different for what you asked, for example if you ask for a SWIG_OLDOBJ, and that is not possible, you will get back a SWIG_NEWOBJ result. But if you ask for a SWIG_NEWOBJ, you always need to return a SWIG_NEWOBJ, making a new array copy if necessary (you can use the %new_copy_array macro to do that ,since in C you need to use malloc, in C++ new). that is the part that probably we will change soon, the alloc will be only an input parameter, and the output will be pass back in the return value as a mask, as is done now in the rest of the UTL. also look at the ruby/rubystrings.swg. tcl/tclstrings.swg and perl/perlstrings.swg which are clearer implementations, since with python we have to do a little more. Marcelo Kevin Ruland wrote: > Marcelo, > > There was a bug posted on the swig-user list about default arguments > in member functions. After a little investigation, I've found two > problems with the PHP code. The first was the memberFunctionHandler > wasn't coping with overloading correctly. The second was the PHP > typemaps weren't bright enough to handle std::string. > > Rather than messing with trying to rewrite the std::string typemaps in > Lib/php4, I figured I might as well try to use the unified typemap > library you've developed. > > After a little cribbing from the python code, I appear to have it > somewhat working (for (in) std::string anyway). I've looked at > typemaps/swigtypemaps.swg and typemaps/fragments.swg and have tried to > follow the lead in the pytypemaps.swg file. > > I'm looking for additional information to support the string and > cstring common library files. I see that I need to define the fragments: > > SWIG_AsCharPtrAndSize > SWIG_FromCharPtrAndSize > > I'm not certain what to make of the alloc parameter to > SWIG_AsCharPtrAndSize, can you please elaborate? It looks like it is > both in and out and the python implementation does something > differently depending on it's initial value and again resets its value. > > Thanks much. > > Kevin > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 > _______________________________________________ > Swig-devel mailing list > Swi...@li... > https://lists.sourceforge.net/lists/listinfo/swig-devel |
From: Kevin R. <kr...@ku...> - 2006-01-18 17:10:31
|
Marcelo, There was a bug posted on the swig-user list about default arguments in member functions. After a little investigation, I've found two problems with the PHP code. The first was the memberFunctionHandler wasn't coping with overloading correctly. The second was the PHP typemaps weren't bright enough to handle std::string. Rather than messing with trying to rewrite the std::string typemaps in Lib/php4, I figured I might as well try to use the unified typemap library you've developed. After a little cribbing from the python code, I appear to have it somewhat working (for (in) std::string anyway). I've looked at typemaps/swigtypemaps.swg and typemaps/fragments.swg and have tried to follow the lead in the pytypemaps.swg file. I'm looking for additional information to support the string and cstring common library files. I see that I need to define the fragments: SWIG_AsCharPtrAndSize SWIG_FromCharPtrAndSize I'm not certain what to make of the alloc parameter to SWIG_AsCharPtrAndSize, can you please elaborate? It looks like it is both in and out and the python implementation does something differently depending on it's initial value and again resets its value. Thanks much. Kevin |
From: Charlie S. <cf...@in...> - 2006-01-17 18:46:38
|
I agree that you can get around this by defining static methods on the class, and its a good point that you could manually make them constructors. Here is how new is defined in the Ruby C source code: VALUE rb_class_new_instance(argc, argv, klass) int argc; VALUE *argv; VALUE klass; { VALUE obj; obj = rb_obj_alloc(klass); rb_obj_call_init(obj, argc, argv); return obj; } > then if you need extra new's, it could be like > > class Something > def self.new2(*a) obj = self.allocate; obj.initialize2(*a); obj end > def self.new3(*a) obj = self.allocate; obj.initialize3(*a); obj end > end > > The problem with the above is that the Ruby code has no way to get at the C initializer functions SWIG has produced. You'd have to change SWIG to expose these initializer functions to Ruby by registering them as singleton methods on the class. And once you've got that far, you might as well just do the whole job in SWIG so you don't have to have two files - one the C code and the other some Ruby wrapper class. So you'd have to change SWIG to: 1) Only generate one allocate method - there is no point in having multiple ones 2) Rename wrap_new_Foo_int methods to wrap_init_Foo_int methods. 3) Generate additional wrapper methods called wrap_new_Foo_int that do something like this: wrap_new_Foo_int {int argc, VALUE *argv) { VALUE self = rb_obj_alloc(klass); wrap_init_Foo_int(argc, argv, self); return self; } 4) Register these new methods as singleton_methods: rb_define_singleton_method(cFoo.klass, "new_from_int", VALUEFUNC(_wrap_init_Foo_int), -1) And that should do it. But once again, is this really necessary? The only thing it enables is the ability to rename constructor functions via the %rename directive. SWIG already let's you have multiple constructors with the same name since it supports method overloading. Thus in this case you can call Foo.new() or Foo.new(3) already. Do you really need to also have Foo.new_from_int(3)? My thoughts are no - its not worth bothering. Thanks, Charlie > where .allocate is the same but both .new and #initialize have parallel > renamings. This could be generated automatically: > > class Something > def self.constructor(suffix) > eval "def self.new#{name} (*a) > obj = self.allocate; obj.initialize#{name}(*a); obj end" > end > constructor "2" > constructor "3" > end > > note: .allocate should (ideally) produce a Ruby object that you cannot > crash Ruby with, but in this case I don't really know what to do. Maybe > it's fine to instead have .allocate be only safe as long as the first > methodcall on the allocated object is an initialize-compatible call ? > > _ _ __ ___ _____ ________ _____________ _____________________ ... > | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju > | Freelance Digital Arts Engineer, Montréal QC Canada > > > |