On Tuesday, 2 May 2017 at 09:55:56 UTC, Stefan Koch wrote:
> [...]
>
> I intended for the debugging functionality to be exposed via a udp socket listening on localhost.
> Such that a debug-ui does not have to deal with ipc difficulties.

Hm, rationale for UDP over TCP here? I would assume one wouldn't want debugging info to be delivered out of order (or not at all); I mean, I guess it would be ok for localhost only (though one is then depending on implementation specifics vs. protocol semantics), but *if* you use sockets, you will eventually get people who use that over the network (and then the fun begins). Using TCP would just remove any potential future headache from the equation.

On Tuesday, 2 May 2017 at 22:08:31 UTC, Moritz Maxeiner wrote:
> On Tuesday, 2 May 2017 at 09:55:56 UTC, Stefan Koch wrote:
>> [...]
>>
>> I intended for the debugging functionality to be exposed via a udp socket listening on localhost.
>> Such that a debug-ui does not have to deal with ipc difficulties.
>
> Hm, rationale for UDP over TCP here? I would assume one wouldn't want debugging info to be delivered out of order (or not at all); I mean, I guess it would be ok for localhost only (though one is then depending on implementation specifics vs. protocol semantics), but *if* you use sockets, you will eventually get people who use that over the network (and then the fun begins). Using TCP would just remove any potential future headache from the equation.

I think any ordering should be done explicitly at the debugging protocol level.
for example when sending sourceline messages the order is given by the line number and ordering can be done by the application.
It's the same for breakpoint setting or for breakpoint trigger notification.
As for lost packages, we want to respond intelligently as well.
And maybe reduce the amount of data in the package, to make arrival of future packages more likely.

On Wednesday, 3 May 2017 at 04:22:00 UTC, Stefan Koch wrote:
> On Tuesday, 2 May 2017 at 22:08:31 UTC, Moritz Maxeiner wrote:
>> [...]
>> Using TCP would just remove any potential future headache from the equation.
>
> I think any ordering should be done explicitly at the debugging protocol level.
> for example when sending sourceline messages the order is given by the line number and ordering can be done by the application.
> It's the same for breakpoint setting or for breakpoint trigger notification.
> As for lost packages, we want to respond intelligently as well.
> And maybe reduce the amount of data in the package, to make arrival of future packages more likely.

So you're going to reinvent TCP in your debugging protocol?

On Wednesday, 3 May 2017 at 06:10:22 UTC, Adrian Matoga wrote:
> So you're going to reinvent TCP in your debugging protocol?


No. there is no need for a full blown recovery mechanism.

For the typical usecase a lossless orderd connection can be assumed.

And most things are not order dependent

On Wednesday, 3 May 2017 at 07:35:56 UTC, Stefan Koch wrote:
> On Wednesday, 3 May 2017 at 06:10:22 UTC, Adrian Matoga wrote:
>> So you're going to reinvent TCP in your debugging protocol?
>
>
> No. there is no need for a full blown recovery mechanism.
>
> For the typical usecase a lossless orderd connection can be assumed.
>
> And most things are not order dependent

What about packet boundaries?

On Sunday, 30 April 2017 at 13:26:09 UTC, Stefan Koch wrote:
> On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
>> [ ... ]
>
> Big news!
> The first step to include debug info has been done.
>
> Yes this means you will be able to step through ctfe code while the compiler executes it.

This should have been kept secret before C++ steals it and does not give credit to D. :D

An article about LLVM jit: https://webkit.org/blog/5852/introducing-the-b3-jit-compiler/

On Wednesday, 3 May 2017 at 08:23:54 UTC, Nordlöw wrote:
> On Wednesday, 3 May 2017 at 07:35:56 UTC, Stefan Koch wrote:
>> On Wednesday, 3 May 2017 at 06:10:22 UTC, Adrian Matoga wrote:
>>> So you're going to reinvent TCP in your debugging protocol?
>>
>>
>> No. there is no need for a full blown recovery mechanism.
>>
>> For the typical usecase a lossless orderd connection can be assumed.
>>
>> And most things are not order dependent
>
> What about packet boundaries?

We send source line by line.
Packets should be under 1k in most cases.

On Wednesday, 3 May 2017 at 04:22:00 UTC, Stefan Koch wrote:
> [...]
>
> I think any ordering should be done explicitly at the debugging protocol level.
> for example when sending sourceline messages the order is given by the line number and ordering can be done by the application.
> It's the same for breakpoint setting or for breakpoint trigger notification.

Why? If I were to write a client for the debugging protocol, I wouldn't want to write protocol ordering logic (and essentially reimplement part of tcp). I would want to react to protocol messages as they arrive.

> As for lost packages, we want to respond intelligently as well.

The only way I know of to respond intelligently to lost packages using udp - if you care about the information in them (which we do in this use case) - is to implement a retransmit mechanism; i.e. you would be reimplementing another part of tcp.

> And maybe reduce the amount of data in the package, to make arrival of future packages more likely.

You assume a causation between udp datagram size and delivery probability, which - however likely - is an implementation detail.

On Wednesday, 3 May 2017 at 07:35:56 UTC, Stefan Koch wrote:
> For the typical usecase a lossless orderd connection can be assumed.

- udp is not connection oriented, i.e. there is no connection
- udp is not lossless and pretending it is means setting yourself up for a headache down the road
- udp datagrams are not guaranteed to arrive in the order they were sent and pretending they do is also setting yourself up for a headache down the road

What you've described so far is a classic, textbook use case of tcp.