Re: debugging in vs code on Windows

[Heromyth via Digitalmars-d-learn]

On Saturday, 14 October 2017 at 19:01:52 UTC, piotrklos wrote:

On Saturday, 14 October 2017 at 13:12:51 UTC, Jerry wrote:

On Friday, 13 October 2017 at 12:55:09 UTC, piotrklos wrote:

(...)


If you use generate a 32-bit binary using DMD, it generates it 
in a format that the C/C++ extension doesn't understand. You 
need to compile -m32mscoff or -m64, and you need to make sure 
the /DEBUG is passed to the linker, as I don't think dmd 
passes it that. You can do that by passing "-L/DEBUG" to DMD 
(when using -m32mscoff or -m64). There should be a .pdb file 
that gets generated, when you start the debugger it should say 
that symbols were loaded for the exe.


I also can't say for certain if debug information is even 
generated for the unittests, so that might be something worth 
looking into to make sure it does.


I have added this to dub.json:
"dmd-flags":[
"-g", "-m64", "-L/DEBUG"
]
but I don't see a pdb file generated when I build. What am I 
doing wrong?


It's not necessary to set "dmd-flags". You need to run dub with 
"--arch=x86_64 --build=debug". Then, the .pdb file is under the 
folder .dub.


To start a debug session, you would add a config file called 
launch.json, set the "program" and press F5.


By the way, don't foret to add a breakpoint.

Re: Assert and undefined behavior

[kdevel via Digitalmars-d-learn]

On Saturday, 14 October 2017 at 09:32:32 UTC, Timon Gehr wrote:
Also, UB can and does sometimes mean that the program can 
execute arbitrary code. It's called "arbitrary code execution": 
https://en.wikipedia.org/wiki/Arbitrary_code_execution


This confuses different levels of reasoning. In C/C++ "undefined 
behavior" is a property of the SOURCE code with respect to the 
specification. It states: The spec does not not apply, it does 
not define the semantic.


This issue is totally different from the question what a given 
program containing undefined behavior actually does after is 
compiles and the after the linker produces an executable. This is 
reasoning about generated MACHINE code.


A result of this confusion has been that some clever people tried 
to "detect" certain kinds of undefined behavior "after" they 
"happended". E.g. 
 This is the 
danger of undefined behavior: The MACHINE code may also work as 
the programmer expected. At least for some time.

Re: debugging in vs code on Windows

[Jerry via Digitalmars-d-learn]

On Saturday, 14 October 2017 at 19:01:52 UTC, piotrklos wrote:

On Saturday, 14 October 2017 at 13:12:51 UTC, Jerry wrote:

On Friday, 13 October 2017 at 12:55:09 UTC, piotrklos wrote:

(...)


If you use generate a 32-bit binary using DMD, it generates it 
in a format that the C/C++ extension doesn't understand. You 
need to compile -m32mscoff or -m64, and you need to make sure 
the /DEBUG is passed to the linker, as I don't think dmd 
passes it that. You can do that by passing "-L/DEBUG" to DMD 
(when using -m32mscoff or -m64). There should be a .pdb file 
that gets generated, when you start the debugger it should say 
that symbols were loaded for the exe.


I also can't say for certain if debug information is even 
generated for the unittests, so that might be something worth 
looking into to make sure it does.


I have added this to dub.json:
"dmd-flags":[
"-g", "-m64", "-L/DEBUG"
]
but I don't see a pdb file generated when I build. What am I 
doing wrong?


Are you sure it's not dflags? I don't use dub but a quick search 
shows there's dflags, but no flags setting.


https://code.dlang.org/package-format?lang=json

Also using verbose flag with dub should show you the commands 
that are executed for building.

Re: debugging in vs code on Windows

[piotrklos via Digitalmars-d-learn]

On Saturday, 14 October 2017 at 13:12:51 UTC, Jerry wrote:

On Friday, 13 October 2017 at 12:55:09 UTC, piotrklos wrote:

(...)


If you use generate a 32-bit binary using DMD, it generates it 
in a format that the C/C++ extension doesn't understand. You 
need to compile -m32mscoff or -m64, and you need to make sure 
the /DEBUG is passed to the linker, as I don't think dmd passes 
it that. You can do that by passing "-L/DEBUG" to DMD (when 
using -m32mscoff or -m64). There should be a .pdb file that 
gets generated, when you start the debugger it should say that 
symbols were loaded for the exe.


I also can't say for certain if debug information is even 
generated for the unittests, so that might be something worth 
looking into to make sure it does.


I have added this to dub.json:
"dmd-flags":[
"-g", "-m64", "-L/DEBUG"
]
but I don't see a pdb file generated when I build. What am I 
doing wrong?

Re: debugging in vs code on Windows

[Jerry via Digitalmars-d-learn]

