On 09/05/12 23:51, Martin Sebor wrote:
On 09/05/2012 09:03 PM, Stefan Teleman wrote:
[...]
Agreed.
But: if the choice is between an implementation which [1] breaks ABI
and [2] performs 20% worse -- even in contrived test cases -- than
another implementation [2] which doesn't break ABI, and
As an ASF project? It's not going to happen.
On Sep 4, 2012, at 12:04 PM, Martin Sebor mse...@gmail.com wrote:
On 09/02/2012 08:42 AM, Jim Jagielski wrote:
On Sep 2, 2012, at 12:02 AM, Martin Sebormse...@gmail.com wrote:
On 08/31/2012 02:38 PM, Liviu Nicoara wrote:
My input below.
On
On Thu, Sep 6, 2012 at 9:16 AM, Liviu Nicoara nikko...@hates.ms wrote:
I think Stefan is referring to adding a mutex member variable to the facet
in question and breaking binary compatibility. If that is the case I have
confused things when I suggested exactly that, earlier. A cursory read
On 09/06/2012 09:58 AM, Stefan Teleman wrote:
On Thu, Sep 6, 2012 at 9:16 AM, Liviu Nicoaranikko...@hates.ms wrote:
I think Stefan is referring to adding a mutex member variable to the facet
in question and breaking binary compatibility. If that is the case I have
confused things when I
What is the latest policy in what regards trivial fixes, e.g., the volatile
qualifier for the max var in LIMITS.cpp we discussed earlier, etc.? It seems
excessive to create a bug report for such issues.
Also, IIUC from reading previous discussions, forward and backward binary
compatible
Liviu Nicoara nikko...@hates.ms writes:
What is the latest policy in what regards trivial fixes, e.g., the
volatile qualifier for the max var in LIMITS.cpp we discussed earlier,
etc.? It seems excessive to create a bug report for such issues.
My advice based on some observations with other
On 09/06/12 14:37, Wojciech Meyer wrote:
Liviu Nicoara nikko...@hates.ms writes:
What is the latest policy in what regards trivial fixes, e.g., the
volatile qualifier for the max var in LIMITS.cpp we discussed earlier,
etc.? It seems excessive to create a bug report for such issues.
[...]
So
If Christopher is interested in moving, then, to be frank, then
I expect him to do whatever work is required to move it, including
any legal legwork. This is esp true since his whole reason
for moving it is, as I mentioned, completely bogus.
My concern is to try to make it a success here.
On Sep
Trivial fixes should just be fixed... the normal expectation is
that bug reports are for non-trivial bugs or for trivial (and
non-trivial) bugs reported from the outside.
If a committers sees a bug, just go ahead and fix it, and
document the fix in a commit log, changefile, etc ;)
On Sep 6,
On Thu, Sep 6, 2012 at 2:46 PM, Stefan Teleman stefan.tele...@gmail.com wrote:
[steleman@darthvader][/src/steleman/programming/stdcxx-ss122/stdcxx-4.2.1/build/tests][09/06/2012
14:40:11][1084] ./22.locale.numpunct.mt --nthreads=2 --nloops=100
# INFO (S1) (10 lines):
# TEXT:
# COMPILER:
On Sep 5, 2012, at 4:03 PM, Martin Sebor wrote:
On 09/05/2012 01:33 PM, Liviu Nicoara wrote:
On 09/05/12 15:17, Martin Sebor wrote:
On 09/05/2012 12:40 PM, Liviu Nicoara wrote:
On 09/05/12 14:09, Stefan Teleman wrote:
On Wed, Sep 5, 2012 at 10:52 AM, Martin Sebor mse...@gmail.com wrote:
I'm not sure how easily we can do that. Almost all of locale
is initialized lazily. Some of the layers might depend on the
facets being initialized lazily as well. This was a deliberate
design choice. One of the constraints was to avoid dynamic
initialization or allocation at startup. [...]
Anyone is welcome to express their opinion here, especially
if you are or have in the past contributed to the project.
The weight of the opinion is (or should be) commensurate to
the value of the contributions. I think the ASF calls this
Meritocracy.
I made the stdcxx process increasingly more
One thing I forgot to mention: we have three active branches,
and, for better or worse, most changes tend to get committed
to 4.2.x first. It's easy to forget or delay committing the
same change to 4.3.x and trunk. Having an issue in Jira
serves as a reminder to also commit the change to the
On Thu, Sep 6, 2012 at 7:31 PM, Liviu Nicoara nikko...@hates.ms wrote:
There would be a performance degradation. IMHO, it would be minor and would
simplify the code considerably.
After finally being able to reproduce the defect with SunPro 12.3 on x86_64 I
tried to remove the lazy
Every project has certain branch strategy, I'm not sure about this so
maybe Martin can advice. I prefer to develop on trunk and cherry pick
to the other branches avoiding bulk merges (and that's in both
directions).
We've done most work on 4.2.x for historical reasons. I think
a better strategy
Liviu Nicoara nikko...@hates.ms writes:
I sure hope we can have totally open (civilized) discussions going
forward. :)
Yes I'm also sure we can, thanks :-)
--
Wojciech Meyer
http://danmey.org
17 matches
Mail list logo
