Re: Battle-plan for CTFE

[Nordlöw via Digitalmars-d-announce]

On Monday, 19 September 2016 at 10:07:06 UTC, Stefan Koch wrote:

Compiling all of phobos does not crash my engine anymore!


Great work! Keep up still!

Re: thisExePath purity

[Jonathan M Davis via Digitalmars-d-learn]

On Tuesday, September 20, 2016 04:17:21 crimaniak via Digitalmars-d-learn 
wrote:
>  static shared immutable ReturnType!T value;

I would point out that immutable is implicitly shared, so there's no reason
to put shared on an immutable variable. However, you _do_ want to put shared
on a static constructor that initializes an immutable variable so that it's
only run once for the program instead of once per thread (the compiler
really should enforce that, but there's a longstanding bug that allows you
to reinitialize an immutable variable by not putting shared on the static
constructor and starting multiple threads).

- Jonathan M Davis

Re: thisExePath purity

[crimaniak via Digitalmars-d-learn]

Hi and thanks all!

On Tuesday, 20 September 2016 at 00:43:10 UTC, Jonathan M Davis 
wrote:



immutable string executablePath;

shared static this()
{
import std.file : thisExePath();
executablePath = thisExePath();
}


This code is good for my needs but I start to think about how to 
call thisExePath only if it is really used and come to this 
solution:


import std.traits: ReturnType, Parameters;

string staticMemoize(alias T, Parms = Parameters!T)() pure
{
struct Holder(alias T)
{
static shared immutable ReturnType!T value;
shared static this(){ value = T(Parms); }
}

return Holder!T.value;
}

unittest
{
import std.file : thisExePath;
assert(staticMemoize!thisExePath == thisExePath);
}

Something like this. Need to refine about input parameters, but I 
hope, idea is clear.
Unlike the function memoize from phobos staticMemoize really 
pure. And unlike proposed solution with ordinary variable 
staticMemoize is lazy, because no call - no instantiation.


https://dlang.org/library/std/functional/memoize.html

Re: [WORK] std.file.update function

[Walter Bright via Digitalmars-d]

One way to implement it is to open the existing file as a memory-mapped file. 
Memory-mapped files only get paged into memory as the memory is referenced. So 
if you did a memcmp(oldfile, newfile, size), it will stop once the first 
difference is found, and the rest of the file is never read.


Also, only the changed pages of the memory-mapped file have to be written. On 
large files, this could be a big savings.

discuss: Comparing Rust and Java or D?

[Brian via Digitalmars-d]

look this article:
https://llogiq.github.io/2016/02/28/java-rust.html

D language how to compare?

Re: polar coordinates with ggplotd

[brocolis via Digitalmars-d-learn]

On Monday, 19 September 2016 at 12:34:56 UTC, Edwin van Leeuwen 
wrote:

On Sunday, 18 September 2016 at 22:13:35 UTC, brocolis wrote:

Found an error in ys line. Thanks.


Does that mean you solved it?

Currently there is no special support for other coordinate 
systems, but I recently added Guides for x/y coordinates which 
should make this relatively straightforward to implement and is 
next on the list. Not sure when I'll get a chunk of time to 
implement it though.


For now you will have to convert the coordinates yourself, 
before plotting them.


Yeah, problem solved. Thanks.

Re: thisExePath purity

[Jonathan M Davis via Digitalmars-d-learn]

On Tuesday, September 20, 2016 00:37:10 Stefan Koch via Digitalmars-d-learn 
wrote:
> On Tuesday, 20 September 2016 at 00:01:58 UTC, crimaniak wrote:
> > Hi!
> >
> > Is there situations when output of thisExePath() can be
> > different during runtime? If yes, what the reason?
> > If no, is this possible to mark it as pure in phobos?
> >
> > https://dlang.org/library/std/file/this_exe_path.html
>
> No way to do that.
> It does I/O.
> However you cheat.
> look for assumePure in https://dlang.org/phobos/std_traits.html
> and then you can create a wrapper for it that is fake pure.

Yes, you can cast a function pointer to force purity, but that's almost
always a bad idea. It makes far more sense to just grab the value once and
reuse it. The only time that I'd suggest using the casting trick for
something like this would be when you can't afford to use static
constructors, and you can't afford to pass the value around. Casting to pure
should be a tool of last resort. It _is_ an option though if you really have
no reasonable alternative.

Another thing to consider in this case is that casting like that would
actually be needlessly expensive if he actually needs to make the call more
than once. It would be far cheaper to just save the result and reuse it. And
if it's stored in an immutable module-level or static variable, then it can
be used in a pure function.

- Jonathan M Davis

Re: thisExePath purity

[Jonathan M Davis via Digitalmars-d-learn]

On Tuesday, September 20, 2016 00:01:58 crimaniak via Digitalmars-d-learn 
wrote:
> Hi!
>
> Is there situations when output of thisExePath() can be different
> during runtime? If yes, what the reason?
> If no, is this possible to mark it as pure in phobos?
>
> https://dlang.org/library/std/file/this_exe_path.html

In principle, it should be impossible for it to change while the program is
running. However, what Phobos has to do to get the information can't be
pure. In the best case, it involves calling C functions that we can
reasonably assume will be pure but can't technically guarantee will be, but
in some cases, it actually involves querying the file system (e.g. on Linux,
it reads "/proc/self/exe"), which definitely can't be pure, because it
involves I/O.

If you really want a pure way to deal with this, then I'd suggest grabbing
the value at startup and setting it to an immutable variable. e.g. something
like

immutable string executablePath;

shared static this()
{
import std.file : thisExePath();
executablePath = thisExePath();
}

and then you can use that variable in pure code, because it's guaranteed not
to change.

- Jonathan M Davis

Re: thisExePath purity

[Steven Schveighoffer via Digitalmars-d-learn]

On 9/19/16 8:01 PM, crimaniak wrote:

Hi!

Is there situations when output of thisExePath() can be different during
runtime? If yes, what the reason?
If no, is this possible to mark it as pure in phobos?

https://dlang.org/library/std/file/this_exe_path.html


Not in a way that D can ensure purity. Yes, it will not change. But that 
guarantee is not communicated via the OS functions required to call to 
get the information.


One thing you can do:

immutable string myPath;

shared static this()
{
   import std.file: thisExePath;
   myPath = thisExePath;
}

// now use myPath as required from pure functions.

-Steve

Re: thisExePath purity

[Stefan Koch via Digitalmars-d-learn]

On Tuesday, 20 September 2016 at 00:01:58 UTC, crimaniak wrote:

Hi!

Is there situations when output of thisExePath() can be 
different during runtime? If yes, what the reason?

If no, is this possible to mark it as pure in phobos?

https://dlang.org/library/std/file/this_exe_path.html


No way to do that.
It does I/O.
However you cheat.
look for assumePure in https://dlang.org/phobos/std_traits.html
and then you can create a wrapper for it that is fake pure.

[Issue 16418] dip25 wrong escaping reference to this

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16418

--- Comment #2 from github-bugzi...@puremagic.com ---
Commit pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/21d65b6a23d8176c9479fb957f5d317916186de8
test typecons.Tuple.rename for sucessful no-ops, working around bug 16418

--

thisExePath purity

[crimaniak via Digitalmars-d-learn]

Hi!

Is there situations when output of thisExePath() can be different 
during runtime? If yes, what the reason?

If no, is this possible to mark it as pure in phobos?

https://dlang.org/library/std/file/this_exe_path.html

[Issue 16513] New: Speed up TemplateInstance.findExistingInstance, hash by mangling

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16513

  Issue ID: 16513
   Summary: Speed up TemplateInstance.findExistingInstance, hash
by mangling
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: c...@dawg.eu

We still have a few reports about extremely slow
TemplateInstance.findExistingInstance performance. What can be seen in profiles
is an excessive amount of TemplateInstance comparisons for lookups in the hash
table that eat ~20% of the compilation time.
Maybe we're producing an unsuited hash that isn't order dependent?
Or it's just an extreme number of instances with many arguments?

Still have to investigate further, but since issue 7469 got fixed we might now
hash by the mangling of the template (.getIdent) instead of doing an expensive
arrayObjectMatch on RootObjects (using a "virtual" match function).

--

[Issue 15907] Unjustified "is not visible from module" deprecation warning when using getMember trait

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15907

--- Comment #11 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/f899b4b59620e354b6ba0acfe843efb559202cd8
fix Issue 15907 - unjustified deprecation with getMember

https://github.com/dlang/dmd/commit/49cb97213303c902844b7189ced1cf8833214437
Merge pull request #6078 from MartinNowak/fix15907

https://github.com/dlang/dmd/commit/101d65993abc868490876883a17b1ba81c04fe19
fix Issue 15907 - unjustified deprecation with getMember

https://github.com/dlang/dmd/commit/6b285369a9b17216244dfdf8f38fbc48ed38dc53
Merge pull request #6111 from MartinNowak/fix15907

--

[Issue 16085] wrong visibility warning for overloaded alias symbol

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16085

--- Comment #14 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/22dc48171eaa3ef43dbec3e6bab6ea7fcb839a37
fix Issue 16085 - wrong visibility warning for overloaded alias symbol

https://github.com/dlang/dmd/commit/8238ad782347330e0a822208c323a83d1d17ac64
Merge pull request #5847 from MartinNowak/fix16085

--

[Issue 16348] [REG 2.070.2] ICE with package visibility

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16348

--- Comment #5 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/93c3dcf26f5c5ae612ccce044012d2b297fe46bf
fix Issue 16348 - ICE with package visibility

https://github.com/dlang/dmd/commit/d400dffec4f782ac9cc27f7e682a726042949f9e
Merge pull request #6014 from MartinNowak/fix16348

--

