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.
