On 21 March 2012 04:26, Jay Norwood wrote:
> yes, thanks. I read your other link and that was helpful. I think I
> presumed that the escape handling was something belonging to stdio, while
> regex would have its own valid escapes that would include \p. But I see now
> that the string literals
On Tuesday, 20 March 2012 at 10:28:11 UTC, Dmitry Olshansky wrote:
Note that if your task is to split buffer by exactly '\n' byte
then loop with memchr is about as fast as it gets, no amount of
magic compiler optimizations would make other generic ways
better (even theoretically). What they *co
On 19.03.2012 23:24, Jay Norwood wrote:
On Monday, 19 March 2012 at 13:55:39 UTC, Dmitry Olshansky wrote:
That's right, however counting is completely separate from regex,
you'd want to use std.algorithm count:
count(match(,"\n"));
or more unicode-friendly:
count(match(, regex("$","m"))
On Monday, 19 March 2012 at 19:24:30 UTC, Jay Norwood wrote:
This fails to build, so I'd guess is missing \p
void wcp (string fn)
{
enum ctr = ctRegex!("\p{WhiteSpace}","m");
}
-- Build started: Project: a7, Configuration: Release Win32
--
Building Release\a7.exe...
a7.d(210):
On Monday, 19 March 2012 at 13:55:39 UTC, Dmitry Olshansky wrote:
That's right, however counting is completely separate from
regex, you'd want to use std.algorithm count:
count(match(,"\n"));
or more unicode-friendly:
count(match(, regex("$","m")); //note the multi-line flag
This only
On 19.03.2012 17:39, Jay Norwood wrote:
On Monday, 19 March 2012 at 13:27:03 UTC, Jay Norwood wrote:
ok, global. So the document implies that I should be able to get a
single match object with a count of the submatches. So I think maybe
I've jumped to the wrong conclusion about how to use it, th
On 19.03.2012 17:27, Jay Norwood wrote:
On Monday, 19 March 2012 at 08:05:18 UTC, Dmitry Olshansky wrote:
Like I told in main D group it's wrong - regex doesn't only count
matches. It finds slices that do match.
Thus to make it more efficient, it returns lazy range that does
searches on request.
On Monday, 19 March 2012 at 13:27:03 UTC, Jay Norwood wrote:
ok, global. So the document implies that I should be able to
get a single match object with a count of the submatches. So I
think maybe I've jumped to the wrong conclusion about how to
use it, thinking I could just use "\n" and "g"
On Monday, 19 March 2012 at 08:05:18 UTC, Dmitry Olshansky wrote:
Like I told in main D group it's wrong - regex doesn't only
count matches. It finds slices that do match.
Thus to make it more efficient, it returns lazy range that does
searches on request. "g" - means global :)
Then code like t
On 19.03.2012 16:59, Jay Norwood wrote:
On Monday, 19 March 2012 at 08:14:18 UTC, Dmitry Olshansky wrote:
On 19.03.2012 12:05, Dmitry Olshansky wrote:
In that case, I should have been able to do something like:
matches=match(input,ctr);
l_cnt = matches.length();
I'm curious what this lengt
On Monday, 19 March 2012 at 08:14:18 UTC, Dmitry Olshansky wrote:
On 19.03.2012 12:05, Dmitry Olshansky wrote:
In that case, I should have been able to do something like:
matches=match(input,ctr);
l_cnt = matches.length();
I'm curious what this length() does as I have no length for
RegexMa
On 19.03.2012 12:05, Dmitry Olshansky wrote:
On 19.03.2012 6:50, Jay Norwood wrote:
On Friday, 16 March 2012 at 03:36:12 UTC, Joshua Niehus wrote:
Hello,
Does anyone know why I would get different results between
ctRegex and regex in the following snippet?
Thanks,
Josh
I'm also having que
On 19.03.2012 6:50, Jay Norwood wrote:
On Friday, 16 March 2012 at 03:36:12 UTC, Joshua Niehus wrote:
Hello,
Does anyone know why I would get different results between
ctRegex and regex in the following snippet?
Thanks,
Josh
I'm also having questions about the matchers. From what I underst
On Friday, 16 March 2012 at 03:36:12 UTC, Joshua Niehus wrote:
Hello,
Does anyone know why I would get different results between
ctRegex and regex in the following snippet?
Thanks,
Josh
I'm also having questions about the matchers. From what I
understand in the docs, if I use this greedy
On 16.03.2012 20:05, Joshua Niehus wrote:
On Friday, 16 March 2012 at 08:34:18 UTC, Dmitry Olshansky wrote:
Ehm, because they have different engines that _should_ give identical
results. And the default one apparently has a bug, that I'm looking into.
Fill the bug report plz.
Ok, submitted: id
On Friday, 16 March 2012 at 08:34:18 UTC, Dmitry Olshansky wrote:
Ehm, because they have different engines that _should_ give
identical results. And the default one apparently has a bug,
that I'm looking into.
Fill the bug report plz.
Ok, submitted: id 7718
Thanks,
Josh
On 16.03.2012 7:36, Joshua Niehus wrote:
Hello,
Does anyone know why I would get different results between
ctRegex and regex in the following snippet?
Ehm, because they have different engines that _should_ give identical
results. And the default one apparently has a bug, that I'm looking into
17 matches
Mail list logo
