RE: [PING] Re: library and build sizes on Windows
Hi all! I assume you're not in C/C++ ? There you could get the times you want with the GetProcessTimes() API. I don't think that theres a ready to use programm like /bin/time for this, but it should't be too hard to write something like this. Cheers, Markus Martin Sebor mailto:[EMAIL PROTECTED] wrote: author=Farid Zaripov-2 -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Thursday, November 22, 2007 2:19 AM To: stdcxx-dev@incubator.apache.org Subject: [PING] Re: library and build sizes on Windows So would be it possible to change the Windows build infrastructure to spit out the date and time in the same format as on UNIX? I.e., ### date: Wed Oct 31 09:38:50 UTC 2007 Including the ### date: part. The exact format of the timestamp itself doesn't have to be exactly the same just as long as it includes the time as well as the date, and it's all on the same line. Done: http://svn.apache.org/viewvc?rev=598697view=rev Farid. I've been doing some work on the test result scripts over the weekend and noticed a whole bunch of places where we print out the date on Windows (I counted 12). I dealt with it by trimming all but the first one from the log when processing it but we should probably get rid of all the extra dates and either replace them with the same output as on UNIX if possible (i.e., real, user, ans system times) or just the real time. Can this be done on Windows? Martin -- 5. Dezember 2007 Salomon Automation am Schweizer Forum fur Logistik, Lausanne, CH Salomon Automation GmbH - Friesachstrasse 15 - A-8114 Friesach bei Graz Sitz der Gesellschaft: Friesach bei Graz UID-NR:ATU28654300 - Firmenbuchnummer: 49324 K Firmenbuchgericht: Landesgericht fur Zivilrechtssachen Graz
Re: [PING] Re: library and build sizes on Windows
Duft Markus wrote: Hi all! I assume you're not in C/C++ ? That's right. I think the Windows scripts are written in some Microsoft flavor of JavaScript or some such scripting language. There you could get the times you want with the GetProcessTimes() API. I don't think that theres a ready to use programm like /bin/time for this, but it should't be too hard to write something like this. We need to get the date at the start of the build, before the compiler has been detected, so I'm hoping it can be done in the VisualStudio JavaScript to avoid having to compile it. Martin Cheers, Markus Martin Sebor mailto:[EMAIL PROTECTED] wrote: author=Farid Zaripov-2 -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Thursday, November 22, 2007 2:19 AM To: stdcxx-dev@incubator.apache.org Subject: [PING] Re: library and build sizes on Windows So would be it possible to change the Windows build infrastructure to spit out the date and time in the same format as on UNIX? I.e., ### date: Wed Oct 31 09:38:50 UTC 2007 Including the ### date: part. The exact format of the timestamp itself doesn't have to be exactly the same just as long as it includes the time as well as the date, and it's all on the same line. Done: http://svn.apache.org/viewvc?rev=598697view=rev Farid. I've been doing some work on the test result scripts over the weekend and noticed a whole bunch of places where we print out the date on Windows (I counted 12). I dealt with it by trimming all but the first one from the log when processing it but we should probably get rid of all the extra dates and either replace them with the same output as on UNIX if possible (i.e., real, user, ans system times) or just the real time. Can this be done on Windows? Martin
Re: [PATCH] STDCXX-507 (or using __declspec(dllexport/dllimport on gcc/cygwin in shared builds)
Martin Sebor wrote: Travis Vitek wrote: It seems that the problem is that the Cygwin environment defines part of the C++ runtime library in the C library. It does? I don't see any such symbols in the localedef.imports file attached to STDCXX-507 (although there are a lot symbols there so I could have easily missed them). Maybe I'm totally off base, but it appears that Farid is trying to avoid exporting set_unexpected, unexpected, set_terminate, terminate, uncaught_exception and the exception types. Aren't all of these things from the support library? Why would it help us to not export them? -- View this message in context: http://www.nabble.com/-PATCH--STDCXX-507-%28or-using-__declspec%28dllexport-dllimport-on-gcc-cygwin-in-shared-builds%29-tp14217944p14257248.html Sent from the stdcxx-dev mailing list archive at Nabble.com.
Re: mailing list for Jira issues?
Martin Sebor wrote: STDCXX-546 suggests we create a separate mailing list to reflect Jira traffic to so as to relieve stdcxx-dev from all the traffic. Since we have just asked INFRA to move our mailing lists from the Incubator to TLP (https://issues.apache.org/jira/browse/INFRA-1422) this would be a good time to make this change. How does everyone feel about it? https://issues.apache.org/jira/browse/STDCXX-546 I have no objections. Either way, I need to look at both sets of messages regardless of where they come from. So, for me, moving the Jira messages to a new -issues list doesn't have any significant impact. I guess it might be useful for users with 'dumb' e-mail clients that don't have proper message filtering. It might be useful for those who want to be involved in votes or notifications that are on the -dev list, but don't want to be involved in the project enough to actually deal with or hear about issues in Jira. Travis -- View this message in context: http://www.nabble.com/mailing-list-for-Jira-issues--tp14248354p14257741.html Sent from the stdcxx-dev mailing list archive at Nabble.com.
[jira] Commented: (STDCXX-664) [IBM XLC++ 9.0/AIX 5.3] SIGABRT in 22.locale.globals.mt
[
https://issues.apache.org/jira/browse/STDCXX-664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12550136
]
Travis Vitek commented on STDCXX-664:
-
The issue is that somehow the classic locale on AIX actually seems to have the
_byname facets installed. The following testcase demonstrates.
[EMAIL PROTECTED] tests]$ cat t.cpp
#include locale
#include stdio.h
int main ()
{
#define TEST(Facet) \
try { \
std::use_facetFacet(classic); \
fprintf (stderr, found facet %s in locale %s\n, \
#Facet, classic.name ().c_str ()); \
} \
catch (...) { \
}
const std::locale classic (std::locale::classic ());
typedef std::ctype_bynamechar ctype_byname;
TEST (ctype_byname);
typedef std::collate_bynamechar collate_byname;
TEST (collate_byname);
typedef std::messages_bynamechar messages_byname;
TEST (messages_byname);
typedef std::numpunct_bynamechar numpunct_byname;
TEST (numpunct_byname);
typedef std::time_get_bynamechar time_get_byname;
TEST (time_get_byname);
typedef std::time_put_bynamechar time_put_byname;
TEST (time_put_byname);
return 0;
}
[IBM XLC++ 9.0/AIX 5.3] SIGABRT in 22.locale.globals.mt
---
Key: STDCXX-664
URL: https://issues.apache.org/jira/browse/STDCXX-664
Project: C++ Standard Library
Issue Type: Bug
Components: Tests
Affects Versions: 4.2.0
Reporter: Travis Vitek
Assignee: Travis Vitek
Fix For: 4.2.1
Appears to affect single-threaded bulids only.
[EMAIL PROTECTED] tests]$ ./22.locale.globals.mt
# INFO (S1) (10 lines):
# TEXT:
# COMPILER: IBM VisualAge C++, __IBMCPP__ = 900
# ENVIRONMENT: powerpc running aix-5.3
# FILE: 22.locale.globals.mt.cpp
# COMPILED: Nov 8 2007, 21:35:16
# COMMENT: thread safety
# CLAUSE: lib.locale.global.templates
# NOTE (S2) (5 lines):
# TEXT: executing locale -a /tmp/tmpfile-fK3jqa
# CLAUSE: lib.locale.global.templates
# FILE: process.cpp
# LINE: 270
# INFO (S1) (3 lines):
# TEXT: testing std::locale globals with 1 thread, 2 iterations each, in
16 locales { C POSIX AR_DZ.UTF-8 AR_BH AR_AA.UTF-8 AR_BH.UTF-8
AR_AE.UTF-8 AR_DZ AR_EG.UTF-8 AR_EG AR_AE AR_AA AR_JO
AR_JO.UTF-8 AR_KW AR_KW.UTF-8 }
# CLAUSE: lib.locale.global.templates
# INFO (S1) (3 lines):
# TEXT: template class T bool std::has_facet (const locale)
# CLAUSE: lib.locale.global.templates
# INFO (S1) (3 lines):
# TEXT: template class T const T std::use_facet (const locale)
# CLAUSE: lib.locale.global.templates
# WARNING (S5) (3 lines):
# TEXT: exceptions not thread safe, skipping that part of test
# CLAUSE: lib.locale.global.templates
/amd/devco/vitek/stdcxx-trunk/tests/localization/22.locale.globals.mt.cpp:311:
use_facet_loop: Assertion 'threw || opt_facets [opt_inx_collate] 0' failed.
IOT/Abort trap (core dumped)
[EMAIL PROTECTED] tests]$
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
RE: [PING] Re: library and build sizes on Windows
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Monday, December 10, 2007 9:30 AM To: stdcxx-dev@incubator.apache.org Subject: RE: [PING] Re: library and build sizes on Windows I've been doing some work on the test result scripts over the weekend and noticed a whole bunch of places where we print out the date on Windows (I counted 12). I dealt with it by trimming all but the first one from the log when processing it but we should probably get rid of all the extra dates and either replace them with the same output as on UNIX if possible (i.e., real, user, ans system times) or just the real time. Can this be done on Windows? I've added printing the real time of the every build step: http://svn.apache.org/viewvc?rev=602995view=rev But batman script also should to be updated to print the timestamp of the build at the beginning (### date:); the duration of the solution generating step (### real time (builddir):) after execution of the configure.bat and total time at the end after cleanup (### real time (total):). All these actions are performed outside the build.wsf script. As for the kernel and user time spent to the each step: it's hard to implement because we need to summarize the all times of the each subprocess. The GetProcessTimes() returns the times only for concrete process and not returning the times of the children processes, like does times() on unix. Farid.
RE: mailing list for Jira issues?
-Original Message- From: Travis Vitek [mailto:[EMAIL PROTECTED] Sent: Monday, December 10, 2007 7:53 PM To: stdcxx-dev@incubator.apache.org Subject: Re: mailing list for Jira issues? How does everyone feel about it? https://issues.apache.org/jira/browse/STDCXX-546 I have no objections. Either way, I need to look at both sets of messages regardless of where they come from. So, for me, moving the Jira messages to a new -issues list doesn't have any significant impact. I guess it might be useful for users with 'dumb' e-mail clients that don't have proper message filtering. My +1 for the change. I'm using the MS Outlook and filtering the JIRA messages by the [jira] in subject. But any reply to jira messages with Re: [jira] in subject are filtered also :( And Outlook dosn't provide the possibility to make more flexible rule :( Farid.
RE: [PATCH] STDCXX-507 (or using __declspec(dllexport/dllimport on gcc/cygwin in shared builds)
-Original Message- From: Travis Vitek [mailto:[EMAIL PROTECTED] Sent: Monday, December 10, 2007 7:25 PM To: stdcxx-dev@incubator.apache.org Subject: Re: [PATCH] STDCXX-507 (or using __declspec(dllexport/dllimport on gcc/cygwin in shared builds) It seems that the problem is that the Cygwin environment defines part of the C++ runtime library in the C library. It does? I don't see any such symbols in the localedef.imports file attached to STDCXX-507 (although there are a lot symbols there so I could have easily missed them). Maybe I'm totally off base, but it appears that Farid is trying to avoid exporting set_unexpected, unexpected, set_terminate, terminate, uncaught_exception and the exception types. Aren't all of these things from the support library? These functions and also dtor() and what() members of the std::exception, std::bad_exception, std::bad_alloc, std::bad_cast, std::bad_typeid are defined in libsupc++.a. Why would it help us to not export them? The using of the __declspec(dllimport) in declarations in client code appends the __imp__ prefix to the referenced symbol. I.e. for the set_terminate() function the referenced symbol name would be __imp__set_terminate (I'm not including the name mangling just for example). So the user will get a undefined reference linker errors. The MSVC doesn't have this problem because the we're using the shared libc in our shared library builds, so the symbol in MSVC libc will be also with __imp__ prefix. But libsupc++ library is present only as static library. But now I see that we can leave the inlude/exception, include/new and include/typeinfo header files unchanged because the gcc/cygwin supports auto-importing feature (it's first searching xxx symbol name, then if the symbol is not found the __imp__xxx symbol will be searched). We just should define _RWSTD_EXPORT as /*empty*/ if the _RWSTD_LIB_SRC macro is not #defined. Farid.
RE: mailing list for Jira issues?
Farid Zaripov-2 wrote: Travis Vitek wrote: I have no objections. Either way, I need to look at both sets of messages regardless of where they come from. So, for me, moving the Jira messages to a new -issues list doesn't have any significant impact. I guess it might be useful for users with 'dumb' e-mail clients that don't have proper message filtering. My +1 for the change. I'm using the MS Outlook and filtering the JIRA messages by the [jira] in subject. But any reply to jira messages with Re: [jira] in subject are filtered also :( And Outlook dosn't provide the possibility to make more flexible rule :( Farid. I don't know how the infra group will set this up, but I wouldn't expect the addition of a new list to fix this problem for you. All generated messages from jira would come from the user that modified the case and be sent to the [EMAIL PROTECTED] list. Any response would appear the same. This is how it works now. Also, I believe that Outlook rules allow you to make a rule handle this situation. You just add an exception to your rule that checks for the strings RE: or Re:. Travis -- View this message in context: http://www.nabble.com/mailing-list-for-Jira-issues--tp14248354p14260442.html Sent from the stdcxx-dev mailing list archive at Nabble.com.
RE: [PATCH] STDCXX-507 (or using __declspec(dllexport/dllimport on gcc/cygwin in shared builds)
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Friday, December 07, 2007 8:56 PM To: stdcxx-dev@incubator.apache.org Subject: Re: [PATCH] STDCXX-507 (or using __declspec(dllexport/dllimport on gcc/cygwin in shared builds) Farid Zaripov wrote: Today I've verified the patch for STDCXX-507 on gcc 4.2.0 and gcc 3.4.4. I get really nervous whenever we start to mess around with the runtime symbols, especially when changing which ones are exported on Windows and which ones aren't. Doesn't exporting just members and not the whole class have an impact on things like RTTI and exceptions? Have you tested it with the other Windows compilers (Intel C++ and MSVC)? Yes. The all examples and tests were compiled and runs as usual. Also, I'm more than a little uncomfortable with hardcoding __CYGWIN__ all over the place. Isn't there a single file where we could tweak _RWSTD_NO_XXX_DEFAULT_CTOR et al macros? Ok, we can leave include/exception, include/new and include/typeinfo header files unchanged since in this patch _RWSTD_EXPORT macro is #defined to /*empty*/ if _RWSTD_LIB_SRC macro is not #defined. Finally, did you consider STDCXX-408 when enabling dllexport? Yes. Unfortunately I haven't access to the HP aCC 3.37 compiler/platform to test how the library builts with the using the dllexport/import directives. The gcc, as I commented in the issue, supports dllexport/dllimport attributes only on Cygwin and Symbian platforms. Farid.
Re: mailing list for Jira issues?
Travis Vitek wrote: Farid Zaripov-2 wrote: Travis Vitek wrote: I have no objections. Either way, I need to look at both sets of messages regardless of where they come from. So, for me, moving the Jira messages to a new -issues list doesn't have any significant impact. I guess it might be useful for users with 'dumb' e-mail clients that don't have proper message filtering. My +1 for the change. I'm using the MS Outlook and filtering the JIRA messages by the [jira] in subject. But any reply to jira messages with Re: [jira] in subject are filtered also :( And Outlook dosn't provide the possibility to make more flexible rule :( Farid. I don't know how the infra group will set this up, but I wouldn't expect the addition of a new list to fix this problem for you. All generated messages from jira would come from the user that modified the case and be sent to the [EMAIL PROTECTED] list. Any response would appear the same. This is how it works now. This, btw., is pretty extensively configurable in Jira. stdcxx is subject to the STDCXX notifications Scheme that I set up for us back in 2005 when our Jira was first created. The latest documentation that explains how this works is here: http://www.atlassian.com/software/jira/docs/latest/notification_schemes.html I suspect you may not be able to view the stdcxx notifications page w/o Jira admin access but here it is anyway: https://issues.apache.org/jira/secure/admin/EditNotifications!default.jspa?schemeId=12310060 Here's our current setup for those who can't access the page, with Events first and the set of available Notifications below (defaults in parens): Issue Created (System) * Reporter * Single Email Address (stdcxx-dev@incubator.apache.org) Issue Updated (System) * Reporter * Current Assignee * Single Email Address (stdcxx-dev@incubator.apache.org) * All Watchers Issue Assigned (System) * All Watchers * Single Email Address (stdcxx-dev@incubator.apache.org) Issue Resolved (System) * Current Assignee * All Watchers * Reporter * Single Email Address (stdcxx-dev@incubator.apache.org) Issue Closed (System) * All Watchers * Current Assignee * Single Email Address (stdcxx-dev@incubator.apache.org) * Reporter Issue Commented (System) * Reporter * Current Assignee * All Watchers * Single Email Address (stdcxx-dev@incubator.apache.org) Issue Comment Edited (System) * Current Assignee * Reporter * Single Email Address (stdcxx-dev@incubator.apache.org) * All Watchers Issue Reopened (System) * Single Email Address (stdcxx-dev@incubator.apache.org) * Reporter * All Watchers * Current Assignee Issue Deleted (System) * Single Email Address (stdcxx-dev@incubator.apache.org) Issue Moved (System) * Single Email Address (stdcxx-dev@incubator.apache.org) Work Logged On Issue (System) Work Started On Issue (System) Work Stopped On Issue (System) Issue Worklog Updated (System) Issue Worklog Deleted (System) Generic Event (System) Also, I believe that Outlook rules allow you to make a rule handle this situation. You just add an exception to your rule that checks for the strings RE: or Re:. Travis
Re: [PATCH] STDCXX-507 (or using __declspec(dllexport/dllimport on gcc/cygwin in shared builds)
Farid Zaripov wrote: -Original Message- From: Travis Vitek [mailto:[EMAIL PROTECTED] Sent: Monday, December 10, 2007 7:25 PM To: stdcxx-dev@incubator.apache.org Subject: Re: [PATCH] STDCXX-507 (or using __declspec(dllexport/dllimport on gcc/cygwin in shared builds) It seems that the problem is that the Cygwin environment defines part of the C++ runtime library in the C library. It does? I don't see any such symbols in the localedef.imports file attached to STDCXX-507 (although there are a lot symbols there so I could have easily missed them). Maybe I'm totally off base, but it appears that Farid is trying to avoid exporting set_unexpected, unexpected, set_terminate, terminate, uncaught_exception and the exception types. Aren't all of these things from the support library? These functions and also dtor() and what() members of the std::exception, std::bad_exception, std::bad_alloc, std::bad_cast, std::bad_typeid are defined in libsupc++.a. They *may be* defined there, right? I.e., most of them typically are but some may not be (e.g.., bad_alloc ctors and assignment operators don't seem to be). When our config tests determine they're not defined in the support library, we define them in stdxxx. But even when they are defined in the runtime we still declare them in our headers, which as Farid explains below seems to be a problem when we use declspec(dllimport) and the runtime is an archive. What if we never used declspec(dllimport), even for runtime symbols defined in the MSVC runtime DLL? Would that be a problem? Why would it help us to not export them? The using of the __declspec(dllimport) in declarations in client code appends the __imp__ prefix to the referenced symbol. I.e. for the set_terminate() function the referenced symbol name would be __imp__set_terminate (I'm not including the name mangling just for example). So the user will get a undefined reference linker errors. The MSVC doesn't have this problem because the we're using the shared libc in our shared library builds, so the symbol in MSVC libc will be also with __imp__ prefix. But libsupc++ library is present only as static library. It sounds like we might need a config test to determine if the C++ runtime is defined in a DLL (MSVC) or in an archive (libsupc++)... But now I see that we can leave the inlude/exception, include/new and include/typeinfo header files unchanged because the gcc/cygwin supports auto-importing feature (it's first searching xxx symbol name, then if the symbol is not found the __imp__xxx symbol will be searched). Aha! That would make it work for gcc. What about MSVC? Does it also support auto-importing? We just should define _RWSTD_EXPORT as /*empty*/ if the _RWSTD_LIB_SRC macro is not #defined. But that would prevent exporting our symbols too. Are you suggesting we not use dllexport/dllimport with gcc on Windows at all? (Because of auto-importing?) I suspect auto-importing comes at a price (since each symbol might need to be looked up twice). If it does, it might make sense to instead avoid declaring just the runtime symbols dllexported when we know they are defined in the gcc runtime and keep dllexport for our own symbols. Maybe we could do this by adding something like _RWSTD_RUNTIME_EXPORT? Martin Farid.
[jira] Commented: (STDCXX-507) [Cygwin] Access violation while loading libstdxxx.dll in dynamic builds
[ https://issues.apache.org/jira/browse/STDCXX-507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12550194 ] Martin Sebor commented on STDCXX-507: - The the thread below for a discussion of this issue: http://www.nabble.com/-PATCH--STDCXX-507--28or-using-__declspec-28dllexport-dllimport-on-gcc-cygwin-in-shared-builds-29-to14217944.html#a14217944 [Cygwin] Access violation while loading libstdxxx.dll in dynamic builds --- Key: STDCXX-507 URL: https://issues.apache.org/jira/browse/STDCXX-507 Project: C++ Standard Library Issue Type: Bug Components: Build Affects Versions: 4.2.0 Environment: gcc 3.4.4/Cygwin Reporter: Farid Zaripov Assignee: Farid Zaripov Fix For: 4.2.1 Attachments: cygwin.patch, localedef.imports Many utilities, examples and tests failed to start due to access violation while loading libstdxxx.dll. In night builds logs they all finished with status 5. The reason is access violation while loading libstdxxx.dll. All of them has many times duplicated imports (see the attached file) and I suppose that bug in ld utility. $ ./localedef || echo $? 5 $ strace /usr/src/stdcxx/trunk/build15d/bin/localedef --- Process 732, exception C005 at 7C919994 --- Process 732, exception C005 at 7C964ED1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [PATCH] STDCXX-507 (or using __declspec(dllexport/dllimport on gcc/cygwin in shared builds)
Farid Zaripov wrote:
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
Sent: Friday, December 07, 2007 8:56 PM
To: stdcxx-dev@incubator.apache.org
Subject: Re: [PATCH] STDCXX-507 (or using
__declspec(dllexport/dllimport on gcc/cygwin in shared builds)
Farid Zaripov wrote:
Today I've verified the patch for STDCXX-507 on gcc 4.2.0 and gcc
3.4.4.
I get really nervous whenever we start to mess around with
the runtime symbols, especially when changing which ones are
exported on Windows and which ones aren't. Doesn't exporting
just members and not the whole class have an impact on things
like RTTI and exceptions?
Have you tested it with the other Windows compilers (Intel
C++ and MSVC)?
Yes. The all examples and tests were compiled and runs as usual.
Also, I'm more than a little uncomfortable with hardcoding
__CYGWIN__ all over the place. Isn't there a single file
where we could tweak _RWSTD_NO_XXX_DEFAULT_CTOR et al macros?
Ok, we can leave include/exception, include/new and include/typeinfo
header
files unchanged since in this patch _RWSTD_EXPORT macro is #defined to
/*empty*/
if _RWSTD_LIB_SRC macro is not #defined.
Finally, did you consider STDCXX-408 when enabling dllexport?
Yes. Unfortunately I haven't access to the HP aCC 3.37
compiler/platform to test
how the library builts with the using the dllexport/import directives.
You could use one of the HP TestDrive servers ;-)
http://www.testdrive.hp.com/
Seriously, what I was suggesting is to make the implementation
general enough to make it easy to extend to other compilers
besides gcc, such as aCC. One way to do it might be to replace
the preprocessor guard around _RWSTD_EXPORT in rw/_defs.h with
_RWSTD_NO_DLLEXPORT and add a config test to see if
__declspec(dll{ex,im}port) is supported.
The gcc, as I commented in the issue, supports dllexport/dllimport
attributes
only on Cygwin and Symbian platforms.
Right, I saw your comment.
Martin
Re: [PING] Re: library and build sizes on Windows
Farid Zaripov wrote: -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Monday, December 10, 2007 9:30 AM To: stdcxx-dev@incubator.apache.org Subject: RE: [PING] Re: library and build sizes on Windows I've been doing some work on the test result scripts over the weekend and noticed a whole bunch of places where we print out the date on Windows (I counted 12). I dealt with it by trimming all but the first one from the log when processing it but we should probably get rid of all the extra dates and either replace them with the same output as on UNIX if possible (i.e., real, user, ans system times) or just the real time. Can this be done on Windows? I've added printing the real time of the every build step: http://svn.apache.org/viewvc?rev=602995view=rev But batman script also should to be updated to print the timestamp of the build at the beginning (### date:); the duration of the solution generating step (### real time (builddir):) after execution of the configure.bat and total time at the end after cleanup (### real time (total):). All these actions are performed outside the build.wsf script. Alright. We need to migrate this script from Batman over to stdcxx so we can enhance it ourselves. In addition to the timing info and the library size I also tried (but couldn't) to determine the name and version of the Windows OS so even the latest test result pages for Windows are incomplete. Andrew, I'm having trouble finding this script. Can you point me in the right direction? As for the kernel and user time spent to the each step: it's hard to implement because we need to summarize the all times of the each subprocess. The GetProcessTimes() returns the times only for concrete process and not returning the times of the children processes, like does times() on unix. Hm. We might need to settle for the real times on Windows. Martin
Re: [PING] Re: library and build sizes on Windows
Martin Sebor wrote: Farid Zaripov wrote: [snip] But batman script also should to be updated to print the timestamp of the build at the beginning (### date:); the duration of the solution generating step (### real time (builddir):) after execution of the configure.bat and total time at the end after cleanup (### real time (total):). All these actions are performed outside the build.wsf script. Alright. We need to migrate this script from Batman over to stdcxx so we can enhance it ourselves. In addition to the timing info and the library size I also tried (but couldn't) to determine the name and version of the Windows OS so even the latest test result pages for Windows are incomplete. Andrew, I'm having trouble finding this script. Can you point me in the right direction? The Batman script is build_stdcxx.bat, located along side the unix build_stdcxx script. This script is batch file, which calls into parse_runlog.wsf script for the purpose of processing the result log for batman. --Andrew Black
Re: [PING] Re: library and build sizes on Windows
Andrew Black wrote: Martin Sebor wrote: Farid Zaripov wrote: [snip] But batman script also should to be updated to print the timestamp of the build at the beginning (### date:); the duration of the solution generating step (### real time (builddir):) after execution of the configure.bat and total time at the end after cleanup (### real time (total):). All these actions are performed outside the build.wsf script. Alright. We need to migrate this script from Batman over to stdcxx so we can enhance it ourselves. In addition to the timing info and the library size I also tried (but couldn't) to determine the name and version of the Windows OS so even the latest test result pages for Windows are incomplete. Andrew, I'm having trouble finding this script. Can you point me in the right direction? The Batman script is build_stdcxx.bat, located along side the unix build_stdcxx script. This script is batch file, which calls into parse_runlog.wsf script for the purpose of processing the result log for batman. I suspect we're not going to want to touch that. But before the script invokes parse_runlog.wsf it does this: echo ### Building solution / Creating HTML log call build\build_%COMPILER%.bat %SHORT% echo ### Post-processing for Batman cscript /nologo parse_runlog.wsf /BUILDTYPE:%SHORT% /CONFIG:%COMPILER% It seems that we'll be interested in making changes to this build\build_%COMPILER%.bat script. Where does it come from? Martin
Re: [PING] Re: library and build sizes on Windows
Martin Sebor wrote: Andrew Black wrote: [snip] The Batman script is build_stdcxx.bat, located along side the unix build_stdcxx script. This script is batch file, which calls into parse_runlog.wsf script for the purpose of processing the result log for batman. I suspect we're not going to want to touch that. But before the script invokes parse_runlog.wsf it does this: echo ### Building solution / Creating HTML log call build\build_%COMPILER%.bat %SHORT% echo ### Post-processing for Batman cscript /nologo parse_runlog.wsf /BUILDTYPE:%SHORT% /CONFIG:%COMPILER% It seems that we'll be interested in making changes to this build\build_%COMPILER%.bat script. Where does it come from? It's the batch file generated by the configure.bat script. --Andrew Black
Re: [PING] Re: library and build sizes on Windows
Andrew Black wrote: Martin Sebor wrote: Andrew Black wrote: [snip] The Batman script is build_stdcxx.bat, located along side the unix build_stdcxx script. This script is batch file, which calls into parse_runlog.wsf script for the purpose of processing the result log for batman. I suspect we're not going to want to touch that. But before the script invokes parse_runlog.wsf it does this: echo ### Building solution / Creating HTML log call build\build_%COMPILER%.bat %SHORT% echo ### Post-processing for Batman cscript /nologo parse_runlog.wsf /BUILDTYPE:%SHORT% /CONFIG:%COMPILER% It seems that we'll be interested in making changes to this build\build_%COMPILER%.bat script. Where does it come from? It's the batch file generated by the configure.bat script. Oh, so the script to migrate from Batman to stdcxx is basically just these few lines of code: @echo on date /T set @echo off echo ### Creating solution call generate.bat /CONFIG:%COMPILER% /BUILDDIR:%~dp0\build /LOCALES:no if %errorlevel% neq 0 ( echo result.file.type=stdcxx-short %OUTFILE% echo state=C %OUTFILE% ) else ( echo ### Building solution / Creating HTML log call build\build_%COMPILER%.bat %SHORT% echo ### Post-processing for Batman cscript /nologo parse_runlog.wsf /BUILDTYPE:%SHORT% /CONFIG:%COMPILER% ) Minus the invocation of parse_runlog.wsf, and minus the error branch. And the date statements that Farid's talking about should go right after the call to generate.bat and after the call to call build\build_%COMPILER%.bat. Travis, could you look into creating this new script and changing build_stdcxx.bat to invoke it? Thanks Martin --Andrew Black
[jira] Commented: (STDCXX-605) [IBM XLC++] errors compiling dynatype.cpp
[ https://issues.apache.org/jira/browse/STDCXX-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12550251 ] Travis Vitek commented on STDCXX-605: - 1. Yes, all of this is because of the compiler bug. As it turns out, a similar problem exists for some builds on VC7.1. 2. I think I can do it, but the only way I can come up with involves quite a bit of template metaprogramming and that adds a lot of complication to the example. Perhaps I'm persuing the wrong method? If not, I'd hope that we could come up with a simpler solution. I'd almost prefer to use named methods for doing the conversions. 3. Fine. 4. I'll file another bug on that issue. I've wasted enough time on this particular goose-chase already. [IBM XLC++] errors compiling dynatype.cpp - Key: STDCXX-605 URL: https://issues.apache.org/jira/browse/STDCXX-605 Project: C++ Standard Library Issue Type: Bug Components: Examples Affects Versions: 4.2.0 Environment: XLC++ 6.0 through 9.0/AIX 5.3 Reporter: Martin Sebor Assignee: Travis Vitek Fix For: 4.2.1 Attachments: stdcxx-605.patch The dynatype.cpp example program fails to compile with IBM XLC++ 9.0 on AIX with ethe following errors: xlCcore_r -c -I$(TOPDIR)/include/ansi-I$(TOPDIR)/include -I$(BUILDDIR)/include -I$(TOPDIR)/examples/include -O -Q -qtemplateregistry=dynatype.ti $(TOPDIR)/examples/tutorial/dynatype.cpp $(TOPDIR)/examples/tutorial/dynatype.cpp, line 203.27: 1540-0216 (S) An expression of type dynatype cannot be converted to type int. $(TOPDIR)/examples/tutorial/dynatype.cpp, line 209.30: 1540-0216 (S) An expression of type dynatype cannot be converted to type double. $(TOPDIR)/examples/tutorial/dynatype.cpp, line 215.30: 1540-0216 (S) An expression of type dynatype cannot be converted to type double. $(TOPDIR)/examples/tutorial/dynatype.cpp, line 222.35: 1540-0216 (S) An expression of type dynatype cannot be converted to type const char *. $(TOPDIR)/examples/tutorial/dynatype.cpp, line 228.35: 1540-0216 (S) An expression of type dynatype cannot be converted to type const char *. $(TOPDIR)/examples/tutorial/dynatype.cpp, line 238.28: 1540-0216 (S) An expression of type dynatype cannot be converted to type char. gmake: *** [dynatype.o] Error 1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
