Re: Visual Studio Code code-d serve-d beta release

[Soulsbane via Digitalmars-d-announce]

On Saturday, 19 August 2017 at 05:11:13 UTC, Soulsbane wrote:

On Thursday, 10 August 2017 at 06:49:23 UTC, Dmitry wrote:

On Wednesday, 9 August 2017 at 14:39:12 UTC, WebFreak001 wrote:
try using the C/C++ Extension in vscode which uses the visual 
studio debugger, that one works great on windows for D


OMG, it's really works. Thank you alot!
I'll try to use VSCode as main IDE for D code.


I got it working! Nice work so far except I no longer see any 
output in the extension Code Outline's[1] pane. It works fine 
in the other version of code-d. I know this functionality 
probably won't be a priority but in my opinion having the two 
extensions work together makes writing D code really sweet.


Thanks again!


And I forgot to link the extension: 
https://marketplace.visualstudio.com/items?itemName=patrys.vscode-code-outline

Re: Visual Studio Code code-d serve-d beta release

[Soulsbane via Digitalmars-d-announce]

On Thursday, 10 August 2017 at 06:49:23 UTC, Dmitry wrote:

On Wednesday, 9 August 2017 at 14:39:12 UTC, WebFreak001 wrote:
try using the C/C++ Extension in vscode which uses the visual 
studio debugger, that one works great on windows for D


OMG, it's really works. Thank you alot!
I'll try to use VSCode as main IDE for D code.


I got it working! Nice work so far except I no longer see any 
output in the extension Code Outline's[1] pane. It works fine in 
the other version of code-d. I know this functionality probably 
won't be a priority but in my opinion having the two extensions 
work together makes writing D code really sweet.


Thanks again!

Re: @safe(bool)

[Manu via Digitalmars-d]

On 18 August 2017 at 02:32, bitwise via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:

> This came to mind while working on a set of containers.
>
> @safety often comes with a performance cost. For example, any container
> that wants to give out a range or iterator has to have a ref-counted or GC
> allocted payload to ensure safety. In a high-performance context though,
> the performance hit may be unacceptable.
>

This sounds like a job for `scope`.
Eg, given a container, the function that returns the range/iterator should
return a `scope` attributed range/iterator. This should insist that the
lifetime of the range that is returned be no longer than the container that
issued it.
We've needed scope to address these issues for a very long time, and it
finally arrived! I'm not sure how far it extends yet though, it's not well
documented yet, and I haven't seen it get a lot of action. I'm not sure
where the boundaries are.

ffmpeg

[Johnson Jones via Digitalmars-d-learn]

Trying to get it to work.

1. The libraries from the main download site seem to be in coff 
format for x86. This means they don't really work for dmd. I use 
omf and I tried to use coffimplib on the lib files and it says 
they are not import libraries.



2. The x64 version works without issue. (I was able to run the 
test version after adding the dll's, since the libs seem to 
require them for some oddball reason)


3. When I use -m32mscoff I get

Win32\Debug DMD\test.obj Offset 0H Record Type 004C
 Error 138: Module or Dictionary corrupt

4. Also, visual Studio cannot launch the x64 program with the 
debugger attached so I have to run it from the command line. It 
was working before, but when I started messing with the ffmpeg 
stuff it broke. So at this point the only way I can use ffmpeg is 
x64 and running stuff from the command line... This is not the 
way I want to go.

Re: Module Info error

[Johnson Jones via Digitalmars-d-learn]

On Saturday, 19 August 2017 at 02:07:25 UTC, Johnson Jones wrote:

Still getting this!

What I don't understand is why I can import certain libraries 
and they compile fine while others don't!


So, moduleInfo is a "function" per module that is created at 
compilation, right?


If one doesn't compile the module then the error results, just 
like standard extern functions. When I don't include the file 
in the project, it doesn't get compiled, even though it gets 
"imported"? Why? Why can't D just know, hey, module X imports 
module Y, module Y needs to be compiled to add moduleInfo?




For example, I am trying to get ffmpeg to work. I downloaded 
from


https://github.com/complistic-gaff/ffmpeg-d

extracted, put that path in my includes(sc.ini). created a 
module to import the standard modules, tried to compile my 
project and I get a bunch of ModuleInfo errors relating to the 
imports I added.


I use GtkD exactly the same, yet no errors.

Now, the only difference is that I import the gtkD.lib. I'm 
assuming that all the moduleInfo's of the 1000+ gtk files are 
in that lib and so That is the reason I don't have the compile 
them all, is that correct?


If so, how can I generate such a lib of moduleInfo's 
recursively for a directory so I can pick up all the files and 
just import it once?


ffmpeg doesn't require compiling but I don't wanna have to 
include ever file in to my project just to be able to get it to 
work because of the moduleInfo's are missing.


Looking at the build.d for gtkD, it looks like it builds a list 
of all the files to compile and does it recursively.


I imagine it can be modified for ffmpeg too to create a utility 
to solve this problem. Dmd should have a mode to do this 
automatically, it's quite an annoying problem ;/


So, I was able to hack the build script and solve my problem. I 
simply replaced the dir entries and such for ffmpeg instead.




module Build;

import core.stdc.stdlib: exit;

import std.algorithm;
import std.array;
import std.file;
import std.getopt;
import std.path;
import std.process;
import std.stdio;
import std.string;

string dcflags;
string ldflags;

int main(string[] args)
{

build("ffmpeg", "ffmpeg");


return(0);
}

void build(string dir, string lib)
{
version(Win64)
{
		std.file.write("build.rf", format("-m64 -c -lib %s %s 
-Igenerated/gtkd -of%s.lib %s", dcflags, ldflags, lib, 
dFiles(dir)));

auto pid = spawnProcess(["dmd", "@build.rf"]);

if ( wait(pid) != 0 )
exit(1);
}
else
{
if (lib == "gtkd")
{
			string[] subDirs = ["libavcodec", "libavdevice", 
"libavfilter", "libavformat", "libavutil", "libswscale"];


foreach(directory; subDirs)
buildObj(dFiles(directory), directory);

string objects;
foreach(directory; subDirs)
objects ~= directory ~".obj ";

			executeShell(format("dmd -lib %s -of%s.lib %s", ldflags, lib, 
objects));


foreach(directory; subDirs)
std.file.remove(directory ~".obj");
}
else
{
buildObj(dFiles(dir), lib);
			executeShell(format("dmd -lib %s -of%s.lib %s.obj", ldflags, 
lib, lib));

std.file.remove(lib ~".obj");
}
}

std.file.remove("build.rf");
}

