Re: Exception chaining and collectException

[Walter Bright via Digitalmars-d]

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.

Re: @safe(bool)

[Nicholas Wilson via Digitalmars-d]

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

On Thursday, August 17, 2017 19:21:16 Timon Gehr via
That makes little sense to me, as DIP 1012 is strictly more 
general.


Whereas this solves the problem with DIP 1012 claims to be 
solving without adding a bunch of extra stuff that IMHO makes 
the built-in attributes more complicated for no real benefit as 
well as having some stuff in it that would effectively split 
the language into multiple variants where code will compile 
with some but not others (most notably, allowing for the 
default @safety level to be globally altered as opposed to 
doing something nice and portable like @safe: at the top of a 
module).


As I explained in that thread it adds very little complication, 
keyword like attributes become enum; last applied wins. If 
anything its reduces complexity as attributes, both builtin and 
user defined, become regular attributes. W.r.t global altering, I 
expect that it would be used by applications (rarely, e.g. 
embedded environments for nothrow nogc final) not libraries. It 
is also only part of the DIP.



As I explained in the initial discussion in DIP 1012,
it does a whole pile of stuff that has nothing to do with its 
stated goal, and I think that most of the other stuff that it 
does is detrimental, whereas if what's proposed here were 
implemented for more than just @safe, it would actually solve 
the stated goal of allowing attributes to be negated and thus 
fix the problem that doing something like putting final: at the 
top of a class can't be undone.


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.


Andrei previously proposed essentially what the OP proposed, 
but no DIP was ever created for it, and it's never happened. It 
probably would stand a decent chance of making it through 
though, since it solves a real problem, and Andrei has 
previously shown interest in this solution.


And there was real interest in DIP 1012, which was the whole 
reason I wrote it, and

I reject your notion that DIP 1012 does not solve a problem.

Re: C++17 Init statement for if/switch

[SrMordred via Digitalmars-d]

On Thursday, 17 August 2017 at 13:11:51 UTC, Enamex wrote:

On Wednesday, 16 August 2017 at 14:19:59 UTC, SrMordred wrote:

On Tuesday, 15 August 2017 at 21:05:09 UTC, bachmeier wrote:

[...]


There are two thinks of c++ that I miss a little on D:
- Structured binding
- Uniform initialization

But in general, I agreed with you.


Initialization in D is pretty uniform now though. What corners 
am I missing?


It's usually:

 name = (args);

Structured bindings... I think C++ did it badly, actually. They 
had the {...} syntax fr object construction that worked 
everywhere and using the same for deconstruction would've 
allowed for quite natural tuples, which manifest almost as 
language-level constructs by then (with the help of 'auto' in 
template parameters).


Nothing too serious, just miss somethings like:
void add_vec( vec2 a, vec2 b );
add_vec( {10,20}, {20,30} );

real simple delegate question.

[WhatMeForget via Digitalmars-d-learn]

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

Re: @safe(bool)

[Jonathan M Davis via Digitalmars-d]

On Thursday, August 17, 2017 19:21:16 Timon Gehr via Digitalmars-d wrote:
> On 17.08.2017 18:36, HyperParrow wrote:
> > On Thursday, 17 August 2017 at 16:32:20 UTC, bitwise wrote:
> >> This came to mind while working on a set of containers.
> >>
> >> [...]
> >> One solution could be this:
> >>
> >> struct Container(T, bool safetyOn = true)
> >> {
> >>
> >> static if(safe)
> >>
> >> RefCounted!(T[]) data;
> >>
> >> else
> >>
> >> T[] data;
> >>
> >> auto opSlice() @safe(safetyOn) {
> >>
> >> return Range(data, 0, data.length);
> >>
> >> }
> >>
> >> }
> >>
> >> A similar solution could be applied to @nogc as well.
> >
> > Yeah, i like it more than
> > https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md.
>
> That makes little sense to me, as DIP 1012 is strictly more general.

Whereas this solves the problem with DIP 1012 claims to be solving without
adding a bunch of extra stuff that IMHO makes the built-in attributes more
complicated for no real benefit as well as having some stuff in it that
would effectively split the language into multiple variants where code will
compile with some but not others (most notably, allowing for the default
@safety level to be globally altered as opposed to doing something nice and
portable like @safe: at the top of a module). As I explained in the initial
discussion in DIP 1012, it does a whole pile of stuff that has nothing to do
with its stated goal, and I think that most of the other stuff that it does
is detrimental, whereas if what's proposed here were implemented for more
than just @safe, it would actually solve the stated goal of allowing
attributes to be negated and thus fix the problem that doing something like
putting final: at the top of a class can't be undone.

Andrei previously proposed essentially what the OP proposed, but no DIP was
ever created for it, and it's never happened. It probably would stand a
decent chance of making it through though, since it solves a real problem,
and Andrei has previously shown interest in this solution.

- Jonathan M Davis

Re: Named multi-imports

[Johnson Jones via Digitalmars-d]

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

On 17.08.2017 23:03, aberba wrote:

On Wednesday, 16 August 2017 at 13:57:17 UTC, jmh530 wrote:

On Wednesday, 16 August 2017 at 09:54:41 UTC, aberba wrote:


This looks really clean for code modularity.

