On 2/6/2018 12:30 PM, 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.
> 
> I admit, I've never used it, so I don't know why it needs to be so complex. But I assume some people depend on that functionality.

Regex is well known to not always be the best solution for string processing tasks. For example, it does not work well at all where recursion is desired, and nobody uses regex for lexer in a compiler.

On 2/6/18 5:23 PM, Walter Bright wrote:
> On 2/6/2018 2:03 PM, Jacob Carlborg wrote:
>> On 2018-02-06 21:11, Walter Bright wrote:
>>
>>> std.string.isEmail() in D1 was a simple function. Maybe regex is just the wrong solution for this problem.
>>
>> If I recall correctly, the current implementation of std.net.isEmail was requested by you.
> 
> Regardless of whether it was requested by me or not, if the current version is not working for us, we need to explore alternatives.

The regex problem is being solved:

https://github.com/dlang/phobos/pull/6129

-Steve

On Tuesday, 6 February 2018 at 22:51:51 UTC, Steven Schveighoffer wrote:
> On 2/6/18 5:23 PM, Walter Bright wrote:
>> On 2/6/2018 2:03 PM, Jacob Carlborg wrote:
>>> On 2018-02-06 21:11, Walter Bright wrote:
>>>
>>>> std.string.isEmail() in D1 was a simple function. Maybe regex is just the wrong solution for this problem.
>>>
>>> If I recall correctly, the current implementation of std.net.isEmail was requested by you.
>> 
>> Regardless of whether it was requested by me or not, if the current version is not working for us, we need to explore alternatives.
>
> The regex problem is being solved:
>
> https://github.com/dlang/phobos/pull/6129
>
> -Steve

That's fixing just the "isEmail" issue which is good I guess.

But after reading this thread, I run some tests on one of my code bases, which uses about 6 regex throughout.

Switching from ctRegex! to regex yielded a 50% build time reduction, and from what I read even the normal regex are slowing things down considerably.

Might need a warning on the docs for ctRegex! explaining it'll screw your build times if you use it, unless there's some way to speed that up to something normal.

Btw, my project which is 3517 lines of D builds in 20s disabling the ctRegex on an i7 4770k at 4.3Ghz.

So I'd say once you start doing some more complex usages, D's build speed goes out the door.

On 02/06/2018 01:11 AM, Dmitry Olshansky wrote:
> On Tuesday, 6 February 2018 at 05:45:35 UTC, Steven Schveighoffer wrote:
>> On 2/6/18 12:35 AM, Dmitry Olshansky wrote:
>>>
>>> That’s really bad idea - isEmail is template so the burden of freaking slow ctRegex
>>> is paid on per instantiation basis. Could be horrible with separate compilation.
>>
>> Obviously it is horrible. On my mac, it took about 2.5 seconds to compile this one line.
>>
>> I'm not sure how to fix it though... I suppose you could make
> 
> Just use the run-time version, it’s not that much slower. But then again static ipRegex = regex(...) will parse and build regex at CTFE.
> 
> Maybe lazy init?
> 

If the regex string isn't dependent on the template's params, just move the regex outside the template.

On Tue, Feb 06, 2018 at 11:20:53PM +0000, Andres Clari via Digitalmars-d wrote: [...]
> Switching from ctRegex! to regex yielded a 50% build time reduction, and from what I read even the normal regex are slowing things down considerably.

I seem to vaguely recall that in some cases, ctRegex might even perform slower than regex().  But either way, my use cases for regexes generally aren't performance-sensitive enough to be worth the trouble of huge compilation time slowdown -- I just use regex() instead of ctRegex.


[...]
> Btw, my project which is 3517 lines of D builds in 20s disabling the ctRegex on an i7 4770k at 4.3Ghz.
> 
> So I'd say once you start doing some more complex usages, D's build speed goes out the door.

That depends on what you're doing with it, and also how you're building it. 3500+ lines isn't a lot of code; it ought to compile pretty fast unless you're using a lot of (1) templates, (2) CTFE.  Also, I find that dub builds are excruciatingly slow compared to just invoking dmd directly, due to network access and rescanning dependencies on every invocation.  I have a 4700+ line vibe.d project; Diet templates are template/CTFE-heavy and generally take the longest to build. (I dumped dub and went back to an SCons-based system with separate compilation for major subsystems -- as long as I don't recompile Diet templates, the whole thing can build within seconds; with Diet templates it takes about 30 seconds :-/.)


T

-- 
Unix was not designed to stop people from doing stupid things, because that would also stop them from doing clever things. -- Doug Gwyn

On Wednesday, 7 February 2018 at 00:36:22 UTC, H. S. Teoh wrote:
> On Tue, Feb 06, 2018 at 11:20:53PM +0000, Andres Clari via Digitalmars-d wrote: [...]
>> [...]
>
> I seem to vaguely recall that in some cases, ctRegex might even perform slower than regex().  But either way, my use cases for regexes generally aren't performance-sensitive enough to be worth the trouble of huge compilation time slowdown -- I just use regex() instead of ctRegex.
>
>
> [...]
>> [...]
>
> That depends on what you're doing with it, and also how you're building it. 3500+ lines isn't a lot of code; it ought to compile pretty fast unless you're using a lot of (1) templates, (2) CTFE.  Also, I find that dub builds are excruciatingly slow compared to just invoking dmd directly, due to network access and rescanning dependencies on every invocation.  I have a 4700+ line vibe.d project; Diet templates are template/CTFE-heavy and generally take the longest to build. (I dumped dub and went back to an SCons-based system with separate compilation for major subsystems -- as long as I don't recompile Diet templates, the whole thing can build within seconds; with Diet templates it takes about 30 seconds :-/.)
>
>
> T

Well I'm using vibe.d, but not templates on this project, just a minimal rest service, and a few timers and runTasks. So yeah I don't see why it should slow down that much.

Is there some tutorial or example for using SCons with dub dependencies?

On Wed, Feb 07, 2018 at 01:22:02AM +0000, Andres Clari via Digitalmars-d wrote: [...]
> Is there some tutorial or example for using SCons with dub dependencies?

Not that I know of.  Basically what I did was:

- Create a dummy dub project in a subdirectory, containing a dummy
  source file containing an empty main().

- Declare whatever dub dependencies you need in this dummy project.

- Run `dub build -v` inside this subdirectory to make dub fetch
  dependencies, build libraries, etc..

- Parse the output, esp. the last few lines that show which include
  paths, linker flags, and libraries are required to build the main
  program.

- Specify these include paths, linker flags, and libraries in your
  SConstruct file for building your real project.

- Build away.

- If you need to refresh dependencies, go into the dummy project and run
  `dub build --force` to rebuild all dependencies, then run scons in
  your real project.

Arguably, some/all of the above could be automated by SCons. Though the whole point is to *not* run dub every single time you build, so I'd keep them separate, or as a non-default build target that only triggers when you explicitly want it to.

Also, none of this is specific to SCons; you could use whatever other build system you wish with the above steps.


T

-- 
This sentence is false.

On Tuesday, 6 February 2018 at 20:11:56 UTC, Walter Bright wrote:
>
> std.string.isEmail() in D1 was a simple function. Maybe regex is just the wrong solution for this problem.
>
> [...]


C .. D style. I love it! (bugs and all).

On 2/6/2018 2:51 PM, Steven Schveighoffer wrote:
> The regex problem is being solved:
> 
> https://github.com/dlang/phobos/pull/6129

Great!

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))