void buildObj(string files, string objName)
{
	std.file.write("build.rf", format("-c %s -Igenerated/gtkd 
-of%s.obj %s", dcflags, objName, files));

auto pid = spawnProcess(["dmd", "@build.rf"]);
if ( wait(pid) != 0 )
exit(1);
}

string dFiles(string sourceDir)
{
string files;
auto entries = dirEntries(sourceDir, SpanMode.breadth);

foreach ( DirEntry entry; entries )
{
if ( entry.isDir == false && entry.name.extension == ".d" )
{
files ~= entry.name ~ " ";
}
}

return files;
}


So the question is, is there a direct way to do this? e.g., have 
dmd do it recursively for us, or rdmd, or a tool that is designed 
to do stuff like this for the general case? (the above code could 
be made more general, which I might do in the future)

Module Info error

[Johnson Jones via Digitalmars-d-learn]

Still getting this!

What I don't understand is why I can import certain libraries and 
they compile fine while others don't!


So, moduleInfo is a "function" per module that is created at 
compilation, right?


If one doesn't compile the module then the error results, just 
like standard extern functions. When I don't include the file in 
the project, it doesn't get compiled, even though it gets 
"imported"? Why? Why can't D just know, hey, module X imports 
module Y, module Y needs to be compiled to add moduleInfo?




For example, I am trying to get ffmpeg to work. I downloaded from

https://github.com/complistic-gaff/ffmpeg-d

extracted, put that path in my includes(sc.ini). created a module 
to import the standard modules, tried to compile my project and I 
get a bunch of ModuleInfo errors relating to the imports I added.


I use GtkD exactly the same, yet no errors.

Now, the only difference is that I import the gtkD.lib. I'm 
assuming that all the moduleInfo's of the 1000+ gtk files are in 
that lib and so That is the reason I don't have the compile them 
all, is that correct?


If so, how can I generate such a lib of moduleInfo's recursively 
for a directory so I can pick up all the files and just import it 
once?


ffmpeg doesn't require compiling but I don't wanna have to 
include ever file in to my project just to be able to get it to 
work because of the moduleInfo's are missing.


Looking at the build.d for gtkD, it looks like it builds a list 
of all the files to compile and does it recursively.


I imagine it can be modified for ffmpeg too to create a utility 
to solve this problem. Dmd should have a mode to do this 
automatically, it's quite an annoying problem ;/

Re: @safe(bool)

[jmh530 via Digitalmars-d]

On Saturday, 19 August 2017 at 00:37:06 UTC, Nicholas Wilson 
wrote:


Having to change the default attributes will be a rare 
occurrence (embedded (nothrow, nogc final) security critical 
(safe).




My reading of that updated DIP is that you can only change the 
default attributes by hacking on DRuntime. If a project has a 
custom runtime, I would figure most people would mention it 
somewhere.

[Issue 17581] Document behavior of -betterC

[via Digitalmars-d-bugs]

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

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 17581] Document behavior of -betterC

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dlang.org/commit/c7b3c834273118264bc79c7784c6703196b42696
Fix Issue 17581 - Document behavior of -betterC

https://github.com/dlang/dlang.org/commit/af8fe998d76653a182424cdb2c49c67911c525ce
Merge pull request #1796 from wilzbach/fix-17581

Fix Issue 17581 - Document behavior of -betterC

--

Re: @safe(bool)

[Nicholas Wilson via Digitalmars-d]

On Friday, 18 August 2017 at 23:11:34 UTC, Jonathan M Davis wrote:
On Friday, August 18, 2017 03:08:07 Nicholas Wilson via 
Digitalmars-d wrote:
On Friday, 18 August 2017 at 01:43:42 UTC, Jonathan M Davis 
wrote:

If you think that then I have clearly failed to express the DIP
at all.
It solves exactly that. I completely fail to see how it is a
detriment to anything.
The 'whole pile of other stuff' is reduced in further revisions
to the DIP.


IMHO, the problem that needs solving is that you can't negate 
attributes, making stuff like


final:

problematic. DIP 1012 goes way beyond that, and I don't think 
that that extra stuff is at all worth having, and I do think 
that it's detrimental. For instance, as it stands, it's 
relatively easy to figure out whether @safe has been explicitly 
applied. You can look on the function and look for @safe: or 
@safe {} which affects it. The same goes for other attributes. 
But as soon as you can do stuff like create new attributes that 
combine attributes, you lose that completely. Suddenly. you 
have to worry about whatever attributes someone came up on 
their own for their project which apply @safe or final or @nogc 
or whatever. You can no longer search or grep for an attribute 
like @safe to see whether it applies.


As I have said before that is a deliberate feature of the DIP and 
not an incidental side product. Many people have requested such a 
feature. It also allows the DIP to solve the export problem:


```d
 version(MyLib_Build)
 enum MyLibExport = dynamicExport;
 else
 enum MyLibExport = dynamicImport;

 // Exported when building the shared object,
 // imported when linking against the shared object.
 @MyLibExport void foo(int x) { ... }
  ```
I get that you dislike that feature: yes you lose the ability to 
see it directly. grep still works (it might take more searches) 
and so does the documentation.


Similarly, having it be possible to alter the default 
attributes globally is incredibly bad IMHO. Suddenly, whether 
your module compiles or not could depend on what settings 
someone used for the default attributes. That should not be 
controlled externally. It should be part of the module just 
like whether a function or variable is const or not is part of 
the module and not defined externally. IMHO, it makes no sense 
whatsoever to have something external control attributes any 
more than it makes sense to control the return types or 
constness of symbols externally. That should be part of the 
declarations/definitions of the symbols in question.


That is a separable feature of the DIP, i.e. the DIP still 
functions without it, and if it truly so incredibly bad more 
people will say so.


But, say you are developing for an embedded platform: you have no 
room for libunwind or exception table and can't use the gc. You 
see some library, libFoo, and you think "Aha! that does exactly 
what I need", then you think can I use it? is this library 
@nothrow @nogc?
You could consult the documentation, but that doesn't tell you 
because there are a bunch of templates that dont have explicit 
attributes. You could try altering the examples to be @nothrow 
@nogc, or you could try to build the whole library as @nothrow 
@nogc and get error messages closer to the site of use.

Yes it is niché, but it has its uses.


[...] , but I don't at all agree that the rest of
what DIP 1012 is trying to do is beneficial.


It fixes export, allows grouping and manipulation of lists of 
attributes


I honestly think that what DIP 1012 is trying to do beyond 
making it possible to negate attributes


Yes,


is going to make the language worse and code harder to maintain.


No.

Yes, it will enable some things that you can't do now, but for 
the most part, I don't think that those things should be 
enabled. I don't want to have to deal with folks complaining 
that my library doesn't work right, because they tried a 
different default for the attributes with it.


Then that library is not for them.

I don't want to have to worry about trying to get someone 
else's code to work because they assumed something about the 
default attributes that does not hold in my case.


Then the library is not for you.

Having to change the default attributes will be a rare occurrence 
(embedded (nothrow, nogc final) security critical (safe).


I don't want to have to track down every custom attribute that 
someone came up with just to see whether they actually apply 
attributes like @safe or nothrow, just so that I can see 
whether those attributes apply.


-vcg-ast, documentation. But really, how others do you go: I 
really need to know if that some function has a particular 
combination of attributes (serious)?



I should be able to look at a
module and see which attributes have been applied to the 
functions in that module without having to go searching 
elsewhere.


IMHO, what needs to be solved with the built-in attributes, is 
the ability to negate the ones that don't have 

Re: Need help with units library

[Joakim via Digitalmars-d-learn]

On Friday, 18 August 2017 at 13:21:06 UTC, alexander1974 wrote:
I want to write a library for working with units (lengths, 
weights, ...). It should allow maths and converting 
with/between different units (cm to mm, angstrom to meter, ...).


[...]


I have no opinion on your layout, but have you seen these 
existing libraries on the D package repository?


http://code.dlang.org/packages/units-d
http://code.dlang.org/packages/quantities

Perhaps you'd be better off contributing to one of them.

[Issue 17193] selective imports -> deprecation warnings even if symbol is not used

[via Digitalmars-d-bugs]

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

--- Comment #3 from b2.t...@gmx.com ---
committer, fix also 16577, it's so closed.

--

[Issue 17193] selective imports -> deprecation warnings even if symbol is not used

[via Digitalmars-d-bugs]

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

b2.t...@gmx.com changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=16577

--

[Issue 16577] A selective import on a symbol that has overloads leads to duplicate deprecation messages

[via Digitalmars-d-bugs]

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

b2.t...@gmx.com changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=17193

--

[Issue 16577] A selective import on a symbol that has overloads leads to duplicate deprecation messages

[via Digitalmars-d-bugs]

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

b2.t...@gmx.com changed:

   What|Removed |Added

Summary|A selective import on a |A selective import on a
   |symbol that has overloads   |symbol that has overloads
   |leads to duplicate messages |leads to duplicate
   ||deprecation messages

--

[Issue 17760] catch block fails to catch Exception subclass when another Exception is in transit

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #3 from Walter Bright  ---
Probably won't get fixed:

http://www.digitalmars.com/d/archives/digitalmars/D/Exception_chaining_and_collectException_305458.html

--

GtkD on android

[Johnson via Digitalmars-d-learn]

Hey Mike, have you put in thought or effort in to getting GtkD 
working on android?



e.g.,

https://github.com/eugals/GTKAndroid/wiki/Building

If I get around to it and no one has beating me before, I will 
try to compile something like the above and get the gtk libs 
required then use the new ldc to create an app for android.

Re: @safe(bool)

[Nicholas Wilson via Digitalmars-d]

On Friday, 18 August 2017 at 15:16:55 UTC, bitwise wrote:
On Friday, 18 August 2017 at 01:43:42 UTC, Jonathan M Davis 
wrote:

[...]

- Jonathan M Davis


Makes sense to me.

The first question that comes to mind is if the extra 
generality provided by DIP 1012 is actually useful, let alone, 
worth breaking changes.


It fixes the non-inverability. They become regular attributes 
instead of keywords. This has the effect of separating their 
definition from their usage allowing you to manipulate them like 
normal attributes, see https://github.com/dlang/DIPs/pull/89/ for 
the most recent revision.


The only breaking changes are nothrow and pure get a leading '@'.
They will go through a proper deprecation process and I will be 
very surprised if anything breaks. The new symbols added to 
core.attributes can use `@future` if need be to further reduce 
the likelihood of any breaking changes.


The rationale section of the DIP only mentions negating 
attributes, which is easily accomplished with what I suggested. 
Unless that section is expanded with additional practical use 
cases, then it doesn't seem worth the trouble to me.


The DIP mentions tagging a module declaration with default 
attributes. If the whole purpose of the DIP is to allow for 
negating attributes, why would you even need this change, when 
the DIP would effectively make it ok to put "@nogc: @safe: 
@etc:" at the top of the file?


This is changed in pull #89.

My suggestion does not cover "inferred" as discussed in the 
DIP, but that could be achieved by letting something like 
"@default" reset all attributes for a given symbol.


How would you know what attributes were in effect before?

I'll concede that DIP1012 makes more logical sense than the 
current state of things, but it seems like something that would 
be best achieved during a transition to a subsequent language 
version.


It seems commonplace here, to discard suggestions based on 
their current viability, when it may be better to add them to a 
feature backlog that could be considered when talking about the 
possibility of a D3.


Why? Breakage will be completely contained with transitional 
behaviour, i.e. the compiler will treat pure as @pure and nothrow 
as @nothrow. I can't think of any other facets that would warrant 
semi-indefinite delay.

Re: @safe(bool)

[Jonathan M Davis via Digitalmars-d]

On Friday, August 18, 2017 03:08:07 Nicholas Wilson via Digitalmars-d wrote:
> On Friday, 18 August 2017 at 01:43:42 UTC, Jonathan M Davis wrote:
> If you think that then I have clearly failed to express the DIP
> at all.
> It solves exactly that. I completely fail to see how it is a
> detriment to anything.
> The 'whole pile of other stuff' is reduced in further revisions
> to the DIP.

IMHO, the problem that needs solving is that you can't negate attributes,
making stuff like

final:

problematic. DIP 1012 goes way beyond that, and I don't think that that
extra stuff is at all worth having, and I do think that it's detrimental.
For instance, as it stands, it's relatively easy to figure out whether @safe
has been explicitly applied. You can look on the function and look for
@safe: or @safe {} which affects it. The same goes for other attributes. But
as soon as you can do stuff like create new attributes that combine
attributes, you lose that completely. Suddenly. you have to worry about
whatever attributes someone came up on their own for their project which
apply @safe or final or @nogc or whatever. You can no longer search or grep
for an attribute like @safe to see whether it applies. Similarly, having it
be possible to alter the default attributes globally is incredibly bad IMHO.
Suddenly, whether your module compiles or not could depend on what settings
someone used for the default attributes. That should not be controlled
externally. It should be part of the module just like whether a function or
variable is const or not is part of the module and not defined externally.
IMHO, it makes no sense whatsoever to have something external control
attributes any more than it makes sense to control the return types or
constness of symbols externally. That should be part of the
declarations/definitions of the symbols in question. And slapping something
like @safe: at the top of the module solves the problem of applying
attributes to an entire module right now just fine except for the fact that
you can't negate attributes, meaning that aside from the few that have
multiple states (namely, the @safety and access level attributes), you can't
alter the attributes on specific functions if you mark the whole module with
a particular attribute. So, we really should have a solution for negating
attributes, but I don't at all agree that the rest of what DIP 1012 is
trying to do is beneficial.

I honestly think that what DIP 1012 is trying to do beyond making it
possible to negate attributes is going to make the language worse and code
harder to maintain. Yes, it will enable some things that you can't do now,
but for the most part, I don't think that those things should be enabled. I
don't want to have to deal with folks complaining that my library doesn't
work right, because they tried a different default for the attributes with
it. I don't want to have to worry about trying to get someone else's code to
work because they assumed something about the default attributes that does
not hold in my case. I don't want to have to track down every custom
attribute that someone came up with just to see whether they actually apply
attributes like @safe or nothrow, just so that I can see whether those
attributes apply. I should be able to look at a module and see which
attributes have been applied to the functions in that module without having
to go searching elsewhere.

IMHO, what needs to be solved with the built-in attributes, is the ability
to negate the ones that don't have multiple states. With that, what we have
now will work just fine. The rest is completely undesirable.

- Jonathan M Davis

Re: Exception chaining and collectException

[Walter Bright via Digitalmars-d]

On 8/18/2017 2:09 AM, Don Clugston wrote:
I invested quite a lot personally in implementing chained exceptions. But I 
agree with you.
I was actually quite proud that I worked out the nasty corner cases during the 
initial implementation. As far as I can tell, problems with chained exceptions 
are not because of bugs and implementation issues, but because of problems with 
the concept itself.


I think it's just a bit too clever.


Thanks for the explanation. When I decided to support Dwarf exceptions, I spent 
a lot of time trying to match that behavior.


We've all invested lots of time in things that didn't pay off. We mustn't get 
trapped by the sunk cost fallacy:


https://en.wikipedia.org/wiki/Sunk_cost

and I'm glad you're ok with that!

Re: Exception chaining and collectException

[Walter Bright via Digitalmars-d]

On 8/18/2017 5:07 AM, Steven Schveighoffer wrote:

If we are to remove them, what happens when exceptions would normally chain?


In C++, throwing an exception while unwinding is a fatal error.

More information:

https://stackoverflow.com/questions/130117/throwing-exceptions-out-of-a-destructor

Re: real simple delegate question.

[angel via Digitalmars-d-learn]

On Friday, 18 August 2017 at 02:38:15 UTC, WhatMeForget wrote:


Can someone explain what is the difference between the two? 
Thanks.


module gates;
import std.stdio;
import std.random;

alias Calculator = int delegate(int);

Calculator makeCalculator()
{
static int context = 0;
int randy = uniform(1, 7);
context++;
writeln("context = ", context);
writeln("randy = ", randy);
return value => context + randy + value;
}

void main()
{
for (int i = 0; i < 3; i++)
{
auto calculator = makeCalculator();
writeln("The result of the calculation: ", 
calculator(0));

}
}
returns:
context = 1
randy = 5
The result of the calculation: 6
context = 2
randy = 2
The result of the calculation: 4
context = 3
randy = 6
The result of the calculation: 9

while the following

void main()
{
auto calculator = makeCalculator();  // thought just one 
would work

for (int i = 0; i < 3; i++)
{
writeln("The result of the calculation: ", 
calculator(0));

}
}
returns:
The result of the calculation: 3
The result of the calculation: 3
The result of the calculation: 3


This actually appears correct ...
The 1-st example:
Each call to makeCalculator() increments a static (i.e. shared 
among all makeCalculator() instances) variable - context.

In addition, makeCalculator() generates a random variable.
Whereas the delegate merely captures these variables, and the 
displayed results reflect this.


The 2-nd example:
There is a single call to makeCalculator().
After this call, context == 1, randy == _apparently 2_.
Now the delegate, as has already been said, merely captures these 
values, so consecutive calls do not change the result.

Re: Beta 2.076.0

[user1234 via Digitalmars-d-announce]

On Friday, 18 August 2017 at 16:52:51 UTC, Martin Nowak wrote:

On 08/18/2017 02:58 PM, Martin Nowak wrote:

First beta for the 2.076.0 release.

This release comes with various phobos additions and lots of 
improvements for -betterC (changelog entry upcoming).


This release will also come with static foreach, see 
https://github.com/dlang/dmd/pull/6760 and 
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1010.md.


Also none of the pull requests for the dlang.org repository seems 
to formalize the changes added by `static foreach`:


https://github.com/dlang/dlang.org/pulls?utf8=%E2%9C%93=is%3Apr%20%22static%20foreach%22%20

Maybe someone could ping the author of the feature ?

Re: @safe(bool)

[Timon Gehr via Digitalmars-d]

On 18.08.2017 17:16, bitwise wrote:

On Friday, 18 August 2017 at 01:43:42 UTC, Jonathan M Davis wrote:

[...]

- Jonathan M Davis


Makes sense to me.

The first question that comes to mind is if the extra generality 
provided by DIP 1012 is actually useful, let alone, worth breaking 
changes. The rationale section of the DIP only mentions negating 
attributes, which is easily accomplished with what I suggested. Unless 
that section is expanded with additional practical use cases, then it 
doesn't seem worth the trouble to me.

...


It's a vastly better design, because it does not try to overfit to a 
single use case. E.g. it allows abstracting over attributes. You can 
have an alias that contains sequences of attributes and then apply the 
summary:


alias naughty = AliasSeq!(impure,system,throws,gc);
alias nice = AliasSeq!(pure,safe,nothrow,nogc);

@nice void foo();
@naughty void bar();


The DIP mentions tagging a module declaration with default attributes. 
If the whole purpose of the DIP is to allow for negating attributes, why 
would you even need this change, when the DIP would effectively make it 
ok to put "@nogc: @safe: @etc:" at the top of the file?


My suggestion does not cover "inferred" as discussed in the DIP, but 
that could be achieved by letting something like "@default" reset all 
attributes for a given symbol.


I'll concede that DIP1012 makes more logical sense than the current 
state of things, but it seems like something that would be best achieved 
during a transition to a subsequent language version. It seems 
commonplace here, to discard suggestions based on their current 
viability, when it may be better to add them to a feature backlog that 
could be considered when talking about the possibility of a D3.





There are non-awkward backwards-compatible ways to implement DIP 1012.

[Issue 14246] RAII - proper destruction of partially constructed objects/structs

[via Digitalmars-d-bugs]

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

--- Comment #11 from github-bugzi...@puremagic.com ---
Commit pushed to stable at https://github.com/dlang/dlang.org

https://github.com/dlang/dlang.org/commit/45ca5e35d3de824e104c3049083eb23fa03775c5
Remove wrong changelog entry

The fix for issue 14246 was reverted, it is not included in 2.075.0
(see bugzilla page for details), and the issue has been reopened.

--

Re: GtkD: How to respond to cell edit's?

[Johnson via Digitalmars-d-learn]

On Friday, 18 August 2017 at 17:06:42 UTC, Mike Wey wrote:

On 18-08-17 02:30, Johnson Jones wrote:

On Friday, 18 August 2017 at 00:27:05 UTC, Johnson Jones wrote:

[...]


Obvious it is easy when you have ID's, but this is meant for 
the original case where I'm not using ID's.


A far as i can tell using id's is the only option.

You can use a templated function as a delegate:

```
void cb(int column)(string index, string text, CellRendererText 
r)

{
writeln(column, " - ", index, " - ", text);
}

RT1.addOnEdited(!1);
RT2.addOnEdited(!2);
RT2.addOnEdited(!3);
```


Thanks! Hopefully that will help ease the pain and help avoid the 
large switch statement ;) It's strange one can't get the 
cellrenderers's from a column ;/

Re: LDC, ARM: unnecessary default initialization

[kinke via Digitalmars-d]

On Friday, 18 August 2017 at 12:09:04 UTC, kinke wrote:

On Friday, 18 August 2017 at 09:42:25 UTC, Jack Applegame wrote:
For some reason, the LDC default initializes the structure, 
even if initialization of all its members is specified as 
void. I believe that this is wrong.


Afaik, this has been brought up multiple times already and is 
so by design. Every aggregate has an init symbol, omitting that 
(and accordingly the default initialization of all instances) 
by initializing each field with void doesn't work. The 
initialization isn't performed fieldwise, but is a bitcopy of 
T.init.
You can skip initialization of specific instances though - `S s 
= void;` - but again not if `s` is a field of another aggregate.


Sorry, I forgot some workaround code:

void ResetHandler() {
Foo foo = void;
foo.__ctor(10);
// or: std.conv.emplace(, 10);
}

Re: GtkD: How to respond to cell edit's?

[Mike Wey via Digitalmars-d-learn]

On 18-08-17 02:30, Johnson Jones wrote:

On Friday, 18 August 2017 at 00:27:05 UTC, Johnson Jones wrote:
I should also mention that when I use an ID to do what I want(again, 
something I don't want to do), I also need to get the column that was 
edited. This is because I'm using one delegate for all the edits.



auto cb = delegate(string index, string text, CellRendererText r)
{
// How to get the column of that we are editing? An index would be 
fine.

writeln(index, " - ", text);
};

RT1.addOnEdited(cb);
RT2.addOnEdited(cb);
RT2.addOnEdited(cb);

Looks like I might have to use separate edit handlers ;/

I wonder if I can somehow template it so I can do something like


RT1.addOnEdited(cb!1);
RT2.addOnEdited(cb!2);
RT2.addOnEdited(cb!3);

without having to write a bunch of code to make it happen. Maybe there 
is a library function that can help?


Obvious it is easy when you have ID's, but this is meant for the 
original case where I'm not using ID's.


A far as i can tell using id's is the only option.

You can use a templated function as a delegate:

```
void cb(int column)(string index, string text, CellRendererText r)
{
writeln(column, " - ", index, " - ", text);
}

RT1.addOnEdited(!1);
RT2.addOnEdited(!2);
RT2.addOnEdited(!3);
```

--
Mike Wey

Re: Beta 2.076.0

[Martin Nowak via Digitalmars-d-announce]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 08/18/2017 02:58 PM, Martin Nowak wrote:
> First beta for the 2.076.0 release.
> 
> This release comes with various phobos additions and lots of 
> improvements for -betterC (changelog entry upcoming).

This release will also come with static foreach, see
https://github.com/dlang/dmd/pull/6760 and
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1010.md.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEpzRNrTw0HqEtE8TmsnOBFhK7GTkFAlmXG2IACgkQsnOBFhK7
GTlSbw//Xi4MkU1XFBrLeWTU64pMf0qmH/Tue6nyUMwo/ipb1lGFEFEq3CZBFDSZ
rqMt1trthFj4wlh9VDy+WMP69rlVOwUxCAXHACjsVNkgBoYa2rxWSMxR8N8bEx8E
A8zYKKQhuxBcTHraBC52HoCk6ObA4k/PInp0y3qwhvNomRjJW4qyBXxH0D1NR57O
cLpR+5cslQ0Sk7WaGf1rFa327xs0h1IChHWogsxNimC/kL85ZoPs6m5aqcTE+Zxu
It6dw5jBnIb0EiX+yH11XGva9Q8cO5822rFIvN6KaWkc4na22LgUlAzo7uGLuD+B
1lbJgJRCY/LF2SN3XdlH2N2wXrwQBf/83xtCDTY1/5HJK+r15BYDTcShLTNPc/o3
200/aJCfQAyn758N0n2Rsr9vyFjjt8Vo4j9UJ4YQW8wwvmSjr9uWFGf1rPs0hUpQ
LICccthbZqA51EZZohkvCRZPTviz8fRKeqqzXIbEyiNhvdiU80V94Nzg24r9P1my
x2dwb0NWZHdiim6XzN7luBbDQ1ReYitb2qEVIeGytek07obej9OUOR5hUy5YLCtq
+ATi2RIL+13PkzGLC6JfXoOLEZ2LpCjtau1m2QpcN14ImS5QBPNJ/l0DQ1Qj/6bb
cAyV4lUGNvVHVLtB3n49kVKI031ASEZWiHJAErECkJQiQSk8T8c=
=JM9b
-END PGP SIGNATURE-

Re: Different Output after each execution

[Moritz Maxeiner via Digitalmars-d-learn]

On Friday, 18 August 2017 at 15:46:13 UTC, Vino.B wrote:
On Friday, 18 August 2017 at 11:24:24 UTC, Moritz Maxeiner 
wrote:
On Friday, 18 August 2017 at 10:50:28 UTC, Moritz Maxeiner 
wrote:

On Friday, 18 August 2017 at 10:06:04 UTC, Vino wrote:

On Friday, 18 August 2017 at 08:34:39 UTC, ikod wrote:

On Friday, 18 August 2017 at 08:00:26 UTC, Vino.B wrote:

Hi All,

 I have written a small program to just list the 
directories, but when i run the program each time i am 
getting different output, hence request you help, below is 
the code


[...]


Do you expect some strict execution order when you run 
'parallel' foreach?


Yes, the order of execution should be the same as the order 
of the directory provided to scan.


Then you cannot parallelize the work[1], use:

---
auto dFiles = dirEntries(Dirlist[i], 
SpanMode.shallow).filter!(a => a.isDir);

foreach (d; dFiles)
{
writefln("%-63s %.20s", d, 
d.timeCreated().toSimpleString);

}
---

[1] You cannot parallelize computations that depend on each 
other, which you make yours do by requiring a specific order 
of execution.


Small correction: You *could* parallelize the conversion to 
string `d.timeCreated().toSimpleString`, but then you'd need 
to merge the resulting sets of strings generated in each work 
unit to regain the original order.


Hi,
  Thank you very much, it worked and need one more help, with 
the below line i am able to list all directories which contains 
the pattern *DND*, now i need the revers, list all the  
directories expect those containing the pattern *DND*.


dirEntries(i, SpanMode.shallow).filter!(a => a.isDir).filter!(a 
=> globMatch(a.baseName, "*DND*"))


Negating the filtering rule should yield you the inverse set:

---
dirEntries(i, SpanMode.shallow).filter!(a => a.isDir).filter!(a 
=> !globMatch(a.baseName, "*DND*"))

---

Also I don't see a reason to use two filter invocations here, you 
can join the conditions to a single filter (same for the 
unnegated one):


---
dirEntries(i, SpanMode.shallow).filter!(a => a.isDir && 
!globMatch(a.baseName, "*DND*"))

---

Re: Different Output after each execution

[Vino.B via Digitalmars-d-learn]

On Friday, 18 August 2017 at 11:24:24 UTC, Moritz Maxeiner wrote:
On Friday, 18 August 2017 at 10:50:28 UTC, Moritz Maxeiner 
wrote:

On Friday, 18 August 2017 at 10:06:04 UTC, Vino wrote:

On Friday, 18 August 2017 at 08:34:39 UTC, ikod wrote:

On Friday, 18 August 2017 at 08:00:26 UTC, Vino.B wrote:

Hi All,

 I have written a small program to just list the 
directories, but when i run the program each time i am 
getting different output, hence request you help, below is 
the code


[...]


Do you expect some strict execution order when you run 
'parallel' foreach?


Yes, the order of execution should be the same as the order 
of the directory provided to scan.


Then you cannot parallelize the work[1], use:

---
auto dFiles = dirEntries(Dirlist[i], 
SpanMode.shallow).filter!(a => a.isDir);

foreach (d; dFiles)
{
writefln("%-63s %.20s", d, d.timeCreated().toSimpleString);
}
---

[1] You cannot parallelize computations that depend on each 
other, which you make yours do by requiring a specific order 
of execution.


Small correction: You *could* parallelize the conversion to 
string `d.timeCreated().toSimpleString`, but then you'd need to 
merge the resulting sets of strings generated in each work unit 
to regain the original order.


Hi,
  Thank you very much, it worked and need one more help, with the 
below line i am able to list all directories which contains the 
pattern *DND*, now i need the revers, list all the  directories 
expect those containing the pattern *DND*.


dirEntries(i, SpanMode.shallow).filter!(a => a.isDir).filter!(a 
=> globMatch(a.baseName, "*DND*"))

Re: @safe(bool)

[bitwise via Digitalmars-d]

On Friday, 18 August 2017 at 01:43:42 UTC, Jonathan M Davis wrote:

[...]

- Jonathan M Davis


Makes sense to me.

The first question that comes to mind is if the extra generality 
provided by DIP 1012 is actually useful, let alone, worth 
breaking changes. The rationale section of the DIP only mentions 
negating attributes, which is easily accomplished with what I 
suggested. Unless that section is expanded with additional 
practical use cases, then it doesn't seem worth the trouble to me.


The DIP mentions tagging a module declaration with default 
attributes. If the whole purpose of the DIP is to allow for 
negating attributes, why would you even need this change, when 
the DIP would effectively make it ok to put "@nogc: @safe: @etc:" 
at the top of the file?


My suggestion does not cover "inferred" as discussed in the DIP, 
but that could be achieved by letting something like "@default" 
reset all attributes for a given symbol.


I'll concede that DIP1012 makes more logical sense than the 
current state of things, but it seems like something that would 
be best achieved during a transition to a subsequent language 
version. It seems commonplace here, to discard suggestions based 
on their current viability, when it may be better to add them to 
a feature backlog that could be considered when talking about the 
possibility of a D3.

Re: Named multi-imports

[Olivier FAURE via Digitalmars-d]

On Friday, 18 August 2017 at 09:18:42 UTC, Timon Gehr wrote:

Any downsides?


...

- It introduces a new type that would not really be necessary. 
This is avoidable, at the cost of a little more verbosity:




D newbie here: is there a non-negligible cost to creating a 
stateless struct type?


Also, since the struct is private and only used for its aliases, 
if there a chance the compiler might elide those costs?

Re: Beta 2.076.0

[jmh530 via Digitalmars-d-announce]

On Friday, 18 August 2017 at 12:58:18 UTC, Martin Nowak wrote:

First beta for the 2.076.0 release.

This release comes with various phobos additions and lots of 
improvements for -betterC (changelog entry upcoming).


http://dlang.org/download.html#dmd_beta 
http://dlang.org/changelog/2.076.0.html


Please report any bugs at https://issues.dlang.org

- -Martin


The changelog also has two mentions of static foreach bugs, but 
nothing else about it.

Re: Named multi-imports

[jmh530 via Digitalmars-d]

On Friday, 18 August 2017 at 09:18:42 UTC, Timon Gehr wrote:

---
module util;

// ...

template Imports(T...){
import std.string,std.algorithm;
mixin([T].map!(x=>"public import "~x~";").join);
// or, starting from DMD 2.076, you could use static 
foreach instead:

// static foreach(x;T) mixin("public import "~x~";");
}

// ...



The static foreach is nice...doesn't depend on phobos.

Need help with units library

[alexander1974 via Digitalmars-d-learn]

I want to write a library for working with units (lengths, 
weights, ...). It should allow maths and converting with/between 
different units (cm to mm, angstrom to meter, ...).


The SI Sytem consists of the base units for length (meter), mass 
(kg), time (second) ,... and the prefixes like yotta (10²⁴) to 
femto (10⁻¹⁵).


enum for the prefixes

enum prefix {
  ...
  c = -2, /// for centi
  m = -3, /// for mili
  ...
}

enum for different units

enum unit { length, weight, ... }

I take a struct to define the units

struct units (T) {
  T _value; /// the value (eg 10)
  prefix _pre;  /// the SI-prefix (eg. c for cm)
  unit _unit;   /// the unit like length or weight to keep them 
apart

};

to keep it simple maybe functions could help (also with ifti)

auto cm (T) (T value) { return units!T(value, prefix.c, 
unit.length); }


conversion within a unit is simple comparing the prefixes:

real conv (prefix lhs, prefix rhs) {
  import std.math:pow;
  int c = rhs - lhs;
  return pow(10.0,c);
}

math could be done with opBinary overloading in the struct

auto opBinary(string op)(length rhs)
  {
return mixin("units(_value "~op~" 
rhs._value*conv(pre,rhs.pre),_pre, _unit)");

  }
auto opBinary(string op)(T rhs) if (isNumeric!T)
  {
return mixin("units(_value "~op~" rhs,_pre,_unit)");
  }

What do you think about the layout so far?
Is there a better way?

How to implement non-SI-units?

Beta 2.076.0

[Martin Nowak via Digitalmars-d-announce]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

First beta for the 2.076.0 release.

This release comes with various phobos additions and lots of
improvements for -betterC (changelog entry upcoming).

http://dlang.org/download.html#dmd_beta
http://dlang.org/changelog/2.076.0.html

Please report any bugs at https://issues.dlang.org

- -Martin

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEpzRNrTw0HqEtE8TmsnOBFhK7GTkFAlmW5GoACgkQsnOBFhK7
GTkcPBAAqCRVty105FDUugcl7Fr+Pxu03MeNXDcqkrdKJhoD05Oe2y6R4DEpkJfM
g+5g5JH+xrJJ2iFGNyy8RCBhMR0mYmmMeswlhH9ESFfgnEdxr4z4fbhW3UIwJpGF
ZxjvyjB5oe3pqQhAKiI66SyGU7FT7L7MZed5hs7jTXeUbeqjL0WpeBkBZysZVp/2
5dAM2bbjgNaRml3sV5PcrIHqOijWLWFMoJfuokUwv6Jlnq0cUp4r+ryy7REfHwOx
V2oOGK2fCD/hfcYURAyO++h1w7ZDWB1HuCKRaI57l5tOStreOWDXm39R/CpO03mX
wSC6N+WY88k1KxL6HON179WCb98Lk7qD+kY3Z76za9iXtyZh26/AXOlUi0TtBRw1
Reqg6ztaFos3ARUrwpn5kPmSbxHg97IvQrq2KLdEmMZUayPhh6jIXMpCIzMX4/Gk
4Rn7m7ZCIDjR6wnyIbNftKeZWSQSpUveNj6eClo4YhPj574kzzkZBkzIs1gEnDvk
QvPHL2sTr8VGTXeiKO2fGPXsxFOHiUGi351TtA7xOTF6RS9NGd828QPxFhsjI1BL
jsbDdG1cw66ZQfcZLJD/8sOdKF5vy2txUGFHLHWEf7H6aKDUliOZ1LtM/tPoV69f
5Fqa0aE2E4Jlj6AoxCn0Npdm5YFxA5XlC5ArXiqnxtkI21ZDjDw=
=V+oH
-END PGP SIGNATURE-

dmd download record

[Joakim via Digitalmars-d]

Downloads from dlang.org, which doesn't include outside distro 
packages like Arch or FreeBSD, have now jumped an order of 
magnitude over the last five years:


http://erdani.com/d/downloads.daily.png

Congrats to all those who kept their head down grinding away on 
code, including the enlightening technical debates in this forum, 
as opposed to all the armchair strategists opining "What D really 
needs is..." but not submitting any pull requests (I partake in 
such strategizing too, but I have also contributed PRs to further 
the mobile effort, for example).


Ldc has seen similar gains, look at the increased downloads over 
the last two years:


http://www.somsubhra.com/github-release-stats/?username=ldc-developers=ldc

Here's to the next order of magnitude jump!

Some news from Dplug

[Guillaume Piolat via Digitalmars-d-announce]

Some news from the audio front!

Reminder: Dplug is a convenient library for creating audio 
plug-ins (VST / AU) for Mac, Windows and now Linux.


Thanks to the effort of Richard Andrew Cattermole and Ethan 
Rekker, Dplug got Linux VST support. Ethan has written down the 
whole story here:


http://www.modernmetalproduction.com/dplug-developing-vst-plugins-for-linux/


Two audio plug-ins were released recently with Dplug:

- The M4 Multiband Compressor by Cut Through Recordings
  
http://www.modernmetalproduction.com/product/m4-multiband-compressor-vst-au/


- Graillon 2 by Auburn Sounds
  https://www.auburnsounds.com/products/Graillon.html

If you need a high performance 1D FFT, pfft the impressive work 
of Jernej Krempuš has been ported to DUB:

http://code.dlang.org/packages/pfft

Re: LDC, ARM: unnecessary default initialization

[kinke via Digitalmars-d]

On Friday, 18 August 2017 at 09:42:25 UTC, Jack Applegame wrote:
For some reason, the LDC default initializes the structure, 
even if initialization of all its members is specified as void. 
I believe that this is wrong.


Afaik, this has been brought up multiple times already and is so 
by design. Every aggregate has an init symbol, omitting that (and 
accordingly the default initialization of all instances) by 
initializing each field with void doesn't work. The 
initialization isn't performed fieldwise, but is a bitcopy of 
T.init.
You can skip initialization of specific instances though - `S s = 
void;` - but again not if `s` is a field of another aggregate.

Re: Exception chaining and collectException

[Steven Schveighoffer via Digitalmars-d]

On Friday, 18 August 2017 at 03:31:38 UTC, Walter Bright wrote:
Chained exceptions are a good idea, but are more or less a 
disaster:


1. No other language does chained exceptions

2. Attempting to hammer D chained exceptions into other 
language schemes (such as C++) makes for lots of unfun hours 
attempting to decode undocumented behavior in those other 
schemes


3. Makes D exceptions incompatible with other language 
exceptions and their infrastructure


4. Are incomprehensibly implemented (I defy anyone to explain 
how the test cases in the test suite are actually supposed to 
work)


5. Are more or less incompatible with non-GC memory allocation

I'd like to remove them from D.

I recommend *not* designing any program that requires them.


If we are to remove them, what happens when exceptions would 
normally chain?


-Steve

[Issue 15831] IFTI voldemort type exploding bloat

[via Digitalmars-d-bugs]

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

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--

[Issue 15831] IFTI voldemort type exploding bloat

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/c272eb830597efcc8fe75c7e1c9791c512a08727
fix issue 15831: mangle back references for types and identifiers

--

Re: Exception chaining and collectException

[jmh530 via Digitalmars-d]

On Friday, 18 August 2017 at 09:09:47 UTC, Don Clugston wrote:


Secondly, exception handling in windows is practically 
undocumented. Certainly it's not documented in a single place. 
When I began to implement it, I feared it might be impossible. 
There isn't any guarantee that exception chaining can actually 
be implemented on all platforms.


I had actually tested the above on Windows with DMD 2.075.1 and 
got the expected behavior, not the buggy behavior.




I invested quite a lot personally in implementing chained 
exceptions. But I agree with you.
I was actually quite proud that I worked out the nasty corner 
cases during the initial implementation. As far as I can tell, 
problems with chained exceptions are not because of bugs and 
implementation issues, but because of problems with the concept 
itself.


I think it's just a bit too clever.


Do you mind pointing me in the direction of where chained 
exceptions are explained?

Re: Different Output after each execution

[Moritz Maxeiner via Digitalmars-d-learn]

On Friday, 18 August 2017 at 10:50:28 UTC, Moritz Maxeiner wrote:

On Friday, 18 August 2017 at 10:06:04 UTC, Vino wrote:

On Friday, 18 August 2017 at 08:34:39 UTC, ikod wrote:

On Friday, 18 August 2017 at 08:00:26 UTC, Vino.B wrote:

Hi All,

 I have written a small program to just list the 
directories, but when i run the program each time i am 
getting different output, hence request you help, below is 
the code


[...]


Do you expect some strict execution order when you run 
'parallel' foreach?


Yes, the order of execution should be the same as the order of 
the directory provided to scan.


Then you cannot parallelize the work[1], use:

---
auto dFiles = dirEntries(Dirlist[i], 
SpanMode.shallow).filter!(a => a.isDir);

foreach (d; dFiles)
{
writefln("%-63s %.20s", d, d.timeCreated().toSimpleString);
}
---

[1] You cannot parallelize computations that depend on each 
other, which you make yours do by requiring a specific order of 
execution.


Small correction: You *could* parallelize the conversion to 
string `d.timeCreated().toSimpleString`, but then you'd need to 
merge the resulting sets of strings generated in each work unit 
to regain the original order.

Re: Different Output after each execution

[Moritz Maxeiner via Digitalmars-d-learn]

On Friday, 18 August 2017 at 10:06:04 UTC, Vino wrote:

On Friday, 18 August 2017 at 08:34:39 UTC, ikod wrote:

On Friday, 18 August 2017 at 08:00:26 UTC, Vino.B wrote:

Hi All,

 I have written a small program to just list the directories, 
but when i run the program each time i am getting different 
output, hence request you help, below is the code


[...]


Do you expect some strict execution order when you run 
'parallel' foreach?


Yes, the order of execution should be the same as the order of 
the directory provided to scan.


Then you cannot parallelize the work[1], use:

---
auto dFiles = dirEntries(Dirlist[i], SpanMode.shallow).filter!(a 
=> a.isDir);

foreach (d; dFiles)
{
writefln("%-63s %.20s", d, d.timeCreated().toSimpleString);
}
---

[1] You cannot parallelize computations that depend on each 
other, which you make yours do by requiring a specific order of 
execution.

[Issue 17761] dmd 2.075.1 creates object files that can't be linked by ld.bfd

[via Digitalmars-d-bugs]

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

--- Comment #1 from Atila Neves  ---
I forgot to add: this is a regression from dmd 2.074.1 - that version builds
fine.

--

[Issue 17761] New: dmd 2.075.1 creates object files that can't be linked by ld.bfd

[via Digitalmars-d-bugs]

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

  Issue ID: 17761
   Summary: dmd 2.075.1 creates object files that can't be linked
by ld.bfd
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: atila.ne...@gmail.com

ld.gold works fine.

To reproduce:

$ git clone g...@github.com:atilaneves/reggae.git
$ dub test

/usr/bin/ld:
.dub/build/unittest-unittest-linux.posix-x86_64-dmd_2075-77175E7974DDAEB08859943E222FA38D/ut.o:
SHT_GROUP section [index 26312] has no SHF_GROUP sections
/usr/bin/ld:
.dub/build/unittest-unittest-linux.posix-x86_64-dmd_2075-77175E7974DDAEB08859943E222FA38D/ut.o:
SHT_GROUP section [index 26313] has no SHF_GROUP sections
/usr/bin/ld:
.dub/build/unittest-unittest-linux.posix-x86_64-dmd_2075-77175E7974DDAEB08859943E222FA38D/ut.o:
SHT_GROUP section [index 26312] has no SHF_GROUP sections
/usr/bin/ld:
.dub/build/unittest-unittest-linux.posix-x86_64-dmd_2075-77175E7974DDAEB08859943E222FA38D/ut.o:
SHT_GROUP section [index 26313] has no SHF_GROUP sections
/usr/bin/ld:
.dub/build/unittest-unittest-linux.posix-x86_64-dmd_2075-77175E7974DDAEB08859943E222FA38D/ut.o:
SHT_GROUP section [index 26312] has no SHF_GROUP sections
/usr/bin/ld:
.dub/build/unittest-unittest-linux.posix-x86_64-dmd_2075-77175E7974DDAEB08859943E222FA38D/ut.o:
SHT_GROUP section [index 26313] has no SHF_GROUP sections
/usr/bin/ld:
.dub/build/unittest-unittest-linux.posix-x86_64-dmd_2075-77175E7974DDAEB08859943E222FA38D/ut.o:
SHT_GROUP section [index 26312] has no SHF_GROUP sections
/usr/bin/ld:
.dub/build/unittest-unittest-linux.posix-x86_64-dmd_2075-77175E7974DDAEB08859943E222FA38D/ut.o:
SHT_GROUP section [index 26313] has no SHF_GROUP sections
.dub/build/unittest-unittest-linux.posix-x86_64-dmd_2075-77175E7974DDAEB08859943E222FA38D/ut.o:
file not recognized: File format not recognized

--

Re: Different Output after each execution

[Vino via Digitalmars-d-learn]

On Friday, 18 August 2017 at 08:34:39 UTC, ikod wrote:

On Friday, 18 August 2017 at 08:00:26 UTC, Vino.B wrote:

Hi All,

 I have written a small program to just list the directories, 
but when i run the program each time i am getting different 
output, hence request you help, below is the code


[...]


Do you expect some strict execution order when you run 
'parallel' foreach?


Yes, the order of execution should be the same as the order of 
the directory provided to scan.

Re: D books for $5

[Kai Nacke via Digitalmars-d-announce]

On Thursday, 3 August 2017 at 21:36:09 UTC, Michael wrote:

On Friday, 16 December 2016 at 05:43:02 UTC, Kai Nacke wrote:

Hi all,

Packt Publishing offers eBooks for $5 for a limited time. If 
your collection of D eBooks is still incomplete then this is a 
great chance for you. :-)


D Cookbook by Adam D. Ruppe 
(https://www.packtpub.com/application-development/d-cookbook)
Learning D by Michael Parker 
(https://www.packtpub.com/application-development/learning-d)
D Web Development by myself 
(https://www.packtpub.com/web-development/d-web-development)


Regards,
Kai


Any chance the print books are going on sale? I buy too many 
books as a student but would love to learn web dev in D.


I think you can buy the eBook (when offered cheap as recently) 
and then use the "Upgrade to Print" option. This gives 50% on the 
print book. I know no other option.


Regards,
Kai

LDC, ARM: unnecessary default initialization

[Jack Applegame via Digitalmars-d]

I explore the possibility of using D for bare metal ARM 
programming.


For some reason, the LDC default initializes the structure, even 
if initialization of all its members is specified as void. I 
believe that this is wrong.


test.d

module test;

import core.bitop : volatileStore;

struct Foo {
uint[64] m = void; // no default initialization
this(uint a) {
foreach(ref b; m) volatileStore(,a++);
}
}

void ResetHandler() {
auto foo = Foo(10);
}


$ldc2 -mtriple=thumb-none-linux-eabi -mcpu=cortex-m3 -c --betterC 
--boundscheck=off -relocation-model=static -O3 -vcolumns test.d


test.o assembly

 <_D4test12ResetHandlerFZv>:
   0:   b510push{r4, lr}
   2:   b0c0sub sp, #256; 0x100 -+
   4:   466cmov r4, sp   | 
default initialization

   6:   f44f 7180   mov.w   r1, #256; 0x100  |
   a:   4620mov r0, r4   | WHY???
   c:   f7ff fffe   bl  0 <__aeabi_memclr4> -+
  10:   2000movsr0, #0
  12:   f100 010a   add.w   r1, r0, #10
  16:   f844 1020   str.w   r1, [r4, r0, lsl #2]
  1a:   3001addsr0, #1
  1c:   2949cmp r1, #73 ; 0x49
  1e:   d1f8bne.n   12 <_D4test12ResetHandlerFZv+0x12>
  20:   b040add sp, #256; 0x100
  22:   bd10pop {r4, pc}
*

Re: Named multi-imports

[Timon Gehr via Digitalmars-d]

On 18.08.2017 03:11, Johnson Jones wrote:




private struct oo{
import std.stdio: writeln, write;
import std.algorithm: filter, map;
// …
}

void main(){
oo.write("result: ");
oo.writeln(oo.map!(x=>x/2)(oo.filter!(x=>x%2==0)([1,2,3,4,5,6,10])));
}


Wow, that might solve the problem! A little more verbose but it does 
combine everything.


Any downsides?



- It is more verbose. ;)


- IMAO it shouldn't even work without 'public' on the imports. (So if 
someone decides to fix that it might break and become more verbose.)



- It introduces a new type that would not really be necessary. This is 
avoidable, at the cost of a little more verbosity:



private template Imports(){
public import std.stdio: writeln, write;
public import std.algorithm: filter, map;
}
private alias oo = Imports!();

void main(){
oo.write("result: ");
oo.writeln(oo.map!(x=>x/2)(oo.filter!(x=>x%2==0)([1,2,3,4,5,6,10])));
}


The pattern can be abstracted into a utility template:

---
module util;

// ...

template Imports(T...){
import std.string,std.algorithm;
mixin([T].map!(x=>"public import "~x~";").join);
// or, starting from DMD 2.076, you could use static foreach instead:
// static foreach(x;T) mixin("public import "~x~";");
}

// ...

---

---
module main;

import util: Imports;
private alias oo = Imports!(
`std.stdio: writeln, write`,
`std.algorithm: filter, map`
);

void main(){
oo.write("result: ");
oo.writeln(oo.map!(x=>x/2)(oo.filter!(x=>x%2==0)([1,2,3,4,5,6,10]))); 
}
---



Thanks.


np.

Re: Exception chaining and collectException

[Don Clugston via Digitalmars-d]

On Friday, 18 August 2017 at 03:31:38 UTC, Walter Bright wrote:
Chained exceptions are a good idea, but are more or less a 
disaster:


1. No other language does chained exceptions

2. Attempting to hammer D chained exceptions into other 
language schemes (such as C++) makes for lots of unfun hours 
attempting to decode undocumented behavior in those other 
schemes


3. Makes D exceptions incompatible with other language 
exceptions and their infrastructure


4. Are incomprehensibly implemented (I defy anyone to explain 
how the test cases in the test suite are actually supposed to 
work)


Well, I wrote them, so I can explain that. The problem is that 
the idea that you can form a "chain" of exceptions turns out to 
be naive.


What if a chained exception needs to get chained to another 
chained exception? And that then needs to be chained to another 
exception?

It forms a tree! That's why the test cases are so complicated.

So to a large extent, this extremely obscure corner case destroys 
the elegance of the concept.


Secondly, exception handling in windows is practically 
undocumented. Certainly it's not documented in a single place. 
When I began to implement it, I feared it might be impossible. 
There isn't any guarantee that exception chaining can actually be 
implemented on all platforms.



5. Are more or less incompatible with non-GC memory allocation

I'd like to remove them from D.

I recommend *not* designing any program that requires them.


I invested quite a lot personally in implementing chained 
exceptions. But I agree with you.
I was actually quite proud that I worked out the nasty corner 
cases during the initial implementation. As far as I can tell, 
problems with chained exceptions are not because of bugs and 
implementation issues, but because of problems with the concept 
itself.


I think it's just a bit too clever.

When using the -profile flag is it known behaviour that phobos unit tests fail?

[firosiro via Digitalmars-d]

When using the -profile flag is it known behaviour that phobos 
unit tests fail?


(Ubuntu 16.04 - DMD64 D Compiler v2.071.0)

For example, when following these steps I get a failed unit test:

$ cd /usr/include/dmd/phobos/std/
$ rdmd -I/usr/include/dmd/phobos/std 
-I/usr/include/dmd/phobos/core -main -unittest -profile format.d

Re: Named multi-imports

[Timon Gehr via Digitalmars-d]

On 18.08.2017 01:25, jmh530 wrote:

On Thursday, 17 August 2017 at 21:49:38 UTC, Timon Gehr wrote:


private struct oo{
import std.stdio: writeln, write;
import std.algorithm: filter, map;
// …
}

void main(){
oo.write("result: ");
oo.writeln(oo.map!(x=>x/2)(oo.filter!(x=>x%2==0)([1,2,3,4,5,6,10])));
}


Would not have thought to do that! Very cool.

Quick follow up: is there a reason this why renamed selective imports 
don't work this way?


I don't think there is. (I.e. I think it is indeed a bug.)


As in the bug from the link below we discussed above

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

Re-writing the import like this seems like the perfect bug fix?


It's one way to do it, but the compiler does not necessarily need to 
generate a new type. Note that unfortunately, renamed imports don't 
overload, so this would not work even with the fixed bug:


import oo=std.stdio: writeln, write;
import oo=std.algorithm: filter, map; // error: oo redefined

void main(){
oo.write("result: ");
oo.writeln(oo.map!(x=>x/2)(oo.filter!(x=>x%2==0)([1,2,3,4,5,6,10])));
}

I think this is working as designed, but IMO they should just overload 
(using distinct overload sets so the semantics is similar to the case 
when using the struct), as should named mixins.

Re: Different Output after each execution

[ikod via Digitalmars-d-learn]

On Friday, 18 August 2017 at 08:00:26 UTC, Vino.B wrote:

Hi All,

 I have written a small program to just list the directories, 
but when i run the program each time i am getting different 
output, hence request you help, below is the code


[...]


Do you expect some strict execution order when you run 'parallel' 
foreach?

Different Output after each execution

[Vino.B via Digitalmars-d-learn]

Hi All,

 I have written a small program to just list the directories, but 
when i run the program each time i am getting different output, 
hence request you help, below is the code


Program:
import std.file: dirEntries, isFile, SpanMode, remove;
import std.stdio: writefln;
import std.algorithm: filter;
import std.parallelism: parallel;
import std.array: array;
import std.datetime;

auto AgedDirlst = [ "C:\\Temp\\TEAM", "C:\\Temp\\PROD_TEAM", 
"C:\\Temp\\BACKUP", "C:\\Temp\\EXPORT", 
"C:\\Temp\\sapnas3\\BACKUP", "C:\\Temp\\EXPORT"];



void AgedDir (string[] Dirlist)
{
 for (auto i = 0; i < Dirlist.length; ++i)
 {
  auto dFiles = dirEntries(Dirlist[i], 
SpanMode.shallow).filter!(a => a.isDir);

  foreach (d; parallel(dFiles , 1))
  {
writefln("%-63s %.20s", d, 
d.timeCreated().toSimpleString);
  }
 }
}

void main ()
{
 AgedDir(AgedDirlst);
}

If i replace the line(.isDir to .isFile) "auto dFiles = 
dirEntries(Dirlist[i], SpanMode.shallow).filter!(a => a.isDir)" 
to auto dFiles = dirEntries(Dirlist[i], 
SpanMode.shallow).filter!(a => a.isFile), then is it working 
perfectly.


From,
Vino.B
Output
C:\Users\Admin\Desktop\Script\D>rdmd AgedDir.d
C:\Temp\TEAM\DIR1   
2017-Aug-16 18:49:21
C:\Temp\TEAM\DIR1   
2017-Aug-16 18:49:21
C:\Temp\TEAM\DND1   
2017-Jun-30 21:02:09
C:\Temp\TEAM\DIR2   
2017-Jun-29 23:21:36
C:\Temp\TEAM\DND5   
2017-Jun-30 23:49:24
C:\Temp\PROD_TEAM\dir1  
2017-Jun-30 05:38:05
C:\Temp\PROD_TEAM\dir1  
2017-Jun-30 05:38:05
C:\Temp\PROD_TEAM\dir2  
2017-Jun-30 05:38:05
C:\Temp\PROD_TEAM\DND1  
2017-Jun-30 21:08:32


C:\Users\Admin\Desktop\Script\D>rdmd AgedDir.d
C:\Temp\TEAM\DIR1   
2017-Aug-16 18:49:21
C:\Temp\TEAM\DIR2   
2017-Jun-29 23:21:36
C:\Temp\TEAM\DND1   
2017-Jun-30 21:02:09
C:\Temp\TEAM\DND5   
2017-Jun-30 23:49:24
C:\Temp\PROD_TEAM\dir1  
2017-Jun-30 05:38:05
C:\Temp\PROD_TEAM\dir1  
2017-Jun-30 05:38:05
C:\Temp\PROD_TEAM\dir2  
2017-Jun-30 05:38:05
C:\Temp\PROD_TEAM\DND1  
2017-Jun-30 21:08:32


C:\Users\Admin\Desktop\Script\D>rdmd AgedDir.d
C:\Temp\TEAM\DND1   
2017-Jun-30 21:02:09
C:\Temp\TEAM\DIR1   
2017-Aug-16 18:49:21
C:\Temp\TEAM\DIR2   
2017-Jun-29 23:21:36
C:\Temp\TEAM\DND5   
2017-Jun-30 23:49:24
C:\Temp\PROD_TEAM\dir1  
2017-Jun-30 05:38:05_TEAM\dir2
C:\Temp\PROD_TEAM\dir1  
2017-Jun-30 05:38:05_TEAM\dir2

  2017-Jun-30 05:38:05
C:\Temp\PROD_TEAM\DND1  
2017-Jun-30 21:08:32


C:\Users\Admin\Desktop\Script\D>rdmd AgedDir.d
C:\Temp\TEAM\DIR1   
2017-Aug-16 18:49:21
C:\Temp\TEAM\DIR1   
2017-Aug-16 18:49:21
C:\Temp\TEAM\DND1   
2017-Jun-30 21:02:09
C:\Temp\TEAM\DIR2   C:\Temp\TEAM\DND5 
  2017-Jun-30 23:49:24
C:\Temp\TEAM\DIR2   C:\Temp\TEAM\DND5 
  2017-Jun-30 23:49:24

2017-Jun-29 23:21:36
C:\Temp\PROD_TEAM\dir1  
2017-Jun-30 05:38:05
C:\Temp\PROD_TEAM\dir1  
2017-Jun-30 05:38:05
C:\Temp\PROD_TEAM\dir2  
2017-Jun-30 05:38:05
C:\Temp\PROD_TEAM\DND1  
2017-Jun-30 21:08:32

Re: Formated Output and file creation time

[Vino.B via Digitalmars-d-learn]

On Wednesday, 16 August 2017 at 17:03:51 UTC, H. S. Teoh wrote:
On Wed, Aug 16, 2017 at 03:30:18PM +, Vino.B via 
Digitalmars-d-learn wrote: [...]

[...]


Try this:

writefln("%-36s %8s %.20s", d, d.size, d.timeCreated());


T


Hi Teoh,

Thank you very much, it worked.

Re: Problem with BP's

[Rainer Schuetze via Digitalmars-d-debugger]

On 18.08.2017 02:05, Johnson Jones wrote:

On Friday, 18 August 2017 at 00:02:23 UTC, Johnson Jones wrote:

On Thursday, 17 August 2017 at 22:41:51 UTC, Johnson Jones wrote:

I was doing something strange ;/

I had code like

mixin(import("Myfile.d"));
CallSomeFunctionInMyFile();

And no BP's could be hit in side the function call. D would say that 
there was an error in the symbols for the project.



but making MyFile.d a module(adding module MyFile; at the top) and doing

import Myfile;
CallSomeFunctionInMyFile();

Allowed the breakpoints to be hit.

I guess this is a related problem with mixin debugging, which still 
doesn't work for me. In a sense, it might be a good why to debug them 
because the file exists already and one doesn't have to have it 
generated by the compiler to debug. This should help get the symbols 
and line numbers correct and the line mappings. Might help make a 
seemless way to debug them. e.g., any BP's in Myfile.d have to be 
translated to the original file they are mixed in at and vice versa 
when debugging them(open Myfile D).


Hmm, maybe that wasn't the fix, still getting the error in some cases:

The error is "Unexpected symbol reader error while processing test.exe"

It might have been coincidence that the above change worked or it 
might be that it only partially fixed it.


What's strange about it is that delegates inside the function I'm 
calling are hit but code in the root of the function are not.


void CallSomeFunctionInMyFile()
{
addDelegate(()
{
   foo();
});

foo();
}

The first foo will break on a BP assinged to it but the second one won't.



You can try switching to the disassembly view to see where the compiler 
generated debug line numbers.


It assumes line numbers and code offsets are always ascending. Maybe 
assumption doesn't hold here.

Re: Debugging Visual D using Visual D

[Rainer Schuetze via Digitalmars-d-debugger]

On 18.08.2017 00:14, Johnson Jones wrote:

On Thursday, 17 August 2017 at 21:18:35 UTC, Johnson Jones wrote:

On Thursday, 17 August 2017 at 17:45:35 UTC, Rainer Schuetze wrote:



On 17.08.2017 19:05, Johnson wrote:

On Wednesday, 16 August 2017 at 19:35:19 UTC, Rainer Schuetze wrote:



On 16.08.2017 21:18, Johnson Jones wrote:
What's strange is that with your changes, privateregistry seems to 
use them... but it still loads the old(I think) visualD because 
when I try the debug the BP's are not hit and the module shows the 
original visualD directory.


The Visual D installer adds the extension to the VS installation 
("c:\Program Files (x86)\Microsoft Visual 
Studio\2017\Community\Common7\IDE\Extensions\Rainer 
Schuetze\VisualD") so it is immediately available for all users and 
suffixes.


You can move it to 
"%HOME%\AppData\Local\Microsoft\VisualStudio\15.0_\Extensions\Rainer 
Schuetze\VisualD" to load it only with the version without suffix. 
With both the system wide extension and the one in the "Exp" 
folder, the extension from the user folder took precedence for me, 
though.


If you run "devenv /RootSuffix Exp /Log" VS writes a log into 
"%APPDATA%\Roaming\Microsoft\VisualStudio\15.0_Exp\ActivityLog.xml" 
that also lists detected extensions.



I completely removed the `Extensions\Rainer Schuetze` directories in 
all visual studio folders that I know of:


C:\Program Files (x86)\Microsoft Visual 
Studio\2017\Enterprise\IDE\Extensions


C:\Users\Main\AppData\Local\Microsoft\VisualStudio\15.0_4d0b469e
C:\Users\Main\AppData\Local\Microsoft\VisualStudio\15.0_4d0b469eExp

Running visual studio still loads Visual D. It seems that it doesn't 
even use the visuald.pkgdef.


Obviously I have those entries in the registry. Which it seems it 
pulls from and either doesn't use the extensions folder at all on my 
system or is overridden by the registry entries? If that's the case, 
how can it be worked around? If not, what else might it be?


If visuald.pkgdef is suppose to be what visual studio uses to load 
visual D as an extension, does it import that in to the registry and 
then use the registry or does it always use the pkgdef file?(which 
doesn't seem to be the case, as, again, visual D is loading with 
visual studio without any of those pkgdef's)


What I'm afraid of is that deleting the registry keys will not do 
any good, they will just be re-imported by loading the pkgdef(or 
not, in which case Visual D won't be found at all) and then the main 
registry keys will be used for the Exp, like it is now.


Basically visual studio is not loading the pkgdef files either at 
all or only once, or every time but not allow them to overwrite the 
registry keys, or something else is going on that I can't seem to 
figure out.





I think you are right that VS imports the settings from the pkgdef 
only once, then uses the registry only.


Maybe try deleting the cache files in 
"%APPDATA%\Local\Microsoft\VisualStudio\15.0_\Extensions".


Ok, It seems to be caching. I deleted everything in the main registry 
related to visualD and ran visual studio and it was still there!


Searched on line and came up with devenv updateconfiguration, reran 
VS, and VisualD was no longer there! Ran experimental and it's still 
there!


Used the same process to remove it from Exp.

So, this surely has to be caching, although I removed all the cache 
files I could fine from both versions.


As of this point there is nothing related to visualD in the registry 
nor the VS folders as far as I can tell and both versions are not 
finding visualD.


I will copy the modified pkgdef file to the exp dir and run it: Did 
nothing, Vi sual D didn't load! Copied the original pkgdef, no go.


Seems Visual studio is not using the pkgdef in

C:\Users\Main\AppData\Local\Microsoft\VisualStudio\15.0_4d0b469eExp\Extensions\Rainer 
Schuetze\VisualD


I put the extensions folder in all the visual studio versions in that 
base dir and it didn't help(so it's not using any directory in 
C:\Users\Main\AppData\Local\Microsoft\VisualStudio).


Of course, at this point it means something is fubar'ed.

I went ahead and installed latest VD so I could get some work done. 
Seems like no problem.



So either visual studio is not doing what it's suppose to or it has 
more cache files laying around that I failed to delete, unless you see 
something different?


[Just me going step by step for reference:

I should mention that after installing the latest, Visual D also gets 
installed in the Exp version ;/ so it "magically" propagated to it.


The evidence seems to point to visual studio simply loading visual D 
from the system registry and completely bypassing everything else. It 
doesn't even look at the pkgdef's(or looked at them once and installed 
them, then uses the registry thereafter).


Does the visualD installer install registry keys? or just the pkgdef 
file and then somehow informs VS and then VS does it?


My guess is that Visual D installs the