Re: STDCXX-536

[Martin Sebor]

Eric Lemings wrote:

FWIW, I just noticed that mpfr  contains the
following configuration option:

  --enable-tests-timeout=NUMenable timeout (NUM seconds) for test
programs
  (NUM <= ) [default=no]; if enabled, env
variable
  $MPFR_TESTS_TIMEOUT overrides NUM (0: no
timeout).


Right. I thought we could do something similar.

Martin



Brad.


-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
Sent: Sunday, March 09, 2008 5:41 PM
To: dev@stdcxx.apache.org
Subject: Re: STDCXX-536

Eric Lemings wrote:
FWIW, I was just reading the description for Jira issue 

STDCXX-536 and

the associated comments.
 
I believe this is basically what Travis has already stated 

in a round-
about manner but it seems to me that if a test is timing 

out, there are

two possibilities: 1. the test is caught in an infinite loop, or 2.)
the test requires too much time to completely execute.  In 

either case,

the test needs to be rewritten to fix the infinite loop or to break
the test into smaller tests that can completely execute in 

a reasonably

short amount of time -- a couple of minutes at most on the slowest
supported platforms.

Right, that's the conclusion we came to for the tests that can be
broken up. The downside of doing this is code duplication (either
source or object) between the small tests that share the same
scaffolding, which will increase compilation and/or link times,
and, of course, run times. With a large enough of number of these
little tests the consequences could be actually worse than the
status quo.

The problem with most of our thread safety tests is that they are
written to do the sane fixed number of operations in parallel, and
this number takes a different amount of time depending on factors
such as the scheduler's time slice and the system load. Ideally,
the tests would take these parameters into consideration and run
for sufficiently long (but no longer) to exercise the functionality
with some desired percentage of parallelism/contention. To do that,
the tests would need to be able to time out.

And aren't multithreaded programs (or tests) supposed to 

perform faster

-- not slower -- than their single-threaded counterparts?  :)

Only if they are written to avoid contention, which is the exact
opposite of what our thread safety tests are designed to do.

Martin

Re: Preliminary triage of 4.2.1 issues

[Martin Sebor]

Eric Lemings wrote:


Suggest postponing the following Jira issues until after the 4.2.1 release:


Thanks for the analysis!



STDCXX-430


I think this is mostly done, or waiting on Boost to apply Farid's
patches. Farid?


STDCXX-701


Here we just need to create the .rdf file but I'm fine deferring
it.


STDCXX-391


Agreed. This one's not going to happen anytime soon.


STDCXX-682


I'd like to try to find the time to do this sometime soon. It
shouldn't be more than 2 hours.


STDCXX-536


Agreed. I don't think we have the time to resolve this for 4.2.1.
I'll let Travis defer it.


STDCXX-527


We have all the data in the attachments to the issue. We just
need to publish it on the project's page.


STDCXX-618


I'll let Travis decide this one.



The reasoning for postponing these issues is one or both of the following:

Not needed to meet primary goals of 4.2.1 release (i.e. HP-UX IPF 
and MSVC 9.0 support)
Not appropriate for a patch release (i.e. can't be resolved within 
timeframe for a patch release)


Could probably postpone some other issues as well but these are the most 
obvious candidates.


I'm sure you're right. I plan to go through them this week to
see what else could be deferred.

Martin



Brad.

Preliminary triage of 4.2.1 issues

[Eric Lemings]

Suggest postponing the following Jira issues until after the 4.2.1  
release:


STDCXX-430
STDCXX-701
STDCXX-391
STDCXX-682
STDCXX-536
STDCXX-527
STDCXX-618

The reasoning for postponing these issues is one or both of the  
following:


	Not needed to meet primary goals of 4.2.1 release (i.e. HP-UX IPF and  
MSVC 9.0 support)
	Not appropriate for a patch release (i.e. can't be resolved within  
timeframe for a patch release)


Could probably postpone some other issues as well but these are the  
most obvious candidates.


Brad.

Potential null pointer dereference in locale_combine.cpp

[Martin Sebor]

Hey Scott,

In case you haven't seen it yet, I reduced the HP aCC warning
in locale_combine.cpp noted in STDCXX-746 to a compiler bug
described in STDCXX-764. So just as a heads up, I suspect that
the bug could be responsible for some of the other warnings.

  http://issues.apache.org/jira/browse/STDCXX-746
  http://issues.apache.org/jira/browse/STDCXX-764

Martin

Re: svn commit: r637539 - /stdcxx/trunk/include/deque

[Martin Sebor]

Farid Zaripov wrote:

-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
Sent: Sunday, March 16, 2008 6:58 AM
To: dev@stdcxx.apache.org
Subject: Re: svn commit: r637539 - /stdcxx/trunk/include/deque


The names pointer1 and pointer2 need to privatized (e.g., _Pointer1).


  Yes, I forgetting about this all the time.


It's easy to do :) We should probably update 17.names.cpp with
these names.

Martin



  Done thus: http://svn.apache.org/viewvc?rev=637542&view=rev

Farid.

RE: svn commit: r637539 - /stdcxx/trunk/include/deque

[Farid Zaripov]

> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
> Sent: Sunday, March 16, 2008 6:58 AM
> To: dev@stdcxx.apache.org
> Subject: Re: svn commit: r637539 - /stdcxx/trunk/include/deque
> 
> 
> The names pointer1 and pointer2 need to privatized (e.g., _Pointer1).

  Yes, I forgetting about this all the time.

  Done thus: http://svn.apache.org/viewvc?rev=637542&view=rev

Farid.

RE: [HPUX/aCC] build failure: 22.locale.money.put

