[Issue 17772] Wrong C++ mangled names for templated functions

[via Digitalmars-d-bugs]

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

Илья Ярошенко  changed:

   What|Removed |Added

   Keywords||betterC, C++, wrong-code

--

[Issue 17772] New: Wrong C++ mangled names for templated functions

[via Digitalmars-d-bugs]

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

  Issue ID: 17772
   Summary: Wrong C++ mangled names for templated functions
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ilyayaroshe...@gmail.com



_Z3fooIiEiv (D) vs _ZN5SPACE3fooIiEET_v(C++)
_Z4foo2IiEiv(D) vs _Z4foo2IiET_v   (C++)




// D
DMD64 D Compiler v2.076.0-b1-dirty

```
extern(C++, SPACE)
T foo(T)(){ T t; return t;}

extern(C++)
T foo2(T)(){ T t; return t;}


pragma(msg, mangledName!(foo!int));
pragma(msg, mangledName!(foo2!int));```

output:

_Z3fooIiEiv
_Z4foo2IiEiv


// C++ (clang++ for macos and linux)

```
namespace SPACE
{
template
T foo() { T t; return t;}

int bar(){ return foo(); }
}

template
T foo2() { T t; return t;}

int bar2(){ return foo2(); }
```

clang++ -emit-llvm  -S -std=c++14 test_exc.cpp

output:

; Function Attrs: nounwind ssp uwtable
define linkonce_odr i32 @_ZN5SPACE3fooIiEET_v() #1 {
  %1 = alloca i32, align 4
  %2 = load i32, i32* %1, align 4
  ret i32 %2
}

; Function Attrs: nounwind ssp uwtable
define linkonce_odr i32 @_Z4foo2IiET_v() #1 {
  %1 = alloca i32, align 4
  %2 = load i32, i32* %1, align 4
  ret i32 %2
}

--

Re: @safe(bool)

[Nicholas Wilson via Digitalmars-d]

On Tuesday, 22 August 2017 at 01:20:13 UTC, Jonathan M Davis 
wrote:
On Tuesday, August 22, 2017 01:01:15 Nicholas Wilson via 
Digitalmars-d wrote:
That attributes are combinable and aliasable are nice side 
effects of being regular attributes which in general are one 
of the main foci of the DIP (the other being fixing the 
non-invertibility).


Which is precisely why I don't like it. Fixing 
non-invertibility is great. I don't like any of the rest.


Any editor that has dcd (or other tooling) support should be 
able to immediately resolve which aliases refer to what as its 
only symbol resolution. Yes it won't be able to do inference 
but it can't under the current system either.


Regardless, it means that I would need to run a tool to figure 
out which attributes actually applied to a function rather than 
just reading it like I could do now. And the fact that this is 
can be done with UDAs right now is _not_ a plus. I can 
understand wanting to reduce the number of attributes being 
manually applied to functions, but I think that hiding them 
with aliases and/or combined attributes is a maintenance 
nightmare and would argue that it's just plain bad practice.


- Jonathan M Davis


Then we shall just have to agree to disagree. I am of the opinion 
that they are very useful properties of UDAs and that's part of 
why I wrote that DIP.

Re: @safe(bool)

[Jonathan M Davis via Digitalmars-d]

On Tuesday, August 22, 2017 01:01:15 Nicholas Wilson via Digitalmars-d 
wrote:
> On Monday, 21 August 2017 at 08:09:25 UTC, Jonathan M Davis wrote:
> > Except that someone could then be pulling in attributes from
> > 3rd party libraries and using those, meaning that you'll
> > potentially have to go digging through other libraries just to
> > figure out whether a function is being marked with @safe or
> > not. You get some of that pain with any custom attribute, but
> > currently, the built-in attributes avoid it completely, and
> > being able to combine attributes makes it far worse, since then
> > you potentially have to go searching through a chain of
> > declarations to figure out which attributes are actually being
> > used. I can understand folks wanting to reduce how many
> > attributes they have to manually put on functions, but I think
> > that it risks being a maintenance nightmare to have to deal
> > with combined or aliased attributes. I would _much_ rather see
> > each attribute applied individually, because it's far easier to
> > figure out what's going on that way. We already have enough
> > problems figuring out which attributes are in play when dealing
> > with attribute inference. I _really_ don't want to see aliasing
> > and combining added to the mix - especially with the built-in
> > attributes. And that seems to be one of if not the main
> > motivation of the DIP.
> >
> > - Jonathan M Davis
>
> That attributes are combinable and aliasable are nice side
> effects of being regular attributes which in general are one of
> the main foci of the DIP (the other being fixing the
> non-invertibility).

Which is precisely why I don't like it. Fixing non-invertibility is great. I
don't like any of the rest.

> Any editor that has dcd (or other tooling) support should be able
> to immediately resolve which aliases refer to what as its only
> symbol resolution. Yes it won't be able to do inference but it
> can't under the current system either.

Regardless, it means that I would need to run a tool to figure out which
attributes actually applied to a function rather than just reading it like I
could do now. And the fact that this is can be done with UDAs right now is
_not_ a plus. I can understand wanting to reduce the number of attributes
being manually applied to functions, but I think that hiding them with
aliases and/or combined attributes is a maintenance nightmare and would
argue that it's just plain bad practice.

- Jonathan M Davis

Re: @safe(bool)

[Nicholas Wilson via Digitalmars-d]

On Monday, 21 August 2017 at 08:09:25 UTC, Jonathan M Davis wrote:
Except that someone could then be pulling in attributes from 
3rd party libraries and using those, meaning that you'll 
potentially have to go digging through other libraries just to 
figure out whether a function is being marked with @safe or 
not. You get some of that pain with any custom attribute, but 
currently, the built-in attributes avoid it completely, and 
being able to combine attributes makes it far worse, since then 
you potentially have to go searching through a chain of 
declarations to figure out which attributes are actually being 
used. I can understand folks wanting to reduce how many 
attributes they have to manually put on functions, but I think 
that it risks being a maintenance nightmare to have to deal 
with combined or aliased attributes. I would _much_ rather see 
each attribute applied individually, because it's far easier to 
figure out what's going on that way. We already have enough 
problems figuring out which attributes are in play when dealing 
with attribute inference. I _really_ don't want to see aliasing 
and combining added to the mix - especially with the built-in 
attributes. And that seems to be one of if not the main 
motivation of the DIP.


- Jonathan M Davis


That attributes are combinable and aliasable are nice side 
effects of being regular attributes which in general are one of 
the main foci of the DIP (the other being fixing the 
non-invertibility).


Any editor that has dcd (or other tooling) support should be able 
to immediately resolve which aliases refer to what as its only 
symbol resolution. Yes it won't be able to do inference but it 
can't under the current system either.

[Issue 17765] void initialisation of out parameters

[via Digitalmars-d-bugs]

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

--- Comment #2 from Nicholas Wilson  ---
Yeah the compiler was not able to determine that all values were assigned
despite there being no conditional logic for the initialisation:

foreach(i; 0 .. M-1)
{
corr[i][i] = 1.0;
for (auto j = i+1; j < M; j++)
{
corr[i][j] = 0.0;
for (auto k = 0; k < N; k++)
corr[i][j] += data[k][i] * data[k][j];
corr[j][i] = corr[i][j];
}
}
foreach(i; 0 .. M) corr[M-1][i] = 0.0;
corr[M-1][M-1] = 1.0;

>I was wondering if this could more of an implementation detail in the function 
>itself.
>
> i.e.:
>
> void g(out float[M][M] corr)
> {
> corr = void; // disables the initial write
> }

That would also work and would probably be less effort in the compiler and less
confusing.

> This shouldn't be allowed in @safe code.

Definitely.

--

Re: @safe(bool)

[Jonathan M Davis via Digitalmars-d]

