Re: _RWSTD_LIB_SRC macro is not #defined in src/export.cpp
From: Martin Sebor [mailto:[EMAIL PROTECTED] To: stdcxx-dev@incubator.apache.org Subject: Re: _RWSTD_LIB_SRC macro is not #defined in src/export.cpp > The _RWSTD_INSTANTIATE_TEMPLATES part is an implementation detail > of _RWSTD_LIB_SRC. If we were to add another detail like that we'd > have to also remember to update export.cpp. That seems just as > brittle as what we're doing now (i.e., not #defining _RWSTD_LIB_SRC). > > The #define _RWSTD_LIB_SRC in every library src file is needed > for the implementing the autolinking feature on MSVC. > I see. You're adding a #pragma comment to _config.h that expands > when _RWSTD_LIB_SRC is #defined and you need it to expand in all > library sources, correct? No. The #pragma comment directive should be expanded only in user's source files (actually it's enough to expand this directive in only one source file of the user's project, but we can't handle this). At the same time #pragma comment shouldn't expanded in library source files, elsewere the linker will search libstdxx.lib while linking the library itself and will fail with the error "libstdxx.lib not found". The negative effect of the using autolinking feature is the case when user uses the some part of the library, that fully implemented in header files and the user don't have to link its project with stdcxx library, but #pragma comment will force the linker to search and use the specified library. For that case there handled _RWSTD_NO_EXT_AUTOLINK macro. Farid.
Re: _RWSTD_LIB_SRC macro is not #defined in src/export.cpp
Farid Zaripov wrote: From: Martin Sebor [mailto:[EMAIL PROTECTED] To: stdcxx-dev@incubator.apache.org Subject: Re: _RWSTD_LIB_SRC macro is not #defined in src/export.cpp Farid Zaripov wrote: I've found that _RWSTD_LIB_SRC macro is not #defined in src/export.cpp file. This is a mistake, or it's required by design? The file is currently only used when compiling with EDG eccp when exported templates are enabled. I don't think (but I'm not 100% sure) we want to #define _RWSTD_LIB_SRC in this case because the effect is to #define _RWSTD_NO_TEMPLATE_DEFINITIONS. If so, I think it would be more correctly to #define _RWSTD_LIB_SRC and also #define _RWSTD_INSTANTIATE_TEMPLATES. The _RWSTD_INSTANTIATE_TEMPLATES part is an implementation detail of _RWSTD_LIB_SRC. If we were to add another detail like that we'd have to also remember to update export.cpp. That seems just as brittle as what we're doing now (i.e., not #defining _RWSTD_LIB_SRC). The #define _RWSTD_LIB_SRC in every library src file is needed for the implementing the autolinking feature on MSVC. I see. You're adding a #pragma comment to _config.h that expands when _RWSTD_LIB_SRC is #defined and you need it to expand in all library sources, correct? Martin
Re: [jira] Resolved: (STDCXX-566) update/generate incubation status file
Farid Zaripov wrote: From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Friday, November 30, 2007 11:30 PM To: stdcxx-dev@incubator.apache.org Subject: RE: [jira] Resolved: (STDCXX-566) update/generate incubation status file 1. logged into people.apache.org 2. svn co http://svn.apache.org/repos/asf/incubator/public/trunk incubator 3. cd incubator 4. updated ./site-author/projects/stdcxx.xml file 5. invoked "ant" (script has updated ./site-publish/projects/stdcxx.html file) 6. commited ./site-author/projects/stdcxx.xml file 7. commited ./site-publish/projects/stdcxx.html file 8. cd /www/incubator.apache.org 9. svn up This isn't working for me. I updated site-author/projects/stdcxx.xml (and removed Bloomberg as Lance's affiliation) and checked it in. You shouldn't check it in here. Checking in this is step 6) ;-) I actually checked it in on another machine altogether, and then checked out all of incubator on people.apache.org. Seems like that should work. To be honest, I don't understand why simply updating a single HTML page needs to be so complicated. All we should need to do is change the XML, check it in (anywhere) and the system should do the rest (i.e., run build.sh via a cron job on a periodic basis and even check in the generated HTML if it has to be in Subversion). But that's for the Incubator folks to work on. Hopefully, this was the last time we had to update the site. Then I ran the build.sh script (there is no "ant" as you said in (5)) as shown below but the site-publish/projects/stdcxx.html file has not been updated. svn status shows no differences to any files at all. Any idea what I'm doing wrong? Yes. It seems that ant has been uninstalled on people.apache.org since I've made the last site update. I've just tried to remove incubator/site-publish/projects/stdcxx.html. It didn't occur to me to do that... After that build.sh script updated the page: - [EMAIL PROTECTED] ~/incubator]$ rm site-publish/projects/stdcxx.html [EMAIL PROTECTED] ~/incubator]$ ./build.sh Buildfile: build.xml prepare: prepare-error: docs: [anakia] Transforming into: /x1/home/faridz/incubator/site-publish [anakia] Input: projects/stdcxx.xml [anakia] Output: /x1/home/faridz/incubator/site-publish/projects/stdcxx.html BUILD SUCCESSFUL Total time: 2 seconds - I've commited the changes thus: http://svn.apache.org/viewvc?view=rev&revision=55 Thanks! Martin Farid.
Re: _RWSTD_LIB_SRC macro is not #defined in src/export.cpp
From: Martin Sebor [mailto:[EMAIL PROTECTED] To: stdcxx-dev@incubator.apache.org Subject: Re: _RWSTD_LIB_SRC macro is not #defined in src/export.cpp Farid Zaripov wrote: >> I've found that _RWSTD_LIB_SRC macro is not #defined in src/export.cpp >> file. >> >> This is a mistake, or it's required by design? > The file is currently only used when compiling with EDG eccp when > exported templates are enabled. I don't think (but I'm not 100% > sure) we want to #define _RWSTD_LIB_SRC in this case because the > effect is to #define _RWSTD_NO_TEMPLATE_DEFINITIONS. If so, I think it would be more correctly to #define _RWSTD_LIB_SRC and also #define _RWSTD_INSTANTIATE_TEMPLATES. The #define _RWSTD_LIB_SRC in every library src file is needed for the implementing the autolinking feature on MSVC. Farid.
Re: [jira] Resolved: (STDCXX-566) update/generate incubation status file
From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Friday, November 30, 2007 11:30 PM To: stdcxx-dev@incubator.apache.org Subject: RE: [jira] Resolved: (STDCXX-566) update/generate incubation status file >> >> 1. logged into people.apache.org >> 2. svn co http://svn.apache.org/repos/asf/incubator/public/trunk >> incubator >> 3. cd incubator >> 4. updated ./site-author/projects/stdcxx.xml file >> 5. invoked "ant" (script has updated >> ./site-publish/projects/stdcxx.html file) >> 6. commited ./site-author/projects/stdcxx.xml file >> 7. commited ./site-publish/projects/stdcxx.html file >> 8. cd /www/incubator.apache.org >> 9. svn up > This isn't working for me. I updated site-author/projects/stdcxx.xml (and > removed Bloomberg as Lance's affiliation) and checked it in. You shouldn't check it in here. Checking in this is step 6) ;-) > Then I ran the > build.sh script (there is no "ant" as you said in (5)) as shown below but > the site-publish/projects/stdcxx.html file has not been updated. svn status > shows no differences to any files at all. Any idea what I'm doing wrong? Yes. It seems that ant has been uninstalled on people.apache.org since I've made the last site update. I've just tried to remove incubator/site-publish/projects/stdcxx.html. After that build.sh script updated the page: - [EMAIL PROTECTED] ~/incubator]$ rm site-publish/projects/stdcxx.html [EMAIL PROTECTED] ~/incubator]$ ./build.sh Buildfile: build.xml prepare: prepare-error: docs: [anakia] Transforming into: /x1/home/faridz/incubator/site-publish [anakia] Input: projects/stdcxx.xml [anakia] Output: /x1/home/faridz/incubator/site-publish/projects/stdcxx.html BUILD SUCCESSFUL Total time: 2 seconds - I've commited the changes thus: http://svn.apache.org/viewvc?view=rev&revision=55 Farid.
Re: _RWSTD_LIB_SRC macro is not #defined in src/export.cpp
Farid Zaripov wrote: I've found that _RWSTD_LIB_SRC macro is not #defined in src/export.cpp file. This is a mistake, or it's required by design? The file is currently only used when compiling with EDG eccp when exported templates are enabled. I don't think (but I'm not 100% sure) we want to #define _RWSTD_LIB_SRC in this case because the effect is to #define _RWSTD_NO_TEMPLATE_DEFINITIONS. You will need to give it a try to see what happens. If nothing breaks we should probably #define it. If it doesn't work because of exported templates we should probably add a comment to the file explaining the restriction so that someone doesn't accidentally cause a regression by following the convention used in the rest of library sources. Martin Farid.
RE: [jira] Resolved: (STDCXX-566) update/generate incubation status file
Farid Zaripov-2 wrote: > >> -Original Message- >> From: Martin Sebor [mailto:[EMAIL PROTECTED] >> Sent: Friday, September 21, 2007 6:54 PM >> To: stdcxx-dev@incubator.apache.org >> Subject: Re: [jira] Resolved: (STDCXX-566) update/generate >> incubation status file >> >> Can you explain how you generated the page so that I or >> someone else can follow your instructions the next time it >> needs to be done? > > 1. logged into people.apache.org > 2. svn co http://svn.apache.org/repos/asf/incubator/public/trunk > incubator > 3. cd incubator > 4. updated ./site-author/projects/stdcxx.xml file > 5. invoked "ant" (script has updated > ./site-publish/projects/stdcxx.html file) > 6. commited ./site-author/projects/stdcxx.xml file > 7. commited ./site-publish/projects/stdcxx.html file > 8. cd /www/incubator.apache.org > 9. svn up > > That's all :) > > The all steps are stated here: > http://incubator.apache.org/guides/website.html > > Farid. > > This isn't working for me. I updated site-author/projects/stdcxx.xml (and removed Bloomberg as Lance's affiliation) and checked it in. Then I ran the build.sh script (there is no "ant" as you said in (5)) as shown below but the site-publish/projects/stdcxx.html file has not been updated. svn status shows no differences to any files at all. Any idea what I'm doing wrong? $ export JAVA_HOME=/usr/local incubator$ ./build.sh Buildfile: build.xml prepare: prepare-error: docs: [anakia] Transforming into: /x1/home/sebor/incubator/site-publish [anakia] Input: projects/incubation-status-template.xml [anakia] Output: /x1/home/sebor/incubator/site-publish/projects/incubation-status-template.html [copy] Copying 10 files to /x1/home/sebor/incubator/site-publish BUILD SUCCESSFUL Total time: 3 seconds -- View this message in context: http://www.nabble.com/-jira--Created%3A-%28STDCXX-566%29-update-generate-incubation-status-file-tf4485434.html#a14093715 Sent from the stdcxx-dev mailing list archive at Nabble.com.
Problem with Memory with strings on HP-IPF
I have a customer that is working on HP-IPF with the SourcePro edition 9
release of the Standard Library. He is noticing quite a bit of memory
growth on the HP IPF versus the HP pa-risc platforms. I was wondering
if anyone has run into this problem.
Here is a sample test case provided by the customer:
#include
#include
#include
void print_mallinfo()
{
struct mallinfo info;
info = mallinfo();
printf("Memory allocation info:\n");
printf(" total space in arena = %d\n", info.arena);
printf(" number of ordinary blocks = %d\n", info.ordblks);
printf(" number of small blocks = %d\n", info.smblks);
printf(" space in holding block headers = %d\n", info.hblkhd);
printf(" number of holding blocks = %d\n", info.hblks);
printf(" space in small blocks in use = %d\n", info.usmblks);
printf(" space in free small blocks = %d\n", info.fsmblks);
printf(" space in ordinary blocks in use = %d\n",
info.uordblks);
printf(" space in free ordinary blocks = %d\n", info.fordblks);
printf(" keep option space penalty = %d\n", info.keepcost);
printf(" space in use = %d\n", info.usmblks + info.uordblks);
printf(" space free = %d\n", info.fsmblks + info.fordblks); }
main(int argc, char **argv)
{
for (int ix=0; ix<2; ix++)
{
std::string *p = new std::string("A");
print_mallinfo();
}
return 0;
}
On a HP-paRisc machine the output is as follows:
Memory allocation info:
total space in arena = 106444
number of ordinary blocks = 141
number of small blocks = 200
space in holding block headers = 1832
number of holding blocks = 2
space in small blocks in use = 80
space in free small blocks = 7920
space in ordinary blocks in use = 21928
space in free ordinary blocks = 74672
keep option space penalty = 0
space in use = 22008
space free = 82592
Memory allocation info:
total space in arena = 106444
number of ordinary blocks = 142
number of small blocks = 200
space in holding block headers = 1832
number of holding blocks = 2
space in small blocks in use = 160
space in free small blocks = 7840
space in ordinary blocks in use = 30152
space in free ordinary blocks = 66448
keep option space penalty = 0
space in use = 30312
space free = 74288
I am still working on trying to get the IPF results.
Jeremy
[jira] Commented: (STDCXX-566) update/generate incubation status file
[ https://issues.apache.org/jira/browse/STDCXX-566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547291 ] Martin Sebor commented on STDCXX-566: - Farid's description from the post below follows: http://www.nabble.com/RE%3A--jira--Resolved%3A-%28STDCXX-566%29-update-generate-incubation-status-file-p12825197.html 1. logged into people.apache.org 2. svn co http://svn.apache.org/repos/asf/incubator/public/trunk incubator 3. cd incubator 4. updated ./site-author/projects/stdcxx.xml file 5. invoked "ant" (script has updated ./site-publish/projects/stdcxx.html file) 6. commited ./site-author/projects/stdcxx.xml file 7. commited ./site-publish/projects/stdcxx.html file 8. cd /www/incubator.apache.org 9. svn up > update/generate incubation status file > -- > > Key: STDCXX-566 > URL: https://issues.apache.org/jira/browse/STDCXX-566 > Project: C++ Standard Library > Issue Type: Task > Components: Web >Reporter: Martin Sebor >Assignee: Farid Zaripov >Priority: Critical > > The stdcxx status page (http://incubator.apache.org/projects/stdcxx.html) is > out of date and needs to be regenerated. > The most recent update to the XML source for the status file is here: > http://svn.apache.org/viewvc/incubator/public/trunk/site-author/projects/stdcxx.xml?view=log > Some potential problems with updating the site are in the following thread: > http://www.nabble.com/next-steps-toward-graduation-tf4386216.html#a12504548 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: moving out of the incubator and becoming a TLP
INFRA-1421 and subtasks have been created to set up stdcxx TLP: http://issues.apache.org/jira/browse/INFRA-1421 Martin Sebor wrote: Now that we've graduated we need to start the process of migrating stdcxx resources to its new home as a Top Level Project (TLP). The steps involved in this process are outlined in the sections of the Guide to Successful Graduation below: http://incubator.apache.org/guides/graduation.html#new-project-hand-over http://incubator.apache.org/guides/graduation.html#project-first-steps http://incubator.apache.org/guides/graduation.html#life-after-graduation This is a heads up to everyone that there these changes are coming up in the next days or weeks, depending on how quickly I manage to pull things together and on how fast the infra team moves. I haven't read all the documentation yet so if anyone has suggestions on how best to proceed or concerns about anything this is an opportunity to raise them. I plan/hope to give periodic updates on our progress to TLP status throughout the process. Feel free to ping the list if there hasn't been an update in a while. Martin
[jira] Updated: (STDCXX-675) [MSVC] implement autolinking feature
[ https://issues.apache.org/jira/browse/STDCXX-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-675: - Patch Info: [Patch Available] > [MSVC] implement autolinking feature > > > Key: STDCXX-675 > URL: https://issues.apache.org/jira/browse/STDCXX-675 > Project: C++ Standard Library > Issue Type: Improvement > Components: Configuration >Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0 > Environment: MSVC, ICC/Windows >Reporter: Farid Zaripov >Assignee: Farid Zaripov >Priority: Trivial > Fix For: 4.2.1 > > Attachments: autolink.patch > > > At the moment the users of the library should explicitly specify the used > library name in linker command line. Here might be problems if the user's > project was compiled with config.h for some configuration (let's say 12d) but > linked with library for another configuration (i.e. libstd12s.lib). > The MSVC and ICC/Windows has the posibility to specify the library using > #pragma comment (lib, libname) directive. So #including any header from the > library will leads to linking automatically with the proper library file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-675) [MSVC] implement autolinking feature
[ https://issues.apache.org/jira/browse/STDCXX-675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547221 ] Farid Zaripov commented on STDCXX-675: -- ChangeLog: STDCXX-675 * include/rw/_autolink.h: New header file to enable autolinking feature. * include/rw/_config-msvcrt.h: #include _autolink.h. * src/export.cpp: Added missing #define _RWSTD_LIB_SRC macro. The _autolink.h file is intended to be #included in _config.h, but since this feature is supported by only MSVC and ICC/Windows, it #included in _config-msvcrt.h. > [MSVC] implement autolinking feature > > > Key: STDCXX-675 > URL: https://issues.apache.org/jira/browse/STDCXX-675 > Project: C++ Standard Library > Issue Type: Improvement > Components: Configuration >Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0 > Environment: MSVC, ICC/Windows >Reporter: Farid Zaripov >Assignee: Farid Zaripov >Priority: Trivial > Fix For: 4.2.1 > > Attachments: autolink.patch > > > At the moment the users of the library should explicitly specify the used > library name in linker command line. Here might be problems if the user's > project was compiled with config.h for some configuration (let's say 12d) but > linked with library for another configuration (i.e. libstd12s.lib). > The MSVC and ICC/Windows has the posibility to specify the library using > #pragma comment (lib, libname) directive. So #including any header from the > library will leads to linking automatically with the proper library file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-675) [MSVC] implement autolinking feature
[ https://issues.apache.org/jira/browse/STDCXX-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farid Zaripov updated STDCXX-675: - Attachment: autolink.patch > [MSVC] implement autolinking feature > > > Key: STDCXX-675 > URL: https://issues.apache.org/jira/browse/STDCXX-675 > Project: C++ Standard Library > Issue Type: Improvement > Components: Configuration >Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0 > Environment: MSVC, ICC/Windows >Reporter: Farid Zaripov >Assignee: Farid Zaripov >Priority: Trivial > Fix For: 4.2.1 > > Attachments: autolink.patch > > > At the moment the users of the library should explicitly specify the used > library name in linker command line. Here might be problems if the user's > project was compiled with config.h for some configuration (let's say 12d) but > linked with library for another configuration (i.e. libstd12s.lib). > The MSVC and ICC/Windows has the posibility to specify the library using > #pragma comment (lib, libname) directive. So #including any header from the > library will leads to linking automatically with the proper library file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
_RWSTD_LIB_SRC macro is not #defined in src/export.cpp
I've found that _RWSTD_LIB_SRC macro is not #defined in src/export.cpp file. This is a mistake, or it's required by design? Farid.
RE: svn commit: r597425 - in /incubator/stdcxx/branches/4.2.x: include/ansi/cwchar tests/strings/21.cwchar.cpp
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] > Sent: Friday, November 30, 2007 2:51 AM > To: stdcxx-dev@incubator.apache.org > Subject: Re: svn commit: r597425 - in > /incubator/stdcxx/branches/4.2.x: include/ansi/cwchar > tests/strings/21.cwchar.cpp > > > Yes, potentially here might be a problems. > > So maybe we need to rethink the original strategy of > #undefining the macros only when _RWSTD_STRICT_ANSI is > #defined. Or is there a way to prevent the expansion of the > macros in the using declarations? > > Btw., it occurs to me that if they are defined as function > macros (i.e., #define getwc() as opposed to #define getwc, > without the parentheses), mentioning getwc w/o an argument > list as is done in using declarations will not cause them to > be expanded. So the problem only exists for object macros > (i.e., those that aren't defined with parentheses). If the using directives are decorated by #ifndef _RWSTD_NO_funname there would be no problems in case the STDCXX-451 issue resolved. > > BTW in ansi/cctype and ansi/cmath headers the masking macros are > > #undefined unconditionally. > > > > I think first we need to collect information how these macros are > > implemented on different platforms and then decide what > should we do. > > I suppose we should do that. But either way we decide we > should be consistent. So if there already are unconditional > #undefs in several other headers we might as well follow suit > with cwchar (and wchar.h) until we gather more information > and decide to change all the other headers to #undef all the > other macros conditionally. Agreed. So it's safe to #undefine getwc and putwc on MSVC. The gcc on Linux doesn't #define these macros. What about other platforms? Farid.
