From: Jason S. <jas...@gm...> - 2006-02-14 06:44:10
|
Hey All, Here is the start of the thread to discuss the next release. My suggestion is that we focus on making a 2.0 release. Wrap up all the 1.3 developments and make it official. 1.3 has been a true development line with lots of changes. It would be nice for people to stick with this as a stable base - so that each release doesn't create the kind of incompatibilities that happened with SVN. Then we can start a 2.1 line for more development? Here's a start of a list of needed items: * full documentation overview - make sure all new 1.3 features are in the docs, and all old docs are up to date * bring Perl support current to Python support for new features Cheers, jas. |
From: Jason S. <jas...@gm...> - 2006-02-17 10:28:33
|
anyone explain why his posts have been blocked? ---------- Forwarded message ---------- From: R. Bernstein <ro...@pa...> Date: Feb 14, 2006 3:17 PM Subject: [Swig-devel] Swig-2.0 planning To: Jason Stewart <jas...@gm...> Interesting you mention Perl support and documentation for SWIG. I've tried now twice to post to swig devel and for reasons that are a mystery to me, neither post has gotten through nor have I gotten a moderation held/rejected message. (But never ascribe to maliciousness that which can easily be explained by oversite. ) So here (for a 3rd time, each time a little different) was something I've tried to post. Perhaps you can ammend and/or post it. .... I recently contributed my first CPAN module which uses SWIG. I used the newer Perl installation system called Module::Build. Before undertaking this I looked around for other setups and information and couldn't find any. I put some rudimentary instructions in the SWIG Wiki: http://www.dabeaz.com/cgi-bin/wiki.pl?SwigFaq/Perl Probably something should probably should be put in the SWIG manual in the Perl section. Either the code itself and/or the comments in the WIKI could be used. Having fresh experience with the Perl SWIG I would be willing to go over the Perl section to describe how to do a full Perl CPAN setup and revise to make the Perl section more complete as the Python section is. Also I'd be willing say to try to get %autodoc so it emits POD and perhaps document %perlcode better. (But before I spend any length of time on this I would want to know that it's not going to get ignored as my posts to swig-devel have. ;-) Jason Stewart writes: > Hey All, > > Here is the start of the thread to discuss the next release. My > suggestion is that we focus on making a 2.0 release. Wrap up all the > 1.3 developments and make it official. > > 1.3 has been a true development line with lots of changes. > > It would be nice for people to stick with this as a stable base - so > that each release doesn't create the kind of incompatibilities that > happened with SVN. > > Then we can start a 2.1 line for more development? > > Here's a start of a list of needed items: > * full documentation overview - make sure all new 1.3 features are in > the docs, and all old docs are up to date > * bring Perl support current to Python support for new features > > Cheers, jas. > > > ------------------------------------------------------- > 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=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-02-19 15:04:43
|
On Tue, 14 Feb 2006, Jason Stewart wrote: > Then we can start a 2.1 line for more development? > Here's a start of a list of needed items: > * full documentation overview - make sure all new 1.3 features are in > the docs, and all old docs are up to date > * bring Perl support current to Python support for new features nested class support... pleaaaase :-] _ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - t=E9l:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montr=E9al QC Canada |
From: Jason S. <jas...@gm...> - 2006-02-20 05:56:02
|
Hey Rocky, On 2/14/06, R. Bernstein <ro...@pa...> wrote: > I recently contributed my first CPAN module which uses SWIG. I used > the newer Perl installation system called Module::Build. Ok, I'm curious to know more about Module::Build. I've never liked MakeMaker, but well it's the standard. If Module::Build can support SWIG out of the box, that would be nice. > Before > undertaking this I looked around for other setups and information and > couldn't find any. > > I put some rudimentary instructions in the SWIG Wiki: > http://www.dabeaz.com/cgi-bin/wiki.pl?SwigFaq/Perl Ok, thanks for that. I looked at it, and would like a little more information about what the 'swig programs' are in swig_source. Are they interface files that will be wrapped? > Probably something should probably should be put in the SWIG > manual in the Perl section. Either the code itself and/or the comments > in the WIKI could be used. > > Having fresh experience with the Perl SWIG I would be willing to go > over the Perl section to describe how to do a full Perl CPAN setup and > revise to make the Perl section more complete as the Python section > is. > > Also I'd be willing say to try to get %autodoc so it emits POD and > perhaps document %perlcode better. > Those would all be really great contributions. Please let me know how I can assist you. Cheers, jas. |
From: David B. <dav...@da...> - 2006-02-28 02:22:38
|
On Feb 14, 2006, at 12:44 AM, Jason Stewart wrote: > Hey All, > > Here is the start of the thread to discuss the next release. My > suggestion is that we focus on making a 2.0 release. Wrap up all the > 1.3 developments and make it official. > I agree. SWIG-2.0 has been way overdue. We're way beyond anything in the older SWIG-1.x releases at this point. > 1.3 has been a true development line with lots of changes. > > It would be nice for people to stick with this as a stable base - so > that each release doesn't create the kind of incompatibilities that > happened with SVN. > Yes. > Then we can start a 2.1 line for more development? > Yes. In my mind, the main requirement for the 2.0 release is just making sure everything works as well as is possible and it's documented--- with more emphasis on the documentation. Cheers, Dave |
From: William S F. <ws...@fu...> - 2006-03-06 22:06:15
|
David Beazley wrote: > > On Mar 5, 2006, at 3:00 PM, William S Fulton wrote: > >> David Beazley wrote: >>> On Mar 5, 2006, at 1:51 PM, Marcelo Matus wrote: >>>> Following the existing LICENSE file, and the dates you get when >>>> using swig -version, >>>> this is a preliminary updated LICENSE file, including the Arizona >>>> part. >>>> >>>> Here they just want the University name around, so, I just copy/ >>>> paste what >>>> seems to be the more "open" license version. >>>> >>> This seems fine. However, I'd like to make one request. Please >>> list the University of Utah/University of California portion first >>> (the oldest license) here and anywhere there is a list of >>> attributions. This is primarily a nod to where SWIG originated. >> >> All fine by me. However, can we change swig -version to print just >> the version and other useful information and not a heap of copyright >> notices? If need be, a one liner refering to the LICENSE file for >> full copyright information. As more and more people claim copyright >> over the code, I can see swig -version is going to get out of control. > > That seems fine to me. > >> Any objections if we also have a uniform approach to copyright >> notices and authors? Let's have a single copyright template which >> just refers to the LICENSE file and put that in all the C/C++ .i and >> .swg source files. I also think it is a bit unfair that some authors >> have their names generated into _wrap.cxx files. To be fair they >> should all be removed so the .i and .swg files which are copied >> verbatim into the generated code do not generate additional copyright >> notices. By law everyone has copyright over the code they write and >> there is no need to display all their names. The commit history and >> CHANGES file contains this information. >> > > In the _wrap.cxx files, let's put a URL reference to the license (on > www.swig.org). Since the wrapper code may travel farther than the > SWIG distribution itself, that might be more useful to someone who > comes across it without knowing much about SWIG. There isn't actually anything that covers the generated code, but obviously it is free. The top of the _wrap.cxx files already have a link to http://www.swig.org, so I take it that we can leave it as is. > Otherwise, all of > this makes sense to me. Personally, I don't really have many concerns > about the copyright as long as it remains clear (in whatever scheme is > adopted) that SWIG originated at University of Utah/ University of > California. > I'm going for the template below for the source code files. It has a URL link to the license files and, it mentions SWIG, thw web site and covers all the authors and other legalese succinctly. There are too many interface files in the Lib directory, many of which just include another file. So I'll use the same template for those files that already have some sort of header and leave the rest without a header. /* ----------------------------------------------------------------------------- * See the LICENSE file for information on copyright, usage and redistribution * of SWIG, and the README file for authors - http://www.swig.org/release.html. * * naming.c * * Functions for generating various kinds of names during code generation. * ----------------------------------------------------------------------------- */ William |
From: William S F. <ws...@fu...> - 2006-02-28 21:52:09
|
David Beazley wrote: > > On Feb 14, 2006, at 12:44 AM, Jason Stewart wrote: > >> Hey All, >> >> Here is the start of the thread to discuss the next release. My >> suggestion is that we focus on making a 2.0 release. Wrap up all the >> 1.3 developments and make it official. >> > > I agree. SWIG-2.0 has been way overdue. We're way beyond anything in > the older SWIG-1.x releases at this point. > >> 1.3 has been a true development line with lots of changes. >> >> It would be nice for people to stick with this as a stable base - so >> that each release doesn't create the kind of incompatibilities that >> happened with SVN. >> > > Yes. > >> Then we can start a 2.1 line for more development? >> > > Yes. > > In my mind, the main requirement for the 2.0 release is just making > sure everything works as well as is possible and it's documented--- with > more emphasis on the documentation. > Here is my take on this. We need a consensus, but largely by the developers who are going to do the work. So we need names against each item in the list of things that need doing. Originally the goal for 2.0 was for nested class support. I don't see that happening for a long time and I don't think anyone thinks that is the vision for 2.0 anymore. So what is the vision for 2.0? In summary I've always seen this as the spit and polish of what we currently have. This would include ironing out as many inconsistencies that exist in the languages, tarting up the documentation, fixing some quirks like output typemaps being applied to methods. There are two major things I think we need doing for 2.0. 1) Common STL framework for the languages so that good support is provided across aboard. One of SWIG's strengths which must be kept in mind is support for many target languages. I often think using SWIG is too much of a learning curve for small projects wrapping for one target language and it would be better to script by hand. If however, more than one target language is needed, then I'd expect SWIG to require very little extra work to add in an additional language. Consistent STL is imperative for this. I'd also like to see std::auto_ptr and boost::shared_ptr support across the board but not essential for 2.0. 2) Better feature matching rules. This is largely done for %rename, but not %feature. I think the plan from many moons ago was to merge %rename and %feature and I think this is a high priority. The regex support would be part of this work. The problem is that this vision has been way exceeded by Marcelo's recent work, which is really a 2.x version of SWIG. The STL support I had in mind was simple. It was pretty much the container classes that Luigi did being in a common directory with SWIGTYPE*& typemaps added to each language to remove the specializations. And that was it, rudimentary, but it would cover nearly everything that users would need and would work with less standards compliant implementations of the STL, which is basically what developers are stuck with. Now we have iterators and all sorts available. This is great, but I think it is too compicated, bloated, overkill and jumping the gun for 2.x development. It doesn't work for older compilers. Marcelo can you explain how your new STL framework is going to work for all the languages? If it is going to involve the UTL, I'm afraid I don't see it working for the strongly typed languages, which is a real shame for getting a truly common framework. The main problem is things just happen without any announcement/planning and I don't have the time to implement what I see as important, so can't really ensure it gets done. Lets try and give advance warning of any major changes in the future. As Marcelo is the most active, I suggest he lays out his plans for future versions and we can work around that in choosing when to release 2.0 and start a 2.x development branch. As for me and what I can do for 2.0, I intend to improve the STL for C# and Java and add in the %feature("shadow") directive for these languages. Also typemaps for mutable strings (StringBuffer/StringBuilder). I would like to have put in directors for C#, but realistically don't have the time. The Java directors have some bugs which need fixing. William |
From: Jason S. <jas...@gm...> - 2006-03-02 05:25:18
|
Hey all, On 3/1/06, William S Fulton <ws...@fu...> wrote: > David Beazley wrote: > > > Here is my take on this. We need a consensus, but largely by the > developers who are going to do the work. So we need names against each > item in the list of things that need doing. > ok. > Originally the goal for 2.0 was for nested class support. I don't see > that happening for a long time and I don't think anyone thinks that is > the vision for 2.0 anymore. ok. I know that I have zero interest. > So what is the vision for 2.0? In summary > I've always seen this as the spit and polish of what we currently have. > This would include ironing out as many inconsistencies that exist in the > languages, tarting up the documentation, fixing some quirks like output > typemaps being applied to methods. > This is what I feel we should focus on. If we do this we could have 2.0 out in two months. > There are two major things I think we need doing for 2.0. > > 1) Common STL framework for the languages > > 2) Better feature matching rules. > I feel these are nice features - but I freel that by working on these we will totally dilute our efforts to focus on documentation and cleanup. Let's focus on these for a 2.5 or 3.0 release unless we can ensure that it really is a simple issue. Cheers, jas. |