From: Manav B. <bha...@gm...> - 2013-08-28 21:05:10
|
Hi, Has anyone attempted to use the --redirect-stdout command line option lately? All my file names are showing up with the processor-id overwriting "stdout.processor." from the left-hand-side. So, for example, processor 0 has a file name as "0tdout.processor.", processor 1 has "1tdout.processor.", and so on. I am getting the same behavior with both intel and gcc compilers. Making the following modification to libmesh.C sets this right: std::stringstream filename("stdout.processor."); filename << libMesh::processor_id(); to std::stringstream filename; filename << "stdout.processor."; filename << libMesh::processor_id(); Not sure why it is not behaving correctly with the filename passed throught the constructor. Manav |
From: John P. <jwp...@gm...> - 2013-08-28 21:19:25
|
On Wed, Aug 28, 2013 at 3:05 PM, Manav Bhatia <bha...@gm...> wrote: > Hi, > > Has anyone attempted to use the --redirect-stdout command line > option lately? > > All my file names are showing up with the processor-id > overwriting "stdout.processor." from the left-hand-side. So, for example, > processor 0 has a file name as "0tdout.processor.", processor 1 has > "1tdout.processor.", and so on. > > I am getting the same behavior with both intel and gcc compilers. > > Making the following modification to libmesh.C sets this right: > > std::stringstream filename("stdout.processor."); > filename << libMesh::processor_id(); > > to > > std::stringstream filename; > filename << "stdout.processor."; > filename << libMesh::processor_id(); > > Not sure why it is not behaving correctly with the filename passed throught > the constructor. > Hmm... http://www.cplusplus.com/reference/sstream/istringstream/istringstream/says: Constructs an istringstream <http://www.cplusplus.com/istringstream> object with a copy of str as content. Internally, its istream <http://www.cplusplus.com/istream::istream> base constructor is passed a pointer to a stringbuf<http://www.cplusplus.com/stringbuf> object constructed with arguments based on str and which. <https://lists.sourceforge.net/lists/listinfo/libmesh-users> but I admit I don't know where the next input is supposed to occur when you use this constructor. What compiler/OS are you using? I'll test it here and make your change momentarily. -- John |
From: Manav B. <bha...@gm...> - 2013-08-28 21:25:45
|
Thanks, John. I am getting the same behavior on Linux Aspen Cluster (kernel 2.6.32-279) with intel compiler 13.0.1, and also gcc 4.4.6, and on Mac 10.8 Mountain Lion with clang (Apple's compiler). -Manav On Wed, Aug 28, 2013 at 5:18 PM, John Peterson <jwp...@gm...> wrote: > > > > On Wed, Aug 28, 2013 at 3:05 PM, Manav Bhatia <bha...@gm...>wrote: > >> Hi, >> >> Has anyone attempted to use the --redirect-stdout command line >> option lately? >> >> All my file names are showing up with the processor-id >> overwriting "stdout.processor." from the left-hand-side. So, for example, >> processor 0 has a file name as "0tdout.processor.", processor 1 has >> "1tdout.processor.", and so on. >> >> I am getting the same behavior with both intel and gcc compilers. >> >> Making the following modification to libmesh.C sets this right: >> >> std::stringstream filename("stdout.processor."); >> filename << libMesh::processor_id(); >> >> to >> >> std::stringstream filename; >> filename << "stdout.processor."; >> filename << libMesh::processor_id(); >> >> Not sure why it is not behaving correctly with the filename passed >> throught >> the constructor. >> > > Hmm... > > http://www.cplusplus.com/reference/sstream/istringstream/istringstream/says: > > Constructs an istringstream <http://www.cplusplus.com/istringstream> object > with a copy of str as content. > Internally, its istream <http://www.cplusplus.com/istream::istream> base > constructor is passed a pointer to a stringbuf<http://www.cplusplus.com/stringbuf> object > constructed with arguments based on str and which. > > <https://lists.sourceforge.net/lists/listinfo/libmesh-users> > but I admit I don't know where the next input is supposed to occur when > you use this constructor. What compiler/OS are you using? > > I'll test it here and make your change momentarily. > > -- > John > |
From: Roy S. <roy...@ic...> - 2013-08-28 22:02:50
|
I'm seeing the "1tdout.processor." behavior with libstdc++ from gcc 4.8. >> On Wed, Aug 28, 2013 at 3:05 PM, Manav Bhatia <bha...@gm...>wrote: >> >>> Not sure why it is not behaving correctly with the filename passed >>> throught >>> the constructor. > On Wed, Aug 28, 2013 at 5:18 PM, John Peterson <jwp...@gm...> wrote: > >> but I admit I don't know where the next input is supposed to occur when >> you use this constructor. What compiler/OS are you using? Warning: amateur C++ standards-lawyering follows. On first glance (at draft n3337): A basic_ostringstream constructor from string is supposed to construct its underlying basic_stringbuf from that string. That in turn is supposed to have the same effect as constructing an empty stringbuf and then calling str(s). And that in turn is supposed to have the postcondition: "pbase() points to the first underlying character"; i.e. the internal pointer starts out at the *beginning* of the initialization string, not the end. So I think the "bug" we're seeing is actually our prior misunderstanding of mandatory stringstream behavior. Thanks for the catch and the fix, Manav! --- Roy |
From: John P. <jwp...@gm...> - 2013-08-28 22:05:12
|
On Wed, Aug 28, 2013 at 4:02 PM, Roy Stogner <roy...@ic...>wrote: > > I'm seeing the "1tdout.processor." behavior with libstdc++ from gcc > 4.8. > > On Wed, Aug 28, 2013 at 3:05 PM, Manav Bhatia <bha...@gm... >>> >wrote: >>> >>> Not sure why it is not behaving correctly with the filename passed >>>> throught >>>> the constructor. >>>> >>> > On Wed, Aug 28, 2013 at 5:18 PM, John Peterson <jwp...@gm...> >> wrote: >> >> but I admit I don't know where the next input is supposed to occur when >>> you use this constructor. What compiler/OS are you using? >>> >> > Warning: amateur C++ standards-lawyering follows. > > On first glance (at draft n3337): > > A basic_ostringstream constructor from string is supposed to construct > its underlying basic_stringbuf from that string. > > That in turn is supposed to have the same effect as constructing an > empty stringbuf and then calling str(s). > > And that in turn is supposed to have the postcondition: "pbase() > points to the first underlying character"; i.e. the internal pointer > starts out at the *beginning* of the initialization string, not the > end. > > > So I think the "bug" we're seeing is actually our prior > misunderstanding of mandatory stringstream behavior. Thanks for the > catch and the fix, Manav! > Agreed. Would using a std::istringstream instead also fix the problem? -- John |
From: Roy S. <roy...@ic...> - 2013-08-28 22:32:06
|
On Wed, 28 Aug 2013, John Peterson wrote: > Agreed. Would using a std::istringstream instead also fix the problem? istringstream is for string->data conversions only, isn't it? Not data->string? Anyway, istringstream is probably the *reason* for the problem - that's the case where it makes perfect sense to initialize the underlying buffer with a string and start your cursor at the beginning of the buffer. For ostringstream I think the extra << call is the natural way to go. --- Roy |
From: John P. <jwp...@gm...> - 2013-08-28 22:34:54
|
On Wed, Aug 28, 2013 at 4:31 PM, Roy Stogner <roy...@ic...>wrote: > > On Wed, 28 Aug 2013, John Peterson wrote: > > Agreed. Would using a std::istringstream instead also fix the problem? >> > > istringstream is for string->data conversions only, isn't it? Not > data->string? > Right, I should have said ostringstream. I tried it though and it has exactly the same problem. > Anyway, istringstream is probably the *reason* for the problem - > that's the case where it makes perfect sense to initialize the > underlying buffer with a string and start your cursor at the > beginning of the buffer. For ostringstream I think the extra << call > is the natural way to go. > Yes, will commit that now. -- John |