RE: type_traits and other things
I'm not sure about these non-ASF copyrights. Yes these are a pain in the (*|*) and before I do anything we'll go over a cut. I have a friend who may be interested in helping in the legal area, I'll try to remember to ask tomorrow. He is a NY Bar member who specializes in software issues, and helped me a lot with getting my employer comfortable in my involvement with ASF. The copyright is largely like the all the STL implementations carrying the HP license. It would be hard to get rid of the reference version license, and after all, they did come up with the design. Most of the other stuff may be doable, but in any case the licenses would be of the no warranty type, and far less stringent that the Stallman variety licenses, i.e. no copylefts. In any case, any non-ASF license would make it non-deployable, and not much use. The commit then review would be very helpful, at least to a separate work-in-progress area. Doing this for the Cygwin port would help too. I'm finishing up some changes that I hope will be a differentiating point from the boost implementation, and giving it a shot at work now -- no interface or semantic changes, of course, just more options in the implementations (like different ways of handling undefined behavior), and beefier tests. Lance -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 28, 2005 4:52 PM To: stdcxx-dev@incubator.apache.org Subject: Re: type_traits and other things Lance Diduck wrote: On shared_ptr and type_traits -- I've requested to copyright release and IP review from work, that could take a couple of weeks. I have most of Sections 2 and 4. Most of this stuff will be crammed with various copyrights, from boost, a couple of books (notably Vandevoorde and Josuttiss), and other attributions to different contributors collected over the course of time. I'm not sure about these non-ASF copyrights. AFAIK, the ASF frowns on, or at least questions such things, even if they are compatible with the Apache License. Our mentors will need to take a look at it and give their yay or nay before we can use the code. It would be easier to get rid of as much as you legally can. The easiest way to separate them IMHO would be to have them in a working directory separate from the existing std stuff. This area would not follow the review then commit rules. The rule would only apply when the library was voted for release, and then merged to 'tr1' or whatever it would be called upon vote. Then the rule applies. Going the commit-then-review route sounds like a sensible approach for new files. I believe some of the TR1 bits are mixed in with the existing stuff so at least in some cases people will need to do both (touch the existing headers in addition to the experimental ones). To isolate the changes in the existing headers we'll need to guard them all with some macro (such as _RWSTD_EXT_TR1). We might also want to consider creating a separate branch for TR development. The Clearcase SCCS makes this easy, and I'll have to find out how to do this with SVN. My initial thought on the directory layout for the TR1 stuff is simply to add include/tr1/ -- TR1 headers src/tr1/ -- TR1 sources The thing to decide on will be the mechanism to enable the TR1 bits in our builds. We could require that a macro be set in addition to adding -Itr1 to the preprocessor options or require only that -Itr1 be before any other -I options so that its headers are found before any existing headers with the same name. We finished up a shared_ptr regression tester at work as well, tests shared_ptr but does no rely on the fact that the template is called shared_ptr. Allows testing of a number of implementations without changing the tester. Make what-if analysis far far easier. We'll definitely need tests for all TR contributions. I'm still refining the test driver but most of it is already in place. Whenever you have a chance it would be great if you could take a look at it and post your feedback. Martin
[PATCH] ---[Cygwin] messages.cpp needs catopen, catgets etc
http://issues.apache.org/jira/browse/STDCXX-23 The current working version of the code does not link for gcc cygwin. This is a temporary fix to at least allow it to link and run the tests, until STDCXX-23 is fully resolved. 1993-05-25 Lance Diduck [EMAIL PROTECTED] * gcc.config chage LDLIBS (manual-entry): temporary fix to allow full build with interrupts on Cygwin.
[jira] Commented: (STDCXX-12) publish Class Reference and User Guide on the stdcxx site
[ http://issues.apache.org/jira/browse/STDCXX-12?page=comments#action_12330685 ] Lance Diduck commented on STDCXX-12: Or, just make the Class Reference and User Guide hyperlinks point directly to booktoc That may work i.e. http://svn.apache.org/repos/asf/incubator/stdcxx/trunk/doc/stdlibref/index.html intead of http://svn.apache.org/repos/asf/incubator/stdcxx/trunk/doc/stdlibref/ publish Class Reference and User Guide on the stdcxx site - Key: STDCXX-12 URL: http://issues.apache.org/jira/browse/STDCXX-12 Project: STDCXX Type: Improvement Components: Web Versions: 4.1.2 Environment: All Reporter: Martin Sebor Priority: Critical Fix For: 4.1.3 The stdcxx documentation in svn needs to be published in a browsable format on the project Web site. Currently only the sources in svn are viewable. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (STDCXX-24) [Cygwin] collate.cpp needs wcsnxfrm
[ http://issues.apache.org/jira/browse/STDCXX-24?page=all ] Lance Diduck updated STDCXX-24: --- Description: Martin Sebor paraphrased: Cygwin really doesn't define wcsnxfrm() (i.e., both _RWSTD_NO_WCSXFRM and _RWSTD_NO_WCSXFRM_IN_LIBC are #defined) we should probably implement our own transformation. Looking at collate.cpp, though, I don't see a check for _RWSTD_NO_WCSXFRM_IN_LIBC, just for the former (which only determines whether function is declared; the latter tells us if it's also not defined). was: http://sources.redhat.com/ml/cygwin/2004-04/msg00679.html shows that libc does not have catopen, catgets, etc. Library compiles but does not link. A recent thread (Jun 2005) discusses adding libcatgets http://blog.gmane.org/gmane.os.cygwin.applications/month=20050601 There are at least these approaches: 1. Implement the missing stuff ourselves 2. Implement messages.cpp in terms of the underlying Windows messaging subsystem (i.e. FormatMessage, etc) 3. Require libcatgets , change build [Cygwin] collate.cpp needs wcsnxfrm --- Key: STDCXX-24 URL: http://issues.apache.org/jira/browse/STDCXX-24 Project: STDCXX Type: Bug Components: 22. Localization Versions: 4.1.2 Environment: Cygwin Reporter: Lance Diduck Fix For: 4.1.3 Martin Sebor paraphrased: Cygwin really doesn't define wcsnxfrm() (i.e., both _RWSTD_NO_WCSXFRM and _RWSTD_NO_WCSXFRM_IN_LIBC are #defined) we should probably implement our own transformation. Looking at collate.cpp, though, I don't see a check for _RWSTD_NO_WCSXFRM_IN_LIBC, just for the former (which only determines whether function is declared; the latter tells us if it's also not defined). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: stdcxx documentation format
Alessio Marchetti wrote: Template-based code is recompiled even when there are no changes in the code and I think compliers are smart enough not to recreate template instantiations when a comment changes. Are there other facets I'm missing? The build system itself (ours or a users) cannot tell the difference between a code change and a documentation change. The compiler will indeed skip over the documentation, but the build system still invokes the compiler for every translation unit depending on the file timestamp, no matter what changes. The versioning system used is also based on file timestamps, and not what actually changed in the file. Additionally, template libraries are released in source code form -- this is stark contrast to the libraries normally associated with compiled languages. Adding the documentation in with the source code implies that the documentation follows the same identical release process that the library itself does, and that the source code follows the same release process that the docs do. But documentation changes depend more on source code changes than the other way around --not that writing the user guide before designing a library isn't a good idea, but in our case the library interface is already specified by committee. What I started doing with Doxygen is creating .ipp files that included the .hpp files of interest. This had the desired effect of making the documentation depend on the code, but not the other way around. See http://www.stack.nl/~dimitri/doxygen/docblocks.html I'm not sure I understand: are you talking about the yellow box (the base class) at http://www.alessio.marchetti.name/test/doxy/structtr1_1_1is__class.html More that the generated documentation does not make any distinction between the user interface and the implementation details. http://www.alessio.marchetti.name/test/doxy/structtr1_1_1detail_1_1is__class __impl.html If we do use a tool like Doxygen (or any tool that generated docs from code) then the source code will have to be separated or otherwise account for how the doc tool works. This isn't hard though. Lance -Original Message- From: Alessio Marchetti [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 07, 2005 8:48 AM To: stdcxx-dev@incubator.apache.org Subject: Re: stdcxx documentation format Lance Diduck wrote: 2. Putting the documentation in the code always sounds like a good idea, but consider that in the STL most of the docs would go in headers, that any change in headers (including docs) forces a recompilation and a new release of code, that source headers are already busy with copyright notices, revision and other coder comments not relevant to a user, porting macros, and other things. You are raising two interesting points: 1. Header files become difficult to read with too many comments. I understand, but this is subjective. I don't agree just because comments can be easily skipped when reading the header file as they are colored differently. Additionally, with Doxygen it is possible to link a verbatim copy (with Doxygen commands removed) of the source in the generated documentation: users of the library don't need to view the headers to read the code (go to the verbatim copy instead, if they have a browser of course...). The size of the headers will increase with comments inside and this can affect compilation time. Maybe this was implied in your comment. 2. Any change to the doc triggers a recompilation Template-based code is recompiled even when there are no changes in the code and I think compliers are smart enough not to recreate template instantiations when a comment changes. Are there other facets I'm missing? However template metaprograms, are almost nothing but declarations. It is possible to get Doxygen to read this and put in the links, but separating out the implementation (i.e. the detail code) from the interface' is solely a job of the documentation. I'm not sure I understand: are you talking about the yellow box (the base class) at http://www.alessio.marchetti.name/test/doxy/structtr1_1_1is__class.html ? I agree this is rather ugly! Alessio
RE: svn co
OK managed to install cygwin subversion client, things seems to be downloading ..except for atomic.S OK I'll try some more later... -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Sunday, August 28, 2005 5:17 PM To: Lance Diduck Cc: stdcxx-dev@incubator.apache.org Subject: Re: svn co Lance Diduck wrote: I'll let you know how the Cygwin client turns out, its still downloading. I'll still have to work around the case issues. (The solution I did come up with is to do a svn list, copy the files names, exclude the problem files, and then do svn cp on each file. Subversion doesn't like this, and requires doing each directory by hand ( no recursion,) and everything stays locked. Subversion solves the issue by asserting that they are a case -insensitive repository. Yeah, that sounds like a pain. We need to rename those two files. [...] But I run across dueling STL implementation problems quite often in fact, so much so that I don't allow any STL containers, streams and such in the public interfaces of the code my teams writes. Apart from stream initialization problems, this was the first time I had trouble making two STLs coexist. That (missing two implementations in the same program) is the subject of stdcxx-1: http://svn.apache.org/viewcvs.cgi/incubator/stdcxx/. Since you have experience in this area your insight will be valuable in getting it implemented. [...] BTW I tried to subscribe to the mailing list and got this unusual error - The following addresses had permanent fatal errors - [EMAIL PROTECTED] (reason: 553 sorry, that domain isn't in my list of allowed rcpthosts (#5.7.1)) It's .org, not .com. Martin
