On Friday, 4 May 2018 at 14:33:09 UTC, Dmitry Olshansky wrote:
On Friday, 4 May 2018 at 11:39:18 UTC, WebFreak wrote:
I am currently working on workspace-d/serve-d but I am
continously running into segfaults with std.regex ctRegex with
the captures in dub and dscanner. I can't provid
On Friday, 4 May 2018 at 11:39:18 UTC, WebFreak wrote:
I am currently working on workspace-d/serve-d but I am
continously running into segfaults with std.regex ctRegex with
the captures in dub and dscanner. I can't provide any other
information really because my internet is dead righ
On Friday, 4 May 2018 at 11:39:18 UTC, WebFreak wrote:
I am currently working on workspace-d/serve-d but I am
continously running into segfaults with std.regex ctRegex with
the captures in dub and dscanner. I can't provide any other
information really because my internet is dead righ
I am currently working on workspace-d/serve-d but I am
continously running into segfaults with std.regex ctRegex with
the captures in dub and dscanner. I can't provide any other
information really because my internet is dead right now. This
issue is happening all the time there, yet I
On Wednesday, 20 September 2017 at 10:29:45 UTC, Daniel Kozak
wrote:
Hmm. I have tested old version od dmd and ldc with BitNFA, but
it does not help much with those two cases
actual version of ldc:
240.964 - 92
211.433 - 5301
6.76683 - 5
ldc 1.2:
215.158 - 92
190.255 - 5301
6.58155 - 5
So th
Hmm. I have tested old version od dmd and ldc with BitNFA, but it does not
help much with those two cases
actual version of ldc:
240.964 - 92
211.433 - 5301
6.76683 - 5
ldc 1.2:
215.158 - 92
190.255 - 5301
6.58155 - 5
So there is some improvments but not as much as I would expected.
On Wed, Se
On Tuesday, 19 September 2017 at 19:52:57 UTC, Daniel Kozak wrote:
Is there a plan to make BitNFA back?
Yes, the moment we have CTFE that doesn't leak.
Is possible that newCTFE will improve problem with memory?
It should but it doesn't support classes and exceptions. I need
them.
Or it
Is there a plan to make BitNFA back? Is possible that newCTFE will improve
problem with memory? Or it is possible to improve those slow cases?
On Tue, Sep 19, 2017 at 8:12 PM, Dmitry Olshansky via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On Tuesday, 19 September 2017 at 16:27:51 UTC,
On Tuesday, 19 September 2017 at 16:27:51 UTC, jmh530 wrote:
On Tuesday, 19 September 2017 at 07:53:27 UTC, Daniel Kozak
wrote:
https://github.com/mariomka/regex-benchmark#performance
Do you know why?
Here is a code:
https://github.com/mariomka/regex-benchmark/blob/master/d/benchmark.d
I have
On Tuesday, 19 September 2017 at 07:53:27 UTC, Daniel Kozak wrote:
https://github.com/mariomka/regex-benchmark#performance
Do you know why?
Here is a code:
https://github.com/mariomka/regex-benchmark/blob/master/d/benchmark.d
I have try it with ldc too, but is still much slower (10x) than
PHP
On Tuesday, 19 September 2017 at 07:53:27 UTC, Daniel Kozak wrote:
https://github.com/mariomka/regex-benchmark#performance
Do you know why?
Here is a code:
https://github.com/mariomka/regex-benchmark/blob/master/d/benchmark.d
I have try it with ldc too, but is still much slower (10x) than
PHP
I have tried it, but does not change anything
On Tue, Sep 19, 2017 at 6:05 PM, Jon Degenhardt via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On Tuesday, 19 September 2017 at 07:53:27 UTC, Daniel Kozak wrote:
>
>> https://github.com/mariomka/regex-benchmark#performance
>>
>> Do you know
On Tuesday, 19 September 2017 at 07:53:27 UTC, Daniel Kozak wrote:
https://github.com/mariomka/regex-benchmark#performance
Do you know why?
Here is a code:
https://github.com/mariomka/regex-benchmark/blob/master/d/benchmark.d
I have try it with ldc too, but is still much slower (10x) than
PHP
On Tuesday, 19 September 2017 at 10:14:05 UTC, Dmitry Olshansky
wrote:
On Tuesday, 19 September 2017 at 07:53:27 UTC, Daniel Kozak
wrote:
https://github.com/mariomka/regex-benchmark#performance
Do you know why?
Here is a code:
https://github.com/mariomka/regex-benchmark/blob/master/d/benchmark
On Tuesday, 19 September 2017 at 07:53:27 UTC, Daniel Kozak wrote:
https://github.com/mariomka/regex-benchmark#performance
Do you know why?
Here is a code:
https://github.com/mariomka/regex-benchmark/blob/master/d/benchmark.d
I have try it with ldc too, but is still much slower (10x) than
PHP
On 19/09/2017 8:53 AM, Daniel Kozak wrote:
https://github.com/mariomka/regex-benchmark#performance
Do you know why?
Here is a code:
https://github.com/mariomka/regex-benchmark/blob/master/d/benchmark.d
I have try it with ldc too, but is still much slower (10x) than PHP
Most likely everything
https://github.com/mariomka/regex-benchmark#performance
Do you know why?
Here is a code:
https://github.com/mariomka/regex-benchmark/blob/master/d/benchmark.d
I have try it with ldc too, but is still much slower (10x) than
PHP
On Sunday, 10 September 2017 at 18:54:21 UTC, Chad Joan wrote:
On Sunday, 10 September 2017 at 11:47:02 UTC, Dmitry Olshansky
wrote:
Yeah, well known problem. Solution is to keep a bit of memory
cached eg in TLS variable.
Indeed.
Is there another issue I can mark it as a duplicate of?
On Sunday, 10 September 2017 at 11:47:02 UTC, Dmitry Olshansky
wrote:
On Sunday, 10 September 2017 at 00:16:10 UTC, Chad Joan wrote:
I was working on std.regex a bit myself, so I created this bug
report to capture some of the findings/progress:
https://issues.dlang.org/show_bug.cgi?id=17820
On Sunday, 10 September 2017 at 00:16:10 UTC, Chad Joan wrote:
On Tuesday, 5 September 2017 at 10:50:46 UTC, Dmitry Olshansky
wrote:
My burndown list for std.regex:
https://issues.dlang.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENE
down this rabbit hole I decided to first
address the long-standing backlog of issues of std.regex and
std.uni.
My burndown list for std.regex:
https://issues.dlang.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=VERIFIE
On Wednesday, 6 September 2017 at 05:23:51 UTC, Jon Degenhardt
wrote:
On Tuesday, 5 September 2017 at 10:50:46 UTC, Dmitry Olshansky
wrote:
Before I'm too deep down this rabbit hole I decided to first
address the long-standing backlog of issues of std.regex and
std.uni.
Not intending t
On Tuesday, 5 September 2017 at 10:50:46 UTC, Dmitry Olshansky
wrote:
Before I'm too deep down this rabbit hole I decided to first
address the long-standing backlog of issues of std.regex and
std.uni.
Not intending to add to your workload, but I added an enhancement
request for someth
backlog of issues of std.regex and
std.uni.
My burndown list for std.regex:
https://issues.dlang.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=VERIFIED&component=phobos&list_id=216638&product=D&query_forma
On 11/17/16 2:22 AM, H. S. Teoh via Digitalmars-d wrote:
I'm running into a std.regex memory corruption bug in git HEAD:
https://issues.dlang.org/show_bug.cgi?id=16698
and I can't seem to find a way to work around the problem besides
recompiling with an older compiler.
I'm running into a std.regex memory corruption bug in git HEAD:
https://issues.dlang.org/show_bug.cgi?id=16698
and I can't seem to find a way to work around the problem besides
recompiling with an older compiler. Any ideas??
T
--
I think Debian's doing something
On 9/30/16 7:29 PM, Dmitry Olshansky wrote:
I know it's not unusual to rant about open bugs and such but it's been 4
months and I'm helpless.
I had some nice breakthrough in std.regex performance back in May but
failed to deliver it to the mainline because of a bug:
https://g
On 9/30/2016 11:45 AM, Stefan Koch wrote:
You can workaround the issue by making ctRegex a static immutable instead of an
enum.
That should work, but I wouldn't call it a workaround. It's the right way to do
that.
On Friday, 30 September 2016 at 17:29:41 UTC, Dmitry Olshansky
wrote:
I know it's not unusual to rant about open bugs and such but
it's been 4 months and I'm helpless.
I had some nice breakthrough in std.regex performance back in
May but failed to deliver it to the mainline b
I know it's not unusual to rant about open bugs and such but it's been 4
months and I'm helpless.
I had some nice breakthrough in std.regex performance back in May but
failed to deliver it to the mainline because of a bug:
https://github.com/dlang/phobos/pull/4286
If anyone fl
On Friday, 22 May 2015 at 12:47:18 UTC, Liam McSherry wrote:
On Friday, 22 May 2015 at 12:40:03 UTC, Chris wrote:
Excuse my ignorance, but how do I file a bug on bugzilla?
http://wiki.dlang.org/Get_involved#File_a_bug_report
Thanks. Here it is:
https://issues.dlang.org/show_bug.cgi?id=14615
On Friday, 22 May 2015 at 12:40:03 UTC, Chris wrote:
Excuse my ignorance, but how do I file a bug on bugzilla?
http://wiki.dlang.org/Get_involved#File_a_bug_report
On Friday, 22 May 2015 at 11:08:38 UTC, Chris wrote:
On Friday, 22 May 2015 at 11:02:12 UTC, Dmitry Olshansky wrote:
On 21-May-2015 14:51, Chris wrote:
std.regex.replaceFirst uses
https://github.com/D-Programming-Language/phobos/blob/master/std/regex/package.d#L734
which returns the input, i
On Friday, 22 May 2015 at 11:02:12 UTC, Dmitry Olshansky wrote:
On 21-May-2015 14:51, Chris wrote:
std.regex.replaceFirst uses
https://github.com/D-Programming-Language/phobos/blob/master/std/regex/package.d#L734
which returns the input, if no match is found. This is "safe",
because
the wors
On 21-May-2015 14:51, Chris wrote:
std.regex.replaceFirst uses
https://github.com/D-Programming-Language/phobos/blob/master/std/regex/package.d#L734
which returns the input, if no match is found. This is "safe", because
the worst thing that can happen is that you get the input back unchanged.
std.regex.replaceFirst uses
https://github.com/D-Programming-Language/phobos/blob/master/std/regex/package.d#L734
which returns the input, if no match is found. This is "safe",
because the worst thing that can happen is that you get the input
back unchanged.
std.regex.replaceFirstInto, on th
On Tuesday, 12 March 2013 at 09:41:08 UTC, Dmitry Olshansky wrote:
... that got a bit lengthy - any thoughts, criticism, opinions ?
I like it. Maybe Nick is right in just having separate functions
so UFCS is still working. Or since opCall works we can just say
the new types are only callable
On Tuesday, 12 March 2013 at 09:41:08 UTC, Dmitry Olshansky wrote:
*Spoiler*: let's slowly deprecate "g" option in std.regex in a
few years or with any luck a bit faster. The better replacement
is proposed.
For better or worse the current API has retained a (high) level
of com
12-Mar-2013 19:08, Nick Sabalausky пишет:
On Tue, 12 Mar 2013 11:06:56 -0400
Nick Sabalausky wrote:
matchFirst
matchAll
matchTest
?
s/matchTest/isMatch/
or rather 'hasMatch'
But that's too obvious :)
The problem is that I wanted to avoid creating a bunch of new names,
especially as t
On Tue, 12 Mar 2013 11:06:56 -0400
Nick Sabalausky wrote:
>
> matchFirst
> matchAll
> matchTest
>
> ?
>
s/matchTest/isMatch/
On Tue, 12 Mar 2013 18:07:42 +0400
Dmitry Olshansky wrote:
> 12-Mar-2013 17:12, Dmitry Olshansky пишет:
> > 12-Mar-2013 14:36, Andrej Mitrovic пишет:
> >> On 3/12/13, Dmitry Olshansky wrote:
> >>> struct match //ditto for replace
> >>> {
> >>> //current behavior
> >>> static auto opCall
12-Mar-2013 17:12, Dmitry Olshansky пишет:
12-Mar-2013 14:36, Andrej Mitrovic пишет:
On 3/12/13, Dmitry Olshansky wrote:
struct match //ditto for replace
{
//current behavior
static auto opCall(.);
}
For a second I was worried this would break UFCS, but actually it
still works.
12-Mar-2013 14:36, Andrej Mitrovic пишет:
On 3/12/13, Dmitry Olshansky wrote:
struct match //ditto for replace
{
//current behavior
static auto opCall(.);
}
For a second I was worried this would break UFCS, but actually it
still works. Pretty kewl.
Actually it does...
On 3/12/13, Dmitry Olshansky wrote:
> struct match //ditto for replace
> {
> //current behavior
> static auto opCall(.);
> }
For a second I was worried this would break UFCS, but actually it
still works. Pretty kewl.
*Spoiler*: let's slowly deprecate "g" option in std.regex in a few years
or with any luck a bit faster. The better replacement is proposed.
For better or worse the current API has retained a (high) level of
compatibility with the old API. That means I've missed the chan
On 14.03.2012 0:54, H. S. Teoh wrote:
On Tue, Mar 13, 2012 at 11:27:57PM +0400, Dmitry Olshansky wrote:
For a couple of releases we have a new revamped std.regex, that as
far as I'm concerned works nicely, thanks to my GSOC commitment last
summer. Yet there was certain dark trend a
On 14.03.2012 0:32, Brad Anderson wrote:
On Tue, Mar 13, 2012 at 1:27 PM, Dmitry Olshansky mailto:dmitry.o...@gmail.com>> wrote:
For a couple of releases we have a new revamped std.regex, that as
far as I'm concerned works nicely, thanks to my GSOC commitment last
summer
On 14.03.2012 0:54, H. S. Teoh wrote:
On Tue, Mar 13, 2012 at 11:27:57PM +0400, Dmitry Olshansky wrote:
For a couple of releases we have a new revamped std.regex, that as
far as I'm concerned works nicely, thanks to my GSOC commitment last
summer. Yet there was certain dark trend a
On 14.03.2012 0:32, Brad Anderson wrote:
On Tue, Mar 13, 2012 at 1:27 PM, Dmitry Olshansky mailto:dmitry.o...@gmail.com>> wrote:
For a couple of releases we have a new revamped std.regex, that as
far as I'm concerned works nicely, thanks to my GSOC commitment last
summer
On Tue, Mar 13, 2012 at 11:27:57PM +0400, Dmitry Olshansky wrote:
> For a couple of releases we have a new revamped std.regex, that as
> far as I'm concerned works nicely, thanks to my GSOC commitment last
> summer. Yet there was certain dark trend around std.regex/std.regexp
> a
On Tue, Mar 13, 2012 at 1:27 PM, Dmitry Olshansky wrote:
> For a couple of releases we have a new revamped std.regex, that as far as
> I'm concerned works nicely, thanks to my GSOC commitment last summer. Yet
> there was certain dark trend around std.regex/std.regexp as both had
On 14.03.2012 0:05, bearophile wrote:
Dmitry Olshansky:
It's about time to break this gloomy aura, and show that std.regex is
actually easy to use, that it does the thing and has some nice extras.
This seems a good moment to ask people regarding this small problem, that we
have al
On Tuesday, 13 March 2012 at 19:27:59 UTC, Dmitry Olshansky wrote:
For a couple of releases we have a new revamped std.regex, that
as far as I'm concerned works nicely, thanks to my GSOC
commitment last summer. Yet there was certain dark trend around
std.regex/std.regexp as both had s
Dmitry Olshansky:
> It's about time to break this gloomy aura, and show that std.regex is
> actually easy to use, that it does the thing and has some nice extras.
This seems a good moment to ask people regarding this small problem, that we
have already discussed a little in Bugizill
On 13.03.2012 23:42, Nick Sabalausky wrote:
"Dmitry Olshansky" wrote in message
news:jjo73v$4gv$1...@digitalmars.com...
For a couple of releases we have a new revamped std.regex, that as far as
I'm concerned works nicely, thanks to my GSOC commitment last summer. Yet
there w
"Dmitry Olshansky" wrote in message
news:jjo73v$4gv$1...@digitalmars.com...
> For a couple of releases we have a new revamped std.regex, that as far as
> I'm concerned works nicely, thanks to my GSOC commitment last summer. Yet
> there was certain dark trend around std.
On 3/13/12 2:27 PM, Dmitry Olshansky wrote:
For a couple of releases we have a new revamped std.regex, that as far
as I'm concerned works nicely, thanks to my GSOC commitment last summer.
Yet there was certain dark trend around std.regex/std.regexp as both had
severe bugs, missing document
For a couple of releases we have a new revamped std.regex, that as far
as I'm concerned works nicely, thanks to my GSOC commitment last summer.
Yet there was certain dark trend around std.regex/std.regexp as both had
severe bugs, missing documentation and what not, enough to consider
I suggest to file this as an enhancement request, as new
std.regex should have been backwards compatible.
http://d.puremagic.com/issues/show_bug.cgi?id=7471
I redid the timings with mingw using time, and I find this strange
$ time ./test2.058.exe
real0m55.500s
user0m0.031s
sys
gex engine on every
iteration here?
David
That is the case. The older regex apparently cached the last regex. will
be more careful in the feature.
I suggest to file this as an enhancement request, as new std.regex
should have been backwards compatible.
--
Dmitry Olshansky
2sec
2.058: 7.65sec
I don't expect a correction for this would make it in 2.058 as it is
likely an issue in 2.057.
import std.file;
import std.string;
import std.datetime;
import std.regex;
private int[string] model;
void main() {
auto name = "english.dic";
foreach(
On Wednesday, 8 February 2012 at 22:21:35 UTC, David Nadlinger
wrote:
On 2/8/12 10:44 PM, Jesse Phillips wrote:
foreach(w; std.string.split(readText(name)))
if(!match(w, regex(r"\d")).empty)
{}
}
Could it be that you are rebuilding the regex engine on every
iteration here?
David
That is t
Timon Gehr:
> The compiler should do loop invariant code motion for pure functions.
Right, that too. But in DMD 2.058alpha this doesn't compile, regex() isn't pure:
import std.regex;
void main() pure {
auto re = regex(r"\d");
}
Bye,
bearophile
On 02/08/2012 11:46 PM, bearophile wrote:
David Nadlinger:
Could it be that you are rebuilding the regex engine on every iteration
here?
This isn't the first time I see this problem.
CPython caches the RE engines to avoid this problem, so after the first time
you use it, it doesn't create th
David Nadlinger:
> Could it be that you are rebuilding the regex engine on every iteration
> here?
This isn't the first time I see this problem.
CPython caches the RE engines to avoid this problem, so after the first time
you use it, it doesn't create the same engine again and again.
Another s
> here?
Yup. This one is a steady 80 msecs (ctRegex seems to be a bit slower
in this case for some reason):
import std.file;
import std.datetime;
import std.regex;
import std.stdio;
private int[string] model;
void main()
{
auto sw = StopWatch(AutoStart.yes);
auto rg = regex(r"\d&q
Here's some runs on win32, -release -O -inline (I just generated
134,950 duplicate words) :
2.054: 82 msecs (467KB exe)
2.055: 77 msecs (505KB exe)
2.056: 84 msecs (1095KB exe)
2.057: 3380 msecs (1179KB exe)
2.058: 3373 msecs (630KB exe)
Compile times are different too:
2.054: timeit dmd -release
On 2/8/12 10:44 PM, Jesse Phillips wrote:
foreach(w; std.string.split(readText(name)))
if(!match(w, regex(r"\d")).empty)
{}
}
Could it be that you are rebuilding the regex engine on every iteration
here?
David
ould make it in 2.058 as it
is likely an issue in 2.057.
import std.file;
import std.string;
import std.datetime;
import std.regex;
private int[string] model;
void main() {
auto name = "english.dic";
foreach(w; std.file.readText(name).toLower.splitLines)
mo
On 1/7/12, Trass3r wrote:
> So much for Optlink being the fastest linker cause it's all
> written in shiny assembler ^^
Well I wasn't timing linking, I was timing the app itself. Optlink
does actually seem a tiny little bit faster than unilink (we're
talking a few milliseconds here), however unil
07.01.2012 5:12, Andrej Mitrovic пишет:
Oooh I've just realized something, the *compilation* calls are what's
destroying the performance. I was using "dmd test.d&& test.exe"
instead of just "test.exe" and this would generate a new exe which
screwed up the results.
So regex has nothing to do wit
Well, for one thing, the Optlink that ships with DMD isn't
entirely assembly anymore. You'd have to ask Walter how much
he's ported to C at this point.
I really doubt the C code is much more high level than the
original one.
On Sat, Jan 7, 2012 at 12:03 AM, Trass3r wrote:
>> So regex has nothing to do with it. Still, some linkers perform better:
>>
>> $ dmd -c test.obj
>> $ link test.obj
>>
>> Average is ~700usecs. But with ulink:
>> $ ulink test.obj
>>
>> Average is ~380 usecs. Interesting!
>
>
> So much for Optlink
So regex has nothing to do with it. Still, some linkers perform
better:
$ dmd -c test.obj
$ link test.obj
Average is ~700usecs. But with ulink:
$ ulink test.obj
Average is ~380 usecs. Interesting!
So much for Optlink being the fastest linker cause it's all
written in shiny assembler ^^
Oooh I've just realized something, the *compilation* calls are what's
destroying the performance. I was using "dmd test.d && test.exe"
instead of just "test.exe" and this would generate a new exe which
screwed up the results.
So regex has nothing to do with it. Still, some linkers perform better:
The following code:
import std.datetime;
import std.regex;
import std.stdio;
import std.array;
void test()
{
auto sw = StopWatch(AutoStart.yes);
auto text = "bla\n".replicate(1024);
auto lines = text.split("\n");
sw.stop();
writefln("done in
On 12/2/2011 2:33 PM, Marco Leise wrote:
http://www.easypolls.net/poll.html?p=4ed9478e4fb7b0e4886eeea2
In general, behavior for things we don't know what to do with should be
"failure". Then, when we do figure out what to do with it, we don't break
existing code.
On Sun, 04 Dec 2011 19:53:59 +0100, Martin Nowak wrote:
> On Fri, 02 Dec 2011 23:33:34 +0100, Marco Leise
> wrote:
>
>> http://www.easypolls.net/poll.html?p=4ed9478e4fb7b0e4886eeea2
>
> auto s = "[\.]"; => Error: undefined escape sequence.
> Do you actually mean r"[\.]" or `[\.]`?
He was refer
On Fri, 02 Dec 2011 23:33:34 +0100, Marco Leise wrote:
http://www.easypolls.net/poll.html?p=4ed9478e4fb7b0e4886eeea2
auto s = "[\.]"; => Error: undefined escape sequence.
Do you actually mean r"[\.]" or `[\.]`?
On 12/3/11 9:51 AM, Dmitry Olshansky wrote:
On 03.12.2011 16:54, Kagamin wrote:
Marco Leise Wrote:
http://www.easypolls.net/poll.html?p=4ed9478e4fb7b0e4886eeea2
Erm... but "\." is a perfectly known escape sequence, so the question
should be "How should std.regex hand
On 12/3/11 8:14 PM, David Nadlinger wrote:
I am only a causal user […]
Oh well, typing is hard.
On 12/3/11 6:00 PM, Vladimir Panteleev wrote:
I think the common intuitive rules regarding escapes in regexes are as
follows:
1) Unescaped punctuation usually has special meaning (so people often
escape all punctuation literals)
I am only a causal user of regexen, and I agree that this is what
that std.regex should throw on unrecognized *letter*
escapes. It's very likely that the user might be trying to use a
character class or feature from another regex engine, but unsupported by
std.regex.
Yes, another point for not going for fully blind approach.
--
Dmitry Olshansky
On 03.12.2011 19:48, Andrei Alexandrescu wrote:
On 12/3/11 6:54 AM, Kagamin wrote:
Marco Leise Wrote:
http://www.easypolls.net/poll.html?p=4ed9478e4fb7b0e4886eeea2
Erm... but "\." is a perfectly known escape sequence, so the question
should be "How should std.regex hand
llows:
1) Unescaped punctuation usually has special meaning (so people often
escape all punctuation literals)
2) Unescaped letters are literal
3) Escaped punctuation is literal
4) Escaped letters have special meaning
Therefore, I think that std.regex should throw on unrecognized *letter*
es
On Sat, 03 Dec 2011 19:00:44 +0200, Vladimir Panteleev
wrote:
escapes
For the context of my post, I meant "escaped" as "prefixed by a backslash".
--
Best regards,
Vladimirmailto:vladi...@thecybershadow.net
On 2011-12-02 22:33:34 +, "Marco Leise" said:
http://www.easypolls.net/poll.html?p=4ed9478e4fb7b0e4886eeea2
I'd say, go with what other engines are doing. PCRE accepts them. I
think POSIX does not, but does not allow any escaping inside a
character class either.
--
Michel Fortin
miche
On 03.12.2011 16:54, Kagamin wrote:
Marco Leise Wrote:
http://www.easypolls.net/poll.html?p=4ed9478e4fb7b0e4886eeea2
Erm... but "\." is a perfectly known escape sequence, so the question should be "How should
std.regex handle known escape sequences as in: "[\.]"&quo
On 12/3/11 6:54 AM, Kagamin wrote:
Marco Leise Wrote:
http://www.easypolls.net/poll.html?p=4ed9478e4fb7b0e4886eeea2
Erm... but "\." is a perfectly known escape sequence, so the question should be "How should
std.regex handle known escape sequences as in: "[\.]&q
Marco Leise Wrote:
> http://www.easypolls.net/poll.html?p=4ed9478e4fb7b0e4886eeea2
Erm... but "\." is a perfectly known escape sequence, so the question should be
"How should std.regex handle known escape sequences as in: "[\.]"".
On 12/2/2011 5:33 PM, Marco Leise wrote:
http://www.easypolls.net/poll.html?p=4ed9478e4fb7b0e4886eeea2
I prefer that regexp engines are as consistent as possible. Everything I
tested accepts this as a valid regular expression, so I think std.regex
should as well.
On Saturday, December 03, 2011 02:35:21 Jesse Phillips wrote:
> On Fri, 02 Dec 2011 17:59:59 -0500, Jonathan M Davis wrote:
> > On Friday, December 02, 2011 23:33:34 Marco Leise wrote:
> >> http://www.easypolls.net/poll.html?p=4ed9478e4fb7b0e4886eeea2
> >
> > Wh
On Fri, 02 Dec 2011 17:59:59 -0500, Jonathan M Davis wrote:
> On Friday, December 02, 2011 23:33:34 Marco Leise wrote:
>> http://www.easypolls.net/poll.html?p=4ed9478e4fb7b0e4886eeea2
>
> Why wouldn't std.regex accept an escaped sequence such as "\."? I
>
On Friday, December 02, 2011 23:33:34 Marco Leise wrote:
> http://www.easypolls.net/poll.html?p=4ed9478e4fb7b0e4886eeea2
Why wouldn't std.regex accept an escaped sequence such as "\."? I thought that
the whole point of something like "\." was to make it so that yo
http://www.easypolls.net/poll.html?p=4ed9478e4fb7b0e4886eeea2
yes
Yes
Fawzi
Yes.
Andrei
Yes
but I did actually use FReD as a
replacement of a buggy std.regex once.
In that case I wanted to have a lazily created static regex, but I did
not find an official way to test whether a Regex has been initialized:
static Regex!char re;
if(!isInitializedRE(re))
re = regex(r"^(.*)\(([0-9]+)\):(.
1 - 100 of 226 matches
Mail list logo
