-Original Message-
From: [EMAIL PROTECTED]
Sent: Mon, 19 Feb 2007 13:35:19 -0700
To: stdcxx-dev@incubator.apache.org
Subject: Re: [jira] Commented: (STDCXX-333) std::wfilebuf extracts more
than 1 character from a 1 byte file
Mark Brown (JIRA) wrote:
[
https
: (STDCXX-333) std::wfilebuf extracts more
than 1 character from a 1 byte file
Mark Brown (JIRA) wrote:
[
https://issues.apache.org/jira/browse/STDCXX-333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12474266
]
Mark Brown commented on STDCXX-333
Hi everyone,
I have been experimenting with stdcxx on Cygwin and Linux. I have come across
the informative stdcxx build results page
(http://people.apache.org/~sebor/stdcxx/results/) and found it quite useful in
my experiments on Linux but in the short time that I have been monitoring the
Hi all,
Just for kicks I'm trying to build a 12d version of the library on Cygwin.
Things looks like they're going okay except for a couple of errors that open up
a message box on the screen telling me that a test had a problem. The build
stops at this point and waits for me to click on a
Okay, after I took out the -fPIC flag to get rid of the pesky warnings the
library build went fine with just a couple of warnings. What's the policy when
it comes to warnings? Are some warnings expected or are builds supposed to be
completely clean?
gcc -c -I/home/mbrown/stdcxx/include/ansi
Hi again,
Sorry about all the emails tonight. I'm sending them out as I run into things.
Hopefully they'll be useful. After the library built all examples are now
getting the same error. Looks like the Cygwin linker can't find the library
even though it's there (I checked :)
$ make
gcc -c
.
-- Mark
-Original Message-
From: [EMAIL PROTECTED]
Sent: Fri, 02 Mar 2007 10:13:47 -0700
To: stdcxx-dev@incubator.apache.org
Subject: Re: Cygwin 12d build issues
Mark Brown wrote:
Hi all,
Just for kicks I'm trying to build a 12d version of the library on
Cygwin. Things looks
Here's a patch for the -fPIC warnings on Cygwin (issue STCXX-346). I got a
little crafty with the conditional and used findstring instead of two ifs. I
hope that's okay. I also took the liberty to add a -*- Makefile -*- tag to
the top of the file to enable emacs syntax highlighting.
-- Mark
Hi,
There appears to be a little typo in the source file alloc.cpp as pointed out
by the gcc compilation error on Cygwin. The patch below fixes it.
gcc -c -I/home/mbrown/stdcxx/include/ansi -D_RWSTDDEBUG-D_RWSTD_USE_CONFIG
-I/home/mbrown/stdcxx/include
I'm trying to compile the tests on Cywgin and I'm getting some errors. Here's
the first one. I tried to see if it was something obvious that I could easily
fix myself but the code in both cases is a macro defined to yet another macro
that expands to either setjmp or sigsetjmp if that's a macro
Here's another test that throws an error at compile time. It looks like the
compiler doesn't like the using N as the dimension of the array. I thought
using variables as array dimensions was not allowed in C++?
gcc -pedantic -nostdinc++ -g -W -Wall -Wcast-qual -Winline -Wshadow
/STDCXX-352
-- Mark
Thanks
Martin
Farid Zaripov wrote:
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED]
Sent: Sunday, March 04, 2007 2:22 AM
To: stdcxx-dev@incubator.apache.org
Subject: Re: Cygwin 12d build issues
Mark Brown wrote:
-Original Message
member functions cbegin() and cend()
Attached is my first attempt at a patch implementing these functions. Please
let me know if I've missed something. The ChangeLong entry is here:
2007-03-13 Mark Brown [EMAIL PROTECTED]
STDCXX-335
* map (cbegin, cend, crbegin, crend
-Original Message-
From: [EMAIL PROTECTED]
Sent: Wed, 14 Mar 2007 11:44:27 -0700
To: stdcxx-dev@incubator.apache.org
Subject: Re: [jira] Closed: (STDCXX-16) __rb_tree::operator=() does not
store rhs' comparison object in lhs
Farid Zaripov (JIRA) wrote:
[
. Am I looking in the right place?
-- Mark
As for the other containers, we'll need to remember to add
tests for these new functions when we get around to porting
(or writing from scratch) the tests for those.
Martin
Mark Brown wrote:
How frustrating!
Here it is again, this time inline
= ListIds::ReverseIterator == tdata.func_.iter_id_
|| ListIds::ConstReverseIterator == tdata.func_.iter_id_;
And the ChangeLog entry to go with it:
2007-03-27 Mark Brown [EMAIL PROTECTED]
* 23.list.insert.cpp (InsertRange, InsertRangeOverload
Hi Eric,
I don't know if there is a development plan per se except for a number of Jira
issues (one for each section of the TR). Your suggestion to make the extensions
available in namespace std sounds like a fine idea to me.
I am also interested in the TR1 extensions but I haven't
-Original Message-
From: [EMAIL PROTECTED]
Sent: Fri, 11 May 2007 16:54:37 -0600
To: stdcxx-dev@incubator.apache.org
Subject: Re: money_get example output
Mark Brown wrote:
Hi all,
Out of curiosity I tried compiling and running the example from the
money_get page with stdcxx
Martin,
Thanks for fixing it! I have a question about the new code: Could you show an
example of an international monetary string that would be correctly parsed by
the facet? I tried a few but none of them could be parsed. For instance, USD
1234 gives this output:
USD 1234 -- -- 0
The same
-Original Message-
From: [EMAIL PROTECTED]
Sent: Sat, 12 May 2007 14:09:34 -0600
To: stdcxx-dev@incubator.apache.org
Subject: Re: svn commit: r537492 -
/incubator/stdcxx/trunk/doc/stdlibref/money-get.html
Mark Brown wrote:
Martin,
Thanks for fixing it! I have a question about
(https://issues.apache.org/jira/browse/STDCXX-412).
-- Mark
-Original Message-
From: [EMAIL PROTECTED]
Sent: Sat, 12 May 2007 15:42:16 -0600
To: stdcxx-dev@incubator.apache.org
Subject: Re: svn commit: r537492 -
/incubator/stdcxx/trunk/doc/stdlibref/money-get.html
Mark Brown wrote
I came across a post from 2002 with a comparison between C stdio, Classic
Iostreams, and Standard Iostreams. I thought it might be interesting to post it
here for reference and re-run the numbers today with the latest versions of
compilers and libraries:
22.locale.num.put.mt gets a SIGSEGV on my system (Fedora 6) even with a single
thread. Here's the output of gdb:
$ gdb ./22.locale.num.put.mt
GNU gdb Red Hat Linux (6.5-15.fc6rh)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License,
It might be more helpful if I include the debugging information. The test runs
okay with just one thread in a debug build so this output is for two threads.
(gdb) r --nthreads=2
Starting program: /home/mbrown/stdcxx-gcc-4.1.1-15D/tests/22.locale.num.put.mt
--nthreads=2
[Thread debugging using
-Original Message-
From: [EMAIL PROTECTED]
Sent: Sat, 16 Jun 2007 15:59:11 -0600
To: stdcxx-dev@incubator.apache.org
Subject: list of available cross-build result views
...is on the page below. This page and the cross-build views are
all set up to get generated from the
-Original Message-
From: [EMAIL PROTECTED]
Sent: Tue, 26 Jun 2007 18:57:44 +0300
To: stdcxx-dev@incubator.apache.org
Subject: RE: status of thread safety tests
-Original Message-
From: Mark Brown [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 26, 2007 5:06 PM
To: stdcxx
-Original Message-
From: [EMAIL PROTECTED]
Sent: Thu, 05 Jul 2007 15:14:29 -0600
To: stdcxx-dev@incubator.apache.org
Subject: [VOTE] ready to graduate
Our mentors as well as a number of IPMC members recently expressed
confidence in stdcxx being ready to graduate out of the
-Original Message-
From: [EMAIL PROTECTED]
Sent: Mon, 30 Jul 2007 17:37:00 -0600
To: stdcxx-dev@incubator.apache.org
Subject: Taking tasks for STDCXX-391
Hi, I am new to this list. I am a colleague of Martin Sebor, and I am
going to start working on some of the tasks in his JIRA
-Original Message-
From: [EMAIL PROTECTED]
Sent: Mon, 20 Aug 2007 05:20:32 -0600
To: stdcxx-dev@incubator.apache.org
Subject: RE: expectation vs requirements for locale facets
Mark Brown wrote:
In my experience, the time_get facet isn't always able to
reliably parse
-Original Message-
From: [EMAIL PROTECTED]
Sent: Fri, 24 Aug 2007 10:38:26 -0600
To: stdcxx-dev@incubator.apache.org
Subject: Re: help scheduling issues
Greetings all.
I've taken a little time to glance over the open tasks which I reported
but have not been assigned. My
Hi Andrew,
I found myself needing documentation for the test driver in the past. Since
you mentioned Doxygen comments in the exec utility, I'm wondering if there is
generated documentation available somewhere that I don't know about. Could you
point me in the right direction?
Many thanks!
--
-Original Message-
From: [EMAIL PROTECTED]
Sent: Thu, 23 Aug 2007 09:21:33 -0600
To: stdcxx-dev@incubator.apache.org
Subject: Re: [jira] Created: (STDCXX-527) publish LOC metrics
Michael van der Westhuizen wrote:
Hi Martin,
On 8/23/07, Martin Sebor (JIRA) [EMAIL PROTECTED]
-Original Message-
From: [EMAIL PROTECTED]
Sent: Sun, 26 Aug 2007 17:37:02 -0600
To: stdcxx-dev@incubator.apache.org
Subject: Re: svn commit: r569152 -
/incubator/stdcxx/branches/4.2.0/etc/config/src/LIMITS.cpp
Mark Brown wrote:
-Original Message-
From: [EMAIL PROTECTED
be a solution?
-- Mark
--Andrew Black
Mark Brown wrote:
Hi Andrew,
I found myself needing documentation for the test driver in the past.
Since you mentioned Doxygen comments in the exec utility, I'm wondering
if there is generated documentation available somewhere that I don't
know about. Could
Martin,
This sounds reasonable to me. Although I wonder, is there any reason
to have a number of ChangeLogs instead of just one at the top of the
tree?
-- Mark
Martin Sebor wrote:
After I generated/updated the latest ChangeLogs I noticed that we have
been less than completely consistent in
Martin Sebor wrote:
After dispatching the remaining issues scheduled for 4.2.0(*) I'd
like to merge the few outstanding minor fixes and docs changes to
4.2.0 and create the (hopefully) final release candidate at the
end of the day (US/Mountain) tomorrow. If anyone has any concerns
please raise
On 10/17/07, Martin Sebor [EMAIL PROTECTED] wrote:
Okay, I've got it:
http://issues.apache.org/jira/browse/STDCXX-162
Damn that was hard!
So, what do we do? Going back to using a mutex for strings would
be *huge* performance hit on one of the most popular platforms
(if not the most
Martin Sebor wrote:
I created what I'm hoping will be the final stdcxx 4.2.0 release
candidate, stdcxx-4.2.0-rc-6:
http://svn.apache.org/repos/asf/incubator/stdcxx/tags/4.2.0-rc-6/
along with a tarball containing the sources:
http://people.apache.org/~sebor/stdcxx/stdcxx-incubating-4.2.0.tar.gz
Martin Sebor wrote:
[snip]
Here are a few possibilities:
1. Clean slate. Everything compiles and links cleanly with no
errors or warnings, and runs successfully to completion with
zero failed assertions.
2. Warnings acceptable, no errors. Same as above except that
warnings are
Other than some warnings gcc 4.1.2 on Linux worked fine this time.
I tried Intel 10.0 and found another test that gave a compiler error.
I didn't investigate it in great detail but it looks like a problem
in the test rather than a compiler bug. In any event, I don't see it
as a blocker for the
Travis asked me to forward his response (thanks for the confirmation,
Travis!) to the list. I suppose I should open an issue for this then.
--Mark
[EMAIL PROTECTED] wrote:
mark.g.brown wrote:
Hi all,
I have the simple program below that aborts with the latest stdcxx but
runs with no problems
I have been looking at the istream_iterator class, mostly out of
curiosity than to try to fix a specific bug, to see if there are
any other discrepancies with the standard and operator++ caught
my attention. The standard says that the operator should return
*in_stream value but the stdcxx
Martin Sebor wrote:
Following up on an old thread...
I suspect this problem that we've been discussing for some time now
might stem from the fact that the standard doesn't actually define
what it means to invalidate an iterator. Here's some background:
Farid Zaripov wrote:
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 31, 2007 6:35 PM
To: stdcxx-dev@incubator.apache.org
Subject: Re: Apache C++ Standard Library 4.2.0 released
FYI: I've made the same announcement on a number of
newsgroups
Have you guys seen the Boost regression test page?
http://engineering.meta-comm.com/boost-regression/1_34_1/user/summary_release.html
I think there are some good ideas there. I like the links to
the test sources and to the compiler errors for the ones that
error out.
--Mark
Martin Sebor wrote:
Woohoo! This is awesome news! Congratulations!
--Mark
William A. Rowe, Jr. wrote:
Congratulations from your mentors, Justin and I, well done guys!
Original Message
Subject: ASF Board Meeting Summary - November 14, 2007
Date: Thu, 15 Nov 2007 10:34:54 -0500
From: Jim
Farid Zaripov wrote:
Whether these examples should be abstract, or based on C++ Standard
Library
declarations/definitions?
Since the source incompatible changes involves changes in
function/class mebmers
prototype, or changes in global data/class data members declaration, or
changing the
Martin Sebor wrote:
Farid Zaripov wrote:
Whether these examples should be abstract, or based on C++ Standard
Library
declarations/definitions?
Examples using the C++ standard library classes or functions would
be great, but any other sort will, in my opinion, work just as well.
The point is
Martin Sebor wrote:
Mark Brown wrote:
[...]
Or adding overloads with different behavior to functions that are
a better match for calls in existing programs. For instance, if we
added an overload for the ostream inserter for wchar_t* that did
something different than print the value
The Linux Documentation Project lists a number of examples of library
incompatibilities:
http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN135
--Mark
On Dec 13, 2007 4:44 PM, Martin Sebor [EMAIL PROTECTED] wrote:
Travis Vitek wrote:
Travis Vitek wrote
Martin Sebor
Have you considered what it's going to mean for merges between branches?
Wouldn't letting the Makefile figure out the version from the pathname of one
of the files be more reliable? If Subversion is like CVS and understands the
$Source$ keyword you could even use it.
-- Mark
On Dec 13, 2007 2:24
Martin,
Most of the links to the log files are broken. They all point to files
in http://people.apache.org/tmp/. Also, I'm not sure I understand how
rows in the tables are supposed to be arranged now. If I recall, they
used to be ordered alphabetically but after your change 26 comes
before 23,
Components: 27. Input/Output
Affects Versions: 4.1.3
Reporter: Mark Brown
When I call tellp() on an empty stringstream I get -1 instead of 0.
#include cassert
#include sstream
main()
{
std::ostringstream out;
std::ios::pos_type pos = out .tellp () ;
assert (pos
: Bug
Components: 27. Input/Output
Affects Versions: 4.1.3
Environment: gcc 3.2.3 on Linux
Reporter: Mark Brown
I get an an abort when I run the following program on Linux.
#include cassert
#include fstream
#include iostream
int main ()
{
{
std
: Cygwin
Reporter: Mark Brown
I tried to build the library on Cygwin but I'm getting linker errors for the
localedef utility. I have the iconv library installed (in /usr/lib) but make
isn't linking with it. I also get linker errors for _catopen, _catgets, and
_catclose. I searched under
[
https://issues.apache.org/jira/browse/STDCXX-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472153
]
Mark Brown commented on STDCXX-337:
---
Here's a simple patch that fixed the iconv and catgets linker errors for me
[
https://issues.apache.org/jira/browse/STDCXX-333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12474266
]
Mark Brown commented on STDCXX-333:
---
I tried to see if I could reproduce this problem on Cygwin. My version
Environment: Cygwin
Reporter: Mark Brown
While trying to reproduce the problem noted in STDCXX-333 on Cygwin I
encountered an error with the stdcxx localedef program:
nls$ ../bin/localedef -c -f /home/mbrown/stdcxx/etc/nls/charmaps/UTF-8 -i
/home/mbrown/stdcxx/etc/nls/src/en_US
[
https://issues.apache.org/jira/browse/STDCXX-24?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12477188
]
Mark Brown commented on STDCXX-24:
--
I can compile the latest library on Cygwin without any errors from collate.cpp
Environment: gcc 3.4.4 on Cygwin
Reporter: Mark Brown
gcc shared library build on Cygwin spits out a warning message about the -fPIC
flag on the command line for every .cpp file:
make[2]: Entering directory `/home/mbrown/stdcxx-12d/lib'
generating dependencies for $(TOPDIR)/src/atomic.s
[
https://issues.apache.org/jira/browse/STDCXX-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12477681
]
Mark Brown commented on STDCXX-337:
---
I'm not sure how it happened but there's a typo in the patch I suggested
[
https://issues.apache.org/jira/browse/STDCXX-338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12479884
]
Mark Brown commented on STDCXX-338:
---
If it helps, I also get the same error with the latest trunk and gcc 4.1.1
Affects Versions: 4.1.3
Environment: Cygwin, gcc
Reporter: Mark Brown
Originally posted here:
http://mail-archives.apache.org/mod_mbox/incubator-stdcxx-dev/200703.mbox/[EMAIL
PROTECTED]
-Original Message-
From: [EMAIL PROTECTED]
Sent: Sat, 3 Mar 2007 11:33:26 -0800
[
https://issues.apache.org/jira/browse/STDCXX-352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12479885
]
Mark Brown commented on STDCXX-352:
---
Also reproduced by Farid Zaripov:
http://mail-archives.apache.org/mod_mbox
Issue Type: Bug
Components: Locales
Affects Versions: 4.1.3
Environment: Cygwin
Reporter: Mark Brown
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
[
https://issues.apache.org/jira/browse/STDCXX-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12483012
]
Mark Brown commented on STDCXX-351:
---
The test compiles now so your change must have fixed it.
[gcc 3.4.6] error
Reporter: Mark Brown
The money_get Class reference pag:
http://incubator.apache.org/stdcxx/doc/stdlibref/money-get.html is missing
documentation for the money_base class.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Components: Documentation
Affects Versions: 4.1.3
Reporter: Mark Brown
-Original Message-
From: [EMAIL PROTECTED]
Sent: Fri, 11 May 2007 16:54:37 -0600
To: stdcxx-dev@incubator.apache.org
Subject: Re: money_get example output
Mark Brown wrote:
Hi all,
Out
[
https://issues.apache.org/jira/browse/STDCXX-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Brown updated STDCXX-413:
--
Component/s: Tests
Description:
The test 22.locale.money.get.cpp doesn't exercise
[
https://issues.apache.org/jira/browse/STDCXX-412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Brown updated STDCXX-412:
--
Summary: money_get fails to parse currency in international format (was:
num_get fails to parse
[
https://issues.apache.org/jira/browse/STDCXX-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Brown updated STDCXX-426:
--
Attachment: strace.run-21.cwchar.log
Attached partial strace output of running exec 21.cwchar
Components: Configuration
Affects Versions: 4.2
Environment: Intel C++ 10 on Linux
Reporter: Mark Brown
Configuring stdcxx for 32-bits using
BUILDMODE=pthreads,archive,optimized,narrow on x86_64 I see the system
architecture is LP64 little endian instead of ILP32 little endian
[
https://issues.apache.org/jira/browse/STDCXX-489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513707
]
Mark Brown commented on STDCXX-489:
---
Hi Andrew,
Can you suggest where to get the correct iccvars.sh script or how
Environment: gcc 4.1.2, Linux/x86_64
Reporter: Mark Brown
According to my timings string::push_back() in stdcxx 4.1.3 is more than twice
as slow than the same function in gcc 4.1.2 on Linux x86_64:
$ time ./push_back-stdcxx 1
real0m2.175s
user0m2.004s
sys 0m0.172s
Environment: gcc 4.1.2 on Linux/x86_64
Reporter: Mark Brown
Comparing overloads of string::operator+=() in stdcxx with the same functions
in gcc 4.1.2, stdcxx is up to twice slower than gcc:
$ time ./op_plus_equal-stdcxx 1 0
real0m2.241s
user0m1.932s
sys
Environment: gcc 4.1.2 on Linux/x86_64
Reporter: Mark Brown
This is a similar problem to STDCXX-492: all overloads of string::append() are
slower than the same overloads in gcc:
$ let n=0; while [ $n -lt 3 ]; do time LD_LIBRARY_PATH=../lib
./append-stdcxx-4.1.3 5 $n; let n
Environment: gcc
Reporter: Mark Brown
Gcc provides many built-in equivalents of C library functions like memcpy or
strlen for optimization purposes. stdcxx should take advantage of them when
possible to deliver better performance.
http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc
[
https://issues.apache.org/jira/browse/STDCXX-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12537089
]
Mark Brown commented on STDCXX-231:
---
I just benchmarked getline() from stdcxx 4.1.3 against the same function
78 matches
Mail list logo
