RE: Windows build error(s)
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Friday, June 22, 2007 3:42 AM To: stdcxx-dev@incubator.apache.org Subject: Re: Windows build error(s) I've found how to handle this error here: http://msdn2.microsoft.com/en-us/library/ms228772(vs.80).aspx Unfortunately, jscript don't present the possibility to install COM message filter, so I've just perform the call in a loop with sleep: http://svn.apache.org/viewvc?view=revrev=548682 This looks like an infinite loop. It might fix the problem with the build but I worry that it could cause trouble under some other error conditions. The MSDN fix also looks quite different (not to mention much more complicated). Isn't there some middle ground between the two approaches? Yes. The both approaches performs retry the call. E.g., could we loop only a limited number of times and only when the error was caused by the timing issue discussed on the MSDN page (if we can reliably detect it)? Perhaps that will help: http://svn.apache.org/viewvc?view=revrev=549748 Unfortunately I can't check how this patch works. Farid.
[jira] Created: (STDCXX-454) rwexcept example crashes due to using delete[] on static buffer
rwexcept example crashes due to using delete[] on static buffer --- Key: STDCXX-454 URL: https://issues.apache.org/jira/browse/STDCXX-454 Project: C++ Standard Library Issue Type: Bug Components: Examples Environment: All Reporter: Farid Zaripov Assignee: Farid Zaripov Fix For: 4.2 The rwexcept example crashes in function exception_handler() while performing delete[] what. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-455) [Cygwin] localedef errors: fatal error - could not load shell32, Win32 error 487
[Cygwin] localedef errors: fatal error - could not load shell32, Win32 error 487 Key: STDCXX-455 URL: https://issues.apache.org/jira/browse/STDCXX-455 Project: C++ Standard Library Issue Type: Bug Components: Locales Environment: Cygwin Reporter: Farid Zaripov Assignee: Farid Zaripov Fix For: 4.2 ar_IN.UTF-8, de_DE.UTF-8 and en_IN.UTF-8 locales are failed: 5437 [main] localedef 3260 d:\_projects\stdcxx_working\cygwin_15s\bin\localedef.exe: *** fatal error - could not load shell32, Win32 error 487 /bin/sh: line 5: 3260 Hangup ./localedef -w -c -f /cygdrive/d/_projects/stdcxx_working/etc/nls/charmaps/$cname -i /cygdrive/d/_projects/stdcxx_working/etc/nls/src/$lname /cygdrive/d/_projects/stdcxx_working/cygwin_15s/nls/ar_IN.UTF-8 make: *** [ar_IN.UTF-8] Error 129 5 [main] localedef 3444 d:\_projects\stdcxx_working\cygwin_15s\bin\localedef.exe: *** fatal error - could not load shell32, Win32 error 487 /bin/sh: line 5: 3444 Hangup ./localedef -w -c -f /cygdrive/d/_projects/stdcxx_working/etc/nls/charmaps/$cname -i /cygdrive/d/_projects/stdcxx_working/etc/nls/src/$lname /cygdrive/d/_projects/stdcxx_working/cygwin_15s/nls/de_DE.UTF-8 make: *** [de_DE.UTF-8] Error 129 5 [main] localedef 3952 d:\_projects\stdcxx_working\cygwin_15s\bin\localedef.exe: *** fatal error - could not load shell32, Win32 error 487 /bin/sh: line 5: 3952 Hangup ./localedef -w -c -f /cygdrive/d/_projects/stdcxx_working/etc/nls/charmaps/$cname -i /cygdrive/d/_projects/stdcxx_working/etc/nls/src/$lname /cygdrive/d/_projects/stdcxx_working/cygwin_15s/nls/en_IN.UTF-8 make: *** [en_IN.UTF-8] Error 129 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (STDCXX-353) [Cygwin] localedef errors: UCS value of symbolic character out of range
[ https://issues.apache.org/jira/browse/STDCXX-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov closed STDCXX-353. Resolution: Cannot Reproduce The new issue about locales: http://issues.apache.org/jira/browse/STDCXX-455 [Cygwin] localedef errors: UCS value of symbolic character out of range --- Key: STDCXX-353 URL: https://issues.apache.org/jira/browse/STDCXX-353 Project: C++ Standard Library Issue Type: Bug Components: Locales Affects Versions: 4.1.3 Environment: Cygwin Reporter: Mark Brown Assignee: Farid Zaripov On Cygwin, locale successfully builds all locales except zh_CN.GB18030 and zh_TW.EUC-TW: $ nice make -C../bin locales -k make: Entering directory `/home/mbrown/stdcxx-gcc-4.1.1-15s/bin' ./localedef -w -c -f /home/mbrown/stdcxx/etc/nls/charmaps/GB18030 -i /home/mbrown/stdcxx/etc/nls/src/zh_CN /home/mbrown/stdcxx-gcc-4.1.1-15s/nls/zh_CN.GB18030 Error 315: UCS value 66304 of symbolic character U00010300 out of range. make: *** [zh_CN.GB18030] Error 4 ./localedef -w -c -f /home/mbrown/stdcxx/etc/nls/charmaps/EUC-TW -i /home/mbrown/stdcxx/etc/nls/src/zh_TW /home/mbrown/stdcxx-gcc-4.1.1-15s/nls/zh_TW.EUC-TW Error 315: UCS value 131083 of symbolic character U0002000B out of range. make: *** [zh_TW.EUC-TW] Error 4 make: Target `locales' not remade because of errors. make: Leaving directory `/home/mbrown/stdcxx-gcc-4.1.1-15s/bin' -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (STDCXX-454) rwexcept example crashes due to using delete[] on static buffer
[ https://issues.apache.org/jira/browse/STDCXX-454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov closed STDCXX-454. rwexcept example crashes due to using delete[] on static buffer --- Key: STDCXX-454 URL: https://issues.apache.org/jira/browse/STDCXX-454 Project: C++ Standard Library Issue Type: Bug Components: Examples Environment: All Reporter: Farid Zaripov Assignee: Farid Zaripov Fix For: 4.2 The rwexcept example crashes in function exception_handler() while performing delete[] what. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-455) [Cygwin] localedef errors: fatal error - could not load shell32, Win32 error 487
[ https://issues.apache.org/jira/browse/STDCXX-455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12507294 ] Farid Zaripov commented on STDCXX-455: -- Unable to debug this problem. Under strace or gdb all works fine. [Cygwin] localedef errors: fatal error - could not load shell32, Win32 error 487 Key: STDCXX-455 URL: https://issues.apache.org/jira/browse/STDCXX-455 Project: C++ Standard Library Issue Type: Bug Components: Locales Environment: Cygwin Reporter: Farid Zaripov Assignee: Farid Zaripov Fix For: 4.2 ar_IN.UTF-8, de_DE.UTF-8 and en_IN.UTF-8 locales are failed: 5437 [main] localedef 3260 d:\_projects\stdcxx_working\cygwin_15s\bin\localedef.exe: *** fatal error - could not load shell32, Win32 error 487 /bin/sh: line 5: 3260 Hangup ./localedef -w -c -f /cygdrive/d/_projects/stdcxx_working/etc/nls/charmaps/$cname -i /cygdrive/d/_projects/stdcxx_working/etc/nls/src/$lname /cygdrive/d/_projects/stdcxx_working/cygwin_15s/nls/ar_IN.UTF-8 make: *** [ar_IN.UTF-8] Error 129 5 [main] localedef 3444 d:\_projects\stdcxx_working\cygwin_15s\bin\localedef.exe: *** fatal error - could not load shell32, Win32 error 487 /bin/sh: line 5: 3444 Hangup ./localedef -w -c -f /cygdrive/d/_projects/stdcxx_working/etc/nls/charmaps/$cname -i /cygdrive/d/_projects/stdcxx_working/etc/nls/src/$lname /cygdrive/d/_projects/stdcxx_working/cygwin_15s/nls/de_DE.UTF-8 make: *** [de_DE.UTF-8] Error 129 5 [main] localedef 3952 d:\_projects\stdcxx_working\cygwin_15s\bin\localedef.exe: *** fatal error - could not load shell32, Win32 error 487 /bin/sh: line 5: 3952 Hangup ./localedef -w -c -f /cygdrive/d/_projects/stdcxx_working/etc/nls/charmaps/$cname -i /cygdrive/d/_projects/stdcxx_working/etc/nls/src/$lname /cygdrive/d/_projects/stdcxx_working/cygwin_15s/nls/en_IN.UTF-8 make: *** [en_IN.UTF-8] Error 129 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: STDCXX examples fails and reasons [MSVC]
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Thursday, June 21, 2007 8:56 PM To: stdcxx-dev@incubator.apache.org Subject: Re: STDCXX examples fails and reasons [MSVC] [...] limits.cpp should produce the qnan for Quiet NAN and snan for Signaling NAN on all platforms. I can't find this requirement in standard. The MSVC/Dinkumware STL produces: static double infinity () = 1.#INF; static double quiet_NaN () = 1.#QNAN; static double signaling_NaN () = 1.#QNAN; The gcc 3.4.4/SGI STL/Cygwin produces: static double infinity () = inf; static double quiet_NaN () = nan; static double signaling_NaN () = nan; Farid.
RE: STDCXX examples fails and reasons [MSVC]
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Thursday, June 21, 2007 8:56 PM To: stdcxx-dev@incubator.apache.org Subject: Re: STDCXX examples fails and reasons [MSVC] [...] time_get looks like a bug (or lack of functionality) in our library time_get::date_order() returns time_get::do_date_order() which always returns dateorder () == no_order (loc/_time_get.h; line 137). Also I observed that time_get::~time_get() should be protected (22.2.5.1), but in our library the time_get::~time_get() is not declared/defined. The same situation with ~time_get_byname(), ~time_put(), ~time_put_byname(). Farid.
Re: STDCXX examples fails and reasons [MSVC]
Farid Zaripov wrote: -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Thursday, June 21, 2007 8:56 PM To: stdcxx-dev@incubator.apache.org Subject: Re: STDCXX examples fails and reasons [MSVC] [...] limits.cpp should produce the qnan for Quiet NAN and snan for Signaling NAN on all platforms. I can't find this requirement in standard. It's not in the C++ standard but it is in C99, under fprintf(), the f and F conversion specifier: A double argument representing an infinity is converted in one of the styles [-]inf or [-]infinity — which style is implementation-defined. A double argument representing a NaN is converted in one of the styles [-]nan or [-]nan(n-char-sequence) — which style, and the meaning of any n-char-sequence, is implementation-defined. The F conversion specifier produces INF, INFINITY, or NAN instead of inf, infinity, or nan, respectively. Martin
Re: svn commit: r549586 - /incubator/stdcxx/trunk/src/exception.cpp
Farid Zaripov wrote: -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Friday, June 22, 2007 3:02 AM To: stdcxx-dev@incubator.apache.org Subject: Re: svn commit: r549586 - /incubator/stdcxx/trunk/src/exception.cpp As you astutely observed in a previous discussion of the issue (at the link below), __rw_free_what_buf() should be extern _RWSTD_EXPORT, to be accessible by user in overridden __rw_throw_proc() otherwise there will be no way for users to avoid a leak in their replacement __rw_throw_proc(). http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg02192.htm l Yes, I remember that. This would be separated patch. Gotcha! Let's make sure to do that (or open a new issue). Also, while it's too late to fix it for this commit, the ChangeLog entry is missing a reference to the Jira issue number it resolves. Please remember to include it future changes, especially those to the library. The bug-fixing patch was here: http://svn.apache.org/viewvc?view=revrev=549584 Ah, okay. Anyway that patch is also related to the STDCXX-293, and is never late to correct the ChangeLog :) http://www.mail-archive.com/[EMAIL PROTECTED]/msg01322 .html We can change the ChangeLog this way but it won't make the Jira Subversion plugin pick up the reference to the patch so the patch won't show up on the Subversion Commits tab. See https://issues.apache.org/jira/browse/INFRA-624 Martin
Re: STDCXX examples fails and reasons [MSVC]
Farid Zaripov wrote: -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Thursday, June 21, 2007 8:56 PM To: stdcxx-dev@incubator.apache.org Subject: Re: STDCXX examples fails and reasons [MSVC] [...] time_get looks like a bug (or lack of functionality) in our library time_get::date_order() returns time_get::do_date_order() which always returns dateorder () == no_order (loc/_time_get.h; line 137). Right. We ran out of time when implementing the facet. The standard doesn't require us to do any better so there hasn't been a lot of pressure to get back to it and finish the job, but that doesn't mean we should never do it. From a QoI point of view we definitely should. Also I observed that time_get::~time_get() should be protected (22.2.5.1), but in our library the time_get::~time_get() is not declared/defined. Yes, it is declared as protected in the standard to prevent standalone facet objects from being constructed. I'm not sure that's a detectable requirement. Violations of the requirement are detectable by non-conforming programs, but I can't think of a way how conformance to it could be detected -- can you? The same situation with ~time_get_byname(), ~time_put(), ~time_put_byname(). Our implementation lets users construct facet objects and use (at least some) them directly rather than going through the use_facet interface, which seems like a reasonable thing to do. Can you think of a reason not to keep this extension? Martin
Re: svn commit: r549766 - in /incubator/stdcxx/trunk: examples/manual/rwexcept.cpp include/rw/_error.h src/exception.cpp
[EMAIL PROTECTED] wrote: Author: faridz Date: Fri Jun 22 03:15:46 2007 New Revision: 549766 URL: http://svn.apache.org/viewvc?view=revrev=549766 [...] Modified: incubator/stdcxx/trunk/include/rw/_error.h URL: http://svn.apache.org/viewvc/incubator/stdcxx/trunk/include/rw/_error.h?view=diffrev=549766r1=549765r2=549766 == --- incubator/stdcxx/trunk/include/rw/_error.h (original) +++ incubator/stdcxx/trunk/include/rw/_error.h Fri Jun 22 03:15:46 2007 @@ -39,9 +39,12 @@ // (if any) used to format the exception object's what() string void _RWSTD_EXPORT __rw_throw (int, ...); +// frees memory buffer used for what() message +void _RWSTD_EXPORT __rw_free_what_buf (char*); ^ [...] Modified: incubator/stdcxx/trunk/src/exception.cpp URL: http://svn.apache.org/viewvc/incubator/stdcxx/trunk/src/exception.cpp?view=diffrev=549766r1=549765r2=549766 == --- incubator/stdcxx/trunk/src/exception.cpp (original) +++ incubator/stdcxx/trunk/src/exception.cpp Fri Jun 22 03:15:46 2007 @@ -438,10 +438,13 @@ static _RWSTD_THREAD int __rw_what_refcnt; -inline void __rw_free_what_buf (char* buf) +// free memory buffer allocated in __rw_vfmtwhat() +_RWSTD_EXPORT inline void __rw_free_what_buf (char* buf) From 7.1.2, p4: If a function with external linkage is declared inline in one translation unit, it shall be declared inline in all translation units in which it appears; no diagnostic is required. Also, I think the convention used in the rest of the code is to put _RWSTD_EXPORT before the return type of the function, but you might want to double-check that. Either way, it should be consistent between the declaration and the definition of the function. Martin
Re: svn commit: r549586 - /incubator/stdcxx/trunk/src/exception.cpp
Farid Zaripov wrote: -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Friday, June 22, 2007 6:07 PM To: stdcxx-dev@incubator.apache.org Subject: Re: svn commit: r549586 - /incubator/stdcxx/trunk/src/exception.cpp Yes, I remember that. This would be separated patch. Gotcha! Let's make sure to do that (or open a new issue). Already done: https://issues.apache.org/jira/browse/STDCXX-454 We can change the ChangeLog this way but it won't make the Jira Subversion plugin pick up the reference to the patch so the patch won't show up on the Subversion Commits tab. See https://issues.apache.org/jira/browse/INFRA-624 Now I understand. Btw why not to extend the JIRA interface to enable to add references to the svn manually? It would cetainly make a lot of sense. I added my vote to the open Jira issues that request this ability. You might want to do the same: http://jira.atlassian.com/browse/SVN-40 http://jira.atlassian.com/browse/SVN-138 Martin
RE: svn commit: r549766 - in /incubator/stdcxx/trunk: examples/manual/rwexcept.cpp include/rw/_error.h src/exception.cpp
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Friday, June 22, 2007 6:38 PM To: stdcxx-dev@incubator.apache.org Subject: Re: svn commit: r549766 - in /incubator/stdcxx/trunk: examples/manual/rwexcept.cpp include/rw/_error.h src/exception.cpp [...] From 7.1.2, p4: If a function with external linkage is declared inline in one translation unit, it shall be declared inline in all translation units in which it appears; no diagnostic is required. Also, I think the convention used in the rest of the code is to put _RWSTD_EXPORT before the return type of the function, but you might want to double-check that. Either way, it should be consistent between the declaration and the definition of the function. Done: http://svn.apache.org/viewvc?view=revrev=549862 Farid.
Re: svn commit: r549766 - in /incubator/stdcxx/trunk: examples/manual/rwexcept.cpp include/rw/_error.h src/exception.cpp
Farid Zaripov wrote: -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Friday, June 22, 2007 6:38 PM To: stdcxx-dev@incubator.apache.org Subject: Re: svn commit: r549766 - in /incubator/stdcxx/trunk: examples/manual/rwexcept.cpp include/rw/_error.h src/exception.cpp [...] From 7.1.2, p4: If a function with external linkage is declared inline in one translation unit, it shall be declared inline in all translation units in which it appears; no diagnostic is required. Also, I think the convention used in the rest of the code is to put _RWSTD_EXPORT before the return type of the function, but you might want to double-check that. Either way, it should be consistent between the declaration and the definition of the function. Done: http://svn.apache.org/viewvc?view=revrev=549862 Sorry, this violates the last sentence of 3.2, p3: An inline function shall be defined in every translation unit in which it is used. Martin
RE: STDCXX examples fails and reasons [MSVC]
-Original Message- From: Farid Zaripov [mailto:[EMAIL PROTECTED] Sent: Friday, June 22, 2007 7:30 PM To: stdcxx-dev@incubator.apache.org Subject: RE: STDCXX examples fails and reasons [MSVC] I have updated the windows build infrastructure to set TZ environment variable before run examples. I've forget to specify the URL with changes: http://svn.apache.org/viewvc?view=revrev=549865 Farid.
Re: Windows build error(s)
Farid Zaripov wrote: -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Friday, June 22, 2007 3:42 AM To: stdcxx-dev@incubator.apache.org Subject: Re: Windows build error(s) I've found how to handle this error here: http://msdn2.microsoft.com/en-us/library/ms228772(vs.80).aspx Unfortunately, jscript don't present the possibility to install COM message filter, so I've just perform the call in a loop with sleep: http://svn.apache.org/viewvc?view=revrev=548682 This looks like an infinite loop. It might fix the problem with the build but I worry that it could cause trouble under some other error conditions. The MSDN fix also looks quite different (not to mention much more complicated). Isn't there some middle ground between the two approaches? Yes. The both approaches performs retry the call. E.g., could we loop only a limited number of times and only when the error was caused by the timing issue discussed on the MSDN page (if we can reliably detect it)? Perhaps that will help: http://svn.apache.org/viewvc?view=revrev=549748 Unfortunately I can't check how this patch works. Okay, this makes me feel better. Thanks Martin
RE: STDCXX examples fails and reasons [MSVC]
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 21, 2007 8:56 PM
To: stdcxx-dev@incubator.apache.org
Subject: Re: STDCXX examples fails and reasons [MSVC]
[...]
time_put like a bug in our infrastructure (I assume the
example assumes a certain time zone and it's being run in
another). The latter could (should?) be fixed by setting
the TZ environment variable time zone to the expected zone
before invoking this example.
I have updated the windows build infrastructure to set TZ environment
variable
before run examples. The proposed similar changes in unix infrastructure
below,
but I'm not sure that is correct:
Index: makefile.rules
===
--- makefile.rules (revision 549750)
+++ makefile.rules (working copy)
@@ -119,8 +119,9 @@
PATH=$$PATH:.;
\
TOPDIR=$(TOPDIR);
\
TMP=$${TMP:-/tmp}/stdcxx-run-;
\
+TZ=MST+7;
\
export TMP;
\
-export LD_LIBRARY_PATH PATH TMP TOPDIR;
\
+export LD_LIBRARY_PATH PATH TMP TOPDIR TZ;
\
trap rm -rf $$TMP HUP INT QUIT TERM EXIT;
\
mkdir -p $$TMP;
\
./run $(RUNFLAGS) $(RUNTARGET);
\
@@ -133,8 +134,9 @@
PATH=$$PATH:$(LIBDIR):.;
\
TOPDIR=$(TOPDIR);
\
TMP=$${TMP:-/tmp}/stdcxx-run-;
\
+TZ=MST+7;
\
export TMP;
\
-export LD_LIBRARY_PATH PATH TMP TOPDIR;
\
+export LD_LIBRARY_PATH PATH TMP TOPDIR TZ;
\
trap rm -rf $$TMP HUP INT QUIT TERM EXIT;
\
mkdir -p $$TMP;
\
./run $(RUNFLAGS) $(RUNTARGET);
\
Farid.
Getting incorrect behavior on strstream
I have a testcase that is showing incorrect behavior ostrstream or
ostringstream:
#include cstdio
#include iostream
#include iomanip
#include sstream
#include strstream
#include cmath
void test1() {
std::ostringstream S;
long double x = std::pow(1e300,2);
S Somethingstd::setprecision(8) x;
S else;
std::printf(Test1: %s\n, S.str().c_str());
}
void test2() {
std::ostrstream S;
long double x = std::pow(1e300,2);
S Something std::setprecision(7) x;
S else;
std::printf(Test2: %s\n, S.str());
}
void test3() {
std::ostrstream S;
long double x = 0.0/0.0;
S Something std::setprecision(8) x;
S else;
std::printf(Test3: %s\n, S.str());
}
int main(int argc, char* argv[]) {
test1();
test2();
test3();
}
On solaris 8 with Sun Studio 8 patch 14 I get the following output
Test1: Something inf
Test2: Something inf else else
Test3: Something nan else
Test1 is missing else
Test2 has an extra else
Test3 looks ok.
On RedHat 3u6 I get the following output:
Test1: Something inf else
Test2: Something inf else
Test3: Something nan elseing inf else
Test1 and 2 look ok
Test3 however has extra output ing inf else
Any thoughts on this problem?
Thanks,
Jeremy
Jeremy Dean
Rogue Wave Software,
A QUOVADX(tm) division
Technical Support
Phone: 303-545-3205 -- 1-800-404-4767
E-mail: [EMAIL PROTECTED]
Web: http://www.roguewave.com/support
Knowledge Base entries:
http://www.roguewave.com/kbdocs/search.html
View issues online at:
http://www.roguewave.com/youraccount/login/
Re: STDCXX progress to graduation
William A. Rowe, Jr. wrote: Noel J. Bergman wrote: William A. Rowe, Jr. wrote: [...] things are as quiet as expected for a mature implementation of a reference standard. Any concern that because of the maturity, it could stagnate and lose community? Not at this time. Because it is widely deployed, there will be a long term demand. Because it's transparent to the developer, and in debugging their apps they can drill right into flaws within stdcxx, I suspect we will see bug feedback folks turn patchers turn contributors turn project members for years, as long as C++ is a widely adopted language. I have little to add to Bill and Justin's encouraging comments, except that the C++ standard is currently being revised and a new, significantly extended one is close to being completed, and is expected to be ratified in the 2010 timeframe. Many new features have already been added to the standard and more still are in the works. We are looking forward to fully implementing all of the new components after the upcoming 4.2 release of stdcxx. We expect to attract even more users to the project with this milestone release, and to grow the community of contributors in the coming months to help us with the implementation of the many new features. Graduating from the incubator will be a crucial step in reaching these goals and ensuring an wider adoption of the project. Martin