On Saturday, 14 October 2017 at 14:23:34 UTC, piotrklos wrote:

On Saturday, 14 October 2017 at 13:20:27 UTC, Jerry wrote:

On Saturday, 14 October 2017 at 10:15:53 UTC, evilrat wrote:
webfreak's NativeDebug extension to be able to click to set 
breakpoint on lines(only for that).




You can just use VS Code setting, put the following into your 
settings.json:


"debug.allowBreakpointsEverywhere": true


But I can already click on the edge of editor and red bubble 
appears. Its just that the execution doesn't stop on those.


That comment wasn't for you, the other one was.

Re: Two way struct wrapper

[drug via Digitalmars-d-learn]

14.10.2017 16:23, Alex пишет:

On Saturday, 14 October 2017 at 12:39:17 UTC, Alex wrote:

ok, the last version for now. Without assumptions on alias number. Sorry 
for noise.


https://run.dlang.io/is/OSJYtY
That's cool, but unfortunately demands access to source code of Foo, 
it's not my case(
I improved your example a little bit - https://run.dlang.io/is/yeKofN, 
it's really great. Need polish of course, but this is a way to get more 
inheritance with structures.

Re: debugging in vs code on Windows

[piotrklos via Digitalmars-d-learn]

On Saturday, 14 October 2017 at 13:20:27 UTC, Jerry wrote:

On Saturday, 14 October 2017 at 10:15:53 UTC, evilrat wrote:
webfreak's NativeDebug extension to be able to click to set 
breakpoint on lines(only for that).




You can just use VS Code setting, put the following into your 
settings.json:


"debug.allowBreakpointsEverywhere": true


But I can already click on the edge of editor and red bubble 
appears. Its just that the execution doesn't stop on those.

Re: Two way struct wrapper

[Alex via Digitalmars-d-learn]

On Saturday, 14 October 2017 at 12:39:17 UTC, Alex wrote:

ok, the last version for now. Without assumptions on alias 
number. Sorry for noise.


https://run.dlang.io/is/OSJYtY

Re: debugging in vs code on Windows

[Jerry via Digitalmars-d-learn]

On Saturday, 14 October 2017 at 10:15:53 UTC, evilrat wrote:
webfreak's NativeDebug extension to be able to click to set 
breakpoint on lines(only for that).




You can just use VS Code setting, put the following into your 
settings.json:


"debug.allowBreakpointsEverywhere": true

Re: debugging in vs code on Windows

[Jerry via Digitalmars-d-learn]

On Friday, 13 October 2017 at 12:55:09 UTC, piotrklos wrote:
I have windows 10, VS Code with code-d and C/C++ language 
extensions. I try to debug but it doesn't work. In particular, 
the debugging doesn't stop on breakpoints. It exits 
immediately. I recompile with -m64 and -g. I use dub to build 
the project. I use unit-threaded and I'm trying to debug a 
unittest build.


Has anyone been able to debug in VS code on Windows? What am I 
doing wrong?