[Issue 15780] [REG2.069] CTFE foreach fails with tuple

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15780

--- Comment #5 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/60390bd21a45479b6377751fef4be40159effe0a
fix Issue 15780 - [REG2.069] CTFE foreach fails with tuple

https://github.com/dlang/dmd/commit/4a108b3e8b9192dde15ffb513f34df7e3bc62d64
Merge pull request #6000 from MartinNowak/fix15780

--

Re: Default Template Instantiation

[Jonathan Marler via Digitalmars-d]

On Monday, 19 September 2016 at 22:17:34 UTC, Mathias Lang wrote:
2016-09-19 23:18 GMT+02:00 Jonathan Marler via Digitalmars-d < 
digitalmars-d@puremagic.com>:



[...]


No you can't. The example is wrong, but Stefan is right. 
Consider:


```
template Foo (T = string) { }

template TakesAlias(alias Sym) {}

alias TakesAlias!(Foo) Bar;
```

In this context, is `TakesAlias` instantiated with the template 
or the template instantiation ?


It is essentially the same category of problems as when trying 
to use a parameterless-functions, sometime you end up calling 
it because of the optional parenthesis. Except that for 
functions we can use `&` or `typeof`.


Good example, thanks for the information.

Re: Default Template Instantiation

[Stefan Koch via Digitalmars-d]

On Monday, 19 September 2016 at 22:17:34 UTC, Mathias Lang wrote:



No you can't. The example is wrong, but Stefan is right.

Try it.
It got fixed a few versions ago.
Maybe it's broken again ?
I remember it working with 2.068

Re: What blogs about D do you read?

[A D dev via Digitalmars-d-learn]

On Monday, 19 September 2016 at 21:49:04 UTC, Ali Çehreli wrote:

  https://atilanevesoncode.wordpress.com/

Ali


Thanks, Ali.

Re: Default Template Instantiation

[Mathias Lang via Digitalmars-d]

2016-09-19 23:18 GMT+02:00 Jonathan Marler via Digitalmars-d <
digitalmars-d@puremagic.com>:

> On Monday, 19 September 2016 at 21:14:38 UTC, Stefan Koch wrote:
>
>> On Monday, 19 September 2016 at 21:09:37 UTC, Jonathan Marler wrote:
>>
>>>
>>> I don't know if I would call this a "destabalizing" language change
>>> though.  It should be backwards compatible with the existing semantics.  It
>>> adds an extra step to type deduction, but this would be the very last step
>>> of type deduction so it would not override any existing semantics.
>>>
>>
>> Consider void functionOrTemplate() {...} and functionOrTemplate(uint N =
>> 1)() {...}
>>
>
> Oh you're right, I didn't think that templates could share the same name
> as functions.  You can't do this with classes:
>
> class classOrTemplate { }
> class classOrTemplate(uint N=1) { }
>
> With this new information, yes this would be a "destabalizing" language
> change.  Thanks for the example.  I'm against this.
>

No you can't. The example is wrong, but Stefan is right.
Consider:

```
template Foo (T = string) { }

template TakesAlias(alias Sym) {}

alias TakesAlias!(Foo) Bar;
```

In this context, is `TakesAlias` instantiated with the template or the
template instantiation ?

It is essentially the same category of problems as when trying to use a
parameterless-functions, sometime you end up calling it because of the
optional parenthesis. Except that for functions we can use `&` or `typeof`.

Re: [OT] Brokerage for the D Language Foundation

[Walter Bright via Digitalmars-d]

On 9/19/2016 10:44 AM, Laeeth Isharc wrote:

[...]


Thanks for taking the time to post this stuff - it's good reading. Stuff I 
didn't know.

Incremental obj generation

[Stefan Koch via Digitalmars-d]

Hi,

The previous thread "[WORK] std.file.update function"
http://forum.dlang.org/thread/nrmb6b$2lc9$1...@digitalmars.com

quickly turned out to be a misnomer after a few posts about 
object-file-formats and codegen.


Therefore I am opening this one.

Of course I do have something to say about the subject.

It is possible to generate object files (at least in coff64 and 
elf) that are usable for a minimal modification maximal extension 
scheme.


This is for example relevant for a techniques to reduce 
template-codegen-times.


I am not sure if the impact on the glue-layer (the part that is 
responsible for triggering object-code generation) will be a high 
cost change or not.


Chances are that we will be able to integrate such a scheme with 
relatively low effort.


If that is the case we should also think about better I/O 
handling for such a case.

Re: What blogs about D do you read?

[Ali Çehreli via Digitalmars-d-learn]

On 09/19/2016 01:20 PM, Guillaume Piolat wrote:

On Monday, 19 September 2016 at 17:42:51 UTC, A D dev wrote:

Hi list,

What blogs about D do you read?

Thanks in advance.


https://dlang.org/blog/
http://dblog.aldacron.net/
http://minas-mina.com/
http://nomad.so/tag/d/
http://blog.thecybershadow.net/
https://p0nce.github.io/d-idioms/ (disclaimer: my own)


  https://atilanevesoncode.wordpress.com/

Ali

Re: Default Template Instantiation

[Jonathan Marler via Digitalmars-d]

On Monday, 19 September 2016 at 21:14:38 UTC, Stefan Koch wrote:
On Monday, 19 September 2016 at 21:09:37 UTC, Jonathan Marler 
wrote:


I don't know if I would call this a "destabalizing" language 
change though.  It should be backwards compatible with the 
existing semantics.  It adds an extra step to type deduction, 
but this would be the very last step of type deduction so it 
would not override any existing semantics.


Consider void functionOrTemplate() {...} and 
functionOrTemplate(uint N = 1)() {...}


Oh you're right, I didn't think that templates could share the 
same name as functions.  You can't do this with classes:


class classOrTemplate { }
class classOrTemplate(uint N=1) { }

With this new information, yes this would be a "destabalizing" 
language change.  Thanks for the example.  I'm against this.

Re: [WORK] std.file.update function

[Walter Bright via Digitalmars-d]

On 9/19/2016 7:04 AM, Andrei Alexandrescu wrote:

On 09/19/2016 01:16 AM, Walter Bright wrote:

The compiler currently creates the complete object file in a buffer,
then writes the buffer to a file in one command. The reason is mostly
because the object file format isn't incremental, the beginning is
written last and the body gets backpatched as the compilation progresses.

Great. In that case, if the target .o file already exists, it should be compared
against the buffer. If identical, there should be no write and the timestamp of
the .o file should stay the same.


That's right. I was just referring to the idea of incrementally writing and 
comparing, which is a great idea for sequential file writing, likely won't work 
for the object file case. I think it is distinct enough to merit a separate 
library function. Note that we already have:


http://dlang.org/phobos/std_file.html#.write

Adding another "writeIfDifferent()" function would be a good thing. The range 
based incremental one should go into std.stdio.


Any case where writing is much more costly than reading (such as SSD drives you 
mentioned, and the new Seagate "archival" drives), would make your technique a 
good one. It works even for memory; I've used it in code to reduce swapping, as in:


if (*p != newvalue) *p = newvalue;


I need to re-emphasize this kind of stuff is important for tooling. Many files
get recompiled to identical object files - e.g. the many innocent bystanders in
a dense dependency structure when one module changes. We also embed
documentation in source files. Being disciplined about reflecting actual changes
in the actual file operations is very helpful for tools that track file writes
and/or timestamps.


That's right.



I can't really see a compilation producing an object file where the
first half of it matches the previous object file and the second half is
different, because of the file format.


Interesting. What happens e.g. if one makes a change to a function whose
generated code is somewhere in the middle of the object file? If it doesn't
alter the call graph, doesn't the new .o file share a common prefix with the old
one?


Two things:

1. The object file starts out with a header that contains file offsets to the 
various tables and sections. Changing the size of any of the pieces in the file 
changes the header, and will likely require moving pieces around to make room.


2. Writing an object file can mean "backpatching" what was written earlier, as a 
declaration one assumed was external turns out to be internal.

Re: Default Template Instantiation

[Stefan Koch via Digitalmars-d]

On Monday, 19 September 2016 at 21:09:37 UTC, Jonathan Marler 
wrote:


I don't know if I would call this a "destabalizing" language 
change though.  It should be backwards compatible with the 
existing semantics.  It adds an extra step to type deduction, 
but this would be the very last step of type deduction so it 
would not override any existing semantics.


Consider void functionOrTemplate() {...} and 
functionOrTemplate(uint N = 1)() {...}

Re: Default Template Instantiation

[Jonathan Marler via Digitalmars-d]

On Monday, 19 September 2016 at 20:47:00 UTC, Stefan Koch wrote:
On Monday, 19 September 2016 at 20:21:30 UTC, Jonathan Marler 
wrote:


Yes that's why the template cannot deduce the parameters. The 
question is, when the parameters cannot be deduced, and they 
are all optional, would it be reasonable for the compiler to 
infer that the user intended to use the default parameters?


This would be a destabilizing language-change and require even 
more logic for templates.




That's what I was wondering.  I was trying to think of examples 
that this kind of feature would over-complicate.  I've been 
thinking about it the last few days and I have the same 
reservations about making template deduction more complicated 
than it already is.  That being said, I have thought of some 
examples that this feature would make much nicer.


I don't know if I would call this a "destabalizing" language 
change though.  It should be backwards compatible with the 
existing semantics.  It adds an extra step to type deduction, but 
this would be the very last step of type deduction so it would 
not override any existing semantics.

Re: What exactly does the compiler switch -betterC do?

[Gary Willoughby via Digitalmars-d-learn]

On Monday, 20 June 2016 at 06:35:32 UTC, Jacob Carlborg wrote:

On 2016-06-19 21:53, Gary Willoughby wrote:
When compiling, what exactly does the -betterC flag do? The 
command help
says "omit generating some runtime information and helper 
functions" but

