and/or when you don't
> have commit permissions. Others may have a different preference.
My personal preference would be both.
>
> Martin
>
>>
>> Thanks,
>> Liviu
>>
>
Thanks,
--
Wojciech Meyer
http://danmey.org
sulting in undefined
>>> run-time behavior.
>>> The cure for this defect has two parts:
>>> 1. the member functions in question must truly return a copy by avoiding a
>>> call to the copy constructor, and using a constructor which creates a deep
>>> copy of the std::string.
>>> 2. access to these member functions must be serialized, in order to
>>> guarantee atomicity
>>> of the creation of the std::string being returned by value.
>>> Patch for 4.2.1 to follow.
>>
>> --
>> This message is automatically generated by JIRA.
>> If you think it was sent incorrectly, please contact your JIRA administrators
>> For more information on JIRA, see: http://www.atlassian.com/software/jira
>>
>
--
Wojciech Meyer
http://danmey.org
but then there is a
balance between analysing and interpreting parts of it, even in the
extreme case if you run it - you will not know if it suppose to
halt. Therefore please use tools but be a bit reserved for the results.
All these MT analysers are based on a simple heuristics and logical
assertions that can't give you 100% right results. I don't think people
here are picky about your patches, it's just better sometimes to take a
breath and see the big picture.
--
Wojciech Meyer
http://danmey.org
ch identical in
> nature to the one I have attached now. Just want to be 100% sure we
> are talking about the same thing. This one still produces failures
> (crashes, assertions, etc.) in the locale MT tests on SPARC and
> elsewhere in your builds?
>
> Thanks,
> Liviu
>
>
--
Wojciech Meyer
http://danmey.org
Liviu Nicoara writes:
> On 09/17/12 11:21, Stefan Teleman wrote:
>> On Mon, Sep 17, 2012 at 11:17 AM, Liviu Nicoara wrote:
>>
>>> I hope you agree that this synchronization is sufficient for the facet
>>> initialization and reading of facet data.
>>
>> Sorry, I do not agree. Two different thread
,
> modulo the issues for which I attach the patch below, for review.
I think it will be a big win to support Clang for the community.
> I built successfully and ran the test suite on both Mac and Linux,
> wigh gcc 4.5.4 and 4.5.2, respectively.
That's cool!
> Thanks.
>
> L
e test cases and open
> issues for all changes.
I fully agree with the test cases and the rest of the paragraph.
It's really good to know your opinion!
Thanks.
--
Wojciech Meyer
http://danmey.org
Liviu Nicoara 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
trunk and cherry pick
to the other branches avoiding bulk merges (and that's in both
directions).
>
> Also, besides the Linux, FreeBSD, Windows, Solaris builds hosted on Apache
> (Jenkins) is anybody building on HP-UX, AIX, etc.?
>
> Thanks.
>
> Liviu
>
--
Wojciech Meyer
http://danmey.org
would help,
> all we'd need to do is ask #infra to move stdcxx to git.
Git sounds much better to me, so I vote for it.
--
Wojciech Meyer
http://danmey.org
atches for 1058 ready to commit to branches (4.2.x and 4.3.x).
>>>
>>> OK to go?
>>
>> The patch looks ok to me. What seems to be the problem? +1
I also had a initial look at the patch. Looks OK, I looked at the other
occurrences of "operator delete" to see if we are not doing the same
thing.
--
Wojciech Meyer
http://danmey.org
Jim Jagielski writes:
> On Sep 2, 2012, at 12:02 AM, Martin Sebor wrote:
>
>> On 08/31/2012 02:38 PM, Liviu Nicoara wrote:
>>> My input below.
>>>
>>> On 08/31/12 09:42, Wojciech Meyer wrote:
>>>> The two significant ones (as far as I can u
be to put the project into attic, that would
kill that codebase once for good. Please, don't. Now let's think clearly
what can we do to keep it alive. I am willing to contribute still, but I
see limited sense of all this operations, if we can't link it to C++ GPL
programs.
I'll le
Jim Jagielski writes:
> So how are/were they committers??
Hi!
Chime in - I think we need to clarify what kind of problems we have with
stdcxx being hosted as an Apache project.
The two significant ones (as far as I can understand):
- as I heard from Christopher Bergström that it's hard to pus
> Could someone please tell me why I'm receiving these email?
Perhaps, because it went to dev@stdcxx.apache.org?
Regards,
Wojciech
Jake Foley writes:
> -Original Message-
> From: Tony Stevenson [mailto:t...@pc-tony.com]
> Sent: Wednesday, August 29, 2012 4:00 AM
> To: Daniel Shahaf
>
Hi William,
On 2/5/2012 10:36 AM, Wojciech Meyer wrote:
> > This is partially because stdcxx is still considered to be a derivate
> > implementation of RogueWave in ARM toolchain, so upgrading at some
> > point would have had a smaller impact on our customers than porting
>
> * I would not like to see major changes to the build infrastructure at
> this time. One of the goals of this project has been portability, and
> this includes the build infrastructure. My understanding is that gmake
> is considered to be more portable than some of the alternatives (cmake,
> ant).
Hi all,
-1
This is partially because stdcxx is still considered to be a derivate
implementation of RogueWave in ARM toolchain, so upgrading at some
point would have had a smaller impact on our customers than porting
the toolchain into another library, apart from that I think this means
that we wi
> Hi all
Hi,
> 1) "better" cmake build system (Actually this has nothing to do with
> Apache or the current build system.)
> 2) Faster code review, QA and easier contribution process (Only the last
> part is slowed down by Apache)
> 3) Actively maintained (To start just bug fixes, better support
> > Now, it would be all fine besides that stdcxx build system checks for
> > this flag here
> >
> > (..)
> > etc/config/GNUmakefile.cfg:247:
> >elif [ ! -x $$file ] ; then\
> >nm -gp $$file.o 2>&1 | grep "T *main *$$">/dev/null ;
> > 2) Removed the changes to the link and compile_then_link
> > functions. Because of the comments within them these
> > were effectively commented out and had no effect.
> > I also don't understand why the chmod +x command is
> > necessary. The linker should set the executable bit after
Hi Martin,
> I've reviewed your patch for STDCXX-1051. It looks reasonable
> to me. I've made a couple of minor changes (see the attached
> diff):
Thanks for this! :)
> 1) Renamed EXEC_RUNNER to CFG_EXEC to match the .cfg suffix
> we use for some of the configuration files (such as
> GNU
Hi Martin,
> Yes, the configure machinery wasn't design with cross compilation
> in mind. We could probably eliminate some, even may, of the runtime
> tests and replace with them compilation (plus linking) only tests.
> Besides making cross compilation easier, doing so would also speed
> up the co
Martin,
Done (in Jira).
Thanks,
Wojciech
-Original Message-
From: Martin Sebor [mailto:mse...@gmail.com]
Sent: 23 September 2010 15:59
To: dev@stdcxx.apache.org
Cc: Wojciech Meyer
Subject: Re: [PATCH] STDCXX-1051: Stdcxx build process needs to be able to
run configuration executable
> C. Bergström wrote:
> > We have ported stdcxx over to cmake and will likely be cross compiling.
> > (mingw and other targets) When the work is more complete I'll ping you
> > for early testing.
> Thanks.
> That's a good news. Please do a pull request on ML once it's working.
BTW: We will h
C. Bergström wrote:
> We have ported stdcxx over to cmake and will likely be cross compiling.
> (mingw and other targets) When the work is more complete I'll ping you
> for early testing.
Thanks.
That's a good news. Please do a pull request on ML once it's working.
Wojciech
Hi,
We are trying to cross compile stdcxx library. The problem we are facing
is that there is no way of telling stdcxx build system, that we don't
want to run configuration files created by configuration step by build
system directly on a host system (through a shell).
For instance, this
Hello Martin,
Any good news about the patch? :)
Wojciech
-Original Message-
From: Martin Sebor [mailto:mse...@gmail.com]
Sent: 04 August 2010 10:36
To: Wojciech Meyer
Cc: dev@stdcxx.apache.org
Subject: Re: stdcxx and POSIX
On 08/02/2010 06:55 AM, Wojciech Meyer wrote:
> Mar
ssage-
From: Wojciech Meyer [mailto:wojciech.me...@arm.com]
Sent: 02 August 2010 09:25
To: 'Martin Sebor'
Cc: dev@stdcxx.apache.org
Subject: RE: stdcxx and POSIX
> Wojciech,
> I started applying the patch hoping to be able to commit it
> before I leave for my trip tomorrow
r it, fortunately I am able to to test them in our environment
(and I will try to do it on vm windows too)
> Martin
Wojciech
On 07/22/2010 11:11 AM, Wojciech Meyer wrote:
> Hi Martin,
>
> Thanks for the update!
>
> I will svn-up the sandbox sometime next week.
>
> Ch
Hi Martin,
Thanks for the update!
I will svn-up the sandbox sometime next week.
Cheers;
Wojciech
PS: It's worth to know others that it's been solved so I CC back to ML.
-Original Message-
From: Martin Sebor [mailto:mse...@gmail.com]
Sent: 22 July 2010 16:52
To: Wojciech Mey
Hi Martin,
Thank you for the quick reply.
> > Hi,
> >
> > We are trying to use stdcxx library on a environment where POSIX
> > environment is not available (and it is not a win32 platform), as
> > a continuation of RoguWave library. We would like to know if
> > stdcxx supports it.
> Probably no
Hi,
We are trying to use stdcxx library on a environment where POSIX
environment is not available (and it is not a win32 platform), as
a continuation of RoguWave library. We would like to know if
stdcxx supports it. We have found some occurrences of POSIX
headers and symbols in file.cpp and iostr
33 matches
Mail list logo