[Farid Zaripov]

> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
> Sent: Thursday, March 13, 2008 8:43 PM
> To: dev@stdcxx.apache.org
> Subject: Re: [HPUX/aCC] build failure: 22.locale.money.put
> 
> I see compilation errors in nightly builds. I suspect it's 
> still fallout from Farid's recent change to string.cc:
> 
>http://svn.apache.org/viewvc?view=rev&revision=629584
> 
> and
> 
>http://svn.apache.org/viewvc?view=rev&revision=635439
> 
> Farid, I think I'm going to have to ask you to revert the 
> patch until you can come up with a cleaner solution.

  The patch partially reverted in this commit:
http://svn.apache.org/viewvc?rev=637897&view=rev

  Partially, because the changes in __rw_replace() not causing the
problems and fixes the
STDCXX-438 issue.

  The rest issues (170, 629, 632) are deferred to 4.3 release.

Farid.

RE: [PATCH] punct.cpp

[Farid Zaripov]

> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] 
> Sent: Friday, March 14, 2008 10:08 PM
> To: dev@stdcxx.apache.org
> Subject: RE: [PATCH] punct.cpp
> 
> > You're right, I was looking at the output of %.g. Looks 
> like we need 
> > to replace the "%g" with "%.0g" here. Let me take care of that.
> > 
> > 
> 
> Actually, I don't think the patch has been applied yet. 
> Farid, please remember to update the test as Travis suggests 
> before committing the patch.

  The test updated thus http://svn.apache.org/viewvc?rev=637392&view=rev

  The patch applied in this commit:
http://svn.apache.org/viewvc?rev=637393&view=rev

Farid.

RE: svn commit: r635439 - /stdcxx/trunk/include/string.cc

[Farid Zaripov]

> -Original Message-
> From: Travis Vitek [mailto:[EMAIL PROTECTED] 
> Sent: Monday, March 10, 2008 8:36 PM
> To: dev@stdcxx.apache.org
> Subject: RE: svn commit: r635439 - /stdcxx/trunk/include/string.cc
> 
> Is this actually safe, and does it actually do what you want? If
> _InputIter::operator* returns a rvalue and you static_cast 
> that to a const_reference, you will get the address of the 
> temporary. That address can't reliably be used to to test 
> that `__first2' is inside `__s' or not, so the bug that you 
> are trying to eliminate here will still exist for iterators of this
type.
  Yes, it was what I want. Actually I don't think we need detect
the self reference for all posible iterators, that could be passed in
string methods. For example the STLport checking the only if
_InputIterator type is string::iterator (which is equal to char_type*).
I think that checking the iterator and reverse_iterator types
is enough. What do you think?

> If _InputIter is a pointer type, you should not need a cast 
> at all, and if it is a class type, you _should_ be able to 
> use the result of
> operator->(), but that isn't really safe because it could 
> return a proxy
> for the actual pointer. I think you could use SFINAE and 
> traits to detect that the return type of operator->() is a 
> pointer type if we really wanted to, and then just make a 
> copy if it isn't.

  Yes, I agree that using the type traits is more suitable solutuion.
I'm not used the type traits in this patch because as Martin said
in
http://www.mail-archive.com/[EMAIL PROTECTED]/msg05705.htm
l
that the changes which are using the type traits should be holded until
4.3 release. Another option is adding the overloads for assign(),
replace(), insert()
methods, but this is not a binary compatible change.

Farid.

Re: [Stdcxx Wiki] Update of "LocaleLookup" by MartinSebor

[Travis Vitek]

Martin Sebor wrote:
> 
> But we do need to come up with a sound specification of the query syntax
> before implementing any more code.
> 

Okay, the proposed query syntax grammar essentially the same as that being
used for the  value in xfail.txt. So we have

   is a shell globbing pattern in the format below. All fields
  are required.

  iso-country  ::= ISO-639-1 or ISO-639-2 two or three character country
code
  iso-language ::= ISO-3166 two character language code
  iana-codeset ::= IANA codeset name with '-' replaced or removed

  match::=
---
  match_list   ::= match | match ' ' match_list

So the previous example to select `en_US.*' with a 1 byte encoding or
`zh_*.UTF-8' with a 2, 3, or 4 byte encoding would use the following query
string.

  en-US-*-1 zh-*-UTF8-2 zh-*-UTF8-3 zh-*-UTF8-4

This long expression could be written using a brace expansion to simplify
it.

  en-US-*-1 zh-*-UTF8-{2,3,4}

I propose that we not support the BRE syntax, simply because it is so
complex. Yes, it might be quite easy to prototype a solution using grep and
other shell utilities, but providing a complete implementatoin in C [where
we actually need it] is going to be difficult at best. For what we need,
shell globbing should be sufficient to handle the cases that we need to
satisfy the objective.

I suppose you could consider en-US-*-1 is "language=en" and "country=US" and
"codeset=*" and "mb_cur_len=1" so '-' represents an intersection operation,
but I prefer to think of the entire expression to be either a match or not a
match.


Martin Sebor wrote:
> 
> I think it's great
> to put together a prototype at the same time, just as long as it's
> understood that the prototype might need to change as we discover
> flaws in it or better ways of doing it.
> 

I have no problem with flaws or small improvements. When we start talking
about implementing a regular expression parser I get concerned.

Travis
-- 
View this message in context: 
http://www.nabble.com/RE%3A--Stdcxx-Wiki--Update-of-%22LocaleLookup%22-by-MartinSebor-tp15992191p16089939.html
Sent from the stdcxx-dev mailing list archive at Nabble.com.