what does this really mean? Is there any specifics somewhere?


It is intended to allow you to link an application without 
druntime. A Hello World using "extern(C) main" and printing 
using "printf" contains the following symbols on OS X:


00a8 S _D4main12__ModuleInfoZ
0068 T _D4main15__unittest_failFiZv
0018 T _D4main7__arrayZ
0040 T _D4main8__assertFiZv
00b5 s _TMP1
 U __d_arraybounds
 U __d_assert
 U __d_unittest
 T _main
 U _printf

If compiled with -betterC, it contains these:

 T _main
 U _printf


I get significantly more symbols than that when compiling the 
following program any idea why?


import core.stdc.stdio;

extern(C) void main()
{
printf("Hello World!\n");
}


$ rdmd --build-only --force -betterC -de -O -inline -release -w 
test.d

$ nm test

Re: What blogs about D do you read?

[A D dev via Digitalmars-d-learn]

On Monday, 19 September 2016 at 20:20:26 UTC, Guillaume Piolat 
wrote:

https://dlang.org/blog/
http://dblog.aldacron.net/
http://minas-mina.com/
http://nomad.so/tag/d/
http://blog.thecybershadow.net/
https://p0nce.github.io/d-idioms/ (disclaimer: my own)



Great, thanks!

Re: consequences of removing semicolons in D like in Python

[Ali Çehreli via Digitalmars-d]

On 09/17/2016 07:32 AM, Chris Wright wrote:


python-style syntax a while back, in the D1 days,
though I forget the name of it.


  http://delight.sourceforge.net/

Ali

Re: Default Template Instantiation

[Stefan Koch via Digitalmars-d]

On Monday, 19 September 2016 at 20:21:30 UTC, Jonathan Marler 
wrote:


Yes that's why the template cannot deduce the parameters. The 
question is, when the parameters cannot be deduced, and they 
are all optional, would it be reasonable for the compiler to 
infer that the user intended to use the default parameters?


This would be a destabilizing language-change and require even 
more logic for templates.


I don't mind saying that any further complication of template 
overload resolution is a rather unpleasant for me to think about.

Re: consequences of removing semicolons in D like in Python

[jmh530 via Digitalmars-d]

On Monday, 19 September 2016 at 20:22:00 UTC, Chris wrote:


The thing is that there is no way of telling how much D code 
would break (including the compiler), if semicolons were 
removed or optional. That's too big of a gamble for a purely 
aesthetic change.


I don't see a reason to make that sort of change within the D 
language or DMD, especially when something like Delight exists 
and probably accomplishes exactly what the OP had wanted.


It looks like the last commit was last year to bring it in line 
with 2.067

https://github.com/pplantinga/delight
so if people are interested they could probably get in touch with 
the author of that and help get it updated.

Re: consequences of removing semicolons in D like in Python

[Chris via Digitalmars-d]

On Monday, 19 September 2016 at 16:52:10 UTC, bpr wrote:
On Saturday, 17 September 2016 at 16:43:13 UTC, Nick Sabalausky 
wrote:
If semicolons are such a terrible drain, there's always JS and 
Python.


For someone who likes D, Nim (http://www.nim-lang.org) would be 
better a choice for a language at the same level with Python 
like syntax. Changing D surface syntax is an obvious 
non-starter.


Or Crystal

https://crystal-lang.org/

It's Ruby syntax with some of the nice features you'd find in D. 
It's only alpha at the moment and doesn't work on Windows.


The thing is that there is no way of telling how much D code 
would break (including the compiler), if semicolons were removed 
or optional. That's too big of a gamble for a purely aesthetic 
change.

Re: Default Template Instantiation

[Jonathan Marler via Digitalmars-d]

On Monday, 19 September 2016 at 19:53:27 UTC, Basile B. wrote:
On Monday, 19 September 2016 at 19:38:37 UTC, Jonathan Marler 
wrote:

If you have a template where:

1) All parameters are optional
2) The parameters cannot be deduced

Would it be reasonable to instantiate the template with the 
default parameter values? For example:


template Foo(string str = "some string", T...)
{
class Foo
{
// class implementation
this() { }
}
}

auto foo = new Foo!()(); // OK
auto foo = new Foo(); // Error: cannot deduce template 
parameters


In this example, there's no way to deduce the template 
parameters for Foo, however, since they are not specified, 
would it be reasonable to just use the defaults?  str would be 
"some string" and T would be empty?


My understanding of this case is that the usage of the 
eponymous member must include all the template parameters 
because for example we could have:


template Foo(string str = "some string", T...)
{
class Foo
{
T[0] a;
T[1] b;
// class implementation
this() { }
}
}

The way "new Foo" is used must tells what are the parent 
template parameters.


Yes that's why the template cannot deduce the parameters. The 
question is, when the parameters cannot be deduced, and they are 
all optional, would it be reasonable for the compiler to infer 
that the user intended to use the default parameters?

Re: What blogs about D do you read?

[Guillaume Piolat via Digitalmars-d-learn]

On Monday, 19 September 2016 at 17:42:51 UTC, A D dev wrote:

Hi list,

What blogs about D do you read?

Thanks in advance.


https://dlang.org/blog/
http://dblog.aldacron.net/
http://minas-mina.com/
http://nomad.so/tag/d/
http://blog.thecybershadow.net/
https://p0nce.github.io/d-idioms/ (disclaimer: my own)

Re: Replace/Rename DWT forum with GUIs forum?

[Dennis Ritchie via Digitalmars-d]

On Monday, 19 September 2016 at 19:29:45 UTC, Karabuta wrote:
+1. Someone once posted a thread about this some time ago. I 
think using "GUIs" is more useful and representative.


+1

Re: The removal of inactive forum groups

[Dennis Ritchie via Digitalmars-d]

On Monday, 19 September 2016 at 09:55:16 UTC, Seb wrote:

I tried a reorganization a couple of months ago:

https://forum.dlang.org/post/gkunyofqycjkgepjz...@forum.dlang.org

It didn't work out, because there are there busy people 
involved: Walter for the NNTP server, Brad for the mailing list 
(IIRC) and CyberShadow for the forum interface.


Thanks for the info. I didn't see your thread. I hope that 
someday the forum reorganizing...

Re: Default Template Instantiation

[Basile B. via Digitalmars-d]

On Monday, 19 September 2016 at 19:38:37 UTC, Jonathan Marler 
wrote:

If you have a template where:

1) All parameters are optional
2) The parameters cannot be deduced

Would it be reasonable to instantiate the template with the 
default parameter values? For example:


template Foo(string str = "some string", T...)
{
class Foo
{
// class implementation
this() { }
}
}

auto foo = new Foo!()(); // OK
auto foo = new Foo(); // Error: cannot deduce template 
parameters


In this example, there's no way to deduce the template 
parameters for Foo, however, since they are not specified, 
would it be reasonable to just use the defaults?  str would be 
"some string" and T would be empty?


My understanding of this case is that the usage of the eponymous 
member must include all the template parameters because for 
example we could have:


template Foo(string str = "some string", T...)
{
class Foo
{
T[0] a;
T[1] b;
// class implementation
this() { }
}
}

The way "new Foo" is used must tells what are the parent template 
parameters.

Re: What blogs about D do you read?

[A D dev via Digitalmars-d-learn]

On Monday, 19 September 2016 at 19:36:22 UTC, Karabuta wrote:
I have one here on Vibe.d for beginners 
https://laberba.github.io/2016/hello-world-app-with-the-vibe.d-web-framework/


I will be writing more for-beginners blogs in the coming few 
weeks.


Thank you. Will read it.

Default Template Instantiation

[Jonathan Marler via Digitalmars-d]

If you have a template where:

1) All parameters are optional
2) The parameters cannot be deduced

Would it be reasonable to instantiate the template with the 
default parameter values? For example:


template Foo(string str = "some string", T...)
{
class Foo
{
// class implementation
this() { }
}
}

auto foo = new Foo!()(); // OK
auto foo = new Foo(); // Error: cannot deduce template parameters

In this example, there's no way to deduce the template parameters 
for Foo, however, since they are not specified, would it be 
reasonable to just use the defaults?  str would be "some string" 
and T would be empty?

Re: What blogs about D do you read?

[Karabuta via Digitalmars-d-learn]

On Monday, 19 September 2016 at 19:29:25 UTC, A D dev wrote:

On Monday, 19 September 2016 at 17:42:51 UTC, A D dev wrote:

Hi list,

What blogs about D do you read?


To be more clear:

- what blogs that include posts on D, would you recommend to a 
D beginner?


Thanks.


I have one here on Vibe.d for beginners 
https://laberba.github.io/2016/hello-world-app-with-the-vibe.d-web-framework/


I will be writing more for-beginners blogs in the coming few 
weeks.

Re: Replace/Rename DWT forum with GUIs forum?

[Karabuta via Digitalmars-d]

On Sunday, 18 September 2016 at 23:21:26 UTC, Gerald wrote:
I would like to suggest that the existing DWT forum be renamed 
or replaced with a more generic GUIs forum. As far as I can 
tell, the DWT forum doesn't get much traffic these days and I 
don't believe any of the current GUI options for D are 
sufficiently popular to warrant their own specific forum.


While I primarily work with and have an interest in GtkD, I'm 
interested in posts with regards to all of the available GUI 
options (GtkD, DLangUI, etc) for D since I have general 
interest in desktop applications. I think grouping everything 
in one forum, similar to what is done for IDEs and Debuggers, 
would bring together posts and people that share a common 
interest.


+1. Someone once posted a thread about this some time ago. I 
think using "GUIs" is more useful and representative.

Re: What blogs about D do you read?

[A D dev via Digitalmars-d-learn]