import io = std.stdio : {writeln, write}, ...


What does this add? A line like below would be confusing.
import io = std.stdio : {writeln, write}, writefln;

The following code compiles and the imports are less 
confusing.


import io = std.stdio : writeln, write;
import std.stdio : writefln;

void main()
{
io.write("foo");
io.writeln("bar");
writefln("My items are %(%s %).", [1,2,3]);
}


Its more like this:

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


oo.writeln();
oo.write();
oo.filter(...);
oo.map(...);



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?

Thanks.

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

[Johnson Jones via Digitalmars-d-learn]

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.

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

[Johnson Jones via Digitalmars-d-learn]

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?

GtkD: How to respond to cell edit's?

[Johnson Jones via Digitalmars-d-learn]

Trying to setup a callback that will propagate changes from a 
cell(and editable GtkCellRendererText) to my model.


Can't seem to find any way to get the actual GtkCellRendererText

CellRendererText has an addOnEdited but I can't find a way to get 
the CellRendererTExt for a TreeViewColumn ;/


All the examples I've seen create the renderer programmatically, 
while I'm using glade.


https://github.com/gtkd-developers/GtkD/blob/master/demos/gtkD/DemoMultiCellRenderer/DemoMultiCellRenderer.d

While I could ID the cell renderer in glade, I'd like to get it 
programmatically.


Any ideas?

Re: Problem with BP's

[Johnson Jones via Digitalmars-d-debugger]

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.

Re: Problem with BP's

[Johnson Jones via Digitalmars-d-debugger]

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.

Re: Named multi-imports

[jmh530 via Digitalmars-d]

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

Re: I'm the new package maintainer for D on ArchLinux

[SamwiseFilmore via Digitalmars-d-announce]

Heading over to the AUR right now! Looking forward to seeing 
those packages added to community!

Re: @safe(bool)

[Nicholas Wilson via Digitalmars-d]

On Thursday, 17 August 2017 at 18:38:40 UTC, HypperParrow wrote:

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

On 17.08.2017 18:36, HyperParrow wrote:

On Thursday, 17 August 2017 at 16:32:20 UTC, bitwise wrote:

[...]


Yeah, i like it more than 
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md.


That makes little sense to me, as DIP 1012 is strictly more 
general.


template safety(bool safetyOn){ // (this can even be in core)
static if(safetyOn) alias safety = FunctionSafety.safe;
else alias safety = FunctionSafety.system;
// else alias safety = infer!FunctionSafety; // even 
better!

}

struct Container(T, bool safetyOn = true){
static if(safe) RefCounted!(T[]) data;
else T[] data;

auto opSlice() @safety!safetyOn {
return Range(data, 0, data.length);
}
}


The application of DIP 1012 would have catastrophic effects on 
the current tooling but as usual nobody thinks to that.


How? In the Simplest terms DIP1012 replaces Keyword attributes 
with enums. Yes, libdparse would have to be updated, but that is 
the case for any substantial DIP. Hardly 'catastrophic'.

Problem with BP's

[Johnson Jones via Digitalmars-d-debugger]

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

Re: Exception chaining and collectException

[H. S. Teoh via Digitalmars-d]

Filed a bug:

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


--T

