Thread overview
October 30
statement1; statement2;

Would be nice to easily be able to set a BP just on statement2 without having to add a new line.



November 03

On 30/10/2018 16:21, Michelle Long wrote:
> statement1; statement2;
> 
> Would be nice to easily be able to set a BP just on statement2 without having to add a new line.
> 

I haven't seen this with the VS native debugger and C++, so I doubt it is feasible.
November 03
On Saturday, 3 November 2018 at 08:10:37 UTC, Rainer Schuetze wrote:
>
>
> On 30/10/2018 16:21, Michelle Long wrote:
>> statement1; statement2;
>> 
>> Would be nice to easily be able to set a BP just on statement2 without having to add a new line.
>> 
>
> I haven't seen this with the VS native debugger and C++, so I doubt it is feasible.

Supposedly it is possible. When you put a BP it has a "char" value which is usually set to 1. (you can see it in when you hover over the BP).

Supposedly setting the value to something else allows one to do BP's in the middle of lines. It may be only valid for certain languages though but it is doable in some cases as you can find information online about people doing it.

https://stackoverflow.com/questions/36166205/setting-a-breakpoint-in-the-middle-of-a-line-with-multiple-statements

https://stackoverflow.com/questions/3952782/setting-break-point-using-source-code-line-number-in-windbg

https://stackoverflow.com/questions/3952782/setting-break-point-using-source-code-line-number-in-windbg

So, this should be possible. After all, it's just a "virtual" problem having to do with whitespace.

November 04

On 03/11/2018 17:31, Michelle Long wrote:
> On Saturday, 3 November 2018 at 08:10:37 UTC, Rainer Schuetze wrote:
>>
>>
>> On 30/10/2018 16:21, Michelle Long wrote:
>>> statement1; statement2;
>>>
>>> Would be nice to easily be able to set a BP just on statement2 without having to add a new line.
>>>
>>
>> I haven't seen this with the VS native debugger and C++, so I doubt it is feasible.
> 
> Supposedly it is possible. When you put a BP it has a "char" value which is usually set to 1. (you can see it in when you hover over the BP).
> 
> Supposedly setting the value to something else allows one to do BP's in the middle of lines. It may be only valid for certain languages though but it is doable in some cases as you can find information online about people doing it.
> 
> https://stackoverflow.com/questions/36166205/setting-a-breakpoint-in-the-middle-of-a-line-with-multiple-statements