On Monday, 19 September 2016 at 17:42:51 UTC, A D dev wrote:

Hi list,

What blogs about D do you read?


To be more clear:

- what blogs that include posts on D, would you recommend to a D 
beginner?


Thanks.

[Issue 16512] New: Nullify the argument passed to allocator.dispose

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16512

  Issue ID: 16512
   Summary: Nullify the argument passed to allocator.dispose
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: yshu...@gmail.com

A good measure to prevent use-after-free.

--

Re: Iterate over two arguments at once

[bachmeier via Digitalmars-d-learn]

On Monday, 19 September 2016 at 18:10:22 UTC, bachmeier wrote:

Suppose I want to iterate over two arrays at once:

foreach(v1, v2; [1.5, 2.5, 3.5], [4.5, 5.5, 6.5]) {
  ...
}

I have seen a way to do this but cannot remember what it is and 
cannot find it.


Thanks for the replies. This is what I needed.

Re: Iterate over two arguments at once

[Jon Degenhardt via Digitalmars-d-learn]

On Monday, 19 September 2016 at 18:10:22 UTC, bachmeier wrote:

Suppose I want to iterate over two arrays at once:

foreach(v1, v2; [1.5, 2.5, 3.5], [4.5, 5.5, 6.5]) {
  ...
}

I have seen a way to do this but cannot remember what it is and 
cannot find it.


range.lockstep:  https://dlang.org/phobos/std_range.html#lockstep

Re: Iterate over two arguments at once

[Steven Schveighoffer via Digitalmars-d-learn]

On 9/19/16 2:10 PM, bachmeier wrote:

Suppose I want to iterate over two arrays at once:

foreach(v1, v2; [1.5, 2.5, 3.5], [4.5, 5.5, 6.5]) {
  ...
}

I have seen a way to do this but cannot remember what it is and cannot
find it.


http://dlang.org/phobos/std_range.html#.zip

-Steve

Re: Iterate over two arguments at once

[Lodovico Giaretta via Digitalmars-d-learn]

On Monday, 19 September 2016 at 18:10:22 UTC, bachmeier wrote:

Suppose I want to iterate over two arrays at once:

foreach(v1, v2; [1.5, 2.5, 3.5], [4.5, 5.5, 6.5]) {
  ...
}

I have seen a way to do this but cannot remember what it is and 
cannot find it.


You can use std.range.zip:

https://dlang.org/phobos/std_range.html#.zip

Or std.range.lockstep:

https://dlang.org/phobos/std_range.html#.lockstep

Re: Battle-plan for CTFE

[Stefan Koch via Digitalmars-d-announce]

On Monday, 19 September 2016 at 18:05:34 UTC, Lurker wrote:


Good news anyway! Do you have any preliminary results or goals 
and expectations that you are going to achieve with your 
rework? Is it mostly perf/memory improvements, are there any 
new features that this rework will unlock?


Thanks for your hard work!


I stated my expectations earlier I think there will be a 2-6x 
performance increase in the non-jited version and around 10-14x 
for the jit.

My preliminary results do support that claim.

As for new features I do not plan on doing language-changes as I 
do not have the ability to anticipate the outcome of doing so.


My work will probably have side-effects on the rest of dmd, for 
example the AST is hard to work with in some cases. I would to 
add like some support for frontend-optimisations as well.


I will also improve documentation in some areas and hope to lower 
the entry-barrier for dmd-development.

Re: vibe.d maxRequestSize

[Chris via Digitalmars-d-learn]

On Monday, 19 September 2016 at 17:54:05 UTC, Steven 
Schveighoffer wrote:

On 9/19/16 1:34 PM, Chris wrote:

[...]


Here is the culprit:

https://github.com/rejectedsoftware/vibe.d/blob/0.7.29/source/vibe/http/server.d#L1861

And the definition of MaxHTTPHeaderLineLength is:

https://github.com/rejectedsoftware/vibe.d/blob/0.7.29/source/vibe/http/server.d#L1861

4096 bytes.

I'm not super-familiar with HTTP protocol requirements, but a 
further diagnosis of your net traffic may reveal that your 
browser is doing something unorthodox, or vibe needs to adjust 
here.


-Steve


Thanks a million! I'll look into it tomorrow.

Iterate over two arguments at once

[bachmeier via Digitalmars-d-learn]

Suppose I want to iterate over two arrays at once:

foreach(v1, v2; [1.5, 2.5, 3.5], [4.5, 5.5, 6.5]) {
  ...
}

I have seen a way to do this but cannot remember what it is and 
cannot find it.

[Issue 16511] Suspected Win64 release-mode code-gen bug

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16511

