On Sunday, 11 February 2018 at 16:26:19 UTC, aliak wrote:
> If anyone wants to do email validation this should be read first:

The isemail function isn't about validating email addresses. It is just about recognizing something that looks like one. just like isurl doesn't actually try to fetch the site to see if it is broken, it just sees if it looks like one as a first step.

On Sunday, 11 February 2018 at 16:35:35 UTC, Adam D. Ruppe wrote:
> The isemail function isn't about validating email addresses. It is just about recognizing something that looks like one. just like isurl doesn't actually try to fetch the site to see if it is broken, it just sees if it looks like one as a first step.

*valid email format... (is better? :) )

When someone says isurl checks if a string is a valid url, I don't think the general assumption is that it makes a network call to check if it is a resolvable url. (could be mistaken of course, but not to me at least). Isurl checks that the format is correct. Same for isemail. The isemail API and the docs all use the term valid as well.

Plus, to further see how hard it is to validate an email, these are apparently all erroneous results (granted wikipedia could be wrong as well):

import std.net.isemail, std.stdio;

void main() {
    isEmail("john.smith(comment)@example.com").valid.writeln; // is valid, prints false
    isEmail("user@[2001:DB8::1]").valid.writeln; // is valid, prints false
    isEmail(`" "@example.org`).valid.writeln; // not valid, prints true
    isEmail(`"very.unusual.@.unusual.com"@example.com`).valid.writeln; // not valid, prints true
}

On Wednesday, 7 February 2018 at 09:27:47 UTC, Stefan Koch wrote:
> 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.
Is this on someone's agenda? It probably needs an enhancement request at the very least, I don't think it's there yet [1].

> 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.
I had a go at this [2].

[1] https://issues.dlang.org/buglist.cgi?bug_severity=enhancement&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=druntime&list_id=219522&product=D&query_format=advanced
[2] https://github.com/UplinkCoder/dmd/pull/3

On Monday, 12 February 2018 at 00:24:32 UTC, Bastiaan Veelo wrote:
> On Wednesday, 7 February 2018 at 09:27:47 UTC, Stefan Koch wrote:
>> 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.
> Is this on someone's agenda? It probably needs an enhancement request at the very least, I don't think it's there yet [1].
>

Was once on my together with other OS memory manager functions, but postponed the work indefinetly.

https://github.com/dlang/druntime/pull/1549

If someone is willing to revive that I’d gladly assist with review.

Lastly on Windows it would need FlushCpuCaches call before executing new memory.

And ofc JIT is cool, but it would be more cool to have sane interpreter that doesn’t leak sooner. Simply put JIT is x5 work due to different architectures and seeing first-hand how it goes I’m not sure we want that in our compiler yet.

On Tuesday, 13 February 2018 at 05:47:10 UTC, Dmitry Olshansky wrote:
>
> Was once on my together with other OS memory manager functions, but postponed the work indefinetly.
>
> https://github.com/dlang/druntime/pull/1549
>
> If someone is willing to revive that I’d gladly assist with review.
>
> Lastly on Windows it would need FlushCpuCaches call before executing new memory.
>
> And ofc JIT is cool, but it would be more cool to have sane interpreter that doesn’t leak sooner. Simply put JIT is x5 work due to different architectures and seeing first-hand how it goes I’m not sure we want that in our compiler yet.

Since dmd is only targeting x86/x86_64 there is really just one arch to support for now.
All the others can fallback to either the interpreter or generated c code compiled into a shared lib :)

newCTFE already provides a very low-level IR that should be trivially translatable to machine -code. (famous last words :o) )