These examples are with the debugger for managed code (e.g. C#), not the debug engine for native applications.

I haven't yet seen any compiler (C++ or D) emit CodeView debug information that contains more than the line number.
November 04
On Sunday, 4 November 2018 at 08:27:34 UTC, Rainer Schuetze wrote:
>
>
> On 03/11/2018 17:31, Michelle Long wrote:
>> On Saturday, 3 November 2018 at 08:10:37 UTC, Rainer Schuetze wrote:
>>>
>>>
>>> On 30/10/2018 16:21, Michelle Long wrote:
>>>> statement1; statement2;
>>>>
>>>> Would be nice to easily be able to set a BP just on statement2 without having to add a new line.
>>>>
>>>
>>> I haven't seen this with the VS native debugger and C++, so I doubt it is feasible.
>> 
>> Supposedly it is possible. When you put a BP it has a "char" value which is usually set to 1. (you can see it in when you hover over the BP).
>> 
>> Supposedly setting the value to something else allows one to do BP's in the middle of lines. It may be only valid for certain languages though but it is doable in some cases as you can find information online about people doing it.
>> 
>> https://stackoverflow.com/questions/36166205/setting-a-breakpoint-in-the-middle-of-a-line-with-multiple-statements
>
> These examples are with the debugger for managed code (e.g. C#), not the debug engine for native applications.
>
> I haven't yet seen any compiler (C++ or D) emit CodeView debug information that contains more than the line number.


Is it then possible to simply split a line internally to handle it?

1. Surely the char/statement for the BP on a multi-statement line can be determined?

2. If such a BP exist then simply insert a new line in the text before compiling(I know it modifies the code but it's just whitespace and it could be an optional feature).

3. Then remove the inserted new line character after compiling. (might need to suppress file modifications temporarily).

4. When a BP is hit just re-calculate the line positions(will be offset by one and such.

Should be pretty simple to do and allows one to not have to worry about reformatting code just to add BP's.

I routinely do stuff like

if (x) return;

and I want a BP on the return, not the if. I have to insert the new line by hand just so I can add a BP!

Since this is a white space problem it really should be trival and technically should be supported by the compiler and debugger/IDE. It's a pretty basic problem and also helpful to have the ability to put BP's in the middle of lines.

It may actually be easier to implement though since the IDE already does have some of the capabilities.

November 20
On Sunday, 4 November 2018 at 21:17:32 UTC, Michelle Long wrote:
> On Sunday, 4 November 2018 at 08:27:34 UTC, Rainer Schuetze wrote:
>> [...]
>
>
> Is it then possible to simply split a line internally to handle it?
>
> [...]

Debug information is mapped to machine-code on a source line by source line basis.

Therefore it's indeed nontrivial to do this.
November 24
On Tuesday, 20 November 2018 at 15:11:56 UTC, Stefan Koch wrote:
> On Sunday, 4 November 2018 at 21:17:32 UTC, Michelle Long wrote:
>> On Sunday, 4 November 2018 at 08:27:34 UTC, Rainer Schuetze wrote:
>>> [...]
>>
>>
>> Is it then possible to simply split a line internally to handle it?
>>
>> [...]
>
> Debug information is mapped to machine-code on a source line by source line basis.
>
> Therefore it's indeed nontrivial to do this.

It is not non-trival. Just because you say it does not mean it is true.


It can be demonstrated to be very trivial to implement which proves you are wrong.

1. Parse d program, split all multi-statement lines in to multi-line statements keeping track of splits.

2. Pass modified program program to compiler.

3. Reverse map from 1 to convert any line numbers from compiler/debugger to original source.

Quite trivial.

I've found that the biggest excuse to thinking is claiming something is impossible.

I've also found that who ever is running this site is a bunch of assholes who block my posts because they think they are special.

When I post a legitimate post and they block it, they might as well go work for the gestapo. There "It's my way or the highway" mentality will ruin D for everyone who doesn't bow down to the flawed dogmas. (it's been scientifically proven that such moronic mentalities are what causes most social problems since open debate and communication is the only way to prevent myopicism. The will find out the hard way I suppose...)





November 26
On Tuesday, 20 November 2018 at 15:11:56 UTC, Stefan Koch wrote:
> On Sunday, 4 November 2018 at 21:17:32 UTC, Michelle Long wrote:
>> On Sunday, 4 November 2018 at 08:27:34 UTC, Rainer Schuetze wrote:
>>> [...]
>>
>>
>> Is it then possible to simply split a line internally to handle it?
>>
>> [...]
>
> Debug information is mapped to machine-code on a source line by source line basis.
>
> Therefore it's indeed nontrivial to do this.


Why would that be non-trivial?

semantically there is nothing different between

statement; statement;

and

statement;
statement;

to say that there is a difference to the compiler is not true.

To say it is non-trivial does not mean it is. You have to at least prove it with some reasonable logic because the facts do not support your claim.


Whatever mapping takes place, one just needs to propagate the column info along with the line. It may be non-trivial to implement in the compiler because of the design, but it is not a hard problem, in fact, it should be quite easy.


In fact, if the compiler simply broke every statement in to it's own line, by adding a new line to each statement(after every `;`) and memorized that mapping then it could be inverted to get the desired behavior... that is almost a trivial solution, so to say it is non-trivial simply does not jive and you will have to be more specific why.

For example, one could write a pre-parser that records the line and column mapping of statements, converts all multi-statement lines into multi-line statements. Compile, then unmap whatever the compiler says:

statement1; statement2; statement3;

Record line/col

0/0 0/12 0/24

convert

statement1;
statement2;
statement3;

0/0
1/0
2/0

map

0/0 -> 0/0
0/12 -> 1/0
0/24 -> 2/0

Then the mapping can be inverted after compilation.

E.g., If there is an error on line 2 it is looked up in the mapping

2/0 -> 0/24.

And so the error is actually at line 0/24 in the original sort(before newlines added).

It's quite simple. So you are simply wrong. One could write such a preprocessor and get the mapping and such and it would work fine. All it would require is to properly parse D code code to get the end of statements ';', insert a new line, and determine the mapping and for the debugger then to invert the map when line info is presented.

Because it is trivial to do, except for the D language processing(which the dmd parser should handle without problem and why it could be done in dmd transparently pre and post), it probably should be looked in to.

It's easy to say something is true or false... but it doesn't make it so. I've demonstrated a feasible solution.

Many people thought it was impossible to do X and they were proven wrong. Have you learned your lesson? We can at least then spend the time in finding an optimal way to do this so we all benefit from it.