--- Comment #2 from Nick Sabalausky  ---
Got a report of the crash happening with both --build=debug (dub's default) and
--build=release. It only crashes with --build=release for me. So not really
sure what's going on. In my lib, I'm going to be working around it, but wanted
to post this here in case there is an underlying codegen thing.

--

Re: vibe.d maxRequestSize

[Steven Schveighoffer via Digitalmars-d-learn]

On 9/19/16 1:34 PM, Chris wrote:

On Monday, 19 September 2016 at 16:55:05 UTC, Steven Schveighoffer wrote:




Hm... you don't get a full stack trace? Hard to tell what max_bytes
should be, it defaults to ulong.max, so no way you are exhausting
that. Without knowing where readUntilSmall is called, it's hard to
diagnose.

-Steve


I didn't want to litter the thread, here it is:

400 - Bad Request

Bad Request

Internal error information:
object.Exception@../../.dub/packages/vibe-d-0.7.29/vibe-d/source/vibe/stream/operations.d(349):
Reached maximum number of bytes while searching for end marker.

/home/chris/.dvm/compilers/dmd-2.071.1/linux/bin/../../src/phobos/std/exception.d:405
pure @safe void
std.exception.bailOut!(Exception).bailOut(immutable(char)[], ulong,
const(char[])) [0x8f11a7]
/home/chris/.dvm/compilers/dmd-2.071.1/linux/bin/../../src/phobos/std/exception.d:363
pure @safe bool std.exception.enforce!(Exception, bool).enforce(bool,
lazy const(char)[], immutable(char)[], ulong) [0x8f112a]
.../../.dub/packages/vibe-d-0.7.29/vibe-d/source/vibe/stream/operations.d:348
void
vibe.stream.operations.readUntilSmall!(vibe.utils.array.AllocAppender!(ubyte[],
ubyte).AllocAppender).readUntilSmall(vibe.core.stream.InputStream, ref
vibe.utils.array.AllocAppender!(ubyte[], ubyte).AllocAppender,
const(ubyte[]), ulong) [0xb06b00]
.../../.dub/packages/vibe-d-0.7.29/vibe-d/source/vibe/stream/operations.d:137
void
vibe.stream.operations.readUntil!(vibe.utils.array.AllocAppender!(ubyte[],
ubyte).AllocAppender).readUntil(vibe.core.stream.InputStream, ref
vibe.utils.array.AllocAppender!(ubyte[], ubyte).AllocAppender,
const(ubyte[]), ulong) [0xb06a1f]
.../../.dub/packages/vibe-d-0.7.29/vibe-d/source/vibe/stream/operations.d:53
void
vibe.stream.operations.readLine!(vibe.utils.array.AllocAppender!(ubyte[], 
ubyte).AllocAppender).readLine(vibe.core.stream.InputStream,
ref vibe.utils.array.AllocAppender!(ubyte[], ubyte).AllocAppender,
ulong, immutable(char)[]) [0xb069c8]
.../../.dub/packages/vibe-d-0.7.29/vibe-d/source/vibe/stream/operations.d:39
ubyte[]
vibe.stream.operations.readLine!().readLine(vibe.core.stream.InputStream, ulong,
immutable(char)[], vibe.utils.memory.Allocator) [0xb06984]
.../../.dub/packages/vibe-d-0.7.29/vibe-d/source/vibe/http/server.d:1861
void
vibe.http.server.parseRequestHeader(vibe.http.server.HTTPServerRequest,
vibe.core.stream.InputStream, vibe.utils.memory.Allocator, ulong)
[0xb5e827]


Here is the culprit:

https://github.com/rejectedsoftware/vibe.d/blob/0.7.29/source/vibe/http/server.d#L1861

And the definition of MaxHTTPHeaderLineLength is:

https://github.com/rejectedsoftware/vibe.d/blob/0.7.29/source/vibe/http/server.d#L1861

4096 bytes.

I'm not super-familiar with HTTP protocol requirements, but a further 
diagnosis of your net traffic may reveal that your browser is doing 
something unorthodox, or vibe needs to adjust here.


-Steve

Re: [OT] Brokerage for the D Language Foundation

[Laeeth Isharc via Digitalmars-d]

On Monday, 19 September 2016 at 02:39:33 UTC, Walter Bright wrote:

On 9/18/2016 5:20 PM, Andrei Alexandrescu wrote:
Thanks. Well this kinda boils down to a tautology. I remember 
my wife asked me
once "what kind of insurance could protect us against 
anything"? There isn't one
(which is kinda terrifying first time you realize it). In the 
US, as an aside, I
don't think there is even a medical insurance that could 
protect you from

financial ruin in all cases.

There is no easy option, and there is no risk-free option - so 
obviously we

aren't looking for such.



My fatalistic view is if the market tanks that badly, it'll 
bring down everything else with it.


What I mean is that if you have a margin account and never use 
margin,  I believe - unless things have changed - that you expose 
yourself to custody risk that you wouldn't have without a margin 
account.  If you're going to have a margin account,  you might 
even make sure you have an unlevered account as well,  since this 
custody risk is reward free.


And as regards equities,  a fifty percent retracement in equities 
would be unexceptional given the move since 2009,and your asset 
allocation should be prepared for that possibility. Being levered 
might not be consistent with that.   That kind of move certainly 
wouldn't mean it brings down everything with it, just that it's a 
hairy period of the kind that happens from time to time.  It's 
entirely possible to have such a move with a surprisingly strong 
economy because stronger wage growth and higher rates might be 
difficult for some sectors and that's not what people expect  
now,  and not what is priced in.


I emailed Andrei directly on lending club.

In investing,  think about risk first,  and consequences over 
probability.   Taleb is mostly right on this. The distribution of 
returns isn't Gaussian.

What blogs about D do you read?

[A D dev via Digitalmars-d-learn]

Hi list,

What blogs about D do you read?

Thanks in advance.

[Issue 16511] Suspected Win64 release-mode code-gen bug

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16511

--- Comment #1 from Nick Sabalausky  ---
Just for the sake of reference, the original report/conversation is here:
https://github.com/Abscissa/libInputVisitor/issues/1

--

Re: vibe.d maxRequestSize

[Chris via Digitalmars-d-learn]

On Monday, 19 September 2016 at 16:55:05 UTC, Steven 
Schveighoffer wrote:





Hm... you don't get a full stack trace? Hard to tell what 
max_bytes should be, it defaults to ulong.max, so no way you 
are exhausting that. Without knowing where readUntilSmall is 
called, it's hard to diagnose.


-Steve


I didn't want to litter the thread, here it is:

400 - Bad Request

Bad Request

Internal error information:
object.Exception@../../.dub/packages/vibe-d-0.7.29/vibe-d/source/vibe/stream/operations.d(349):
 Reached maximum number of bytes while searching for end marker.

/home/chris/.dvm/compilers/dmd-2.071.1/linux/bin/../../src/phobos/std/exception.d:405
 pure @safe void std.exception.bailOut!(Exception).bailOut(immutable(char)[], 
ulong, const(char[])) [0x8f11a7]
/home/chris/.dvm/compilers/dmd-2.071.1/linux/bin/../../src/phobos/std/exception.d:363
 pure @safe bool std.exception.enforce!(Exception, bool).enforce(bool, lazy 
const(char)[], immutable(char)[], ulong) [0x8f112a]
../../.dub/packages/vibe-d-0.7.29/vibe-d/source/vibe/stream/operations.d:348 
void 
vibe.stream.operations.readUntilSmall!(vibe.utils.array.AllocAppender!(ubyte[], 
ubyte).AllocAppender).readUntilSmall(vibe.core.stream.InputStream, ref 
vibe.utils.array.AllocAppender!(ubyte[], ubyte).AllocAppender, const(ubyte[]), 
ulong) [0xb06b00]
../../.dub/packages/vibe-d-0.7.29/vibe-d/source/vibe/stream/operations.d:137 
void vibe.stream.operations.readUntil!(vibe.utils.array.AllocAppender!(ubyte[], 
ubyte).AllocAppender).readUntil(vibe.core.stream.InputStream, ref 
vibe.utils.array.AllocAppender!(ubyte[], ubyte).AllocAppender, const(ubyte[]), 
ulong) [0xb06a1f]
../../.dub/packages/vibe-d-0.7.29/vibe-d/source/vibe/stream/operations.d:53 
void vibe.stream.operations.readLine!(vibe.utils.array.AllocAppender!(ubyte[], 
ubyte).AllocAppender).readLine(vibe.core.stream.InputStream, ref 
vibe.utils.array.AllocAppender!(ubyte[], ubyte).AllocAppender, ulong, 
immutable(char)[]) [0xb069c8]
../../.dub/packages/vibe-d-0.7.29/vibe-d/source/vibe/stream/operations.d:39 
ubyte[] 
vibe.stream.operations.readLine!().readLine(vibe.core.stream.InputStream, 
ulong, immutable(char)[], vibe.utils.memory.Allocator) [0xb06984]
../../.dub/packages/vibe-d-0.7.29/vibe-d/source/vibe/http/server.d:1861 void 
vibe.http.server.parseRequestHeader(vibe.http.server.HTTPServerRequest, 
vibe.core.stream.InputStream, vibe.utils.memory.Allocator, ulong) [0xb5e827]
../../.dub/packages/vibe-d-0.7.29/vibe-d/source/vibe/http/server.d:1659 bool 
vibe.http.server.handleRequest(vibe.core.stream.Stream, 
vibe.core.net.TCPConnection, vibe.http.server.HTTPListenInfo, ref 
vibe.http.server.HTTPServerSettings, ref bool) [0xb5c5d0]
../../.dub/packages/vibe-d-0.7.29/vibe-d/source/vibe/http/server.d:1552 void 
vibe.http.server.handleHTTPConnection(vibe.core.net.TCPConnection, 
vibe.http.server.HTTPListenInfo) [0xb5be4e]
../../.dub/packages/vibe-d-0.7.29/vibe-d/source/vibe/http/server.d:1433 void 
vibe.http.server.listenHTTPPlain(vibe.http.server.HTTPServerSettings).doListen(vibe.http.server.HTTPListenInfo,
 bool, bool).__lambda4(vibe.core.net.TCPConnection) [0xb5b814]
../../.dub/packages/vibe-d-0.7.29/vibe-d/source/vibe/core/drivers/libevent2_tcp.d:610
 void vibe.core.drivers.libevent2_tcp.ClientTask.execute() [0xbe8715]
../../.dub/packages/vibe-d-0.7.29/vibe-d/source/vibe/core/core.d:488 void 
vibe.core.core.makeTaskFuncInfo!(void delegate()).makeTaskFuncInfo(ref void 
delegate()).callDelegate(vibe.core.core.TaskFuncInfo*) [0xafea75]
../../.dub/packages/vibe-d-0.7.29/vibe-d/source/vibe/core/core.d:1119 void 
vibe.core.core.CoreTask.run() [0xb8dd79]
??:? void core.thread.Fiber.run() [0xc70ea5]
??:? fiber_entryPoint [0xc70c27]
??:? [0x]

[Issue 16511] New: Suspected Win64 release-mode code-gen bug

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16511

  Issue ID: 16511
   Summary: Suspected Win64 release-mode code-gen bug
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: critical
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: cbkbbej...@mailinator.com

I've reveived a bug report on a lib of mine that I'm suspecting may be a 64-bit
release-mode code-gen bug, because it involves what, at least *appears*, to be
a fiber overflowing its stack *ONLY* on 64-bit in release mode. I could
understand a stack overlflow on 32-bit-only, but this seems backwards. And a
release-mode-only crash seems to suggest a code-gen bug as well.

Sorry I dont have a reduced case right now, but you can reproduce like this:

On a Win64 machine with DUB 1.0.0
:

- Download this Gist to a fresh directory:
https://gist.github.com/MrSmith33/c2f435937aefbc3eead25aa873363d84

- From that directory, run:

> dub --arch=x86_64 --build=release --verbose --compiler=dmd

It will build, run, and then crash.

Omitting *either* of --arch=x86_64 or --build=release will eliminate the crash.

--

Re: vibe.d maxRequestSize

[Steven Schveighoffer via Digitalmars-d-learn]

On 9/19/16 11:59 AM, Chris wrote:

On Thursday, 15 September 2016 at 13:26:48 UTC, Steven Schveighoffer wrote:

On 9/15/16 9:11 AM, Chris wrote:

On Wednesday, 14 September 2016 at 20:23:09 UTC, Steven Schveighoffer
wrote:



Hm.. I have adjusted this in my project, and it works (set to 50M).
Needed it for uploading large images.

Using version 0.7.29



It doesn't seem to make any difference in my case. I wonder what could
be wrong


Seems to be in use:

https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/http/server.d#L1832




Finally, I could find where it happens. If I use "get" in a HTML form
(instead of "post"), vibe.d complains. I set the max request and request
header size to 25MB.

`
400 - Bad Request

Bad Request

Internal error information:
object.Exception@../../.dub/packages/vibe-d-0.7.29/vibe-d/source/vibe/stream/operations.d(349):
Reached maximum number of bytes while searching for end marker.

`

https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/stream/operations.d#L349




Hm... you don't get a full stack trace? Hard to tell what max_bytes 
should be, it defaults to ulong.max, so no way you are exhausting that. 
Without knowing where readUntilSmall is called, it's hard to diagnose.


-Steve

Re: consequences of removing semicolons in D like in Python

[bpr via Digitalmars-d]

On Saturday, 17 September 2016 at 16:43:13 UTC, Nick Sabalausky 
wrote:
If semicolons are such a terrible drain, there's always JS and 
Python.


For someone who likes D, Nim (http://www.nim-lang.org) would be 
better a choice for a language at the same level with Python like 
syntax. Changing D surface syntax is an obvious non-starter.

Re: seg fault, now what?

[Kagamin via Digitalmars-d-learn]

On Saturday, 17 September 2016 at 21:12:08 UTC, Ryan wrote:
But I don't have another e-mail address, and it seems a bit 
much to create a fake e-mail account for a few bug reports.


mailmetrash.com :)

Re: Ah, simple solution to unittests inside templates

[H. S. Teoh via Digitalmars-d]

On Mon, Sep 19, 2016 at 09:02:05AM -0700, H. S. Teoh via Digitalmars-d wrote:
> On Sat, Sep 17, 2016 at 01:22:52PM -0400, Andrei Alexandrescu via 
> Digitalmars-d wrote:
> > Recall the discussion a few days ago about unittests inside templates
> > being instantiated with the template. Often that's desirable, but
> > sometimes not - for example when you want to generate nice ddoc
> > unittests and avoid bloating. For those cases, here's a simple
> > solution that I don't think has been mentioned:
> 
> I've already mentioned this exact idea recently in the d-learn forum.
> Nobody responded then.
[...]

Correction: it was on this very same forum:


http://forum.dlang.org/post/mailman.96.1472754654.2965.digitalmar...@puremagic.com


T

-- 
May you live all the days of your life. -- Jonathan Swift

Re: Ah, simple solution to unittests inside templates

[H. S. Teoh via Digitalmars-d]

On Sat, Sep 17, 2016 at 01:22:52PM -0400, Andrei Alexandrescu via Digitalmars-d 
wrote:
> Recall the discussion a few days ago about unittests inside templates
> being instantiated with the template. Often that's desirable, but
> sometimes not - for example when you want to generate nice ddoc
> unittests and avoid bloating. For those cases, here's a simple
> solution that I don't think has been mentioned:

I've already mentioned this exact idea recently in the d-learn forum.
Nobody responded then.


> /** Awesome struct */
> struct Awesome(T)
> {
> /** Awesome function. */
> void awesome() {}
> 
> ///
> static if (is(T == int)) unittest
> {
> Awesome awesome;
> awesome.awesome;
> }
> }
> 
> The unittest documentation is nicely generated. The unittest code
> itself is only generated for one instantiation.
[...]

And you also have to make sure Awesome!int is actually instantiated,
otherwise the unittest won't actually run!


T

-- 
In theory, there is no difference between theory and practice.

Re: consequences of removing semicolons in D like in Python

[bachmeier via Digitalmars-d]

On Monday, 19 September 2016 at 15:13:10 UTC, Chris Wright wrote:

On Mon, 19 Sep 2016 13:06:30 +, pineapple wrote:

If you
spend enough time writing Python, you will start to run into 
cases where
meaningful whitespace makes it difficult to write readable, 
functional

code.


For the most part, you can wrap a statement in parentheses in 
lieu of semicolons.


That's called Lisp.

Re: vibe.d maxRequestSize

[Chris via Digitalmars-d-learn]

On Thursday, 15 September 2016 at 13:26:48 UTC, Steven 
Schveighoffer wrote:

On 9/15/16 9:11 AM, Chris wrote:
On Wednesday, 14 September 2016 at 20:23:09 UTC, Steven 
Schveighoffer

wrote:



Hm.. I have adjusted this in my project, and it works (set to 
50M).

Needed it for uploading large images.

Using version 0.7.29

-Steve


It doesn't seem to make any difference in my case. I wonder 
what could

be wrong


Seems to be in use:

https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/http/server.d#L1832

-Steve


Finally, I could find where it happens. If I use "get" in a HTML 
form (instead of "post"), vibe.d complains. I set the max request 
and request header size to 25MB.


`
400 - Bad Request

Bad Request

Internal error information:
object.Exception@../../.dub/packages/vibe-d-0.7.29/vibe-d/source/vibe/stream/operations.d(349):
 Reached maximum number of bytes while searching for end marker.

`

https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/stream/operations.d#L349

[Issue 16510] New: Request: RSA digital signature validation in phobos

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16510

  Issue ID: 16510
   Summary: Request: RSA digital signature validation in phobos
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: an...@s-e-a-p.de

This is a request for adding RSA to std.digest. Especially I am interested in
the digital signature validation.

RSA is used for creating digital signatures for e.g. JSON Web Tokens. It would
be great if the algorithm could be added to Phobos.

--

Re: consequences of removing semicolons in D like in Python

[Chris Wright via Digitalmars-d]

On Mon, 19 Sep 2016 13:06:30 +, pineapple wrote:
> If you
> spend enough time writing Python, you will start to run into cases where
> meaningful whitespace makes it difficult to write readable, functional
> code.

For the most part, you can wrap a statement in parentheses in lieu of 
semicolons.

[Issue 16509] New: DIP25 'return' attribute not documented for functions

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16509

  Issue ID: 16509
   Summary: DIP25 'return' attribute not documented for functions
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: major
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: mathias.l...@sociomantic.com

The 'return' attribute is almost undocumented in `specs/function.dd`.
It was added to the grammar in https://github.com/dlang/dlang.org/pull/1415 but
no paragraph has been written to explain it.

One wishing to fix this should probably use http://wiki.dlang.org/DIP25 as
reference.

Marking as major since it's now enabled by default.

--

Re: Emplace vs closures

[Steven Schveighoffer via Digitalmars-d]

On 9/19/16 10:26 AM, Lodovico Giaretta wrote:

On Monday, 19 September 2016 at 14:22:16 UTC, Steven Schveighoffer wrote:

On 9/19/16 7:27 AM, Lodovico Giaretta wrote:


What I'd like to know: is this usage widespread? Should we forbid it for
the sake of security?


No. There is no security concern here. You are dereferencing a null
pointer, which is perfectly safe.


Ok, wrong wording. I meant "should we forbid it to avoid long hours of
debugging and unexpected behaviours? One uses emplace expecting that it
Just Works(TM), which is not true for nested things."


Maybe we can disable the emplace that will certainly cause a Null 
pointer segfault when used, and allow the copying version. But there may 
still be code that uses the struct without needing the context pointer, 
that would then be broken.


My opinion is just not to worry about it. We don't get much traffic here 
complaining of this issue, you may be the one hardest hit by it (and you 
likely won't have it happen any more).


For instance, we have way way more complaints of people using classes 
without allocating them, and that is a similar problem.


However, a sufficient warning in the docs is certainly in order, at 
least as long as we aren't going to forbid it.


-Steve

Re: seg fault, now what?

[Steven Schveighoffer via Digitalmars-d-learn]

On 9/17/16 5:12 PM, Ryan wrote:

Is there an alternative to reporting bugs via bugzilla?

I tried to open an account, but they recommend not using your main
e-mail address because it will be posted to the web for all the spammers
to find. But I don't have another e-mail address, and it seems a bit
much to create a fake e-mail account for a few bug reports.


Slightly OT, but with a gmail/yahoo address, generally the spam filter 
is quite good. I've used my yahoo address for years on bugzilla and this 
forum, and never had adverse spamming issues.


-Steve

Re: Emplace vs closures

[Lodovico Giaretta via Digitalmars-d]

On Monday, 19 September 2016 at 14:22:16 UTC, Steven 
Schveighoffer wrote:

On 9/19/16 7:27 AM, Lodovico Giaretta wrote:

What I'd like to know: is this usage widespread? Should we 
forbid it for

the sake of security?


No. There is no security concern here. You are dereferencing a 
null pointer, which is perfectly safe.


-Steve


Ok, wrong wording. I meant "should we forbid it to avoid long 
hours of debugging and unexpected behaviours? One uses emplace 
expecting that it Just Works(TM), which is not true for nested 
things."

Re: Emplace vs closures

[Steven Schveighoffer via Digitalmars-d]

On 9/19/16 7:27 AM, Lodovico Giaretta wrote:


What I'd like to know: is this usage widespread? Should we forbid it for
the sake of security?


No. There is no security concern here. You are dereferencing a null 
pointer, which is perfectly safe.


-Steve

Re: [WORK] std.file.update function

[Stefan Koch via Digitalmars-d]

On Monday, 19 September 2016 at 14:04:03 UTC, Andrei Alexandrescu 
wrote:


Interesting. What happens e.g. if one makes a change to a 
function whose generated code is somewhere in the middle of the 
object file? If it doesn't alter the call graph, doesn't the 
new .o file share a common prefix with the old one?


Only if the TOC is unchanged.
There are a lot of common sections in the same order but with 
different offsets.

we would need some binary patching method.

But I am unaware of file-systems supporting this.
Microsofts incremental linking mechnism makes use of thunks so it 
can avoid changing the header iirc.


But all of this needs codegen to adept.

Re: [WORK] std.file.update function

[Andrei Alexandrescu via Digitalmars-d]

On 09/18/2016 10:05 PM, Brad Roberts via Digitalmars-d wrote:

This is nice in the case of no changes, but problematic in the case of
some changes.  The standard write new, rename technique never has either
file in a half-right state.  The file is atomically either old or new
and nothing in between.  This can be critical.


Good point, should be also part of the doco or a flag with update (e.g.
Yes.atomic). Alternative: the caller may wish to rename the file prior 
to the operation and then rename it back after the operation. -- Andrei

Re: [WORK] std.file.update function

[Andrei Alexandrescu via Digitalmars-d]

On 09/19/2016 01:16 AM, Walter Bright wrote:

On 9/18/2016 8:20 AM, Andrei Alexandrescu wrote:

On 09/18/2016 11:17 AM, Andrei Alexandrescu wrote:

Simplest case is - source file is being changed, therefore a new object
file is being produced, therefore a new executable is being produced.


Forgot to mention a situation here: if you change the source code of a
module
without influencing the object file (e.g. documentation, certain style
changes,
unittests in non-unittest builds etc) there'd be no linking upon
rebuilding. --



The compiler currently creates the complete object file in a buffer,
then writes the buffer to a file in one command. The reason is mostly
because the object file format isn't incremental, the beginning is
written last and the body gets backpatched as the compilation progresses.


Great. In that case, if the target .o file already exists, it should be 
compared against the buffer. If identical, there should be no write and 
the timestamp of the .o file should stay the same.


I need to re-emphasize this kind of stuff is important for tooling. Many 
files get recompiled to identical object files - e.g. the many innocent 
bystanders in a dense dependency structure when one module changes. We 
also embed documentation in source files. Being disciplined about 
reflecting actual changes in the actual file operations is very helpful 
for tools that track file writes and/or timestamps.



I can't really see a compilation producing an object file where the
first half of it matches the previous object file and the second half is
different, because of the file format.


Interesting. What happens e.g. if one makes a change to a function whose 
generated code is somewhere in the middle of the object file? If it 
doesn't alter the call graph, doesn't the new .o file share a common 
prefix with the old one?



Interestingly, the win32 .lib format is designed for incredibly slow
floppy disks, in that updating the library need not read/write every
disk sector.

I'd love to design our own high speed formats, but then they'd be
incompatible with everybody else's.


This (and the subsequent considerations) is drifting off-topic. This is 
about getting a useful function off the ground, and sadly is 
degenerating into yet another off-topic debate leading to no progress.



Andrei

Re: [WORK] std.file.update function

[ketmar via Digitalmars-d]

On Monday, 19 September 2016 at 06:53:47 UTC, Walter Bright wrote:
Doing a linker inside DMD means that object files imported from 
other C/C++ compilers have to be correctly interpreted. I could 
do it, but I couldn't do that and continue to work on D.


yeah. there is a reason for absense of 100500 hobbyst FOSS 
linkers. ;-) contrary to what it may look like, correct linking 
is really hard task. and mostly not fun to write too. people 
usually trying, and then just silently returning to binutils. ;-)

