On Tuesday, 6 February 2018 at 18:56:44 UTC, H. S. Teoh wrote:
>
> We seriously need to get newCTFE finished and merged.  Stefan is very busy with other stuff ATM; I wonder if a few of us can continue his work and get newCTFE into a mergeable state.  Given how much D's "compile-time" features are advertised, and D's new (ick) slogan of being fast or whatever, it's high time we actually delivered on our promises by actually making CTFE more usable.
>
There are some good news for you.
I've recently allocated a few more resources to newCTFE again.

I have to stress that it is not enough to get newCTFE feature complete.
It is also vital make performance-related pass through the code.
newCTFE currently still at a Proof-Of-Concept quality level.

That said, newCTFE is designed with performance and JIT in mind.
It can achieve a 10-30x speed-up when implemented properly.

One thing that I really need in druntime is a cross-platform way to allocate executable memory-pages, this can be done by someone else.

Another Thing that can be done is reviewing the code and alerting me to potential problems. i.e. Missing or indecipherable comments as well as spelling mistakes.
(with the correction please (just telling me something is wrong, will not help since I obliviously don't know how to spell it))

On Tuesday, 6 February 2018 at 22:29:07 UTC, Walter Bright wrote:
> nobody uses regex for lexer in a compiler.

Some years ago I was surprised when I saw this in Clojure's source code. It appears to still be there today:

https://github.com/clojure/clojure/blob/1215ba346ffea3fe48def6ec70542e3300b6f9ed/src/jvm/clojure/lang/LispReader.java#L66-L73

---
static Pattern symbolPat = Pattern.compile("[:]?([\\D&&[^/]].*/)?(/|[\\D&&[^/]][^/]*)");
//static Pattern varPat = Pattern.compile("([\\D&&[^:\\.]][^:\\.]*):([\\D&&[^:\\.]][^:\\.]*)");
//static Pattern intPat = Pattern.compile("[-+]?[0-9]+\\.?");
static Pattern intPat =
		Pattern.compile(
				"([-+]?)(?:(0)|([1-9][0-9]*)|0[xX]([0-9A-Fa-f]+)|0([0-7]+)|([1-9][0-9]?)[rR]([0-9A-Za-z]+)|0[0-9]+)(N)?");
static Pattern ratioPat = Pattern.compile("([-+]?[0-9]+)/([0-9]+)");
static Pattern floatPat = Pattern.compile("([-+]?[0-9]+(\\.[0-9]*)?([eE][-+]?[0-9]+)?)(M)?");
---

On Wednesday, 7 February 2018 at 09:27:47 UTC, Stefan Koch wrote:
> Another Thing that can be done is reviewing the code and alerting me to potential problems. i.e. Missing or indecipherable comments as well as spelling mistakes.
> (with the correction please (just telling me something is wrong, will not help since I obliviously don't know how to spell it))

What is the preferred place for this? https://github.com/dlang/dmd/pull/7073 or do you want PRs against a fork of yours?

On 2/7/2018 1:07 PM, Nathan S. wrote:
> On Tuesday, 6 February 2018 at 22:29:07 UTC, Walter Bright wrote:
>> nobody uses regex for lexer in a compiler.
> 
> Some years ago I was surprised when I saw this in Clojure's source code. It appears to still be there today:
> 
> https://github.com/clojure/clojure/blob/1215ba346ffea3fe48def6ec70542e3300b6f9ed/src/jvm/clojure/lang/LispReader.java#L66-L73 
> 
> 
> ---
> static Pattern symbolPat = Pattern.compile("[:]?([\\D&&[^/]].*/)?(/|[\\D&&[^/]][^/]*)");
> //static Pattern varPat = Pattern.compile("([\\D&&[^:\\.]][^:\\.]*):([\\D&&[^:\\.]][^:\\.]*)");
> //static Pattern intPat = Pattern.compile("[-+]?[0-9]+\\.?");
> static Pattern intPat =
>          Pattern.compile(
>                  "([-+]?)(?:(0)|([1-9][0-9]*)|0[xX]([0-9A-Fa-f]+)|0([0-7]+)|([1-9][0-9]?)[rR]([0-9A-Za-z]+)|0[0-9]+)(N)?"); 
> 
> static Pattern ratioPat = Pattern.compile("([-+]?[0-9]+)/([0-9]+)");
> static Pattern floatPat = Pattern.compile("([-+]?[0-9]+(\\.[0-9]*)?([eE][-+]?[0-9]+)?)(M)?");
> ---


Yes, I'm sure somebody does it. And now that regex has produced a match, you have to scan it again to turn it into a number, making for slow lexing. And if regex doesn't produce a match, you get a generic error message rather than something specific like "character 'A' is not allowed in a numeric literal".

(Generic error messages are one of the downsides of using tools like lex and yacc.)

On Wednesday, 7 February 2018 at 22:00:48 UTC, Bastiaan Veelo wrote:
> On Wednesday, 7 February 2018 at 09:27:47 UTC, Stefan Koch wrote:
>> Another Thing that can be done is reviewing the code and alerting me to potential problems. i.e. Missing or indecipherable comments as well as spelling mistakes.
>> (with the correction please (just telling me something is wrong, will not help since I obliviously don't know how to spell it))
>
> What is the preferred place for this? https://github.com/dlang/dmd/pull/7073 or do you want PRs against a fork of yours?

I'd prefer a pr against https://github.com/UplinkCoder/dmd/newCTFE_reboot

On Wednesday, 7 February 2018 at 22:00:48 UTC, Bastiaan Veelo wrote:
> On Wednesday, 7 February 2018 at 09:27:47 UTC, Stefan Koch wrote:
>> Another Thing that can be done is reviewing the code and alerting me to potential problems. i.e. Missing or indecipherable comments as well as spelling mistakes.
>> (with the correction please (just telling me something is wrong, will not help since I obliviously don't know how to spell it))
>
> What is the preferred place for this? https://github.com/dlang/dmd/pull/7073 or do you want PRs against a fork of yours?
Corrected link:
https://github.com/UplinkCoder/dmd/tree/newCTFE_reboot

On Monday, 5 February 2018 at 21:27:57 UTC, H. S. Teoh wrote:
> One of my D projects for the past while has been taking unusually long times to compile.  This morning, I finally decided to sit down and figure out exactly why. What I found was rather disturbing:
>
> ------
> import std.regex;
> void main() {
> 	auto re = regex(``);
> }
> ------
>
> Compile command: time dmd -c test.d
>
> Output:
> ------
> real    0m3.113s
> user    0m2.884s
> sys     0m0.226s
> ------
>
> Comment out the call to `regex()`, and I get:
>
> ------
> real    0m0.285s
> user    0m0.262s
> sys     0m0.023s
> ------
>
> Clearly, something is wrong if the mere act of compiling a regex causes a 4-line program to take *3 seconds* to compile, where normally dmd takes less than a second.
>
Thank you for this finding!

I was wondering why my little vibe.d project started to take approximately twice the
time to compile, and because of making a mistake in my test setup, even my minimal
program still included the file containing the regex. So that even reducing the used
code to a minimum the compilation time was ~7 sec compared to less than 4 seconds.

Would be cool if we could get fast compilation of regex.

I am coming from using scripting languages (perl and ruby) using regex a lot, so that this is really disappointing for me.

Beginner question:
How to split my project, to compile the regex part separately as a lib and just link them?

On 02/08/2018 06:21 AM, Martin Tschierschke wrote:
> 
> Beginner question:
> How to split my project, to compile the regex part separately as a lib and just link them?
> 

Unfortunately that depends completely on what buildsystem you're using. But if you're just calling the compiler directly, then it's really easy:

> dmd -lib -of=myLib.a [all other flags your project may need] fileYouWantInLib.d anyOtherFileYouAlsoWant.d

> dmd myLib.a [your project's usual flags, and all the rest of your .d files]

If on windows, then just replace ".a" with ".lib".

On Tuesday, 6 February 2018 at 20:30:42 UTC, Steven Schveighoffer wrote:
>
> The regex in question I think is to ensure an email address like abc@192.168.0.5 has a valid IP address. The D1 function doesn't support that requirement.

>
> -Steve

An invalid IP is not necessarily an invalid email though.

You'd be surprised how much __garbage__ a valid email actually can contain.

https://www.w3.org/Protocols/rfc822/

Generally the best way to validate an email is just to check if there is a value before @ and a value after.

The real way to validate an email is to check if the email exists on a SMTP server, BUT some SMTP servers will not provide such information (Such as gmail I think?) and thus you can't really rely on that either.

On Friday, 9 February 2018 at 14:19:56 UTC, bauss wrote:
> Generally the best way to validate an email is just to check if there is a value before @ and a value after.
>
> The real way to validate an email is to check if the email exists on a SMTP server, BUT some SMTP servers will not provide such information (Such as gmail I think?) and thus you can't really rely on that either.

+1.

If anyone wants to do email validation this should be read first:

https://hackernoon.com/the-100-correct-way-to-validate-email-addresses-7c4818f24643