On Tuesday, August 22, 2017 00:21:16 bitwise via Digitalmars-d wrote:
> On Monday, 21 August 2017 at 08:09:25 UTC, Jonathan M Davis wrote:
> > you potentially have to go searching through a chain of
> > declarations to figure out which attributes are actually being
> > used.
>
> A good IDE should give you this info if you hover over a
> function. I realize D's tool support is spotty at the moment, but
> it seems like the kind of think that's ok to be optimistic about.

If you need an IDE to figure out what your code is doing, that's an epic
fail IMHO. Walter has made similar statements on several occasions. D was
originally designed in such a way that IDEs should not be necessary (e.g. it
tries to avoid a lot of the boilerplate code that is typical in Java
programs). Most of the folks around here do not use IDEs. I use (g)vim as my
code editor, and I have no desire to use an IDE. I should be able to figure
out what's going on just by looking at the code, and having to go spelunking
to figure out which attributes really apply because they're hidden behind
aliases or combined in other attributes is just wasting my time IMHO. As
long as the attributes are applied directly without being renamed (be it
directly on the function or to the module as a whole), then the situation is
quite tractable, but if we end up with aliased attributes and combined
attributes, that goes completely out the window.

- Jonathan M Davis

Re: @safe(bool)

[bitwise via Digitalmars-d]

On Monday, 21 August 2017 at 08:09:25 UTC, Jonathan M Davis wrote:


you potentially have to go searching through a chain of 
declarations to figure out which attributes are actually being 
used.


A good IDE should give you this info if you hover over a 
function. I realize D's tool support is spotty at the moment, but 
it seems like the kind of think that's ok to be optimistic about.

GStreamer issues.

[Johnson via Digitalmars-d-learn]

I can't get the example to work(although slightly modified).

The installed version of GStreamer is 1.12.2
The file is: D:\temp\test.ogg
Loading
Setting to PLAYING.
Running.
XError: Could not demultiplex stream. dbug: gstoggdemux.c(4418): 
gst_ogg_demux_find_chains (): 
/GstPipeline:audio-player/GstOggDemux:ogg-parser:

can't get first chain

Actually I was getting a much worse error before ;/ I can't 
remember it now.



The installed version of GStreamer is 1.12.2
The file is: D:\temp\test2.wav
Loading
Setting to PLAYING.
Running.
XError: Internal data stream error. dbug: gstwavparse.c(2249): 
gst_wavparse_loop (): 
/GstPipeline:audio-player/GstWavParse:wav-parser:

streaming stopped, reason not-linked (-1)

Basically all I did was change the sink:

sink = ElementFactory.make("autoaudiosink", "auto-output");

So it I could get past the error about alsa. I think the last 
name doesn't matter?


I downloaded the gstreamer binaries from their site, had some 
issues with a few of the dll's complaining about gxx errors, I 
removed them(h264, soundtouch, tag).



For the wav I changed
//parser = ElementFactory.make("oggdemux", "ogg-parser");
//decoder = ElementFactory.make("vorbisdec", "vorbis-decoder");
parser = ElementFactory.make("wavparse", "wav-parser");
decoder = ElementFactory.make("audioconvert", "wav-decoder");


which, is all i could find on line, I don't know if it's right at 
all.



Ultimately I want to be able to read somewhat arbitrary audio 
formats(most common at least), get the raw channel data(samples 
for each channel), play/pause/stop with good accuracy(no latency 
or low latency(<20ms), possibly do some pitch shifting and basic 
mixing(EQ, limiting, panning, etc), and eventually play some 
videos.


Is GstreamerD going to be useful for this or so I look in to 
using ffmpeg directly and do some of the stuff(e.g., eq) myself?


Thanks.

Re: GtkD: New widget

[Johnson via Digitalmars-d-learn]

On Monday, 21 August 2017 at 20:54:04 UTC, Mike Wey wrote:

On 21-08-17 03:45, Johnson Jones wrote:

[...]


If you want gtk to know about the functions you override you 
could use gtkd.Implement.ImplementCLass.


[...]


Thanks, I'll test it out when I get a chance. I was able to work 
around the issue for now but I imagine I'll need the ability to 
implement my own container in the future.


BTW, when I try to create a value I get an error about opCall

Value handleSize = new Value(0);

vs

Value handleSize = Value(0);

I'd rather not create a value on the heap when I only need it 
locally.


Could you add a way to create the value with the right type to 
Value?


Even static constructors would work(probably could templatize it).

Although, I'm not sure how much it matters since value itself 
seems to allocate on the heap ;/


public this()
{
this(new GValue);
}

But it might help reduce some memory waste.

Re: Mixed up over mixins.

[Johnson via Digitalmars-d-learn]

On Monday, 21 August 2017 at 07:34:23 UTC, WhatMeForget wrote:

On Sunday, 20 August 2017 at 22:50:40 UTC, Johnson Jones wrote:

On Sunday, 20 August 2017 at 19:27:43 UTC, WhatMeWorry wrote:

[...]



It's not difficult, it's just new. It's not that you are a 
poor programmer, but you simply have not learned how to think 
about mixins correctly. Stop whining about it and focus that 
energy on working with them.


[...]


Thank you.  You have rejuvenated my quest for mixin mastery :)


Just stick with it ;) Things will click. The more you trudge 
through them and just try to immerse yourself in it the faster it 
will happen. I use mixins all the time because they are a great 
way to simplify code... although actually writing them can be a 
pain because you can't debug them in any sane way.


Remember, that you will generally use string generation a ton 
because that is mainly what you are working.


Sometimes, for complex tasks I might have to write a function 
that I run at runtime like a normal program that takes in a 
string and outputs it. This lets me debug properly. As long as 
one doesn't use crazy io(even file IO is blocked ;/) the same 
function can be run at compile time(CTFE).


This means

myfoo("asdfasdf");

will be ran at compile time, the reason is simply that the input 
is constant, there are no side effects, and so the output can be 
computed at compile time.


But the same function can be debugged if ran at runtime... and 
remember, the output is a string, so you can just print it out, 
no mixin is occuring at this point.


The idea is that you make sure the string output is going to be 
the correct D code you want to mixin. It should look like normal 
D code, because if you do a mixin on it, it has to be to compile. 
Any syntax errors will be picked up and you'll be hunting them 
down because D will give you an obtuse error rather than a 
specific line number in the mixin(this is a severe issue with D 
but no one seem to care). If you debugged at runtime, you will 
get a line number where the error occurred, which is why you go 
that route.



Once you've gotten your function written to do the code, you 
simply wrap a mixin() around it, you might have to change a bit 
of runtime to compile time stuff(file io to import) and then all 
that string stuff that you generated becomes D code!


mixin("int i = 3"); <- bug
mixin("int i = 3;"); <- ok

same as

int i = 3;

useless example but sometimes it's helpful. Sometimes to get the 
things working you have to use mixins of mixins:


mixin("mixin("~something~");");

or, take this example

auto alpha = "hello";
mixin("w"~"r"~"i"~"te(`"~alpha~"`);");

before the mixin we have

"w"~"r"~"i"~"te(`"~alpha~"`);"

which, when simplified is

"write(`"~alpha~"`);"

which, since alpha is a constant, we have

"write(`hello`);"

which, the mixin simply does

write(`hello`);

which is now D code.

A mixin, in a sense, just "unstringifies" it's argument and 
inserts it directly in to the source code... it better be valid 
code, which also means the string better be a valid string of D 
code.

Re: cv2pdb: cannot add symbols to module, probably msobj140.dll missing

[Johnson via Digitalmars-d-debugger]

On Monday, 21 August 2017 at 06:16:49 UTC, Rainer Schuetze wrote:



On 21.08.2017 05:24, Johnson wrote:

On Monday, 21 August 2017 at 03:18:38 UTC, Johnson wrote:

[...]


This just started happening too and a few hours ago I upgraded 
VS, so maybe the msobj140.dll changed and broke cv2pdb?  I 
copied it to the cv2pdb dir so it should have no trouble 
finding it. I've also cleaned the dir. It seems it's doing it 
on about everything I change. Going to reboot to see if that 
helps.