Re: Emplace vs closures

[ag0aep6g via Digitalmars-d]

On 09/19/2016 02:55 PM, Timon Gehr wrote:

This works:
import std.stdio;
void main(){
int x=3;
enum l=()=>x;
writeln(x);
}

I.e. l has the correct runtime context even though it is a static value.


Enums are a special kind of static value, though. Can't do that with 
`static` instead of `enum`. Enums (often?) don't manifest until they're 
used. Could .init work that way?

Re: Forum for new programmers in spanish.

[Geert via Digitalmars-d-learn]

On Monday, 19 September 2016 at 10:10:18 UTC, Seb wrote:


I don't speak Spanish, but I do like your idea of bringing D to 
more people :)

Two ideas:

1) You could help to translate the DLang Tour to Spanish:

https://tour.dlang.org
https://github.com/dlang-tour/spanish

2) StackOverflow has an excellent PageRank and thus many 
communities are moving there discussions over as it helps to 
increase their visibility and searchability. I don't know how 
good the spanish StackOverflow is, but it might be easier than 
maintaining a forum yourself?



Thanks Seb. I'll look at the DLang Tour.

On the other hand, i think a forum will be better, not only to 
help, but also to keep D programmers closer and expectant for 
news. Although, you are right, StackOverflow would be better to 
increase searchability and easier than maintaining a forum. I'll 
keep that in mind before taking a decision. Thanks!