(Rhetorical) Why is dlang community provide so many options 
(see https://wiki.dlang.org/Debuggers) and **every single one** 
of them is faulty in some way? I tried windbg and mago-mi but 
didn't gen anywhere.


If you use generate a 32-bit binary using DMD, it generates it in 
a format that the C/C++ extension doesn't understand. You need to 
compile -m32mscoff or -m64, and you need to make sure the /DEBUG 
is passed to the linker, as I don't think dmd passes it that. You 
can do that by passing "-L/DEBUG" to DMD (when using -m32mscoff 
or -m64). There should be a .pdb file that gets generated, when 
you start the debugger it should say that symbols were loaded for 
the exe.


I also can't say for certain if debug information is even 
generated for the unittests, so that might be something worth 
looking into to make sure it does.

Re: Is there an opposite of .toString()?

[myst via Digitalmars-d-learn]

On Saturday, 14 October 2017 at 03:47:29 UTC, Jonathan M Davis 
wrote:
The function to use for conversions in general is std.conv.to. 
And really, there isn't much of a reason to ever call toString. 
Functions like writeln, format, and to may use it internally, 
but it's more or less an anti-pattern to do so in your own code 
- especially if we're talking about generic code. If you're 
looking to convert something to string, to!string works with 
pretty much everything and toString works with considerably 
less. And if there's a generic way to convert from string to 
something else, it's also with to - e.g. to!int("42"). However, 
for that conversion to work, it either has to be a built-in 
type so that to understands it, or the type will need a 
constructor that takes a string. In general, in order to 
generically convert to a user-defined type, either that target 
type must have a constructor that accepts that source type, or 
the source type must define opCast or an alias to convert to 
the target type. std.conv.to is very powerful, but it does need 
to have something to work with. If anything approaching a 
standard conversion exists, it can be done with std.conv.to; 
otherwise, it's going to depend on the type.


I think that in general, you're going to find that converting 
to a string works with most everything, but aside from built-in 
types, converting from a string with std.conv.to is unlikely to 
work. _Some_ types do have constructors that take strings, but 
most don't. Built-in types will work, because std.conv.to 
understands how to do that conversion. For user-defined types, 
either you're likely going to have to parse the string 
yourself, or they may contain another function for doing the 
conversion (for instance std.datetime.systime.SysTime uses 
toISOExtString and fromISOExtString to convert to and from the 
ISO extended format for a date and time and has other functions 
for other time formats).


This is not what I asked about.

You can also check out std.conv.parse, which acts similarly to 
std.conv.to, but whereas to converts the entire string, parse 
converts the first portion of a string and therefore is meant 
to allow for parsing multiple values from a string.


This is what I asked about. Thanks.

Re: Two way struct wrapper

[Alex via Digitalmars-d-learn]

On Saturday, 14 October 2017 at 11:25:20 UTC, Alex wrote:
of course, with the proper operator in line 32

return T(mixin("this" ~ op ~ "f"));

https://run.dlang.io/is/jGKVYN

Re: Two way struct wrapper

[Alex via Digitalmars-d-learn]

On Wednesday, 11 October 2017 at 12:35:51 UTC, drug wrote:
Using `alias this` it's easy to make wrapper for structure that 
calls wrapped structure methods like its own. This is one way - 
from wrapper to wrapped transformation. Is it possible to 
create the opposite way from wrapped to wrapper?


https://run.dlang.io/is/Avyu3I

All calls to Bar is redirected to Foo, but output of Foo is not 
redirected to Bar.


How about a template for the opBinary operator?
https://run.dlang.io/is/7gi5Wl

The code relies on the fact, that only one alias this is allowed.
https://dlang.org/spec/class.html#AliasThis

If more are possible at some moment, I suppose it will be 
possible to static foreach over them to choose the right member, 
based on its type.

Re: Huge increase in UT compile time

[Saurabh Das via Digitalmars-d-learn]

On Saturday, 14 October 2017 at 09:03:05 UTC, Joakim wrote:

On Saturday, 14 October 2017 at 04:36:25 UTC, Saurabh Das wrote:

[...]


I can reproduce on linux/x64, looks like a memory leak, as dmd 
balloons out to eat up all available memory until it's killed.  
I see it with this minimal command passed to dmd 2.075.1, but 
not the 2.074.1 frontend, as reported:


./dmd2/linux/bin64/dmd -c -o- foo.d -unittest -deps=foo.deps

The closest issue I was able to find in bugzilla is this one, 
but that says it goes away with -o-, not the case here:


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

I suggest one of you file a bug with the minimal command, 
noting that it goes away if -unittest or -deps is not passed.  
Make sure you mark it as a regression, just like the above bug, 
as Walter pays special attention to those.


Filed a bug report: https://issues.dlang.org/show_bug.cgi?id=17898

Hope I didn't miss anything.

Re: debugging in vs code on Windows

[evilrat via Digitalmars-d-learn]

On Saturday, 14 October 2017 at 07:40:31 UTC, piotrklos wrote:

On Friday, 13 October 2017 at 17:04:00 UTC, kerdemdemir wrote:

On Friday, 13 October 2017 at 12:55:09 UTC, piotrklos wrote:

(...)


I am using VisualD(https://github.com/dlang/visuald/releases) 
with vs2015 community version(free) and I can debug. I highly 
recommend it if you haven't tried yet. Those options like "-g"
 is presented to you with interfaces. Forexample "-g" is 
automatically is being added if you are selecting debug 
builds(like Debug DMD or Debug LDC).


I will consider that, but I really like VS Code because I often 
switch between Linux and Windows machine, so I can have the 
same thing on both.


Does VisualD play well with dub?


Only "dub generate visuald"

As for VS Code you need code-d extension, MS C++ extension in 
order to debug, and webfreak's NativeDebug extension to be able 
to click to set breakpoint on lines(only for that). Then under 
the debug pallette configure MS VS debugger and hit run from 
there. That's it.

Re: Assert and undefined behavior

[Timon Gehr via Digitalmars-d-learn]

On 14.10.2017 07:20, Jesse Phillips wrote:

On Thursday, 12 October 2017 at 15:37:23 UTC, John Burton wrote:


This is an example of what I mean :-

undefined what it is meant to do anyway, so the compiler can 
"optimize" out the if condition as it only affects the case where the 
language doesn't define what it's supposed to do anyway, and compiles 
the code as if it was :-


void test(int[] data)
{
    control_nuclear_reactor();
}



Yeah the C/C++ community/haters love to talk about all the code the 
compiler can inject because of undefined behavior. But that is not what 
it means.

...


It can mean that, but that is not even what happened in the given example.

The compiler does not know the value of data.length so it could not make 
such a transformation of the code.


The compiler can easily prove that the value of data.length does not 
change between the two points in the program. According to the 
specification, the behavior of the program is undefined in case the 
assertion fails, not just the behavior of the program after the 
assertion would have failed if it had not been removed.


Now had the assert been written 
before the if, you're telling the compiler some properties of 
data.length before you check it and it could make such optimizations.


The point is assert tells the compiler something it can use to reason 
about its job, not that it can insert additional runtime checks to see 
if you code is invalid an then add new jumps to execute whatever the 
hell it wants.




In the above example, a branch was removed, not added.

However, optimizers can add branches. (For example, it can check whether 
there is aliasing and use optimized code if it is not the case.)


Also, UB can and does sometimes mean that the program can execute 
arbitrary code. It's called "arbitrary code execution": 
https://en.wikipedia.org/wiki/Arbitrary_code_execution

Re: Huge increase in UT compile time

[Joakim via Digitalmars-d-learn]

On Saturday, 14 October 2017 at 04:36:25 UTC, Saurabh Das wrote:
On Wednesday, 11 October 2017 at 08:11:37 UTC, Jonathan M Davis 
wrote:
On Wednesday, October 11, 2017 06:25:19 Dhananjay via 
Digitalmars-d-learn wrote:

Hello,

I am upgrading to DMD 2.076.1 from DMD 2.069.2 (similar 
results on 2.075.1), and seeing a huge increase in unittest 
compilation time when the -deps parameter is also passed to 
dmd. This is on both OSX and linux. What can be the cause of 
this?


Well, that's a pretty big version jump. So, a lot could have 
changed. One thing that comes to mind would be that imports 
were overhauled pretty thoroughly to try and fix various 
import bugs. This blog article talks about some of that:


http://www.schveiguy.com/blog/2016/03/import-changes-in-d-2-071/

Or the change could be the result of something else entirely. 
Figuring it out would likely require doing a fair bit of 
debugging to narrow down when the change happened (and that's 
assuming that it's caused by a single commit or small set of 
commits rather than simply getting worse over time due to a 
variety of factors).


- Jonathan M Davis


The following observations (for the above test program) were 
recorded on Mac OS X 10.11.6:


DMD64 D Compiler v2.073.1
real0m0.091s
user0m0.067s
sys 0m0.020s

DMD64 D Compiler v2.074.0
real0m0.105s
user0m0.072s
sys 0m0.022s

DMD64 D Compiler v2.075.1
real0m44.932s
user0m35.732s
sys 0m7.098s

DMD64 D Compiler v2.076.1
real0m46.833s
user0m37.827s
sys 0m7.254s

Furthermore, 2.075.1 gave a bunch of deprecation warnings in 
std/string.d. The -de switch had to be removed before running.


Hope this helps,
Saurabh


I can reproduce on linux/x64, looks like a memory leak, as dmd 
balloons out to eat up all available memory until it's killed.  I 
see it with this minimal command passed to dmd 2.075.1, but not 
the 2.074.1 frontend, as reported:


./dmd2/linux/bin64/dmd -c -o- foo.d -unittest -deps=foo.deps

The closest issue I was able to find in bugzilla is this one, but 
that says it goes away with -o-, not the case here:


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

I suggest one of you file a bug with the minimal command, noting 
that it goes away if -unittest or -deps is not passed.  Make sure 
you mark it as a regression, just like the above bug, as Walter 
pays special attention to those.

Re: debugging in vs code on Windows

[piotrklos via Digitalmars-d-learn]

On Friday, 13 October 2017 at 17:04:00 UTC, kerdemdemir wrote:

On Friday, 13 October 2017 at 12:55:09 UTC, piotrklos wrote:

(...)


I am using VisualD(https://github.com/dlang/visuald/releases) 
with vs2015 community version(free) and I can debug. I highly 
recommend it if you haven't tried yet. Those options like "-g"  
is presented to you with interfaces. Forexample "-g" is 
automatically is being added if you are selecting debug 
builds(like Debug DMD or Debug LDC).


I will consider that, but I really like VS Code because I often 
switch between Linux and Windows machine, so I can have the same 
thing on both.


Does VisualD play well with dub?

Re: Assert and undefined behavior

[Jonathan M Davis via Digitalmars-d-learn]

On Saturday, October 14, 2017 05:20:47 Jesse Phillips via Digitalmars-d-
learn wrote:
> The point is assert tells the compiler something it can use to
> reason about its job, not that it can insert additional runtime
> checks to see if you code is invalid an then add new jumps to
> execute whatever the hell it wants.

+1

- Jonathan M Davis