Unfortunately, the VS2017 15.3.1 update seems to cause quite 
some trouble. Bad linker (breaks TLS), bad vcvars*.bat (change 
current directory), and this issue, too.


I guess they changed something about the (undocumented) 
interface to the respective DLLs.


;/ That sucks ;/

I guess I might just have to install VS2015, or does that have 
issues too?


Any idea what might be the best VS version that is most 
compatible with Visual D?

[Issue 17767] Dmd can't link recast.d, Gdc can't compile it and Ldc can perfectly compile it.

[via Digitalmars-d-bugs]

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

--- Comment #4 from Iain Buclaw  ---
(In reply to ecstatic.coder from comment #3)
> Please could you simply download the latest file from Github and compile
> locally with your own version of gdc.
> 
> https://github.com/senselogic/RECAST/blob/master/recast.d
> 
> If it compiles fine with your version, then I know it's just a compiler
> version problem, not a compiler bug, and this will eventually be solved once
> I will be able to use the same version as you :)

I initially got a link error, but when pushing out phobos 2.076 it worked fine.

The internal error in both places seem to suggest a bug in earlier versions of
the front-end, in particular, a bogus Dsymbol was passed to the backend.

You're going to have to try multiple versions of dmd here, possible starting
from 2.066 or 2.068, and noting any differences between versions.

What I expect you to find is, that 2.066 ICE'd, 2.071 works, 2.075 regressed
and has linker errors, and 2.076 is fine again.

--

[Issue 17761] [REG2.075] 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

Martin Nowak  changed:

   What|Removed |Added

   Keywords||link-failure, pull

--- Comment #4 from Martin Nowak  ---
My version `ld.bfd -v`
GNU ld version 2.27-24.fc26

Was able to reproduce this in an ArchLinux container.

ld.bfd -v
GNU ld (GNU Binutils) 2.28.0.20170506


https://github.com/dlang/dmd/pull/7093

--

[Issue 16177] Inner exception cannot be caught by specific type; becomes a collateral of the original exception

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

Re: GtkD: New widget

[Mike Wey via Digitalmars-d-learn]

On 21-08-17 03:45, Johnson Jones wrote:

Hey Mike, I bet you can answer this!

I'd like to extend a widget to add some functionality.

class MyBox : Box
{
 protected GtkBox* gtkBox;

 import std.typecons;
 _gtk.Box Wrapped;
 mixin Proxy!Wrapped;

 public this(Box b)
 {
 this.gtkBox = b.getBoxStruct();
 super(gtkBox, false);
 }

}

Trying something like the above does extend the box, as far as allowing 
one to replace it, I think(using the code);


auto b = new MyBox(W1);
auto p = W1.getParent();
auto c = cast(Box)W4;
c.remove(W1);
c.add(b);

So, W4 is the main boxx, W1 is the box inside the main box I replaced 
with the new box b.


When running that code, nothing changes, which, assuming we are actually 
using the new box, then that is fine.


But I'm pretty sure that gtk never has a clue about `MyBox`? I say this 
because I'd like to simply modify the reported sizes of the box.


A gtkBox is not the same as a gtk.Box.

It seems like the best I can do is use a gtk.Container and inherit from 
that.



e.g.,

class FixableSizedBox : Container
{
 protected GtkContainer* gtkContainer;

 import std.typecons;
 _gtk.Container Wrapped;
 mixin Proxy!Wrapped;

 public this(Container b)
 {
 this.gtkContainer = b.getContainerStruct();
 super(gtkContainer, false);
 }

}

But even the GtkD container doesn't seem to contain any code to deal 
with handling the sizes.



All I'm really looking to do is set the size of a container to whatever 
I want.




If you want gtk to know about the functions you override you could use 
gtkd.Implement.ImplementCLass.


It's only in master and not completely finished yet, but you could use 
it to for example overrride the getPreferredHeight and getPreferredWidth 
functions.


I'm not completely clear on what you want to do with the size so they 
might not be the correct functions to override.



```
class MyBox : Box
{
  import gtkd.Implement;
  import gobject.c.functions : g_object_newv;

  mixin ImplementClass!GtkBox;

  this()
  {
//TODO: sort out the constructor.
super(cast(GtkApplication*)g_object_newv(getType(), 0, null), true);

  }

  override public void getPreferredHeight(out int minimumHeight, out 
int naturalHeight)

  {
//Set minimumHeight and naturalHeight.
  }

  override public void getPreferredWidth(out int minimumWidth, out int 
naturalWidth)

  {
//Set minimumWidth and naturalWidth.
  }
}
```

--
Mike Wey

Re: Mixed up over mixins.

[Ali Çehreli via Digitalmars-d-learn]

On 08/21/2017 12:29 AM, WhatMeForget wrote:

> Thanks. Don't know if you noticed, but i used some code from your book.
> Hope you take that as a complement.

I did notice that and thank you. Every time I see people struggle with 
code that originated from my half-witted examples, I actually feel 
guilty. :)


Ali

Re: Exception chaining and collectException

[Ali Çehreli via Digitalmars-d]

On 08/19/2017 01:58 PM, Nemanja Boric wrote:


C++ also provides a way to inspect if you're in the middle of the stack
unwinding caused by an exception, to make this a bit more controllable,
and I would think we should provide the similar primitive:
http://en.cppreference.com/w/cpp/error/uncaught_exception.



I don't know whether C++11 changed matters but according to popular 
C++98 wisdom, we were told "Don't use [std::uncaught_exception]":


  www.gotw.ca/gotw/047.htm

Ali

Re: Exception chaining and collectException

[Ali Çehreli via Digitalmars-d]

On 08/17/2017 02:48 PM, H. S. Teoh via Digitalmars-d wrote:

> So the question becomes, why does the catch block *not*
> catch the instance of MyException when another exception is in transit?!

I caught (!) the same or similar behavior last year:

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

Ali

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

[Steven Schveighoffer via Digitalmars-d-learn]

On 8/16/17 11:23 AM, Steven Schveighoffer wrote:

On 8/16/17 8:58 AM, Steven Schveighoffer wrote:
However, I have found a better way to call postblit that involves the 
qualifiers than the way Variant currently does it. I'm going to submit 
a PR to fix these issues.


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


This has been merged, so you should now be able to send shared types 
properly through send/receive on master dmd. Don't think it made it into 
2.076 beta though.


-Steve

Re: Exception chaining and collectException

[H. S. Teoh via Digitalmars-d]

On Sat, Aug 19, 2017 at 08:58:51PM +, Nemanja Boric via Digitalmars-d wrote:
> On Friday, 18 August 2017 at 22:51:35 UTC, Walter Bright wrote:
> > 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.
> > 
> 
> Well, you still can throw it, but you're not allowed to let it escape
> the destructor (you need to catch them before they would chain).

This was what I was trying to do: wrap some code in a try-catch in the
dtor so that any exceptions thrown won't escape the dtor.

However, the current inconsistent behaviour is making this difficult.
The same dtor behaves differently depending on whether it was called
from a normal end of scope, or while an Exception is in transit.  I.e.,
when called normally, the catch clause catches MyException, but when
another Exception is in transit, the catch clause fails to catch
MyException (yet it does catch the base class Exception, a rather
strange behaviour).


T

-- 
The most powerful one-line C program: #include "/dev/tty" -- IOCCC

[Issue 17673] regex(["\\\\\\\\|\\\\\"", "\"|$"]) - wrong whichPattern

[via Digitalmars-d-bugs]

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

Dmitry Olshansky  changed:

   What|Removed |Added

   Severity|critical|normal

--

[Issue 17771] foreach over const input range fails