Re: Release 2.071.2

[Ilya Yaroshenko via Digitalmars-d-announce]

On Monday, 19 September 2016 at 13:08:34 UTC, Martin Nowak wrote:
On Monday, 19 September 2016 at 12:26:21 UTC, Jack Stouffer 
wrote:
On a slightly related note, I think it would be a good idea to 
branch off 2.072 and start beta testing right away, as it's 
been five months since the last point release, and A LOT has 
changed since then.  I fear that we may see a huge number of 
regressions for this beta cycle because they've just been 
compounding over this time.


Yes, that was my intention as well. We'll discuss how to 
proceed in the next few days.
On the good side those have mostly been phobos instead of 
language changes.

https://github.com/dlang/dmd/compare/stable...master
AFAIK the dmd work was mostly on C->D conversion and a few 
smaller fixes for @safe and @nogc.
On the bad side phobos changes had the tendency to not care too 
much about compatibility in the past.


As I've been on vacation the past 3-4 weeks, I still need to 
catch up and get a better overview.


Thank you for the release!

Please merge 2 ndslice PRs [1] for 2.072. They are required for 
Mir to exclude ndslice package except experimental 
ndslice.algotithm and future modules. It is very costly to 
maintain both Phobos and Mir versions. So I would like to exclude 
already accepted ndslice modules from Mir. 3 PRs are already 
merged by Andrei, he also reviewed #4780. #4781 is main 
preparation for Mir and it contains mapSlice, which was reviewed 
as ndMap in #4652.


[1] https://github.com/dlang/phobos/milestone/9

Best regards,
Ilya

Re: Ah, simple solution to unittests inside templates

[Steven Schveighoffer via Digitalmars-d]

On 9/18/16 8:14 AM, Andrei Alexandrescu wrote:

On 9/18/16 6:00 AM, Jonathan M Davis via Digitalmars-d wrote:

Yes. That's DIP 82:

http://wiki.dlang.org/DIP82

I need to go over it again and then introduce it into the new DIP
process.
But I really think that that's where we should go to fix this problem.


Just a thought: things that we can't do have high priority. Things that
we can do with a modest cost are much less attractive. Consider:

struct Awesome(A, B, C)
{
private enum ut = is(A == int) && is(B == int) && is(C == int);

static if (ut) unittest
{
...
}
}

You're looking at an overhead with a small fixed cost plus a few
characters ("if (ut)") per unittest.


This is exactly how I did RedBlackTree unit tests:

https://github.com/dlang/phobos/blob/master/std/container/rbtree.d#L748
https://github.com/dlang/phobos/blob/master/std/container/rbtree.d#L815

This is still less than ideal, and has caused some real problems over 
the years. e.g.:


https://issues.dlang.org/show_bug.cgi?id=12246
https://issues.dlang.org/show_bug.cgi?id=14082

The best solution IMO is not to run templated unit tests unless 
specifically requested. Perhaps only run them when instantiated inside a 
unittest block?


All that being said, running unit tests on EVERY integral type caught 
about 3 bugs in the compiler when I was creating dcollections, and found 
several corner-case bugs in my code as well. It was well worth the 
"overhead" IMO.


-Steve

Re: Emplace vs closures

[Lodovico Giaretta via Digitalmars-d]

On Monday, 19 September 2016 at 11:27:03 UTC, Lodovico Giaretta 
wrote:
What I'd like to know: is this usage widespread? Should we 
forbid it for the sake of security?


A big issue I'm finding is that inside most Phobos unittests 
classes and structs are not marked static even when they could, 
so putting any restriction on emplace will break most of them.


