From furnish at xdiv.lanl.gov Wed Dec 17 17:02:30 1997 From: furnish at xdiv.lanl.gov (Geoffrey M. Furnish) Date: Wed, 17 Dec 1997 16:02:30 GMT Subject: [C++-SIG] RE: [META-SIG] Terminating comatose SIGs In-Reply-To: <199712161902.OAA01055@eric.CNRI.Reston.Va.US> References: <199712161902.OAA01055@eric.CNRI.Reston.Va.US> Message-ID: <199712171602.QAA01971@twix.lanl.gov> As the C++ Sig chair, I would like to say that I strongly disagree with this characterization. Low traffic on a mailing list does not directly imply lack of activity or interest. As it happens, Paul Dubois and I spent about an hour on the phone yesterday morning (before this flame bait arrived in my inbox) discussing our ongoing work on the C++ interface that we are constructing. Both of us are overseeing significant efforts at integrating Python into large scientific C++ frameworks at our respective laboratories (LLNL and LANL). There is absolutely no question whatsoever that large numbers of people are and will continue to be affected by what we are doing to integrate Python and C++. These are primarily "internal" (ie, laboratory staff) customers who for the most part, probably do not participate directly on c.l.p. Paul and I decided (while I was still at LLNL) to carry on the C++/Python binding work in a public forum for the overall benefit of the worldwide Python community. I regard any suggestion that the C++ Sig should be shut down just because Paul and I both prefer to avoid babbling inceasently into an archived newsgroup (which has a variety of legal ramifications for those of us working in defense laboratories--the spook wannabes among you should be able to ponder that with amusement for quite some time...) but rather to only make postings when we have something worthwhile to say, to be flatly capricious in nature. In particular, I would like to say very directly that I consider message count to be an extraordinarily poor measure of the worthfulness of a public forum. I personally receive an average of about 100 emails per day. I personally cannot possibly endeavor to participate regularly in c.l.p. in my current employment environment. High volume fourms are quite literally the last thing on earth I want. What I want are highly focused, technical forums in which the content/crap ratio is kept as high as possible and the volume manageable. In my opinion (as the SIG chair), if you were to actually be participating on the C++ sig, you would conclude that your time was not being wasted reading voluminous meanderings of people babbling into their mail tools. That the volume was acceptable, and the content rich (modulo spams), and that in the main, when something comes across that sig, it is worth reading and contains info from people who have taken the time to make sure that what they have to say is worth reading. How you can say that this particular sig should be killed, is frankly beyond me. In particular, I am /not/ asking for an "extension" as the thread sig dude did. The PSA needs to decide whether it is willing to host technical discussion about binding Python to C++ or not. I thought that had been decided. Evidently it needs to be redecided. In particular, I am not interested in entertaining injunctions to get the sig volume up by a certain date or else. I am busy with my regular job, a portion of which involves binding Python to C++, and I (and others) can only commit to making public posts at the rate that we have something valuable to say, whatever that is--and it can't be determined in advance by fiat by people who are not above us in our respective org charts. If it is your intent to kill the C++ sig, let's get it over with. But I am saying here and now, for the record, that I consider that to be an exceedingly ill conceived course of action. Paul Dubois and I have both expended significant effort to condition laborotory policies into such a manner that allows laboratory employees to participate in Python public forums. If the PSA now turns around and says "well, you're not blabbering enough into this channel so we'll have to shut it down", that will have an obvious and undeniable chilling effect on Python users within the laboratories. Does that /really/ make sense to you? If however, the PSA is willing to host discussion about binding Python to C++, then let's let this be the last time this issue has to be redecided. As the SIG Chair, I certainly consider it one of my responsibilities to inform the PSA when the SIG has run its course. In my opinion, that time has not yet come. Guido van Rossum writes: > I went through the various SIG archives, mostly at Findmail, and the > following sigs are clearly in coma (and have been for a long time). I > think that comatose SIGs don't serve any purpose, and that these SIG > mailing lists should be terminated. Their archives should be saved, > of course. > > Here are the numbers of messages since August: > > c++-sig (2 in Aug, 1 in Oct, 7 in Nov -- of which 2 spams and one > reply to a spam) > > locator-sig (0 in Aug-Oct, 1 in Nov, 6 in Dec) > > objc-sig (0 in Aug, 8 in Sep, 4 in Oct, 2 in Dec) > > pattern-sig (5 in Aug, 4 in Oct) > > plot-sig (38 in Sep, 12 in Oct, 10 in Nov, 2 in Dec) > > progenv-sig (2 in Aug, 1 in Nov, 1 in Dec) > > thread-sig (2 in Aug, 19 in Sep, 9 in Nov, 2 in Dec) > > web-sig (1 in Aug, 0 since) > > With these traffic levels, you can't maintain that there is an > interest that warrants a separate SIG -- people interested in these > subjects are better off using the main list, where they are more > likely to reach other individuals with the same interests. > > One could argue that there's still hope for the plot-sig and > thread-sig. Still, the trend is unmistakable -- they can be given an > extension of three months to get their act together. > > I also really like Paul Prescod's idea for the proposed SGML SIG: a > fixed expiration time of 6 month, after which it is killed > automatically unless there's a proven interest to continue. This > should be done for all SIGs, including the currently successful ones. > > --Guido van Rossum (home page: http://www.python.org/~guido/) > > _______________ > META-SIG - SIG on Python.Org SIGs and Mailing Lists > > send messages to: meta-sig at python.org > administrivia to: meta-sig-request at python.org > _______________ _______________ C++-SIG - SIG for Development of a C++ Binding to Python send messages to: c++-sig at python.org administrivia to: c++-sig-request at python.org _______________ From dubois1 at llnl.gov Wed Dec 17 19:22:31 1997 From: dubois1 at llnl.gov (Paul F. Dubois) Date: Wed, 17 Dec 1997 10:22:31 -0800 Subject: [C++-SIG] RE: [META-SIG] Terminating comatose SIGs Message-ID: <01bd0b18$bd0feca0$998a7380@pduboispc> Geoff's report that I have just gotten back to work on this is correct. I'm going to want to get feedback on what I have done so far. Actually, the part I'm working on at the moment doesn't even involve anything high-tech, although I think eventually people are going to want the more elaborate facilities. Here is a tiny example of the sort of thing I can do now, and am going to want feedback on when I'm ready: static Dict test_dict() { // test the Dict class Dict a; a["hi"] = Stryng("ho"); return a; } static PyObject* ex_test (PyObject* self, PyObject* args) { try { List a; Tuple t(args); for(Tuple::iterator i = t.begin(); i != t.end(); i++) { a.append(*i); } a.append(test_numbers()); a.append(test_list()); a.append(test_dict()); return ort(a); } catch (const PyException&) { return Py_Null; } } So I would appreciate keeping this SIG alive until we've had more time to do this work. Or, as Jonathan Winters once remarked to a circling buzzard, "Hey, clown, I ain't dead yet!". -----Original Message----- From: Phil Austin To: Geoffrey M. Furnish Cc: Guido van Rossum ; meta-sig at python.org ; Python/C++ SIG ; dubois1 at llnl.gov Date: Wednesday, December 17, 1997 9:47 AM Subject: Re: [C++-SIG] RE: [META-SIG] Terminating comatose SIGs >>>>>> "GF" == Geoffrey M Furnish writes: > > > GF> If however, the PSA is willing to host discussion about > GF> binding Python to C++, then let's let this be the last time > GF> this issue has to be redecided. > >Here's two pieces of information that have a direct bearing on >the (future) impact of the Python/C++ Sig: > >1) As of last night, an expression template array library > (http://monet.uwaterloo.ca/blitz) that > pushes non-EDG-based C++ compilers beyond their limits works with > a GNU compiler (http://www.cygnus.com/egcs). > >2) Mumit Khan has succeeded in porting egcs-1.0 to windows95/NT using both > the cygwin and mingwin dlls. (http://www.xraylith.wisc.edu/~khan). > >This means: > >a) that the number of people able to compile and experiment with a > C++-extended python is about to increase by several orders of > magnitude. > >b) that the numerical performance increase made possible by expression > templates should focus attention on standard-conformance, STL > techniques, dead-code removal, incremental compilation, etc. The > better egcs gets in these areas, the more compelling the advantages > of the LLNL-modified python becomes. > >So the no-compromises approach of GF and PDB is about to pay off, and >it would be short-sighted to shut down the C++ sig 2 weeks after the >approval of the draft standard and the release of a near-standard >conforming free compiler. > >Regards, Phil > > > _______________ C++-SIG - SIG for Development of a C++ Binding to Python send messages to: c++-sig at python.org administrivia to: c++-sig-request at python.org _______________ From paul at ra.avid.com Wed Dec 17 22:01:51 1997 From: paul at ra.avid.com (Paul Miller) Date: Wed, 17 Dec 1997 15:01:51 -0600 Subject: [C++-SIG] RE: [META-SIG] Terminating comatose SIGs References: <01bd0b18$bd0feca0$998a7380@pduboispc> Message-ID: <34983DBF.37EE3A04@elastic.avid.com> Paul F. Dubois wrote: > Dict a; > a["hi"] = Stryng("ho"); > return a; nice. > try { > List a; > Tuple t(args); > for(Tuple::iterator i = t.begin(); i != t.end(); i++) { > a.append(*i); > } ... nicer! This all looks really good. What I'm even more interested in however is easier writing of Python extension classes in C++. I've done a bit of work here, as I'm providing a Python scripting interface into an object-oriented 3D graphics application I'm leading. FYI - I also did C++ wrappers for tuples and lists. However, I put my C++ Python wrappers in "namespace Python" to avoid name collisions with other things called "List" or "Tuple". I would recommend the same thing. Another thing I did that may be useful to others is when writing an extension function, I made some overloaded "Convert()" methods to call when returning common values. At the end of a function which is supposed to return Py_None for example, you just call: return Convert(); To return a "C" string, it's return Convert("my string"); I didn't get far with making the Py_HEAD stuff and method registration any nicer however. -- Paul T. Miller | paul at elastic.avid.com Principal Engineer | Opinions expressed here are my own. Avid Technology, Inc. Madison - Graphics and Effects Software Group _______________ C++-SIG - SIG for Development of a C++ Binding to Python send messages to: c++-sig at python.org administrivia to: c++-sig-request at python.org _______________ From dubois1 at llnl.gov Wed Dec 17 22:38:57 1997 From: dubois1 at llnl.gov (Paul F. Dubois) Date: Wed, 17 Dec 1997 13:38:57 -0800 Subject: [C++-SIG] RE: [META-SIG] Terminating comatose SIGs Message-ID: <01bd0b34$2de18040$998a7380@pduboispc> -----Original Message----- From: Paul Miller To: Paul F. Dubois ; Python/C++ SIG Date: Wednesday, December 17, 1997 1:03 PM Subject: Re: [C++-SIG] RE: [META-SIG] Terminating comatose SIGs >Paul F. Dubois wrote: > >> Dict a; >> a["hi"] = Stryng("ho"); >> return a; > >nice. > >> try { >> List a; >> Tuple t(args); >> for(Tuple::iterator i = t.begin(); i != t.end(); i++) { >> a.append(*i); >> } > >... nicer! > >This all looks really good. What I'm even more interested in however is >easier writing of Python extension classes in C++. I've done a bit of >work here, as I'm providing a Python scripting interface into an >object-oriented 3D graphics application I'm leading. Yes, that is certainly the goal. > >FYI - I also did C++ wrappers for tuples and lists. However, I put my >C++ Python wrappers in "namespace Python" to avoid name collisions with >other things called "List" or "Tuple". I would recommend the same thing. > Well, it is currently "namespace Py", but I'm flexible (:->. >Another thing I did that may be useful to others is when writing an >extension function, I made some overloaded "Convert()" methods to call >when returning common values. > >At the end of a function which is supposed to return Py_None for >example, you just call: > return Convert(); > >To return a "C" string, it's > return Convert("my string"); > >I didn't get far with making the Py_HEAD stuff and method registration >any nicer however. > In my current implementation, these might be: return ort(Py_None) (ort stands for "owned reference to") and return ort(Stryng("my string")) At the moment I have no implicit conversions of basic types into objects. Anyway, I'm not ready really to put this up as a straw man, so let's defer discussion of my fragment for now. >-- >Paul T. Miller | paul at elastic.avid.com >Principal Engineer | Opinions expressed here are my own. >Avid Technology, Inc. Madison - Graphics and Effects Software Group > >_______________ >C++-SIG - SIG for Development of a C++ Binding to Python > >send messages to: c++-sig at python.org >administrivia to: c++-sig-request at python.org >_______________ > _______________ C++-SIG - SIG for Development of a C++ Binding to Python send messages to: c++-sig at python.org administrivia to: c++-sig-request at python.org _______________ From robert at directed.edu Wed Dec 24 18:47:14 1997 From: robert at directed.edu (robert at directed.edu) Date: Wed, 24 Dec 1997 12:47:14 -0500 Subject: [C++-SIG] P R E S S R E L E A S E Message-ID: A non-text attachment was scrubbed... Name: not available Type: text/plain charset=us-ascii Size: 1374 bytes Desc: not available URL: