The "setenv" output will be gone (by default) as of CMake 2.8.7
because of this recent commit:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5a94d099ddbd8f3d4b850957faa8c11f619c6f18
Does using ctest from 'next' or 'master' already show any improvement
over 2.8.6?
On Wed, Nov 16, 2011 at
On 11/16/2011 4:11 PM, Sean McBride wrote:
The downside is that this solution would be fragile. xcodebuild's
output is not guaranteed to be the same forever, it's not like a public
API. Already today, gcc and clang output pretty differently. I'm a
little worried this would bite us.
Besides,
A little off topic, but I am wondering if the ctest performance issue
for xcode could be fixed without changing the regex. The problem with
xcode is that it spits out very verbose output. I am wondering if some
short circuit stuff could be put in place. Maybe do a string compare of
the first
On 11/16/2011 2:12 PM, Alexandru Ciobanu wrote:
This is how I run the tests (pseudocode):
recomp()
repeat 1000 times:
regexec()
Thanks for the explanation.
TRex -- 680ms
PCRE -- 610ms ( with pcre_exec() )
PCRE -- 990ms ( with pcre_dfa_exec() )
re2 --
On Wednesday 16 November 2011, Alexandru Ciobanu wrote:
> Hi Brad,
...
> Advantages of TRE:
> - API very similar to standard regex.h (i.e. easy to integrate with
> CMake) - supports wide characters
> - compiles on many platforms Windows, AIX, HP-UX, you name it.
>
> What do you think about TRE
Hi Brad,
[1]
> On 11/16/2011 12:44 PM, Alexandru Ciobanu wrote:
>> For each library the steps are:
>> - regcomp() the regular expression
>> - regexec() the expression on the string
>
> Can you time each of these steps separately for each library? I would not
> be surprised if the compilation ti
On 11/16/2011 12:44 PM, Alexandru Ciobanu wrote:
For each library the steps are:
- regcomp() the regular expression
- regexec() the expression on the string
Can you time each of these steps separately for each library? I would not
be surprised if the compilation time is the bottleneck. The ev
Just looking at the calendar...
Three short weeks from today, we are planning to schedule the build
and upload of CMake 2.8.7-rc1 so all of you can give it a try.
Followed by weekly rc's as needed until the final official release of
CMake 2.8.7, scheduled for Wednesday Dec. 28, 2011.
If you are a
On Wed, Nov 16, 2011 at 6:44 PM, Alexandru Ciobanu
wrote:
> As it can be seen re2 and the standard regex.h are orders of magnitude
> faster in executing this particular regular expression.
> The difference between PCRE and re2 is also confirmed by this study:
> http://swtch.com/~rsc/regexp/re
On Wednesday 16 November 2011, Alexandru Ciobanu wrote:
> Hi,
>
> I was successful in making CMake work with PCRE. As expected, it was
> straightforward.
>
> The problem is that PCRE is also slow. So, I tested the same string and
> regex with multiple different libraries in order to assess perfor
Hi,
I was successful in making CMake work with PCRE. As expected, it was
straightforward.
The problem is that PCRE is also slow. So, I tested the same string and regex
with multiple different libraries in order to assess performance.
The regular expression in question is:
([^:]+): warni
On 11/16/2011 9:05 AM, OKUMURA Yuki wrote:
(Sorry Bill, i repost here..)
2011/11/16 Bill Hoffman:
- snip -
What type of evolution will Ninja need? I suppose it could use cmake
scripts and exectue_process which can do&& type things pretty easy.
Why not insert "cmd /c" everywhere? :)
Anyway,
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=12580
==
Reported By:arrowdodger
Assigned To:
(Sorry Bill, i repost here..)
2011/11/16 Bill Hoffman :
- snip -
> What type of evolution will Ninja need? I suppose it could use cmake
> scripts and exectue_process which can do && type things pretty easy.
Why not insert "cmd /c" everywhere? :)
Anyway, i had tried this in early this month,
htt
14 matches
Mail list logo