[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

--- Comment #2 from hst...@quickfur.ath.cx ---
https://issues.dlang.org/show_bug.cgi?id=16799

--

[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

--- Comment #1 from hst...@quickfur.ath.cx ---
May be related to bug #16799.

--

[Issue 17760] New: 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

  Issue ID: 17760
   Summary: catch block fails to catch Exception subclass when
another Exception is in transit
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: hst...@quickfur.ath.cx

Code:
-
import std.stdio;
class MyException : Exception
{
this() { super("MYMY"); }
}
struct S
{
~this()
{
try { throw new MyException; }
catch(MyException e) { writefln("Collected MyException: %s", e.msg); }
catch(Exception e)   { writefln("Collected Exception: %s",   e.msg); }
}
void method() { throw new Exception("Dumb error"); }
}
void main()
{
try {
S s;
s.method();
} catch(Exception) {}
}
-

Expected output:
-
Collected MyException: MYMY
-

Actual output:
-
Collected Exception: MYMY
-

This appears to happen only when another Exception is in transit. If S is
destructed normally at the end of the block rather than as part of exception
winding (e.g., if the call to s.method() is commented out), the catch block
works as expected.

--

[Issue 16799] try-catch blocks fail to catch exception in druntime unittests

[via Digitalmars-d-bugs]

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

hst...@quickfur.ath.cx changed:

   What|Removed |Added

 CC||hst...@quickfur.ath.cx

--

Re: Debugging Visual D using Visual D

[Johnson Jones via Digitalmars-d-debugger]

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 registry keys, possibly 
wrong/old way, VS uses 

Re: Exception chaining and collectException

[H. S. Teoh via Digitalmars-d]

Here's a reduced example that does not depend on std.exception:
---
import std.stdio;
class MyException : Exception
{
this() { super("MYMY"); }
}
struct S
{
~this()
{
try { throw new MyException; }
catch(MyException e) { writefln("Collected MyException: %s", e.msg); }
catch(Exception e)   { writefln("Collected Exception: %s",   e.msg); }
}
void method() { throw new Exception("Dumb error"); }
}
void main()
{
try {
S s;
s.method();
} catch(Exception) {}
}
---

Expected output:
Collected MyException: MYMY

Actual output:
Collected Exception: MYMY

Looks like a bug in druntime, or a codegen bug?


T

-- 
Help a man when he is in trouble and he will remember you when he is in trouble 
again.

Exception chaining and collectException

[H. S. Teoh via Digitalmars-d]

Code:

import std.exception : collectException;
import std.stdio;
class MyException : Exception { this() { super("MYMY"); } }
void f() { throw new MyException(); }
struct S
{
~this()
{
auto e = collectException!MyException(f());
writefln("Collected: %s (%s)", typeid(e).toString, e.msg);
}
void method()
{
throw new Exception("Dumb error");
}
}
void main()
{
try
{
S s;
s.method();
}
catch (Exception e)
{
writefln("Caught: %s (%s) (next=%s)", typeid(e).toString, e.msg,
 e.next ? e.next.toString : "null");
}
}


Expected output: collectException should collect MyException while "Dumb
error" is in transit, and the output should contain a "Collected:" line.

Actual behaviour: collectException doesn't work as advertised;
MyException gets chained to the Exception in transit, and the
"Collected:" line is never printed.

If we change the collectException call to:

auto e = collectException!Exception(f());

then it *does* work as advertised: the MyException instance is not
chained, but is correctly collected by collectException.

Why???

The code in question is reduced from a larger project where the dtor
needs to do some non-trivial cleanup, but needs to ignore certain errors
that may occur during cleanup. So it needs collectException to catch
only certain subclasses of Exception, rather than all Exceptions.  But
the above inconsistent behaviour hampers this.

Investigating the implementation of collectException, it seems that all
it does is to use a try-catch block to catch an exception of the
requested type.  So the question becomes, why does the catch block *not*
catch the instance of MyException when another exception is in transit?!


T

-- 
Gone Chopin. Bach in a minuet.

Re: Named multi-imports

[Timon Gehr via Digitalmars-d]

On 17.08.2017 23:03, aberba wrote:

On Wednesday, 16 August 2017 at 13:57:17 UTC, jmh530 wrote:

On Wednesday, 16 August 2017 at 09:54:41 UTC, aberba wrote:


This looks really clean for code modularity.

import io = std.stdio : {writeln, write}, ...


What does this add? A line like below would be confusing.
import io = std.stdio : {writeln, write}, writefln;

The following code compiles and the imports are less confusing.

import io = std.stdio : writeln, write;
import std.stdio : writefln;

void main()
{
io.write("foo");
io.writeln("bar");
writefln("My items are %(%s %).", [1,2,3]);
}


Its more like this:

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


oo.writeln();
oo.write();
oo.filter(...);
oo.map(...);



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])));
}

Re: Implicit conversion from const to mutable

[Steven Schveighoffer via Digitalmars-d-learn]

On 8/17/17 5:28 PM, Balagopal Komarath wrote:

On Thursday, 17 August 2017 at 20:22:09 UTC, Steven Schveighoffer wrote:


This should "work". I don't think your static assert will pass, but 
the main function below should run.


Thanks. But, isn't my static assert testing for exactly this?



I might be wrong. It's hard to tell, because the compiler doesn't work 
with the struct itself.


If I change the alias this to something else, your form of conversion 
does work. But the compiler may recognize that specific form and still 
disallow it. IMO, that would be a further bug.


-Steve

Re: @safe(bool)

[Timon Gehr via Digitalmars-d]

On 17.08.2017 20:38, HypperParrow wrote:

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

On 17.08.2017 18:36, HyperParrow wrote:

On Thursday, 17 August 2017 at 16:32:20 UTC, bitwise wrote:

[...]


Yeah, i like it more than 
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md.


That makes little sense to me, as DIP 1012 is strictly more general.

template safety(bool safetyOn){ // (this can even be in core)
static if(safetyOn) alias safety = FunctionSafety.safe;
else alias safety = FunctionSafety.system;
// else alias safety = infer!FunctionSafety; // even better!
}

struct Container(T, bool safetyOn = true){
static if(safe) RefCounted!(T[]) data;
else T[] data;

auto opSlice() @safety!safetyOn {
return Range(data, 0, data.length);
}
}


The application of DIP 1012 would have catastrophic effects on the 
current tooling but as usual nobody thinks to that.


AFAICT, both of those claims are exaggerations. How exactly would it be 
"catastrophic"? This feature is easy to implement (basically, it just 
patches together a couple of existing pieces).

Re: Implicit conversion from const to mutable

[Balagopal Komarath via Digitalmars-d-learn]

On Thursday, 17 August 2017 at 20:22:09 UTC, Steven Schveighoffer 
wrote:


This should "work". I don't think your static assert will pass, 
but the main function below should run.


Thanks. But, isn't my static assert testing for exactly this?

Re: Debugging Visual D using Visual D

[Johnson Jones via Digitalmars-d-debugger]

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?

Re: Named multi-imports

[Johnson Jones via Digitalmars-d]

On Thursday, 17 August 2017 at 21:03:33 UTC, aberba wrote:

On Wednesday, 16 August 2017 at 13:57:17 UTC, jmh530 wrote:

On Wednesday, 16 August 2017 at 09:54:41 UTC, aberba wrote:


This looks really clean for code modularity.

import io = std.stdio : {writeln, write}, ...


What does this add? A line like below would be confusing.
import io = std.stdio : {writeln, write}, writefln;

The following code compiles and the imports are less confusing.

import io = std.stdio : writeln, write;
import std.stdio : writefln;

void main()
{
io.write("foo");
io.writeln("bar");
writefln("My items are %(%s %).", [1,2,3]);
}


Its more like this:

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


oo.writeln();
oo.write();
oo.filter(...);
oo.map(...);


Someone gets it! ;)

Re: Named multi-imports

[aberba via Digitalmars-d]

On Wednesday, 16 August 2017 at 13:57:17 UTC, jmh530 wrote:

On Wednesday, 16 August 2017 at 09:54:41 UTC, aberba wrote:


This looks really clean for code modularity.

import io = std.stdio : {writeln, write}, ...


What does this add? A line like below would be confusing.
import io = std.stdio : {writeln, write}, writefln;

The following code compiles and the imports are less confusing.

import io = std.stdio : writeln, write;
import std.stdio : writefln;

void main()
{
io.write("foo");
io.writeln("bar");
writefln("My items are %(%s %).", [1,2,3]);
}


Its more like this:

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


oo.writeln();
oo.write();
oo.filter(...);
oo.map(...);

Re: Need some vibe.d hosting advice

[aberba via Digitalmars-d]

On Tuesday, 15 August 2017 at 10:28:04 UTC, aberba wrote:
On Saturday, 12 August 2017 at 08:49:44 UTC, Paolo Invernizzi 
wrote:

On Friday, 11 August 2017 at 13:06:54 UTC, aberba wrote:



[...]


We are using dockerized vibe.d containers in a docker swarm 
hosted on DigitalOcean.


/Paolo


Breaking the app into microservices and in a managed 
environment since we don't have devOps.





Everything managed under one dashboard
On this, i just took a close look a Deis.com Workfkow which is 
exactly heroku but uses kubenetes and docker under the hood. A 
true self hosted Heroku.


The beautiful thing is any docker image can be used (no need for 
build packs)

Re: Implicit conversion from const to mutable

[Steven Schveighoffer via Digitalmars-d-learn]

On 8/17/17 3:24 PM, Balagopal Komarath wrote:
Is it possible to make structs containing slices support implicit 
conversion from const to mutable?


This should "work". I don't think your static assert will pass, but the 
main function below should run.


struct A
{
   int[] a;
   A dup() const
   {
   return A(a.dup);
   }
   alias dup this;
}

void main()
{
const A a;
A a2 = a;
}

However, this results in a segfault as far back as 2.064, and 2.063 
doesn't seem to like it (but maybe because alias this wasn't supported? 
I'm not sure).


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

-Steve

[Issue 17759] struct that attempts to implicitly cast away const causes segfault

[via Digitalmars-d-bugs]

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

--- Comment #1 from Steven Schveighoffer  ---
should say, attempts to legally *implicitly* cast away const.

--

[Issue 17759] New: struct that attempts to implicitly cast away const causes segfault

[via Digitalmars-d-bugs]

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

  Issue ID: 17759
   Summary: struct that attempts to implicitly cast away const
causes segfault
   Product: D
   Version: D2
  Hardware: x86_64
OS: Mac OS X
Status: NEW
  Keywords: ice, ice-on-valid-code
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: schvei...@yahoo.com

Consider the following struct which attempts to legally cast away const:

struct A
{
   int[] a;
   A foo() const { return A.init; }
   alias foo this;
}

The compiler segfaults, all the way back to 2.064. This is the minimum I could
do to make it happen. If you change anything, it seems to start compiling.

In LDC, it says "illegal instruction: 4"

If you use -v, I get this output:
predefs   DigitalMars Posix OSX darwin LittleEndian D_Version2 all D_SIMD
D_InlineAsm_X86_64 X86_64 D_LP64 D_PIC assert D_HardFloat
binarydmd
version   v2.075.1
config/Users/steves/.dvm/compilers/dmd-2.075.1/osx/bin/dmd.conf
parse testimplicitmutable
importall testimplicitmutable
importobject   
(/Users/steves/.dvm/compilers/dmd-2.075.1/osx/bin/../../src/druntime/import/object.d)
importcore.attribute   
(/Users/steves/.dvm/compilers/dmd-2.075.1/osx/bin/../../src/druntime/import/core/attribute.d)
semantic  testimplicitmutable
semantic2 testimplicitmutable
semantic3 testimplicitmutable
Segmentation fault: 11

--

Implicit conversion from const to mutable

[Balagopal Komarath via Digitalmars-d-learn]

Is it possible to make structs containing slices support implicit 
conversion from const to mutable? I tried adding a postblit that 
dupes the member 'a'. That didn't work.


struct A
{
int[] a;
}

void main()
{
static assert (is(const(A) : A)); // fails
}

Re: @safe(bool)

[HypperParrow via Digitalmars-d]

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

On 17.08.2017 18:36, HyperParrow wrote:

On Thursday, 17 August 2017 at 16:32:20 UTC, bitwise wrote:

[...]


Yeah, i like it more than 
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md.


That makes little sense to me, as DIP 1012 is strictly more 
general.


template safety(bool safetyOn){ // (this can even be in core)
static if(safetyOn) alias safety = FunctionSafety.safe;
else alias safety = FunctionSafety.system;
// else alias safety = infer!FunctionSafety; // even better!
}

struct Container(T, bool safetyOn = true){
static if(safe) RefCounted!(T[]) data;
else T[] data;

auto opSlice() @safety!safetyOn {
return Range(data, 0, data.length);
}
}


The application of DIP 1012 would have catastrophic effects on 
the current tooling but as usual nobody thinks to that.

Re: @safe(bool)

[Timon Gehr via Digitalmars-d]

On 17.08.2017 18:36, HyperParrow wrote:

On Thursday, 17 August 2017 at 16:32:20 UTC, bitwise wrote:

This came to mind while working on a set of containers.

[...]
One solution could be this:

struct Container(T, bool safetyOn = true)
{
static if(safe)
RefCounted!(T[]) data;
else
T[] data;

auto opSlice() @safe(safetyOn) {
return Range(data, 0, data.length);
}
}

A similar solution could be applied to @nogc as well.


Yeah, i like it more than 
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md.


That makes little sense to me, as DIP 1012 is strictly more general.

template safety(bool safetyOn){ // (this can even be in core)
static if(safetyOn) alias safety = FunctionSafety.safe;
else alias safety = FunctionSafety.system;
// else alias safety = infer!FunctionSafety; // even better!
}

struct Container(T, bool safetyOn = true){
static if(safe) RefCounted!(T[]) data;
else T[] data;

auto opSlice() @safety!safetyOn {
return Range(data, 0, data.length);
}
}

Re: Visual D 0.45 released - better VS2017 integration

[Johnson via Digitalmars-d-announce]

On Thursday, 17 August 2017 at 07:49:53 UTC, Rainer Schuetze 
wrote:


On 03.08.2017 09:04, Rainer Schuetze wrote:

[...]


I have uploaded a new version 0.45.1 that should fix some 
anti-virus programs to reject the installation or execution of 
Visual D (by building against the MS runtime instead of the DM 
runtime).


A few other changes crept in aswell, like improved tooltips and 
a number of bug fixes. See full list of changes here: 
http://rainers.github.io/visuald/visuald/VersionHistory.html


Cool! Thanks!

Re: Debugging Visual D using Visual D

[Johnson via Digitalmars-d-debugger]

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.

Re: @safe(bool)

[Moritz Maxeiner via Digitalmars-d]

On Thursday, 17 August 2017 at 16:32:20 UTC, bitwise wrote:
The only problem would be the lack of actual @safe annotations 
on the container, as they would only be applicable to one 
variant, and otherwise cause a compile-time error.

[...]


Shouldn't the already compiler derive the appropriate attributes 
(@safe/@system, @nogc) for functions inside templates?

Re: @safe(bool)

[HyperParrow via Digitalmars-d]

On Thursday, 17 August 2017 at 16:32:20 UTC, bitwise wrote:

This came to mind while working on a set of containers.

[...]
One solution could be this:

struct Container(T, bool safetyOn = true)
{
static if(safe)
RefCounted!(T[]) data;
else
T[] data;

auto opSlice() @safe(safetyOn) {
return Range(data, 0, data.length);
}
}

A similar solution could be applied to @nogc as well.


Yeah, i like it more than 
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md.

Re: New Features [was Named multi-imports]

[Jesse Phillips via Digitalmars-d]

This was hard to keep reading, but ultimately enjoyable, because 
your arguments stem from interpretations and opinions of my point 
rather than the points I was making.


It is interesting that you feel I've claimed your point is 
baseless when I made no attempt to say such. Would help if I 
confirm that you do have valid arguments?


I provided a general response to a general question. You asked 
why people would be against features, which in your response has 
changed it to why people would be against features nearly 
mathematically proven to be correct.


I'm not saying we shouldn't look at the feature suggestion and 
way the pros and cons, but when you make a statement like "Adding 
language features should be see as something good, cause without 
them, we wouldn't get anywhere." it sounds more like your stating 
"Language features provide benefits, ignore the harm they cause 
it can't out weigh the harm it does."


On Wednesday, 16 August 2017 at 22:19:31 UTC, Johnson Jones wrote:
Cost is not a one way street. When you don't do something it is 
doing something.  The whole problem with backwards 
compatibility is that it

is based on ignorance.


But it isn't, your examples are all new, unestablished products 
which have no market to keep. There is a reason C++, Java, C#, C, 
Go, and countless other products keep backwards compatibility and 
it has nothing to do with ignorance. There is evidence even 
within the D community and Python, that breaking backwards 
compatibility does enough harm that it could be argued the change 
wasn't worth it (especially if done routinely).


D may have a number of features which C++ doesn't and visa 
versa, the complexity of the language for C++ to have those 
features means I work with D and not C++.


Then why are you so against adding features? That is what made 
D better than C++?


I didn't say that D features made it better than C++. I did say 
that the complexity of C++ has kept me away from it.