[via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Steven Schveighoffer  ---
The compiler doesn't attempt to modify attributes in almost any case.

For instance:

auto foo()
{
   const int x = 5;
   return x;
}

auto y = foo(); // y is const(int), even though it could be just int

So this behavior is consistent. You need to tell the compiler to make the copy
with the correct attributes.

Note that many many ranges are not implicitly copyable to a mutable version, so
this ability would not help in most cases.

One valid enhancement that you could propose is to add a function somewhere in
phobos (probably in typecons) that returns a copy of the item with as many
qualifiers removed as possible. Then your code could become something like:

foreach(x; unqual(r))

--

Re: std.format expand "%s"

[Steven Schveighoffer via Digitalmars-d-learn]

On 8/21/17 10:58 AM, jmh530 wrote:

On Monday, 21 August 2017 at 13:57:01 UTC, Steven Schveighoffer wrote:


Well, for most things, %s does not do the same thing as another 
specifier. It's only integers, which format the same as %d, and 
floating points, which format the same as %g.


For all others, the format is specified as %s.

I think what you really want is just isFloatingPoint or isIntegral.


I'm pretty sure that isFloatingPoint/isIntegral is not what I need, but 
I'm also not sure if what I was asking for above is needed either. So 
I'll just drop it for now.


What I mean is that %s goes to %d for isIntegral!(typeof(x)), and %s 
goes to %g for isFloatingPoint!(typeof(x)), and stays as %s for 
everything else.


Given this, you could probably write the function you were looking for.

-Steve

[Issue 17771] foreach over const input range fails

[via Digitalmars-d-bugs]

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

Alex Goltman  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #2 from Alex Goltman  ---
If it fails to implicitly copy to a non-const (e.g.  a struct with a pointer
inside) then so be it - but why not make it try at least? as in:

Unqual!(typeof(range)) _r = range;

It seems weird that foreach which intentionally copies the range to avoid
modifying it will fail because a range is an unmodifiable const.

--

[Issue 13262] Cannot send certain shared data to another thread

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/373babe48e186d2e9a54042bd35317c928b14bc3
fix issue 13262 - Ensure shared data can be sent and received via
send/receive. Also now allows all types of shared items to be stored in
a Variant.

https://github.com/dlang/phobos/commit/e2a16ccd4d78ce7288d9abfb253bf64bc6638198
Merge pull request #5694 from schveiguy/fix13262

fix issue 13262 - Cannot send certain shared data to another thread

--

[Issue 13262] Cannot send certain shared data to another thread

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--

Re: std.format expand "%s"

[jmh530 via Digitalmars-d-learn]

On Monday, 21 August 2017 at 13:57:01 UTC, Steven Schveighoffer 
wrote:


Well, for most things, %s does not do the same thing as another 
specifier. It's only integers, which format the same as %d, and 
floating points, which format the same as %g.


For all others, the format is specified as %s.

I think what you really want is just isFloatingPoint or 
isIntegral.


-Steve


I'm pretty sure that isFloatingPoint/isIntegral is not what I 
need, but I'm also not sure if what I was asking for above is 
needed either. So I'll just drop it for now.

[Issue 17771] foreach over const input range fails

[via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

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

--- Comment #1 from Steven Schveighoffer  ---
1. foreach (and D in general) doesn't attempt to change any attributes, it
simply makes a copy via:

auto _r = range;

2. Ranges aren't always copyable to non-const versions implicitly.

So you need to do this yourself or cast:

foreach(x; cast() r)

--

[Issue 17765] void initialisation of out parameters

[via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com

--- Comment #1 from Steven Schveighoffer  ---
In the case of out variables, one of the reasons the init is done is to ensure
that the data is all written to.

2 things:

1. If the compiler can prove that the out variable is completely written in all
paths, then the initial write can be removed (could be happening already).
2. If the out = void syntax is accepted, and not all the data is written, then
this should really be an error.

Both require advanced flow analysis, and may not be possible in all cases, so
the result is that in cases where =void is used, not writing all the data is
going to be UB.

Another issue is that the current grammar/syntax defines =X to mean "pass X as
parameter if none specified". =void looks weird, and it also doesn't fit the
grammar if you have required parameters after it.

I was wondering if this could more of an implementation detail in the function
itself.

i.e.:

void g(out float[M][M] corr)
{
corr = void; // disables the initial write
}

This shouldn't be allowed in @safe code.

--

Re: Folder Size

[Vino.B via Digitalmars-d-learn]

On Monday, 21 August 2017 at 08:57:52 UTC, Aravinda VK wrote:

On Saturday, 19 August 2017 at 14:19:39 UTC, Vino.B wrote:

[...]


Keep a variable to add the sizes of subdirs

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

ulong subdirTotal = 0;
foreach (d; dFiles)
{
subdirTotal = 0;
auto SdFiles = dirEntries(d, SpanMode.depth).array;
foreach(f; SdFiles) {
subdirTotal += f.size;
}
writeln(d, "\t", subdirTotal);
}

--
Aravinda
http://aravindavk.in


Hi Aravinda,

  Thank you for the idea, but i have to tweek my code toas below 
to get the required output and now I am able to get the required 
output


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

  foreach (d; dFiles)
{
  auto SdFiles = dirEntries(d, SpanMode.depth).array;
  //auto entry = SdFiles.front;
  foreach (f; SdFiles)
{
subdirTotal += f.size;
}
ulong subdirTotalGB = (subdirTotal/1000/1000);
writefln("%-63s %s %s", d, subdirTotalGB, " 
MB");
subdirTotal = 0;


}

From,
Vino.B

Re: Mixed up over mixins.

[Steven Schveighoffer via Digitalmars-d-learn]

On 8/21/17 3:29 AM, WhatMeForget wrote:

On Sunday, 20 August 2017 at 19:41:14 UTC, Ali Çehreli wrote:

On 08/20/2017 12:27 PM, WhatMeWorry wrote:

> // Mixins are for mixing in generated code into the
source code.
> // The mixed in code may be generated as a template
instance
> // or a string.

Yes, it means that the string must be legal D code.

> mixin(`writeln(` ~ `Hello`  ~ `);` );

Yes, that's a D string but the string itself is not legal D code 
because it would be mixing in the following:


writeln(Hello);

The problem is, there is no Hello defined in the program.

You need to make sure that Hello is a string itself:

writeln("Hello");

So, you need to use the following mixin:

mixin(`writeln(` ~ `"Hello"`  ~ `);` );



Of course, why didn't I "see" that before. I should have slept on it and 
tried again with fresh eyes.  I'm keeping a "beginners journal" on code 
generation.  Maybe write a 101 introduction with lots of samples and 
exercises.


When doing mixins, especially when the code to generate the mixin string 
isn't a simple literal, a great thing to do is to use pragma(msg) to 
show the actual string you are mixing in.


e.g.:
enum mixinstr = ...
pragma(msg, mixinstr);
mixin(mixinstr);

Often times, your error is obvious when you see it that way.

-Steve

[Issue 8841] Missing line numbers in stack trace?

[via Digitalmars-d-bugs]

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

Gerald Jansen  changed:

   What|Removed |Added

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

--

[Issue 17727] addr2line does not understand debug info

[via Digitalmars-d-bugs]

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

Gerald Jansen  changed:

   What|Removed |Added

 CC||jansen.ger...@gmail.com
   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=8841

--

[Issue 17761] [REG2.075] 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 #3 from anonymous4  ---
Maybe depends on OS/ld version.

--

[Issue 17761] [REG2.075] 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

Martin Nowak  changed:

   What|Removed |Added

 CC||c...@dawg.eu

--- Comment #2 from Martin Nowak  ---
Please always at least add the exact commit hash/tag when referencing external
code in a bug entry. At best use Digger to reduce the test case.
Can't reproduce this with

reggae: 1e499c7b257c23415b1e745b6bd937f889300b85
unit-threaded: 0.7.28
dmd: v2.075.1
dub: 1.4.0

I used `curl -fsS https://dlang.org/install.sh | bash -s dmd-2.075.1` to get
the compiler.

On a sidenote, my dub hash is different than yours, not sure what command line
flags differ.
.dub/build/unittest-unittest-linux.posix-x86_64-dmd_2075-C42D717244B28E601F8D29F4D95527E

This is the compiler invocation from dub.

dmd -c
-of.dub/build/unittest-unittest-linux.posix-x86_64-dmd_2075-C42D717244B28E601F8D29F4D95527E0/ut.o
-debug -g -unittest -w -version=Have_reggae -version=Have_unit_threaded -Isrc
-Ipayload
-I../../../home/dawg/.dub/packages/unit-threaded-0.7.28/unit-threaded/source/
-Jpayload/reggae -Jtests/json bin/ut.d ...

--

[Issue 10157] Vector ops with different types

[via Digitalmars-d-bugs]

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

--- Comment #3 from anonymous4  ---
Hmm... vector ops are array ops?

--

Re: std.format expand "%s"

[Steven Schveighoffer via Digitalmars-d-learn]

On 8/20/17 9:52 PM, jmh530 wrote:
I'm playing around with std.format and I'm trying to figure out if there 
is any way to identify what "%s" should expand to.


So for instance:
int x = 1;
auto result = x.format!"%s";

I would know that result="1". I could run "1" through unformatValue and 
get back 1. I'm looking to see if there is a way to get back "%d": 
really a function would be like f(x, "%s") produces "%d".


Is there anything like that in std.format?


Well, for most things, %s does not do the same thing as another 
specifier. It's only integers, which format the same as %d, and floating 
points, which format the same as %g.


For all others, the format is specified as %s.

I think what you really want is just isFloatingPoint or isIntegral.

-Steve

[Issue 17766] Wrong choice of generic mutable/const/immutable methods

[via Digitalmars-d-bugs]

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

ZombineDev  changed:

   What|Removed |Added

 CC||petar.p.ki...@gmail.com

--

[Issue 10157] Vector ops with different types

[via Digitalmars-d-bugs]

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

anonymous4  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Hardware|x86 |All
 Resolution|FIXED   |---
 OS|Windows |All

--- Comment #2 from anonymous4  ---
void f()
{
ubyte[] a;
char[] b;
a[]=b[];
}
Error: cannot implicitly convert expression `b[]` of type `char[]` to `ubyte[]`

--

[Issue 17761] [REG2.075] 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

anonymous4  changed:

   What|Removed |Added

Summary|dmd 2.075.1 creates object  |[REG2.075] dmd 2.075.1
   |files that can't be linked  |creates object files that
   |by ld.bfd   |can't be linked by ld.bfd
   Severity|major   |regression

--

[Issue 17769] dmd accepts conversion from shared(int)* to int* when value comes from method

[via Digitalmars-d-bugs]

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

anonymous4  changed:

   What|Removed |Added

   Hardware|x86_64  |All
 OS|Linux   |All

--

[Issue 17771] New: foreach over const input range fails

[via Digitalmars-d-bugs]

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

  Issue ID: 17771
   Summary: foreach over const input range fails
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: alex.golt...@gmail.com

```
static struct NumRange {
int front = 0;
int end = 0;

@property auto length() const { return end - front; }
@property bool empty() const { return length == 0; }
void popFront() { front++; }
}
const r = NumRange(0, 5);
foreach (x; r) {
writeln(x);
}
```
results in
```
Error: mutable method test.main.NumRange.popFront is not callable using a const
object
```
even though foreach copies the input range it gets (as evident from running
foreach on same range twice), so it can at least try to copy it to an
non-const.

--

[Issue 17767] Dmd can't link recast.d, Gdc can't compile it and Ldc can perfectly compile it.

[via Digitalmars-d-bugs]

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

--- Comment #3 from ecstatic.coder  ---
Please could you simply download the latest file from Github and compile
locally with your own version of gdc.

https://github.com/senselogic/RECAST/blob/master/recast.d

If it compiles fine with your version, then I know it's just a compiler version
problem, not a compiler bug, and this will eventually be solved once I will be
able to use the same version as you :)

--

Re: DerelictGL3 reload crashes in 32 builds

[Mike Parker via Digitalmars-d-learn]

On Monday, 21 August 2017 at 02:40:59 UTC, Mike Parker wrote:

On Sunday, 20 August 2017 at 19:29:55 UTC, Igor wrote:
In 64 bit builds it works with both LDC and DMD but in 32 bit 
LDC version crashes and DMD release version crashes. Using LDC 
debug build I managed to find that it crashes after executing 
ret instruction from bindGLFunc in glloader. If someone wants 
to try it you can do it with this project: 
https://github.com/igor84/dngin. I was testing this from 
Visual Studio but dub 32 bit LDC build also crashed.


Am I doing something wrong or is this some known DerelictGL3 
or compiler issue?


This is a known issue [1] that I'm currently trying to resolve. 
I hadn't yet tested it using free functions (the bug report 
uses context types), so this new information helps.


[1] https://github.com/DerelictOrg/DerelictGL3/issues/56


I'm unable to reproduce this locally using my little test app. It 
only crashes for me in 32-bit when using context objects.


I also took your winmain.d module, modified it to compile with 
`dub --single`, then compiled and executed it with both the 
default architecture (-m32) and -m32mscoff (via dub's 
-ax86_mscoff command line argument). In both cases it compiled 
executed just fine.


Have you tried to compile outside of VisualD?

Re: delegates that return void + lambdas

[Steven Schveighoffer via Digitalmars-d-learn]

On 8/21/17 8:15 AM, Joshua Hodkinson wrote:
So I have run across the following issue while working with delegates 
and lambdas,



---
struct Struct {
 int prop;
}

alias Func = void delegate(ref Struct);
Func func = (ref s) => s.prop += 1;
---

with compiler error `Error: cannot return non-void from function`

I understand that the lambda syntax in this case would be short for

---
Func func = (ref s) { return s.prop += 1; };
---

But does this mean you can't have lambdas that return void?

Thanks


You can return void when your return type is void. When the return type 
is void, you can't return something other than void.


i.e., this should work:

alias Func = int delegate(ref Struct);

Or this:

void foo();

// with your original Func definition
Func func = (ref s) => foo();

You can also do this:

Func func = (ref s) { s += 1; };

-Steve

delegates that return void + lambdas

[Joshua Hodkinson via Digitalmars-d-learn]

So I have run across the following issue while working with 
delegates and lambdas,



---
struct Struct {
int prop;
}

alias Func = void delegate(ref Struct);
Func func = (ref s) => s.prop += 1;
---

with compiler error `Error: cannot return non-void from function`

I understand that the lambda syntax in this case would be short 
for


---
Func func = (ref s) { return s.prop += 1; };
---

But does this mean you can't have lambdas that return void?

Thanks

Re: DIP 1011-extern(delegate)--Formal Review

[Mike Parker via Digitalmars-d]

On Friday, 11 August 2017 at 10:45:03 UTC, Mike Parker wrote:
The first stage of the formal review for DIP 1011 [1], 
"extern(delegate)", is now underway. From now until 11:59 PM ET 
on August 25 (3:59 AM GMT on August 26), the community has the 
opportunity to provide last-minute feedback. If you missed the 
preliminary review [2], this is your chance to provide input.


Just to remind everyone: there are four more days remaining in 
the feedback period. If you have any input, type now!

Re: dmd (v2.075.0): fully static linking: undefined reference to `__tls_get_addr'

[Jacob Carlborg via Digitalmars-d-learn]

On 2017-08-19 16:07, kdevel wrote:

test.d
---
void main ()
{
}
---

$ dmd -c test.d
$ cc -o test test.o -L/[...]/dmd2/linux/lib64 -lphobos2 -static 
-lpthread -lrt
/[...]/dmd2/linux/lib64/libphobos2.a(sections_elf_shared_774_420.o): In 
function `_D2rt19sections_elf_shared11getTLSRangeFNbNimmZAv':
src/rt/sections_elf_shared.d:(.text._D2rt19sections_elf_shared11getTLSRangeFNbNimmZAv[_D2rt19sections_elf_shared11getTLSRangeFNbNimmZAv]+0x38): 
undefined reference to `__tls_get_addr'

collect2: error: ld returned 1 exit status

Found that on the net but no solution:
http://www.digitalmars.com/d/archives/digitalmars/D/learn/Static_linking_on_Linux_with_dmd_or_gcc_74954.html 



Any hints?


You can use LDC to statically link the binary.

--
/Jacob Carlborg

[Issue 17770] Null pointer access in CTFE code

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com

--- Comment #1 from ag0ae...@gmail.com ---
Slightly more reduced, and including a variant that throws an AssertError
instead of segfaulting:


struct S { T* t; }
struct T { string name; }

S foo(string name)
{
return S(new T(name[0 .. $]));
}

int bar(string name)
{
version (segfault)
size_t len = name.length; // segfault
else version (asserterror)
string n = name; // AssertError@ddmd/ctfeexpr.d(1854)
return 0;
}

const S s = foo("");
enum b = bar(s.t.name);


--

[Issue 17770] Null pointer access in CTFE code

[via Digitalmars-d-bugs]

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

Sönke Ludwig  changed:

   What|Removed |Added

   Keywords||CTFE, ice

--

[Issue 17770] New: Null pointer access in CTFE code

[via Digitalmars-d-bugs]

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

  Issue ID: 17770
   Summary: Null pointer access in CTFE code
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: slud...@outerproduct.org

Compiling the following snippet with DMD 2.076.0-b1 yields:

object.Error@(0): Access Violation

0x0042FF45

Earlier compiler versions produce similar errors.

---
struct S { T*[] nodes; }
struct T { string name; }

S foo(string text)
{
T*[] ret;
while (text.length) {
auto n = new T;
n.name = text;
text = text[1 .. $];
ret ~= n;
}
return S(ret);
}

string bar(in S doc)
{
foreach (n; doc.nodes)
baz(n);
return null;
}

void baz(in T* node)
{
switch (node.name) {
default:
case "|":
break;
}
}

static const n = foo("xx");
enum b = bar(n);
---

--

Re: std.range.put vs R.put: Best practices?

[Jon Degenhardt via Digitalmars-d-learn]

On Monday, 21 August 2017 at 05:58:01 UTC, Jonathan M Davis wrote:
On Monday, August 21, 2017 02:34:23 Mike Parker via 
Digitalmars-d-learn wrote:
On Sunday, 20 August 2017 at 18:08:27 UTC, Jon Degenhardt 
wrote:

> Documentation for std.range.put
> (https://dlang.org/phobos/std_range_primitives.html#.put) has
>
> the intriguing line:
>> put should not be used "UFCS-style", e.g. r.put(e). Doing 
>> this
>> may call R.put directly, by-passing any transformation 
>> feature

>> provided by Range.put. put(r, e) is prefered.
>
> This raises the question of whether std.range.put is always 
> preferred over calling an output range's 'put' method, or if 
> there are times when calling an output range's 'put' method 
> directly is preferred. Also, it seems an easy oversight to 
> unintentionally call the wrong one.

>
> Does anyone have recommendations or best practice 
> suggestions for which form to use and when?


It's recommended to always use the utility function in 
std.range unless you are working with an output range that has 
a well known put implementation. The issue is that put can be 
implemented to take any number or type of arguments, but as 
long as it has an implementation with one parameter of the 
range's element type, then the utility function will do the 
right thing internally whether you pass multiple elements, a 
single element, an array... It's particularly useful in 
generic code where most ranges are used. But again, if you are 
working with a specific range type then you can do as you 
like. Also, when the output range is a dynamic array, UFCS 
with the utility function is fine.


As for mitigating the risk of calling the wrong one, when you 
do so you'll either get a compile-time error because of a 
parameter mismatch or it will do the right thing. If there's 
another likely outcome, I'm unaware of it.


To add to that, the free function put handles putting different 
character types to a range of characters (IIRC, it also handles 
putting entire strings as well), whereas a particular 
implementation of put probably doesn't. In principle, a 
specific range type could do everything that the free function 
does, but it's highly unlikely that it will.


In general, it's really just better to use the free function 
put, and arguably, we should have used a different function 
name for the output ranges themselves with the idea that the 
free function would always be the one called, and it would call 
the special function that the output ranges defined. 
Unfortunately, however, that's not how it works. In general, 
IMHO, output ranges really weren't thought out well enough. 
It's more like they were added as a countepart to input ranges 
because Andrei felt like they needed to be there rather than 
having them be fully fleshed out on their own. The result is a 
basic idea that's very powerful but that suffers in the details 
and probably needs at least a minor redesign (e.g. the output 
API has no concept of an output range that's full).


In any case, I'd just suggest that you never use put with UFCS. 
Unfortunately, if you're using UFCS enough, it becomes habit to 
just call the function as if it were a member function, which 
is then a problem when using output ranges, but we're kind of 
stuck at this point. On the bright side, it's really only 
likely to cause issues in generic code where the member 
function might work with your tests but not everything that's 
passed to it. In other cases, if what you're doing doesn't work 
with the member function, then the code won't compile, and 
you'll know to switch to using the free function.




Mike, Jonathan - Thanks for the detailed responses!

Yes, by habit I use UFCS, there is where potential for the wrong 
call comes from. I agree also that output ranges are very 
powerful in concept, but the details are not fully fleshed out at 
this point. A few enhancements could make it much more compelling.


--Jon

Re: Folder Size

[Aravinda VK via Digitalmars-d-learn]

On Saturday, 19 August 2017 at 14:19:39 UTC, Vino.B wrote:

Hi All,

  I have written a small program to find the size of folder's , 
but the output is not as expected, hence request your help and 
advice on any techniques to reduce the run time of the program.


Requirement:
The script has to scan several file system

("C:\\Temp\\TEAM","C:\\Temp\\PROD_TEAM", "C:\\Temp\\BACKUP")

Display only the sub folder level 1 name whose name should not 
contain *DND* and size


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


Eg: C:\Temp\TEAM\USER_BACKUP , C:\Temp\PROD_TEAM\PROD_BACKUP , 
C:\Temp\BACKUP\SUPPORT_BACKUP


Need the folder name and size of each folder under
 C:\Temp\TEAM\USER_BACKUP , C:\Temp\PROD_TEAM\PROD_BACKUP , 
C:\Temp\BACKUP\SUPPORT_BACKUP


Program

import std.file: dirEntries, isFile, SpanMode;
import std.stdio: writeln;
import std.algorithm: filter;
import std.array: array;
import std.path;

auto AgedDirlst = [ "C:\\Temp\\TEAM\\USER_BACKUP" , 
"C:\\Temp\\PROD_TEAM\\PROD_BACKUP" , 
"C:\\Temp\\BACKUP\\SUPPORT_BACKUP" ];


void main ()
{
foreach (string i; AgedDirlst[0 .. $])
 {
	  auto dFiles = dirEntries(i, SpanMode.shallow).filter!(a => 
a.isDir && !globMatch(a.baseName, "*DND*")).array;

  foreach (d; dFiles)
{
  auto SdFiles = dirEntries(d, SpanMode.depth).array;
  foreach (f; SdFiles)
  writeln(f.dirName, "\t", f.size);

}
 }
writeln("*");
}

Output:

C:\Temp\TEAM\USER_BACKUP\DIR1   41129
C:\Temp\TEAM\USER_BACKUP\DIR1\dir3  68
C:\Temp\TEAM\USER_BACKUP\DIR1   0

C:\Temp\TEAM\USER_BACKUP\DIR2\dir4  3410
C:\Temp\TEAM\USER_BACKUP\DIR2\dir4  2277663
C:\Temp\TEAM\USER_BACKUP\DIR2   0
C:\Temp\TEAM\USER_BACKUP\DIR2   1156

C:\Temp\PROD_TEAM\PROD_BACKUP\dir1  41129
C:\Temp\PROD_TEAM\PROD_BACKUP\dir1\dir3 68
C:\Temp\PROD_TEAM\PROD_BACKUP\dir1  0
C:\Temp\PROD_TEAM\PROD_BACKUP\dir1\DND1 36590125
C:\Temp\PROD_TEAM\PROD_BACKUP\dir1  0

C:\Temp\PROD_TEAM\PROD_BACKUP\dir2\dir4 3410
C:\Temp\PROD_TEAM\PROD_BACKUP\dir2  0
C:\Temp\PROD_TEAM\PROD_BACKUP\dir2  1156

C:\Temp\BACKUP\SUPPORT_BACKUP\dir1\DND1 36590125
C:\Temp\BACKUP\SUPPORT_BACKUP\dir1  0
C:\Temp\BACKUP\SUPPORT_BACKUP\dir2\DND2 1156
---
Required Output
---
C:\Temp\TEAM\USER_BACKUP\DIR1   41197  
(41129+68)
C:\Temp\TEAM\USER_BACKUP\DIR2   2282229 
(3410+2277663+1156)
C:\Temp\PROD_TEAM\PROD_BACKUP\dir1  36631322 
(41129+68+36590125)

C:\Temp\PROD_TEAM\PROD_BACKUP\dir2  4566 (3410+1156)
C:\Temp\BACKUP\SUPPORT_BACKUP\dir1  36590125
C:\Temp\BACKUP\SUPPORT_BACKUP\dir2  1156

From,
Vino.B


Keep a variable to add the sizes of subdirs

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

ulong subdirTotal = 0;
foreach (d; dFiles)
{
subdirTotal = 0;
auto SdFiles = dirEntries(d, SpanMode.depth).array;
foreach(f; SdFiles) {
subdirTotal += f.size;
}
writeln(d, "\t", subdirTotal);
}

--
Aravinda
http://aravindavk.in

Re: Fix D's segfaults!

[Bastiaan Veelo via Digitalmars-d]

On Monday, 21 August 2017 at 08:11:15 UTC, Shachar Shemesh wrote:

On 20/08/17 22:34, Bastiaan Veelo wrote:
You are looking at the stack trace. The reason you don't see 
line numbers is probably that you did not compile with 
debugging information on?


No. It's the same problem as 
https://issues.dlang.org/show_bug.cgi?id=17727


It's a bug in DMD.

Shachar


I see, thanks.

Re: Fix D's segfaults!

[Shachar Shemesh via Digitalmars-d]

On 20/08/17 22:34, Bastiaan Veelo wrote:

On Sunday, 20 August 2017 at 19:14:10 UTC, Johnson Jones wrote:
Dne 20. 8. 2017 8:06 odpoledne napsal uživatel "Johnson Jones via 
Digitalmars-d" :


D has a major issue with segfaults! It always reports the fault in 
the lowest function that it occurs! This is completely useless!


std.file.FileException@std\file.d(755): Attempting to rename file 
X.lib to Y.lib: The system cannot find the file specified.


0x0041015E
0x00402C69
0x004025A3
0x00413ECF
0x00413E93
0x00413D94
0x0040DAD7
0x76D78744 in BaseThreadInitThunk
0x76FD582D in RtlGetAppContainerNamedObjectPath
0x76FD57FD in RtlGetAppContainerNamedObjectPath



[..]

This should be quite easy with a stacktrace, simply walk back until 
the location is in user code.


You are looking at the stack trace. The reason you don't see line 
numbers is probably that you did not compile with debugging information on?


No. It's the same problem as https://issues.dlang.org/show_bug.cgi?id=17727

It's a bug in DMD.

Shachar

Re: @safe(bool)

[Jonathan M Davis via Digitalmars-d]

On Monday, August 21, 2017 10:41:49 Danni Coy via Digitalmars-d wrote:
> > 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.
>
> you can still search or grep but it's now a two step process. when you
> grep the @safe attribute you will find the custom attribute declaration.
> you then search for the custom declaration. You need to do the first step
> exactly once for each codebase (unless you forget).
>
> It's more diffucult but only a little bit.

Except that someone could then be pulling in attributes from 3rd party
libraries and using those, meaning that you'll potentially have to go
digging through other libraries just to figure out whether a function is
being marked with @safe or not. You get some of that pain with any custom
attribute, but currently, the built-in attributes avoid it completely, and
being able to combine attributes makes it far worse, since then you
potentially have to go searching through a chain of declarations to figure
out which attributes are actually being used. I can understand folks wanting
to reduce how many attributes they have to manually put on functions, but I
think that it risks being a maintenance nightmare to have to deal with
combined or aliased attributes. I would _much_ rather see each attribute
applied individually, because it's far easier to figure out what's going on
that way. We already have enough problems figuring out which attributes are
in play when dealing with attribute inference. I _really_ don't want to see
aliasing and combining added to the mix - especially with the built-in
attributes. And that seems to be one of if not the main motivation of the
DIP.

- Jonathan M Davis

Re: Trial v0.3.1 is out

[Jacob Carlborg via Digitalmars-d-announce]

On 2017-08-20 22:56, Szabo Bogdan wrote:

Hi,

I added some new improvements to `trial` http://trial.szabobogdan.com/ 
which is a hackable test runner for D.


This release contains:

- Spec test discovery


Ah, I like it. Might give this a try.

--
/Jacob Carlborg

Re: Mixed up over mixins.

[WhatMeForget via Digitalmars-d-learn]

On Sunday, 20 August 2017 at 22:50:40 UTC, Johnson Jones wrote:

On Sunday, 20 August 2017 at 19:27:43 UTC, WhatMeWorry wrote:

[...]



It's not difficult, it's just new. It's not that you are a poor 
programmer, but you simply have not learned how to think about 
mixins correctly. Stop whining about it and focus that energy 
on working with them.


[...]


Thank you.  You have rejuvenated my quest for mixin mastery :)

Re: Fix D's segfaults!

[Nemanja Boric via Digitalmars-d]

On Sunday, 20 August 2017 at 18:01:06 UTC, Johnson Jones wrote:
D has a major issue with segfaults! It always reports the fault 
in the lowest function that it occurs! This is completely 
useless!


std.file.FileException@std\file.d(755): Attempting to rename 
file X.lib to Y.lib: The system cannot find the file specified.


0x0041015E
0x00402C69
0x004025A3
0x00413ECF
0x00413E93
0x00413D94
0x0040DAD7
0x76D78744 in BaseThreadInitThunk
0x76FD582D in RtlGetAppContainerNamedObjectPath
0x76FD57FD in RtlGetAppContainerNamedObjectPath

This tells me nothing about where the error occurred in *my* 
program!


Dmd needs to be modified so that errors try to show from the 
source code. This should be obvious the reasons, if it is not 
possible, make it possible! There are no excuses why dmd should 
make me go on an easter egg hunt when a seg fault occurs.


There are many issues and ideas reported in bugzilla about this: 
https://issues.dlang.org/show_bug.cgi?id=14885 
https://issues.dlang.org/show_bug.cgi?id=5944 etc. Here's the one 
that specifically tackles the `FileException` and the problem 
you're reporting: https://issues.dlang.org/show_bug.cgi?id=13543

Re: Mixed up over mixins.

[WhatMeForget via Digitalmars-d-learn]

On Sunday, 20 August 2017 at 19:41:14 UTC, Ali Çehreli wrote:

On 08/20/2017 12:27 PM, WhatMeWorry wrote:

> // Mixins are for mixing in generated code into the
source code.
> // The mixed in code may be generated as a template
instance
> // or a string.

Yes, it means that the string must be legal D code.

> mixin(`writeln(` ~ `Hello`  ~ `);` );

Yes, that's a D string but the string itself is not legal D 
code because it would be mixing in the following:


writeln(Hello);

The problem is, there is no Hello defined in the program.

You need to make sure that Hello is a string itself:

writeln("Hello");

So, you need to use the following mixin:

mixin(`writeln(` ~ `"Hello"`  ~ `);` );

Ali


Of course, why didn't I "see" that before. I should have slept on 
it and tried again with fresh eyes.  I'm keeping a "beginners 
journal" on code generation.  Maybe write a 101 introduction with 
lots of samples and exercises.


Thanks. Don't know if you noticed, but i used some code from your 
book. Hope you take that as a complement.

Re: Fix D's segfaults!

[Nemanja Boric via Digitalmars-d]

On Sunday, 20 August 2017 at 19:35:45 UTC, Ali Çehreli wrote:

On 08/20/2017 12:14 PM, Johnson Jones wrote:

>>> Dmd needs to be modified so that errors try to show from
the source
>>> code. This should be obvious the reasons, if it is not
possible, make
>>> it possible! There are no excuses why dmd should make me go
on an
>>> easter egg hunt when a seg fault occurs.

You can open an enhancement request at

  https://issues.dlang.org/enter_bug.cgi

I don't know how well it works with D but what I used to do 
with C++ was to put a break point at Exception constructor, 
which would give me the useful stack to go back to my own code.


Ali


The usual trick is to set the breakpoint on `_d_throwdwarf`.

Re: cv2pdb: cannot add symbols to module, probably msobj140.dll missing

[Rainer Schuetze via Digitalmars-d-debugger]

On 21.08.2017 05:24, Johnson wrote:

On Monday, 21 August 2017 at 03:18:38 UTC, Johnson wrote:
All of a sudden I'm getting this error. All I did was comment out a 
huge block of code so I could check something. The code compiles but 
the pdb conversion gives me that error ;/


Uncommenting out the code allows it to work again. I can't see why the 
code I'm commenting out would give that error ;/


Deleting the code also produces the same result.

It seems to be in use with GTK and event handlers. The handlers are 
completely isolated yet are somehow causing the problem.


You won't believe this, I'm sure, but

//Dialog.addOnDestroy((Widget w) {    });

causes the error! Must be some serious bug! Uncommenting allows the 
code to build fine.


I tried restarting visual D with no luck ;/


This just started happening too and a few hours ago I upgraded VS, so 
maybe the msobj140.dll changed and broke cv2pdb?  I copied it to the 
cv2pdb dir so it should have no trouble finding it. I've also cleaned 
the dir. It seems it's doing it on about everything I change. Going to 
reboot to see if that helps.




Unfortunately, the VS2017 15.3.1 update seems to cause quite some 
trouble. Bad linker (breaks TLS), bad vcvars*.bat (change current 
directory), and this issue, too.


I guess they changed something about the (undocumented) interface to the 
respective DLLs.

Re: Debugging Visual D using Visual D

[Rainer Schuetze via Digitalmars-d-debugger]

On 20.08.2017 20:32, Johnson Jones wrote:

On Friday, 18 August 2017 at 06:37:44 UTC, Rainer Schuetze wrote:






Glad you figured it out. I had to enable Visual D in the extension 
manager when using the local pkgdef.


Visual D installs for all users, so I think just installing into the 
users AppData is not an option. VS 2017 doesn't seem to inspect the 
"All Users" folders.


The installer is not supposed to write to the system registry for 
VS2017 related components. I see some bad entries for mago and two 
entries for marshalling some data, though, but they don't seem to have 
an impact on extension detection (IIRC they are needed during build).


It writes a few clsID's I think. about 2 or 3, let me check...

Computer\HKEY_CLASSES_ROOT\TypeLib\{002a2de9-8bb6-484d-9903-7e4ad4084715}
C:\Program Files (x86)\VisualD\vdserver.tlb


Computer\HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{002A2DE9-8BB6-484D-980E-7E4AD4084715} 
C:\Program Files (x86)\VisualD\visuald.dll


These are the ones referred to above that might be used during building.




Computer\HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{002a2de9-8bb6-484d-aa05-7e4ad4084715} 
C:\Program Files (x86)\VisualD\DParser\DParserCOMServer.exe


This one is needed to start the semantic engine as a local COM server.



Computer\HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{97348AC0-2B6B-4B99-A245-4C7E2C09D403} 


C:\Program Files (x86)\VisualD\Mago\MagoNatDE.dll

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\MagoDebugger


In theory Mago is not a VS debug engine, but a system wide COM component 
that can be used by other debugger frontends, too. I haven't seen 
another application using it, though.




Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VisualD


I also had to reinstall VisualD because for x64 the debugger would not 
run. That probably came from me deleting one of those directories(the 
ones referring to mago I guess).


So, I'm not sure if some of those keys are interfering with getting 
isolation between the VS versions or what, but it seems that Visual 
Studio load the registry version first before the extension package and 
also then caches it. This makes it impossible to actually use the 
isolated visual D even when everything is setup right as far as the 
pkgdef's.






IMO all of these registry keys should have no influence on extension 
loading.

Re: std.range.put vs R.put: Best practices?

[Jonathan M Davis via Digitalmars-d-learn]

On Monday, August 21, 2017 02:34:23 Mike Parker via Digitalmars-d-learn 
wrote:
> On Sunday, 20 August 2017 at 18:08:27 UTC, Jon Degenhardt wrote:
> > Documentation for std.range.put
> > (https://dlang.org/phobos/std_range_primitives.html#.put) has
> >
> > the intriguing line:
> >> put should not be used "UFCS-style", e.g. r.put(e). Doing this
> >> may call R.put directly, by-passing any transformation feature
> >> provided by Range.put. put(r, e) is prefered.
> >
> > This raises the question of whether std.range.put is always
> > preferred over calling an output range's 'put' method, or if
> > there are times when calling an output range's 'put' method
> > directly is preferred. Also, it seems an easy oversight to
> > unintentionally call the wrong one.
> >
> > Does anyone have recommendations or best practice suggestions
> > for which form to use and when?
> >
> > --Jon
>
> It's recommended to always use the utility function in std.range
> unless you are working with an output range that has a well known
> put implementation. The issue is that put can be implemented to
> take any number or type of arguments, but as long as it has an
> implementation with one parameter of the range's element type,
> then the utility function will do the right thing internally
> whether you pass multiple elements, a single element, an array...
> It's particularly useful in generic code where most ranges are
> used. But again, if you are working with a specific range type
> then you can do as you like. Also, when the output range is a
> dynamic array, UFCS with the utility function is fine.
>
> As for mitigating the risk of calling the wrong one, when you do
> so you'll either get a compile-time error because of a parameter
> mismatch or it will do the right thing. If there's another likely
> outcome, I'm unaware of it.

To add to that, the free function put handles putting different character
types to a range of characters (IIRC, it also handles putting entire strings
as well), whereas a particular implementation of put probably doesn't. In
principle, a specific range type could do everything that the free function
does, but it's highly unlikely that it will.

In general, it's really just better to use the free function put, and
arguably, we should have used a different function name for the output
ranges themselves with the idea that the free function would always be the
one called, and it would call the special function that the output ranges
defined. Unfortunately, however, that's not how it works. In general, IMHO,
output ranges really weren't thought out well enough. It's more like they
were added as a countepart to input ranges because Andrei felt like they
needed to be there rather than having them be fully fleshed out on their
own. The result is a basic idea that's very powerful but that suffers in the
details and probably needs at least a minor redesign (e.g. the output API
has no concept of an output range that's full).

In any case, I'd just suggest that you never use put with UFCS.
Unfortunately, if you're using UFCS enough, it becomes habit to just call
the function as if it were a member function, which is then a problem when
using output ranges, but we're kind of stuck at this point. On the bright
side, it's really only likely to cause issues in generic code where the
member function might work with your tests but not everything that's passed
to it. In other cases, if what you're doing doesn't work with the member
function, then the code won't compile, and you'll know to switch to using
the free function.

- Jonathan M Davis