This of course is not a problem for Phobos (we can easily put 
static everywhere it's needed), but most DUB packages will 
probably have the same poor usage of static without the 
maintainance effort of Phobos (so will remain broken forever).


I already found many (direct or indirect) uses of emplace for 
non-static nested structs and classes in std.conv, std.typecons 
and std.experimental.allocator.

Re: Release 2.071.2

[Martin Nowak via Digitalmars-d-announce]

On Monday, 19 September 2016 at 12:26:21 UTC, Jack Stouffer wrote:
On a slightly related note, I think it would be a good idea to 
branch off 2.072 and start beta testing right away, as it's 
been five months since the last point release, and A LOT has 
changed since then.  I fear that we may see a huge number of 
regressions for this beta cycle because they've just been 
compounding over this time.


Yes, that was my intention as well. We'll discuss how to proceed 
in the next few days.
On the good side those have mostly been phobos instead of 
language changes.

https://github.com/dlang/dmd/compare/stable...master
AFAIK the dmd work was mostly on C->D conversion and a few 
smaller fixes for @safe and @nogc.
On the bad side phobos changes had the tendency to not care too 
much about compatibility in the past.


As I've been on vacation the past 3-4 weeks, I still need to 
catch up and get a better overview.

Re: consequences of removing semicolons in D like in Python

[pineapple via Digitalmars-d]

On Friday, 16 September 2016 at 23:00:08 UTC, eugene wrote:

Hello everyone,
what if to remove semicolons at the end of each line of code in 
D like in Python?

Is it worth it?


If you write JS in a professional environment, you will almost 
certainly be required to terminate every line with a semicolon 
because it's too easy to write code that behaves in unexpected 
ways otherwise. If you spend enough time writing Python, you will 
start to run into cases where meaningful whitespace makes it 
difficult to write readable, functional code.


Omitting semicolons satisfies a small handful of programmers who 
don't like having them all over the place, sure, but it alienates 
everyone who takes development seriously enough that the 
ambiguity becomes a hinderance.

Re: Emplace vs closures

[Timon Gehr via Digitalmars-d]

On 19.09.2016 14:35, ag0aep6g wrote:

On 09/19/2016 02:24 PM, Lodovico Giaretta wrote:

Oh. I didn't thought about that. This means that in the following
example, the initialization of `s` is more than a simple call to
`S.init`. I was under the impression that in D `S.init` should represent
a valid state for whatever type `S`.


Yeah, .init and nested structs don't really fit together. On the one
hand .init is supposed to be a valid value. On the other hand it must be
a static value. Can't have both with nested structs. Maybe they
shouldn't have .init at all.


This works:
import std.stdio;
void main(){
int x=3;
enum l=()=>x;
writeln(x);
}

I.e. l has the correct runtime context even though it is a static value.

Re: Emplace vs closures

[ag0aep6g via Digitalmars-d]

On 09/19/2016 02:24 PM, Lodovico Giaretta wrote:

Oh. I didn't thought about that. This means that in the following
example, the initialization of `s` is more than a simple call to
`S.init`. I was under the impression that in D `S.init` should represent
a valid state for whatever type `S`.


Yeah, .init and nested structs don't really fit together. On the one 
hand .init is supposed to be a valid value. On the other hand it must be 
a static value. Can't have both with nested structs. Maybe they 
shouldn't have .init at all.

Re: polar coordinates with ggplotd

[Edwin van Leeuwen via Digitalmars-d-learn]

On Sunday, 18 September 2016 at 22:13:35 UTC, brocolis wrote:

Found an error in ys line. Thanks.


Does that mean you solved it?

Currently there is no special support for other coordinate 
systems, but I recently added Guides for x/y coordinates which 
should make this relatively straightforward to implement and is 
next on the list. Not sure when I'll get a chunk of time to 
implement it though.


For now you will have to convert the coordinates yourself, before 
plotting them.

Re: Release 2.071.2

[Jack Stouffer via Digitalmars-d-announce]

On Monday, 19 September 2016 at 11:08:33 UTC, Martin Nowak wrote:

Glad to announce D 2.071.2.

http://dlang.org/download.html

This point release fixes many issues with the new lookup and 
import rules. It should be used as a stopgap version when 
updating older code. The deprecations, the old access checks, 
and the -transition=import/checkimports switches are planned to 
be removed with 2.073.x.


Those new rules should now be finalized and semantic changes, 
deprecations, as well as the -transition=import and 
-transition=checkimports switches should work as expected. 
Please file a bug if you have any problems.


Also see the changelog for more details.

http://dlang.org/changelog/2.071.2.html

-Martin


Thanks for releasing this.

On a slightly related note, I think it would be a good idea to 
branch off 2.072 and start beta testing right away, as it's been 
five months since the last point release, and A LOT has changed 
since then.  I fear that we may see a huge number of regressions 
for this beta cycle because they've just been compounding over 
this time.

Re: Emplace vs closures

[Lodovico Giaretta via Digitalmars-d]

On Monday, 19 September 2016 at 11:45:25 UTC, ag0aep6g wrote:
Note that it would also segfault with `auto ps = S.init;`, and 
for the same reason: missing context pointer.


Oh. I didn't thought about that. This means that in the following 
example, the initialization of `s` is more than a simple call to 
`S.init`. I was under the impression that in D `S.init` should 
represent a valid state for whatever type `S`.


void main()
{
int x = 42;
struct S
{
auto getX() { return x; }
}

S s; // this line does not simply call S.init,
 // but also creates a closure and puts it inside s.
}

There is a difference, though: You're copying an existing 
object here, including the context pointer. So maybe we could 
disallow the variant above that writes the .init value, and 
still allow the copying variant.


Yeah, I will try that.

Re: Emplace vs closures

[ag0aep6g via Digitalmars-d]

On 09/19/2016 01:27 PM, Lodovico Giaretta wrote:

As we all should know, std.conv.emplace does not play well with closures:

void main()
{
int x = 42;
struct S
{
auto getX() { return x; }
}

S s;
assert(s.getX == x);

auto ps = someBuffer.emplace!S();
assert(s.getX == x);// SEGFAULT!
}


Should probably be `assert(ps.getX == x);`.

Note that it would also segfault with `auto ps = S.init;`, and for the 
same reason: missing context pointer.



As this is not fixable (we cannot pass closures around in D), we should
IMHO forbid such usages of emplace (i.e. static assert(!isNested!S))

I was already working on this, when I stumbled upon this unittest in
std.conv (simplified):

unittest
{
int i = 0;
struct S1
{
void foo(){++i;}
}
S1 sa = void;
S1 sb;
emplace(, sb);   // automagically works
sa.foo();
assert(i == 1);
}

Of course there's no way to distinguish between this (legitimate?) use
case and the former one, so preventing those segfaults will also
prohibit this kind of usage.


There is a difference, though: You're copying an existing object here, 
including the context pointer. So maybe we could disallow the variant 
above that writes the .init value, and still allow the copying variant.

Emplace vs closures

[Lodovico Giaretta via Digitalmars-d]

As we all should know, std.conv.emplace does not play well with 
closures:


void main()
{
int x = 42;
struct S
{
auto getX() { return x; }
}

S s;
assert(s.getX == x);

auto ps = someBuffer.emplace!S();
assert(s.getX == x);// SEGFAULT!
}

As this is not fixable (we cannot pass closures around in D), we 
should IMHO forbid such usages of emplace (i.e. static 
assert(!isNested!S))


I was already working on this, when I stumbled upon this unittest 
in std.conv (simplified):


unittest
{
int i = 0;
struct S1
{
void foo(){++i;}
}
S1 sa = void;
S1 sb;
emplace(, sb);   // automagically works
sa.foo();
assert(i == 1);
}

Of course there's no way to distinguish between this 
(legitimate?) use case and the former one, so preventing those 
segfaults will also prohibit this kind of usage.


What I'd like to know: is this usage widespread? Should we forbid 
it for the sake of security?

[Issue 16405] Trojan Win32/Ipac.B!cl detected on dmd-2.071.1.exe

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16405

Martin Nowak  changed:

   What|Removed |Added

 CC||c...@dawg.eu

--- Comment #6 from Martin Nowak  ---
(In reply to Sobirari Muhomori from comment #5)
> I uploaded the file at
> https://www.microsoft.com/en-us/security/portal/submission/submit.aspx for
> online scan with microsoft antivirus and it tells that the file is not
> detected.

How did you manage to upload the installer exe that is bigger than 10MB?

--

Release 2.071.2

[Martin Nowak via Digitalmars-d-announce]

Glad to announce D 2.071.2.

http://dlang.org/download.html

This point release fixes many issues with the new lookup and import
rules. It should be used as a stopgap version when updating older code.
The deprecations, the old access checks, and the
-transition=import/checkimports switches are planned to be removed with
2.073.x.

Those new rules should now be finalized and semantic changes,
deprecations, as well as the -transition=import and
-transition=checkimports switches should work as expected.
Please file a bug if you have any problems.

Also see the changelog for more details.

http://dlang.org/changelog/2.071.2.html

-Martin

[Issue 16071] Source file path and module name should match exactly

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16071

Mathias Lang  changed:

   What|Removed |Added

 CC||mathias.l...@sociomantic.co
   ||m

--- Comment #2 from Mathias Lang  ---
Thanks for the rationale, and glad to hear you're planning to fix it in DMD!
We should probably document it at some point, but it's a minor point.

--

Re: consequences of removing semicolons in D like in Python

[Kagamin via Digitalmars-d]

On Saturday, 17 September 2016 at 14:47:38 UTC, eugene wrote:

On Saturday, 17 September 2016 at 14:23:40 UTC, jmh530 wrote:
What if the OP wrote a compiler that turned his version of D 
sans semicolons into proper D code?


i didn't try to implement it myself, but i will try


There's already a compiler: http://delight.sourceforge.net/

Re: Forum for new programmers in spanish.

[Seb via Digitalmars-d-learn]

On Monday, 19 September 2016 at 05:56:04 UTC, Geert wrote:

Hi all!

I'm a PHP programmer, and i've been searching for new languages 
to learn. I think D it's the best of the newest languages, due 
its good documentation, clean sintaxis (or less verbose), and 
the applications developed in D run fast. I've read a D 
application could run as fast as one devoloped in C++ if it's 
well optimized (this is what interests me most).


I think D has a good community wich is constantly growing. But 
i have not found good resources of it in my native language: 
spanish. It is for this reason that i was thinking on 
developing a D spanish forum in my own server, to help new 
programmers who don't speak english. I think a divided 
community takes longer to reach a target, and that is not my 
intention. I would like anyone who speaks english stays and 
make contributions here.



What do you think about it?


I don't speak Spanish, but I do like your idea of bringing D to 
more people :)

Two ideas:

1) You could help to translate the DLang Tour to Spanish:

https://tour.dlang.org
https://github.com/dlang-tour/spanish

2) StackOverflow has an excellent PageRank and thus many 
communities are moving there discussions over as it helps to 
increase their visibility and searchability. I don't know how 
good the spanish StackOverflow is, but it might be easier than 
maintaining a forum yourself?

Re: Battle-plan for CTFE

[Stefan Koch via Digitalmars-d-announce]

On Thursday, 8 September 2016 at 18:54:52 UTC, Stefan Koch wrote:
On Thursday, 8 September 2016 at 13:11:23 UTC, Stefan Koch 
wrote:
On Thursday, 8 September 2016 at 10:44:55 UTC, Stefan Koch 
wrote:

compiling parts of phobos does no longer crash the new engine.
However it still produces incorrect byte-code :)


I think I have taken care of the incorrect bytecode.
It was not an issue with the engine itself but rather with the 
way I plugged it in.
The new engine is not supposed being called if the old one has 
already started to interpret the function, because the two do 
not and should not share state.


I found more incorrect code.
this time it's located more deeply in the engine.
I am investigating the cause.
It seems to be related closures somehow.


Compiling all of phobos does not crash my engine anymore!
However running the unittests does show incorrect results :(
This is concerning since I am mostly bailing out.

I think this too seems to be related to closures produced in 
templates.

Really nasty stuff.

[Issue 16071] Source file path and module name should match exactly

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16071

Walter Bright  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bugzi...@digitalmars.com
 Resolution|--- |WONTFIX

--- Comment #1 from Walter Bright  ---
The purpose for it being overridden is so that one can temporarily "swap in" an
alternate version of a source file from another directory. This is very useful
in debugging thinks like Phobos. It's a feature not a bug.

I plan to fix dmd so that its imports match its file structure, for the reasons
you mentioned.

Anyhow, this is working as designed, and is a feature.

--

Re: Omitting optional tags

[Kagamin via Digitalmars-d]

Well, a lot can be done to optimize generated html, e.g. it has a 
lot of spaces and questionable markup like href='object.html'>object

Re: The removal of inactive forum groups

[Seb via Digitalmars-d]

On Sunday, 18 September 2016 at 13:17:33 UTC, Dennis Ritchie 
wrote:

Hi, all
It seems to me that a group of `Beta` should be removed, 
because the last activity in this group dated November 30, 2015:

https://forum.dlang.org/post/565bc28c.8080...@dawg.eu

Group `Study` is also not very active, so it would be logical 
to move it higher than it is situated now, or otherwise 
reorganize the forum. Of course, at the very bottom of the 
forum group is doomed to `extinction`.


Any thoughts?


I tried a reorganization a couple of months ago:

https://forum.dlang.org/post/gkunyofqycjkgepjz...@forum.dlang.org

It didn't work out, because there are there busy people involved: 
Walter for the NNTP server, Brad for the mailing list (IIRC) and 
CyberShadow for the forum interface.