If you can find a specific reason why having such a notation is 
wrong then that would be a valid point, but generalities that 
don't apply is not helpful to the cause.


I did which you know since that is the very next thing you touch 
on.


As far as your argument about ambiguities, that already exists, 
so it is not a problem with a new feature that extends what we 
have(it might inherit the problem, but it is not the cause of 
it). So, you should talk to walter about fixing that.


But ambiguities don't exist. If I name an import the compiler 
knows exactly which symbols I'm referring to. In fact named 
imports is one of the solutions Walter put in place to fix the 
ambiguity problem which you're now wanting to introduce into one 
of the approaches to solving the problem.


My main argument is that your two arguments: 1. Adding language 
features is bad. 2. The proposed idea creates the issue of 
ambiguity between identical symbols.


But I didn't make the argument that "adding language features is 
bad." I made the argument that "adding language features has a 
cost." And to be more explicit, "it has a cost and you should be 
aware of the cost making the choices based on what the pros are 
with the costs and the weight of those pros and costs."


2. The ambiguity is, at it's root, part of D's module system 
design and part of D's problem, not the addition of something 
new on top of it. It cannot be fixed by not adding the addition 
and can't be fixed by choosing not to have it. So it too is 
irrelevant. If, it were to complicate the addition and make the 
addition have new problems, then that is a valid argument, but 
that is something you have to prove or show, which you haven't 
done.


D has facilities for handling ambiguity, it is at the root of D, 
part of D's module system design. This argument only shows you 
are not aware or understand D's approach to solving the problem.


So what I have ended up doing, rather than really defend my 
proposal for what it is and does, is have to correct your logic 
so that maybe we hopefully get somewhere. Note that none of 
this is an attack on you so don't get upset.  I simply would 
like to see this feature get implemented if it is a good idea, 
and if it not, then I don't want it to... but before we can 
determine that in a correct way, we first have to judge it for 
what it is rather than what it is not.


Right, that is why I started with the general arguments, we have 
to be using the same decision making logic. Your view of features 
suggested that your approach to decision making differs from that 
of the top D contributors and a portion of the community. My 
logic could be wrong, but reflecting back to my first paragraph, 
you aren't going to be able to correct my logic if you don't 
understand what that logic is and instead go on a rampage of a 
view some fictitious person has in your head.

@safe(bool)

[bitwise via Digitalmars-d]

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.


It's fairly easy to make a container that toggles it's 
implementation between  ref-counted, GC, or raw pointers/arrays, 
based on a template parameter. This would allow a single 
container to be used in both performance sensitive and safe 
contexts (in theory). The only problem would be the lack of 
actual @safe annotations on the container, as they would only be 
applicable to one variant, and otherwise cause a compile-time 
error.


One solution could be this:

struct Container(T, bool safetyOn = true)
{
static if(safe)
RefCounted!(T[]) data;
else
T[] data;

auto opSlice() @safe(safetyOn) {
return Range(data, 0, data.length);
}
}

A similar solution could be applied to @nogc as well.

Re: D outperformed by C++, what am I doing wrong?

[data pulverizer via Digitalmars-d-learn]

On Sunday, 13 August 2017 at 06:09:39 UTC, amfvcg wrote:

Hi all,
I'm solving below task:

given container T and value R return sum of R-ranges over T. An 
example:

input : T=[1,1,1] R=2
output : [2, 1]

input : T=[1,2,3] R=1
output : [1,2,3]
(see dlang unittests for more examples)


Below c++ code compiled with g++-5.4.0 -O2 -std=c++14 runs on 
my machine in 656 836 us.
Below D code compiled with dmd v2.067.1 -O runs on my machine 
in ~ 14.5 sec.


Each language has it's own "way of programming", and as I'm a 
beginner in D - probably I'm running through bushes instead of 
highway. Therefore I'd like to ask you, experienced dlang devs, 
to shed some light on "how to do it dlang-way".


...



From time to time the forum gets questions like these. It would 
be nice it we had blog articles concerning high performance 
programming in D, a kind of best practice approach, everything 
from programming idioms, to compilers, and compiler flags.

[Issue 5144] Issue with SYSTEMTIME2d_time daylightSavingTA()

