debugger blues

[cy via Digitalmars-d]

On Friday, 25 March 2016 at 08:14:15 UTC, Iain Buclaw wrote:
> Have you considered raising a bug report as the compiler asks?
>
> http://bugzilla.gdcproject.org/

Yes, and that would be yet another gigantic software monstrosity 
that I have to compile the latest version in, and yet another 
signup process for their bug tracker, and yet another thing to 
keep track of. I'll get around to it.

The error was with just my distribution's release of GDC, so I'm 
pretty helpless to say that the bug even still exists. It was 
just a bug that made me wonder how people would even go and make 
a mistake like that.

> It's called stack trace, uncaught exceptions print this 
> information out.

No, the stack trace is the hierarchy of functions that are 
currently calling each other. I meant the functions that had been 
called previously, even the ones that have returned.

> This is something that you can do with signal handlers.

Ah, yes the wonder of being forced to use @nogc, nothrow, and 
@system. In the very accessible and undocumented spot of 
core.sys.c.signal! And heaven help you if you're trying to signal 
a process in Microsoft.

> There's more than one dwarf reader

yeah, I was exaggerating.

> Again, use OS signal handlers?

I tried! You can't even allocate a mutex! And then the thread you 
tried to signal dies anyway, because the signal gets sent to all 
of them! And then your process both exits and does not exit, and 
there's a mysterious copy of it in the background, despite you 
never forking, going at 100% CPU.

A nice setup for signal handlers would be really cool. But what D 
has now is... minimal.

> I'm afraid to say that only you can improve your own printf 
> messages.

Or, write a print function that actually puts spaces between the 
arguments, or write a function that adds the file and line so you 
know where the statement was written and don't have to go hunting 
for it. Or std.experimental.logger or whatever. I'd use 
std.experimental.logger except it DOESN'T LET YOU PUT SPACES 
BETWEEN THE ARGUMENTS >:(

(can you tell I programmed a lot in python?)

> etc.linux.memoryerror - you can use that for catching SIGSEGV 
> and dumping stacktrace.

Uh... huh. I didn't know about that. Actually I still don't know 
about that. It's not in phobos that I can see.

> I'd suggest that you do the same for other signals such as 
> SIGKILL

Handling SIGKILL, now that would be an accomplishment!
(Friar Tuck... I am under attack!  Pray save me!)

> Use @disable this(this); in your structs.

Well, obviously. But I meant a way to specify it in the function 
I'm writing. Like @nocopy or @move or something.

> In the library or in your program?  Last time I checked phobos 
> still has some way to go on that front.

In the library... ish. In the language. You can't pass an inout 
type as a template parameter to save it in a structure, so your 
structure can be agnostic of whether it's dealing with const or 
not, but you still have to write two identical member functions 
to set up and return that structure.

> But granted that const is transitive, you should introduce it 
> in a bottom up fashion.

The real problem is making code that works for both const and 
non-const, since like 99% of all code is exactly the same, just 
with "const" slapped on. What would be ideal is that you could 
label "frikkin everything" as const (except the stuff that 
actually does mutate) and the compiler would silently upgrade it 
to a mutable function if called with a mutable object, instead of 
erroring out and having to copypasta each function, to have a 
mutable version.

>> * it would be nice to be able to return an iterator whose 
>> elements are
> either const or not const, using inout, instead of having to 
> write the function twice.
>
> This should be very possible, but I wouldn't know where you are 
> going wrong.

inout only applies to function parameters, or function local 
variables. It so happens that a template parameter to a struct is 
outside of that, so Iterator!(inout(Item)) just flat out won't 
work.

Maybe you could define the structure inside the function, but 
then two functions couldn't share the same structure. And you 
can't define the template specialization inside the function, 
since inout can't be template parameters.

> ref MyStruct() { return s; }

...you can do that? Huh.

>> * heap allocated structs, stack allocated classes, it would be 
>> nice to
> have allocation strategy independent from layout strategy.
>
> Use pointer to structs and scope classes.

I know there are ways to do it. It would be nice if those ways 
weren't so verbosely explicit, just a flag or a switch or 
something. There's been a lot of work on allocators recently, so 
I remain hopeful that struct/class usage can become allocation 
strategy agnostic.

> I can not ask the hundreds of contributors to stop the 
> fantastic work they are doing.

What if I say pretty please?

>> * a pony
>
> Of all points above, this is one that can actually be arranged.
>  No joke!

I'll stick with ferrets, thanks.