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: John L. <le...@cs...> - 2006-08-28 22:46:07
|
On 08/24/06 16:38, William S Fulton wrote: > The Examples/python/imports tests is broken for Python and some of the > other languages too in swig-1.3.29 and current cvs. Maybe you could have > a look John to see where the runtime is going wrong? > > I'm getting a: > Spam -> Base -> Bar : bad swig > I looked at it and it runs fine on my computer for several languages (python, perl, guile). The latest CVS as of today, Mon Aug 28. Are you still getting it? I guess I will need more information John |
From: William S F. <ws...@fu...> - 2006-08-24 21:47:36
|
The Examples/python/imports tests is broken for Python and some of the other languages too in swig-1.3.29 and current cvs. Maybe you could have a look John to see where the runtime is going wrong? I'm getting a: Spam -> Base -> Bar : bad swig Thanks William |
From: William S F. <ws...@fu...> - 2006-08-24 21:47:09
|
Ali - wrote: > Hi, > > I would like to generate java interface wrappers instead of java classes > generated by swig (don't ask why). One of way of doing this could be by > modifying java.swig by finding where the methods are generated and getting > rid of the method bodies. However, there are millions of lines (well, 30-40) > to be modified this way. How is it possible to have a super control over the > methods body and comment them out by one or two lines of swig codes? > You don't need to modify java.swg, you just use typemaps and features in your own interface file. Below is an example for an abstract method returning an int. // Remove method body for Base::pureVirtual %typemap(javaout) int Base::pureVirtual ";" // Make proxy Base::pureVirtual an abstract method %javamethodmodifiers Base::pureVirtual "public abstract" // Features (%javamethodmodifiers above apply to base and derived // classes so we override the above back to what it normally is %javamethodmodifiers Derived::pureVirtual "public" // Make Base an abstract class %typemap(javaclassmodifiers) Base "public abstract class" %inline %{ class Base { public: virtual int pureVirtual() = 0; }; class Derived : public Base { public: int pureVirtual() { return 0; } }; %} BTW, Swig does not map pure virtual methods to abstract methods in the proxy class because then it is not possible to have the abstract base class as return type or parameter in any methods, consider: class Base { public: virtual Base* clone() = 0; }; If you apply the same approach to clone as pureVirtual, the code will never compile and you will have to think of other ways to marshal the return type, none of which can be automated by inspection of the method declaration. William |
From: Ali - <sa...@ho...> - 2006-08-21 16:08:36
|
Hi, I would like to generate java interface wrappers instead of java classes generated by swig (don't ask why). One of way of doing this could be by modifying java.swig by finding where the methods are generated and getting rid of the method bodies. However, there are millions of lines (well, 30-40) to be modified this way. How is it possible to have a super control over the methods body and comment them out by one or two lines of swig codes? _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ |
From: John L. <le...@cs...> - 2006-08-15 22:01:12
|
On 08/15/06 05:12, mark gossage wrote: > Hello All, > John, Thanks for spelling out that the SWIG_InitializeModule() does, its a lot clearer now. > > I have a proposed modification to SWIG_InitializeModule(), I want to run it past you all first, before I commit it. > >From looking at the code, it looks fine. I will need to test it, but than can be done after you commit it to CVS. Anytime you make changes to the core runtime stuff, you should also try and test it with as many language modules as you can. Python, Ruby, Perl, Tcl, and maybe Chicken, Guile. To test, you just need to run the test suite for each language (and have the dev packages installed). I usually run the test suites before and after the change to make sure nothing fails... We need to take this precaution since the runtime is such a critical point to SWIG, and changes can not be made lightly. John |
From: <ma...@go...> - 2006-08-15 10:15:49
|
Hello All, John, Thanks for spelling out that the SWIG_InitializeModule() does, its a lot clearer now. I have a proposed modification to SWIG_InitializeModule(), I want to run it past you all first, before I commit it. Instead of the usual SWIG_InitializeModule(void *clientdata) { static int init_run = 0; if (init_run) return; init_run = 1; .. I am adding a more complex set of code. The reason is that for multiple interpreters, you need to make sure each interpreter gets a pointer to the swig_module. In summary, the code does the following: 1. Check to see if the interpreter holds a pointer to a SWIG module. If it doesnt hold a pointer, then add a pointer in. Also check to see if the module has been initialised (ie if the next pointer has been set), and if not set it to loop back. 2. If the interpreter holds the pointer, then search the loop for the current SWIG module, if its found, then all is initalised and we are finished. If the current module is not in the list, then add it into the list. (code chunk at the bottom). I tested this with 3 interpeters and 2 SWIG modules, it looks ok, but I only tested on one language (Lua). If any of the developers think their might be an issue, let me know. Otherwise I will commit this in a couple of days. Regards, Mark =================== SWIGRUNTIME void SWIG_InitializeModule(void *clientdata) { size_t i; swig_module_info *module_head, *iter; int found; clientdata = clientdata; /* Try and load any already created modules */ module_head = SWIG_GetModule(clientdata); if (!module_head) { /* This is the first module loaded for this interpreter */ /* so set the swig module into the interpreter */ SWIG_SetModule(clientdata, &swig_module); module_head = &swig_module; /* check to see if the circular list has been setup, if not, set it up */ if (swig_module.next==0) { /* Initialize the swig_module */ swig_module.type_initial = swig_type_initial; swig_module.cast_initial = swig_cast_initial; swig_module.next = &swig_module; } } else { /* the interpreter has loaded a SWIG module, but has it loaded this one? */ found=0; iter=module_head; do { if (iter==&swig_module) { found=1; break; } iter=iter->next; } while (iter!= module_head); /* if the is found in the list, then all is done and we may leave */ if (found) return; /* otherwise we must add out module into the list */ swig_module.next = module_head->next; module_head->next = &swig_module; } rest of code is as usual... ===== |
From: William S F. <ws...@fu...> - 2006-08-14 20:47:14
|
Fred Eisele wrote: > <snip/> >> You will need to read over the code from an existing module. >> (If you take any notes/create any docs they would be greatly >> appreciated, even if they are really basic.... :) > > Ok, I presume the notes would go in the wiki. > Any particular place? > Patches to the main documentation would be best, in particular Typemaps.html. William |
From: William S F. <ws...@fu...> - 2006-08-14 20:44:12
|
Henning Thielemann wrote: >> Date: Wed, 09 Aug 2006 22:14:01 +0100 >> From: William S Fulton <ws...@fu...> >> Subject: Re: [Swig-devel] Formatting of source code (Was: Ada language >> module for SWIG) >> Cc: swi...@li... >> Message-ID: <44D...@fu...> >> Content-Type: text/plain; charset=ISO-8859-1 >> >> >> indent -kr --honour-newlines --line-length160 --indent-level2 -T File -T >> DohObjInfo -T Parm -T Language -T List -T Typetab -T ModuleFactory -T >> ErrorMessageFormat -T Symtab -T Hash -T String -T DohBase -T Node -T >> String_or_char -T SwigType -T Dispatcher -T Wrapper -T DohStringMethods >> -T DohFileMethods -T DohListMethods -T DohHashMethods -T DOH -T >> DohIterator -T ParmList -T FILE -T HashNode -T DOHString_or_char >> >> The -T options are for type identification so that the pointer is >> aligned properly next to parameter names in function >> declarations/definitions. >> >> This by and large fits in with what is the most common style. The main >> deviations / most common changes it makes are: >> >> 1) if statements with return statements on one line are split into two lines > > Why not. > >> 2) Code has been edited with a mixture of editors that either translate >> 8 spaces into a tab and others that leave the 8 spaces. The indent >> options above translates 8 spaces into tabs. Personally, I think tabs >> should be banned, but it seems that the most common setting that people >> use is the 8 spaces = tab option, so we'll go with this unless there is >> large consensus to see spaces only. > > I'd agree to removing TABs. > >> 3) Some of the SWIG code has been written very squashed up with no >> spaces after the comma separating parameters when making function calls. >> I can't get indent to match this, > > Was this your goal? > >> so from now on we will have spaces after the commas in function calls. > > Fine. > The goal was to match the current style as closely as possible. Consistency in style is the overriding goal and using a code formatter enforces this. It's unfortunate that the tool adds in spaces after function parameters and splits if statements as it breaks the goal of least change, but as an aside, I personally think the style is preferable. >> 4) parser.y is a dog's dinner of styles and indent doesn't really >> understand yacc, so makes it even worse, so this one will need doing by >> hand at some point!! > > Is it modified frequently? I thought the C++ parser is rather finished and > the main work is spent on wrapping. > Hah, if only. This is probably the most frequently edited file in the core. Many bug fixes are fixed in here as well as adding in new features. William |
From: Fred E. <ph...@gm...> - 2006-08-12 20:49:07
|
<snip/> > You will need to read over the code from an existing module. > (If you take any notes/create any docs they would be greatly > appreciated, even if they are really basic.... :) Ok, I presume the notes would go in the wiki. Any particular place? |
From: John L. <le...@cs...> - 2006-08-12 20:20:14
|
On 08/12/06 07:54, Fred Eisele wrote: > With that in mind, what are "Marcelo's typemaps"? > http://www.swig.org/Doc1.3/Typemaps.html#Typemaps ? > I am not finding anything compelling in the documentation. It isn't documented in the manual (yet), but the typemaps are in the Lib/typemaps directory... check out the README file in that directory, or also read fragments.swg. You will need to read over the code from an existing module. (If you take any notes/create any docs they would be greatly appreciated, even if they are really basic.... :) John |
From: Fred E. <ph...@gm...> - 2006-08-12 12:54:48
|
Thanks William, John & Joseph, The current wrapper languages --especially R and Java-- will help a lot. The first thing I will do is generate wrappers for currently supported languages. And yes, I will take that discussion to the swig-users list. Then, given your estimates I will work on generating wrappers for MATLAB/Octave. As I will not need a full set of call semantics for my project, , for the first cut, I will go for the "good enough" weeks not "production quality" months implementation. With that in mind, what are "Marcelo's typemaps"? http://www.swig.org/Doc1.3/Typemaps.html#Typemaps ? I am not finding anything compelling in the documentation. >From that point, I plan on putting in a few hours a week to get "production quality". In any case, how does the check-in process work? |
From: Josh C. <jc...@nc...> - 2006-08-11 14:26:07
|
On Wed, 9 Aug 2006, William S Fulton wrote: > Thanks, I tried the most advanced: astyle and bcpp, but they were too > buggy, eg altering the meaning of the code. > > I had another look at indent and I overcame the initial problems I had > with it. So, I suggest we use it as the definitive SWIG style guide and > run it through the whole of the code base. I propose using: I use the emacs c++ mode for editing c++ code. Its auto-indent features can be used in batch mode, e.g.: emacs --batch foo.cpp --eval "(progn (indent-region (point-min) (point-max) nil) (save-buffer))" That will get you the default indentation, but you can get, e.g., four spaces, no tabs, like this: emacs --batch foo.cpp --eval "(progn (setq indent-tabs-mode nil) (setq c-basic-offset 4) (indent-region (point-min) (point-max) nil) (save-buffer))" This only affects indentation, but there may be stuff in there for doing other beautifications if that's desired. > 4) parser.y is a dog's dinner of styles and indent doesn't really > understand yacc, so makes it even worse, so this one will need doing by > hand at some point!! There are yacc and bison modes for emacs floating around. If nothing else, they might help you to do this interactively. Josh |
From: Henning T. <sw...@he...> - 2006-08-11 11:47:18
|
> Date: Wed, 09 Aug 2006 22:14:01 +0100 > From: William S Fulton <ws...@fu...> > Subject: Re: [Swig-devel] Formatting of source code (Was: Ada language > module for SWIG) > Cc: swi...@li... > Message-ID: <44D...@fu...> > Content-Type: text/plain; charset=ISO-8859-1 > > > indent -kr --honour-newlines --line-length160 --indent-level2 -T File -T > DohObjInfo -T Parm -T Language -T List -T Typetab -T ModuleFactory -T > ErrorMessageFormat -T Symtab -T Hash -T String -T DohBase -T Node -T > String_or_char -T SwigType -T Dispatcher -T Wrapper -T DohStringMethods > -T DohFileMethods -T DohListMethods -T DohHashMethods -T DOH -T > DohIterator -T ParmList -T FILE -T HashNode -T DOHString_or_char > > The -T options are for type identification so that the pointer is > aligned properly next to parameter names in function > declarations/definitions. > > This by and large fits in with what is the most common style. The main > deviations / most common changes it makes are: > > 1) if statements with return statements on one line are split into two lines Why not. > 2) Code has been edited with a mixture of editors that either translate > 8 spaces into a tab and others that leave the 8 spaces. The indent > options above translates 8 spaces into tabs. Personally, I think tabs > should be banned, but it seems that the most common setting that people > use is the 8 spaces = tab option, so we'll go with this unless there is > large consensus to see spaces only. I'd agree to removing TABs. > 3) Some of the SWIG code has been written very squashed up with no > spaces after the comma separating parameters when making function calls. > I can't get indent to match this, Was this your goal? > so from now on we will have spaces after the commas in function calls. Fine. > 4) parser.y is a dog's dinner of styles and indent doesn't really > understand yacc, so makes it even worse, so this one will need doing by > hand at some point!! Is it modified frequently? I thought the C++ parser is rather finished and the main work is spent on wrapping. |
From: art y. <ay...@sp...> - 2006-08-11 02:14:53
|
Hey, I haven't contributed in a long time, but I recently started working at a place where we use SWIG and I was able to put this patch together: patch: http://www.superheterodyne.net/soft/swig-no-ambiguous-overload.zip Contains: swig.diff (patch -p1) Examples/test-suite/ambiguous_overload.i Some libraries (such as the C++ maya interface) provide methods with defaults that will never be useful. consider the following legal C++ class Test1 { public: void foo( int x, double y ) { printf("foo:int(%d),double(%f)\n", x, y); } void foo( int x, double y = 0.0, int z = 0 ) { printf("foo:int(%d),double(%f),int(%d)\n", x, y, z); } void foo( int x, double y = 0.0, char c = 0 ) { printf("foo:int(%d),double(%f),char(%c)\n", x, y, c); } }; The problem here is that if we produce a call to either of the following: Test1::foo(int) Test1::foo(int,double) Which strictly speaking are available, they will produce compile-time errors about being ambiguous (in particular, the y parameter can never be used with a default). The patch adds a Swig_overload_legal function which checks each pair of generated wrapper signatures for ambiguity and puts the "overload:ignore" property on the shorter of the two. -- Discordant is the murmur at such treading down of lovely things while god's most lordly gift to man is decency of mind. Call that man only blest who has in sweet tranquility brought his life to close. If only I could act as such, my hope is good. -- Aeschylus' Agamemnon (translated by H. W. Smyth) |
From: Joseph W. <jo...@gn...> - 2006-08-10 19:43:17
|
Based on my experience creating the R module I'm guessing about six calendar months with about 10 hours a week to get something production quality. However getting something that works minimially can take just a week or two. However, in the case of R there was already a pre-existing module, which helped immensely. |
From: John L. <le...@cs...> - 2006-08-09 23:16:41
|
John Lenz wrote: > > static int _swig_module_init = 0; > > void SWIG_init() { > if (!_swig_module_init) { > SWIG_InitModule(...); _swig_module_init = 1; > } else { > ... > } > } Just noticed you need to add the above or it doesn't work... John |
From: John L. <le...@cs...> - 2006-08-09 23:13:25
|
William S Fulton wrote: > Fred Eisele wrote: >> Hi, >> I have a project that involves making an certain set of algorithms more >> generally available. >> This implies the (re)writing of some java as a c/c++ library. >> Then the library needs to be made accessible in scripting (or at least >> late binding) environments. >> I am considering SWIG for this purpose. >> The problem I have is most of these languages do not have SWIG "exits", >> namely: >> - R or S (http://www.r-project.org) >> - Octave or MatLab ( http://www.gnu.org/software/octave/) >> - SAS (http://www.sas.com/) >> - Squeak (http://squeak.org) >> >> What I want to know... >> How long does it take to develop one of these exits/modules? >> If you can give two estimates that would be great i.e. >> - How long it took you to develop your module >> - How long it would take a "mere mortal" (i.e. me :-) >> >> I have used SWIG to generate wrappers in the past. >> In fact, I was involved with the Xerces/Perl use of SWIG a few years ago. >> >> Wrapping up... >> - I have complete control over the C/C++ code being wrapped. >> - I need wrappers for --at least-- four different languages in multiple >> implementations. >> - I will be doing this as part of my regular job (it isn't a side project). >> - I have permission to release all modules under an open license. >> - I don't (yet) have permission to release the C/C++ library. >> > > cvs SWIG has R/S support. How long it takes to write a module depends on > a few things, most importantly > > 1) Knowledge of the target language and the C api into it > 2) Knowledge of swig > 3) Knowledge of C/C++ for both wrapping and coding the new language module > 4) How close the new language is to an existing supported language > 5) To what degree of support you want, eg directors I would also suggest that you take a language that is similar to the one you want to wrap, and read through Lib/modules/chicken.cxx, guile.cxx, tcl.cxx, python.cxx or java.cxx (just pick one). It should only take an hour or so to get a general idea of what needs to happen on the code side, and those files shouldn't be that hard to understand. The python.cxx might be a little more complicated than the others... This will give you a better idea of what is involved. As william said, on the typemap side you should be able to easily uuse Marcelo's typemaps. John |
From: William S F. <ws...@fu...> - 2006-08-09 21:35:36
|
Fred Eisele wrote: > Hi, > I have a project that involves making an certain set of algorithms more > generally available. > This implies the (re)writing of some java as a c/c++ library. > Then the library needs to be made accessible in scripting (or at least > late binding) environments. > I am considering SWIG for this purpose. > The problem I have is most of these languages do not have SWIG "exits", > namely: > - R or S (http://www.r-project.org) > - Octave or MatLab ( http://www.gnu.org/software/octave/) > - SAS (http://www.sas.com/) > - Squeak (http://squeak.org) > > What I want to know... > How long does it take to develop one of these exits/modules? > If you can give two estimates that would be great i.e. > - How long it took you to develop your module > - How long it would take a "mere mortal" (i.e. me :-) > > I have used SWIG to generate wrappers in the past. > In fact, I was involved with the Xerces/Perl use of SWIG a few years ago. > > Wrapping up... > - I have complete control over the C/C++ code being wrapped. > - I need wrappers for --at least-- four different languages in multiple > implementations. > - I will be doing this as part of my regular job (it isn't a side project). > - I have permission to release all modules under an open license. > - I don't (yet) have permission to release the C/C++ library. > cvs SWIG has R/S support. How long it takes to write a module depends on a few things, most importantly 1) Knowledge of the target language and the C api into it 2) Knowledge of swig 3) Knowledge of C/C++ for both wrapping and coding the new language module 4) How close the new language is to an existing supported language 5) To what degree of support you want, eg directors For me to wrap say Squeak, which I know nothing about would take some time while I got up to scratch on the language. The time I've put into say the Java module would add up to many many man weeks, but then a lot less time has gone into the C# module yet they are equally good. This is because the two languages are quite similar and the wrappers are designed to be very similar, so it is largely a copy paste job for C#. The work that Marcelo has done for the scripting languages *should* mean it is rather easy to support a new language very well. I don't know how well this pans out in practice as no-one else has successfully supported a new language with his centralised macros (Lib/typemaps directory). As a guess you should have the basics of a language module up and running in a week. William |
From: William S F. <ws...@fu...> - 2006-08-09 21:21:20
|
Bob Marinier wrote: > Mikael Magnusson wrote: >> On Thu, Aug 03, 2006 at 09:10:53PM +0100, William S Fulton wrote: >> >>> Henning Thielemann wrote: >>> >>>> There is a rich set of options for indent. I assume that there is also a >>>> possibility to let it format in the SWIG way. >>>> >>>> >>> Nearly. As I said, it was not working very well for C++ files. It looks >>> okay for C files. That's why I am asking for recommendations for C++ >>> beautifiers as indent is C focused. >>> >>> William >>> >> >> bcpp? >> >> http://www.faqs.org/docs/Linux-HOWTO/C-C++Beautifier-HOWTO.html >> >> Mikael >> >> > Beat me to it! That page also lists several other beautifiers in section 4. > > Bob > Thanks, I tried the most advanced: astyle and bcpp, but they were too buggy, eg altering the meaning of the code. I had another look at indent and I overcame the initial problems I had with it. So, I suggest we use it as the definitive SWIG style guide and run it through the whole of the code base. I propose using: indent -kr --honour-newlines --line-length160 --indent-level2 -T File -T DohObjInfo -T Parm -T Language -T List -T Typetab -T ModuleFactory -T ErrorMessageFormat -T Symtab -T Hash -T String -T DohBase -T Node -T String_or_char -T SwigType -T Dispatcher -T Wrapper -T DohStringMethods -T DohFileMethods -T DohListMethods -T DohHashMethods -T DOH -T DohIterator -T ParmList -T FILE -T HashNode -T DOHString_or_char The -T options are for type identification so that the pointer is aligned properly next to parameter names in function declarations/definitions. This by and large fits in with what is the most common style. The main deviations / most common changes it makes are: 1) if statements with return statements on one line are split into two lines 2) Code has been edited with a mixture of editors that either translate 8 spaces into a tab and others that leave the 8 spaces. The indent options above translates 8 spaces into tabs. Personally, I think tabs should be banned, but it seems that the most common setting that people use is the 8 spaces = tab option, so we'll go with this unless there is large consensus to see spaces only. 3) Some of the SWIG code has been written very squashed up with no spaces after the comma separating parameters when making function calls. I can't get indent to match this, so from now on we will have spaces after the commas in function calls. 4) parser.y is a dog's dinner of styles and indent doesn't really understand yacc, so makes it even worse, so this one will need doing by hand at some point!! Any thoughts or comments? William |
From: Fred E. <ph...@gm...> - 2006-08-09 15:35:36
|
Hi, I have a project that involves making an certain set of algorithms more generally available. This implies the (re)writing of some java as a c/c++ library. Then the library needs to be made accessible in scripting (or at least late binding) environments. I am considering SWIG for this purpose. The problem I have is most of these languages do not have SWIG "exits", namely: - R or S (http://www.r-project.org) - Octave or MatLab (http://www.gnu.org/software/octave/) - SAS (http://www.sas.com/) - Squeak (http://squeak.org) What I want to know... How long does it take to develop one of these exits/modules? If you can give two estimates that would be great i.e. - How long it took you to develop your module - How long it would take a "mere mortal" (i.e. me :-) I have used SWIG to generate wrappers in the past. In fact, I was involved with the Xerces/Perl use of SWIG a few years ago. Wrapping up... - I have complete control over the C/C++ code being wrapped. - I need wrappers for --at least-- four different languages in multiple implementations. - I will be doing this as part of my regular job (it isn't a side project). - I have permission to release all modules under an open license. - I don't (yet) have permission to release the C/C++ library. Thanks |
From: Robin E. <lo...@gm...> - 2006-08-09 12:44:23
|
Hi, I sent this to swig-user, but maybe swig-devel is better place? """ I'm working on a function that should take a PHP resource as parameter and then use the stream API on it. However, I'm having hard time to figure out how to write the typemap conversion. My C++ method takes a php_stream* as a in-param. Example conversion from ZVAL is like this: zval *zstream; php_stream *stream; if (FAILURE == zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "r", &zstream)) return; php_stream_from_zval(stream, &zstream); """ -- regards, Robin |
From: John L. <le...@cs...> - 2006-08-09 02:59:11
|
Hey, I just finished moving to a new apartment so haven't been watching swig mailing list that closely. Are you still having problems with the Lua runtime? If so, could you summarize the problem? First, let me try and give you an overview of what should be happening. SWIG_InitModule() should be called only once per module, even in the case of multiple interpreters. All the memory linked together is declared in static arrays, and no memory is malloced(). Thus, if InitModule is called twice, two different sets of module rings could be pointing at the same memory and cause some corruption. That said, the type system code is designed to allow multiple interpreters to use the same module structures at the same time. This is why many language modules include code like the following in the %init section static int _swig_module_init = 0; void SWIG_init() { if (!_swig_module_init) { SWIG_InitModule(...); } else { ... } } thus when the same module is initialized from a different interpreter, the init is not called again. Notice though that the second interpreter does need a pointer to the module ring (the linked list of swig_module_info structures), so in the else part of that block should be some code like swig_module_info *module_head = SWIG_GetModule(clientdata); if (!module_head) { SWIG_SetModule(clientdata, &swig_module); } so that the first module to be loaded in the second interpreter sets the global pointer to the ring of modules. Note that both the first and second interpreter will point to the same circularly linked list of modules, which is ok from the stand point of the global swig type code, but might not work out so well for the clientdata attached to swig_type_info...? What is not supported, (but could be added if Lua needs it), is for a single module to be loaded into two different module rings at the same time (one for the first interp, one for the second). This would require the use of malloc during the init, which is something we tried (and succeeded) in avoiding. I guess we could have the first loaded use the static, and any more malloc a copy... John |
From: Roberto G. <r....@ci...> - 2006-08-07 07:04:40
|
Hi William, thanks for your answer. i've just tried swig and gcc-xml and both are able to provide the output = that i need (reflex also, being based on gcc-xml). I'm looking to embed a piece of code in my application to keep it small = and independent from the xml produced by those tools. regards. ----- Original Message -----=20 From: William S Fulton=20 To: Roberto Gori=20 Cc: swi...@li...=20 Sent: Friday, August 04, 2006 11:02 PM Subject: Re: [Swig-devel] c++ parser Roberto Gori wrote: > Hi, > =20 > i need to parse a generic c++ function arguments list like this: > =20 > int a, char b, void (*f)(int), double g[], float c=3D5 > =20 > and i would like to write a function to obtain the names of the > identifiers (a, b, f, g, c) and eventually the corresponding types = also. > =20 > i've puzzled for long time with this problem without finding a good > solution. > =20 > Could someone give me some advice, please? > Could someone point me to a snippet of code to parse only the = function > arguments? (i don't need to parse all the C++ syntax) > Regards. > =20 If you use the xml module (swig -xml) you'll get this information as shown below. The Reflex C++ reflection tool would probably also provide you with = this information - = http://seal-reflex.web.cern.ch/seal-reflex/examples.html. It uses gccxml, which you could also look at as a separate tool. William <cdecl id=3D"239" addr=3D"b7cd4438" > <attributelist id=3D"240" addr=3D"b7cd4438" > <attribute name=3D"name" value=3D"foo" id=3D"241" addr=3D"b7cd49f8" /> <attribute name=3D"sym_symtab" value=3D"b7cc9b68" = id=3D"242" addr=3D"b7cc9b68" /> <attribute name=3D"sym_nextSibling" value=3D"b7cd45a8" id=3D"243" addr=3D"b7cd45a8" /> <attribute name=3D"csym_nextSibling" = value=3D"b7cd45a8" id=3D"244" addr=3D"b7cd45a8" /> <attribute name=3D"kind" value=3D"function" id=3D"245" addr=3D"b7cd49f8" /> <attribute name=3D"sym_name" value=3D"foo" id=3D"246" addr=3D"b7cd49f8" /> <attribute name=3D"decl" value=3D"f(int,char,p.f(int).void,a().double,float)." id=3D"247" addr=3D"b7cd49f8" /> <attribute name=3D"sym_overloaded" value=3D"b7cd4438" id=3D"248" addr=3D"b7cd4438" /> <parmlist id=3D"249" addr=3D"b7cd4158" > <parm id=3D"250"> <attributelist id=3D"251" addr=3D"b7cd4158" > <attribute name=3D"name" value=3D"a" = id=3D"252" addr=3D"b7cd49f8" /> <attribute name=3D"type" value=3D"int" = id=3D"253" addr=3D"b7cd49f8" /> </attributelist > </parm > <parm id=3D"254"> <attributelist id=3D"255" addr=3D"b7cd41e8" > <attribute name=3D"name" value=3D"b" = id=3D"256" addr=3D"b7cd49f8" /> <attribute name=3D"type" value=3D"char" = id=3D"257" addr=3D"b7cd49f8" /> </attributelist > </parm > <parm id=3D"258"> <attributelist id=3D"259" addr=3D"b7cd4238" > <attribute name=3D"name" value=3D"f" = id=3D"260" addr=3D"b7cd49f8" /> <attribute name=3D"type" = value=3D"p.f(int).void" id=3D"261" addr=3D"b7cd49f8" /> </attributelist > </parm > <parm id=3D"262"> <attributelist id=3D"263" addr=3D"b7cd4348" > <attribute name=3D"name" value=3D"g" = id=3D"264" addr=3D"b7cd49f8" /> <attribute name=3D"type" = value=3D"a().double" id=3D"265" addr=3D"b7cd49f8" /> </attributelist > </parm > <parm id=3D"266"> <attributelist id=3D"267" addr=3D"b7cd43e8" > <attribute name=3D"name" value=3D"c" = id=3D"268" addr=3D"b7cd49f8" /> <attribute name=3D"value" value=3D"5" = id=3D"269" addr=3D"b7cd49f8" /> <attribute name=3D"type" value=3D"float" id=3D"270" addr=3D"b7cd49f8" /> </attributelist > </parm > </parmlist > <attribute name=3D"type" value=3D"void" id=3D"271" addr=3D"b7cd49f8" /> <attribute name=3D"sym_overname" value=3D"__SWIG_0" = id=3D"272" addr=3D"b7cd49f8" /> </attributelist > </cdecl > |
From: William S F. <ws...@fu...> - 2006-08-04 21:08:51
|
Roberto Gori wrote: > Hi, > > i need to parse a generic c++ function arguments list like this: > > int a, char b, void (*f)(int), double g[], float c=5 > > and i would like to write a function to obtain the names of the > identifiers (a, b, f, g, c) and eventually the corresponding types also. > > i've puzzled for long time with this problem without finding a good > solution. > > Could someone give me some advice, please? > Could someone point me to a snippet of code to parse only the function > arguments? (i don't need to parse all the C++ syntax) > Regards. > If you use the xml module (swig -xml) you'll get this information as shown below. The Reflex C++ reflection tool would probably also provide you with this information - http://seal-reflex.web.cern.ch/seal-reflex/examples.html. It uses gccxml, which you could also look at as a separate tool. William <cdecl id="239" addr="b7cd4438" > <attributelist id="240" addr="b7cd4438" > <attribute name="name" value="foo" id="241" addr="b7cd49f8" /> <attribute name="sym_symtab" value="b7cc9b68" id="242" addr="b7cc9b68" /> <attribute name="sym_nextSibling" value="b7cd45a8" id="243" addr="b7cd45a8" /> <attribute name="csym_nextSibling" value="b7cd45a8" id="244" addr="b7cd45a8" /> <attribute name="kind" value="function" id="245" addr="b7cd49f8" /> <attribute name="sym_name" value="foo" id="246" addr="b7cd49f8" /> <attribute name="decl" value="f(int,char,p.f(int).void,a().double,float)." id="247" addr="b7cd49f8" /> <attribute name="sym_overloaded" value="b7cd4438" id="248" addr="b7cd4438" /> <parmlist id="249" addr="b7cd4158" > <parm id="250"> <attributelist id="251" addr="b7cd4158" > <attribute name="name" value="a" id="252" addr="b7cd49f8" /> <attribute name="type" value="int" id="253" addr="b7cd49f8" /> </attributelist > </parm > <parm id="254"> <attributelist id="255" addr="b7cd41e8" > <attribute name="name" value="b" id="256" addr="b7cd49f8" /> <attribute name="type" value="char" id="257" addr="b7cd49f8" /> </attributelist > </parm > <parm id="258"> <attributelist id="259" addr="b7cd4238" > <attribute name="name" value="f" id="260" addr="b7cd49f8" /> <attribute name="type" value="p.f(int).void" id="261" addr="b7cd49f8" /> </attributelist > </parm > <parm id="262"> <attributelist id="263" addr="b7cd4348" > <attribute name="name" value="g" id="264" addr="b7cd49f8" /> <attribute name="type" value="a().double" id="265" addr="b7cd49f8" /> </attributelist > </parm > <parm id="266"> <attributelist id="267" addr="b7cd43e8" > <attribute name="name" value="c" id="268" addr="b7cd49f8" /> <attribute name="value" value="5" id="269" addr="b7cd49f8" /> <attribute name="type" value="float" id="270" addr="b7cd49f8" /> </attributelist > </parm > </parmlist > <attribute name="type" value="void" id="271" addr="b7cd49f8" /> <attribute name="sym_overname" value="__SWIG_0" id="272" addr="b7cd49f8" /> </attributelist > </cdecl > |
From: Roberto G. <r....@ci...> - 2006-08-04 07:55:10
|
Hi, i need to parse a generic c++ function arguments list like this: int a, char b, void (*f)(int), double g[], float c=3D5 and i would like to write a function to obtain the names of the = identifiers (a, b, f, g, c) and eventually the corresponding types = also. i've puzzled for long time with this problem without finding a good = solution. Could someone give me some advice, please? Could someone point me to a snippet of code to parse only the function = arguments? (i don't need to parse all the C++ syntax) Regards. Roberto |