[via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||schvei...@yahoo.com
 Resolution|--- |WONTFIX

--- Comment #4 from Steven Schveighoffer  ---
(In reply to RazvanN from comment #3)
> Is D1 maintained anymore? Shouldn't we close this?

Some industry leaders (e.g. sociomantic) use D1, but I believe nobody uses D1
Phobos.

--

[Issue 5144] Issue with SYSTEMTIME2d_time daylightSavingTA()

[via Digitalmars-d-bugs]

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

RazvanN  changed:

   What|Removed |Added

 CC||razvan.nitu1...@gmail.com

--- Comment #3 from RazvanN  ---
Is D1 maintained anymore? Shouldn't we close this?

--

Re: Named multi-imports

[jmh530 via Digitalmars-d]

On Thursday, 17 August 2017 at 11:40:11 UTC, rjframe wrote:


It doesn't quite work; it provides access to all names in the 
module, and
write/writeln is introduced into the global namespace; e.g., 
it's

interpreted as
`import io = std.stdio; import std.stdio : write, writeln;`

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


Yeah, I wouldn't have expected the following code to compile 
without error


import io = std.stdio : writeln;

void main()
{
io.write("foo"); //expect error here, but none
writeln("blah"); //expect error here, but none
io.writeln("bar"); //no error
}

Re: Does anyone understand how to use "shared" types with concurrency send/receive functions?

[Steven Schveighoffer via Digitalmars-d-learn]

On 8/17/17 8:41 AM, Kagamin wrote:

On Wednesday, 16 August 2017 at 13:14:55 UTC, Steven Schveighoffer wrote:
But that isn't a concern for Variant. It is only calling the postblit, 
which does work.


Shouldn't it call destructor when it goes out of scope?


You're right, and it does. It uses the typeid to destroy it, which I 
think ignores any attributes.


I've updated my PR to switch to the __xdtor method, which takes into 
account attributes of the method.


This doesn't suffer from the same incorrect assumption the compiler 
makes when destroying something in a scope, so ironically, using a 
Variant to wrap a shared type with a destructor is going to work better 
than using the stack :)


-Steve

Re: C++17 Init statement for if/switch

[Enamex via Digitalmars-d]

On Wednesday, 16 August 2017 at 14:19:59 UTC, SrMordred wrote:

On Tuesday, 15 August 2017 at 21:05:09 UTC, bachmeier wrote:
On Tuesday, 15 August 2017 at 20:31:50 UTC, Jonathan Marler 
wrote:


Without alot of usage, it will just be an esoteric construct 
that looks confusing to the average developer.


That is correct. After a while it gets tiring to see a 
neverending stream of complexity added to the language while 
things that would actually help (like IDE support) do not get 
any attention. As a general rule, if it's being added to C++, 
it's probably a bad idea.


There are two thinks of c++ that I miss a little on D:
- Structured binding
- Uniform initialization

But in general, I agreed with you.


Initialization in D is pretty uniform now though. What corners am 
I missing?


It's usually:

 name = (args);

Structured bindings... I think C++ did it badly, actually. They 
had the {...} syntax fr object construction that worked 
everywhere and using the same for deconstruction would've allowed 
for quite natural tuples, which manifest almost as language-level 
constructs by then (with the help of 'auto' in template 
parameters).

Re: Does anyone understand how to use "shared" types with concurrency send/receive functions?

[Kagamin via Digitalmars-d-learn]

On Wednesday, 16 August 2017 at 23:15:10 UTC, crimaniak wrote:
I wonder if it possible and usable to make some template to 
support this pattern, where we give mutex(es), shared object(s) 
and delegate to operate with objects as non-shared.


https://dpaste.dzfl.pl/8b3b05c8ec0a like this? Not sure if it 
helps, don't forget that it's a casted shared object.

Re: Who here uses vibe-s3 from code.dlang.org?

[yawniek via Digitalmars-d]

On Monday, 14 August 2017 at 19:07:07 UTC, aberba wrote:

On Sunday, 13 August 2017 at 21:38:37 UTC, yawniek wrote:

On Tuesday, 8 August 2017 at 08:49:33 UTC, Andre Pany wrote:

[...]


the original goal of vibe-s3 was to allow streaming uploads of 
large files so that no memory/disk needs to be used.
shelling out (calling aws console client) is definitly not an 
option.


What exactly is missing or not working in its current state?


from what i know file upload/download and multipart is working 
fine but setting options/headers is currently done via submitting 
the headers.

thus all the interfaces are a bit crude.
for the rest see the github issues.
please report any problems in the github, also you can submit how 
you would EXPECT the API to work

Re: Does anyone understand how to use "shared" types with concurrency send/receive functions?

[Kagamin via Digitalmars-d-learn]

On Wednesday, 16 August 2017 at 13:14:55 UTC, Steven 
Schveighoffer wrote:
But that isn't a concern for Variant. It is only calling the 
postblit, which does work.


Shouldn't it call destructor when it goes out of scope?

[Issue 8343] Last argument of topNCopy forcing a sort?

[via Digitalmars-d-bugs]

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

RazvanN  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--

[Issue 8343] Last argument of topNCopy forcing a sort?

[via Digitalmars-d-bugs]

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

RazvanN  changed:

   What|Removed |Added

 CC||razvan.nitu1...@gmail.com

--- Comment #1 from RazvanN  ---
>From docs :  "If sorted is true, the target is sorted. Otherwise, the target
respects the heap property" [1].

[1] https://dlang.org/phobos/std_algorithm_sorting.html#topNCopy

> But if the programmer gives "true" as the last argument, can't topNCopy just 
> sort the little result calling sort() on it before returning?

That is exactly what it does.

Closing as invalid.

--

Re: Named multi-imports

[rjframe via Digitalmars-d]

On Wed, 16 Aug 2017 12:04:13 +, jmh530 wrote:
> 
> Well I knew that renamed imports were allowed, but I didn't realize you
> could do re-named selective imports (the " : writeln,
> write" part of it). I just double-checked and it worked. I don't recall
> it working in the past.
> 
> I see that there's an example in the spec, but it is a little more
> complicated than my example.

It doesn't quite work; it provides access to all names in the module, and 
write/writeln is introduced into the global namespace; e.g., it's 
interpreted as
`import io = std.stdio; import std.stdio : write, writeln;`

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

[Issue 10157] Vector ops with different types

[via Digitalmars-d-bugs]

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

Martin Nowak  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||c...@dawg.eu
 Resolution|--- |FIXED

--- Comment #1 from Martin Nowak  ---
https://github.com/dlang/dmd/pull/4218

--

Re: DLang quarterly EU?

[Iain Buclaw via Digitalmars-d]

On 16 August 2017 at 00:02, Atila Neves via Digitalmars-d
 wrote:
> On Sunday, 7 May 2017 at 16:37:02 UTC, Ethan Watson wrote:
>>
>> On Sunday, 7 May 2017 at 11:32:53 UTC, Adam Wilson wrote:
>>>
>>> On 5/7/17 12:57, Seb wrote:

 +1 - maybe its worth considering to make it for two days (=one weekend)
>>>
>>>
>>> That can work. It would be two or three days vacation depending on flight
>>> schedules.
>>> ...
>>> Not to mention a cool way to see new cities if it moves around.
>>
>>
>> Yes, that was the intention on both counts. There's no point to flying
>> somewhere just for the day. Especially since there will doubtless be Micro
>> BeerConfs in the evening ;-)
>>
>> Andrei suggested that Bucharest be the first city we hold this in. Sounds
>> like a great plan to me.
>
>
> We should probably organise this!
>
> Atila

Yes, who is willing to host?

Iain.

Re: Automatic function body writing howto?

[Oleg B via Digitalmars-d-learn]

On Wednesday, 16 August 2017 at 22:48:59 UTC, Meta wrote:
It's hard to tell offhand but I would recommend that you 
extract the inner string into a function that generates that 
string, allowing you to print out the finished product before 
mixing it in.


It's have a same result...

[Issue 17758] New: assignment of different vector types should require cast

[via Digitalmars-d-bugs]

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

  Issue ID: 17758
   Summary: assignment of different vector types should require
cast
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: c...@dawg.eu

cat > bug.d << CODE
void test()
{
__vector(float[4]) f4;
__vector(uint[4]) u4;
__vector(void[16]) v16;
f4 = cast(typeof(f4)) u4; // OK
f4 = u4; // should fail
v16 = f4; // OK
f4 = v16; // should fail
f4 = cast(typeof(f4)) v16; // OK
}
CODE
dmd -c bug

It's somewhat broken that vectors of different types can be assigned without
any casting. This is OK for implicit conversions to void16 vectors, but not for
conversions from void16.

--

Re: Stefan Koch: New CTFE fix

[Olivier FAURE via Digitalmars-d]

On Wednesday, 16 August 2017 at 13:55:51 UTC, Johnson wrote:
Oh, your such a bad boy. How bout you grow up. If I'm childish, 
you are just a smaller child because you are doing the exact 
same thing... getting on the internet, pretending to be some 
bad boy with something to say... like anyone will listen to 
you. That goes for your buddy too. Probably all the same person 
that has nothing real to say.


For what it's worth, I apologize for what I said earlier. I stand 
by it, but I shouldn't have called you names for the sake of it.


That said, you're insulting people who are (mostly) trying to 
help you. This isn't a "who's right and who's wrong" thing. I'm 
*not* trying to smack you down or prove you're an idiot, I'm 
trying to help you (and, as you're no doubt thinking, I'm bored 
and I like drama on the internet and whatever).


Don't behave like that, please. It's somewhat hurtful to other 
people, it ruins productive discussion, and it probably makes the 
discussion irritating for you too.


I do agree that Moritz "do" comment was a little pedantic, and I 
think his next answers in this thread are barely more 
constructive than yours, but again, it's not a "he's wrong then 
you're right" thing. You could have told him off without being 
extremely aggressive and insulting. The fact that you did that is 
why Biotronic and I have been calling you "immature", not because 
we're all infatuated with Moritz or because we're a hive mind 
dedicated to being jealous of you.

Re: Visual D 0.45 released - better VS2017 integration

[Rainer Schuetze via Digitalmars-d-announce]

On 03.08.2017 09:04, Rainer Schuetze wrote:

Hi,

there is a new version 0.45 of Visual D available at 
http://rainers.github.io/visuald/visuald/StartPage.html


Most changes are bug fixes and incremental improvements, maybe standing 
out:


* improved VS 2017 integration
* task list support
* dparser update to recent language additions

See http://rainers.github.io/visuald/visuald/VersionHistory.html for the 
full version history.


Visual D is a Visual Studio extension that adds D language support to 
VS2008-2017. It is written in D, its source code can be found on github: 
https://github.com/D-Programming-Language/visuald, pull requests welcome.


Rainer


I have uploaded a new version 0.45.1 that should fix some anti-virus 
programs to reject the installation or execution of Visual D (by 
building against the MS runtime instead of the DM runtime).


A few other changes crept in aswell, like improved tooltips and a number 
of bug fixes. See full list of changes here: 
http://rainers.github.io/visuald/visuald/VersionHistory.html

[Issue 16744] We should have a TypeOf template so that typeof can be used with templates like staticMap

[via Digitalmars-d-bugs]

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

ZombineDev  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||petar.p.ki...@gmail.com
 Resolution|FIXED   |---

--