Re: Beta 2.089.0
On Thursday, 17 October 2019 at 06:02:33 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.089.0 release, ♥ to the 44 contributors. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.089.0.html As usual please report any bugs at https://issues.dlang.org -Martin Martin, DMD has been unbuildable from ZIP files for many releases now. This has been reported to Bugzilla a while ago and has been asked about on the forum a few times. Could you please look into it? https://issues.dlang.org/show_bug.cgi?id=18791
Re: Blog post about printing associative arrays from GDB
On Thursday, 24 October 2019 at 14:20:42 UTC, Mihails wrote: On Thursday, 24 October 2019 at 13:16:39 UTC, Johannes Riecken wrote: GDB uses internal functions of C++'s runtime to do the pretty-printing for C++. Implementing that for D's runtime library in its current form would seem like a considerable effort to me, since D's runtime library seems to be a bit hairier with respect to the internal fields, no? That wouldn't be a considerable effort on its own (I think all necessary machinery is already part of druntime.rt package) but right now you would need to have druntime built with debugging symbols to get anything done. For C++ standard containers it is not a problem because those are defined in header files. If AA implementation was switched to templates, it would "just work" for druntime too. Cool, if you (or someone else) can give me the fields or functions in the druntime.rt package that can be used to print associative arrays from GDB, then I can try my hand at building a pretty-printer using GDB's Python API next week.
Re: DIP 1021--Argument Ownership and Function Calls--Formal Assessment
On Wednesday, 23 October 2019 at 16:54:36 UTC, 12345swordy wrote: "“But D has a GC!”, I hear you exclaim. No body said that. Funny how you chose the simplest argument to argue against. Yes, but it’s also a systems programming language with value types and pointers, meaning that today, D isn’t memory safe. DIP1000 was a step in the right direction, but we have to be memory safe unless programmers opt-out via a “I know what I’m doing” @trusted block or function. This includes transitioning to @safe by default." https://dlang.org/blog/2019/10/15/my-vision-of-ds-future/ -Alex Despite the mess DIP1000 was and still is, it did actually solve some problems. Even still there are bugs related to DIP1000 that aren't being fixed anymore cause the focus has already shifted away from it. The DIP1000 still says it will be "updated" but that's most likely never going to happen. Especially considering this DIP1021 has an example of a bug that the DIP doesn't even fix. For @safe, it is already safe if you use the GC. If you use @safe with DIP1021 you are restricting the user in what code they can write and it doesn't make their code any safer. This is just a flat restriction for no purpose for them. For manual memory management, this does not solve the problem illustrated by the DIP's example. Especially considering that in a blog post (formally unbeknownst to the DIP1021) the intention is to introduce a @live attribute. And the actual problem won't actually be fixed unless the @live attribute is there. So it doesn't benefit @safe users, it doesn't benefit manual memory management users and it won't come to fruition until some future attribute is implemented. I'm all for implementing Rust's memory management in D, but this is just horrible project management in all regards. Maybe it wouldn't be that big of a deal if it was a smaller project where you can muddle through finding your way willy nilly, but the whole purpose of the formalities -is- should be so you don't do that.
Re: Blog post about printing associative arrays from GDB
On Thursday, 24 October 2019 at 13:16:39 UTC, Johannes Riecken wrote: GDB uses internal functions of C++'s runtime to do the pretty-printing for C++. Implementing that for D's runtime library in its current form would seem like a considerable effort to me, since D's runtime library seems to be a bit hairier with respect to the internal fields, no? That wouldn't be a considerable effort on its own (I think all necessary machinery is already part of druntime.rt package) but right now you would need to have druntime built with debugging symbols to get anything done. For C++ standard containers it is not a problem because those are defined in header files. If AA implementation was switched to templates, it would "just work" for druntime too.
Re: Blog post about printing associative arrays from GDB
On Thursday, 24 October 2019 at 11:20:07 UTC, Mihails wrote: GDB has some dedicated functionality to improve pretty-printing and expression evaluation of things that too complex to figure out automatically: - https://sourceware.org/gdb/onlinedocs/gdb/Pretty-Printing.html - https://sourceware.org/gdb/onlinedocs/gdb/Writing-an-Xmethod.html GCC, for example, provides such scripts for improved debugging of C++ standard library as part of its distribution. Writing something similar for DMD/GDC/LDC shouldn't be too hard. GDB uses internal functions of C++'s runtime to do the pretty-printing for C++. Implementing that for D's runtime library in its current form would seem like a considerable effort to me, since D's runtime library seems to be a bit hairier with respect to the internal fields, no?
Re: Blog post about printing associative arrays from GDB
GDB has some dedicated functionality to improve pretty-printing and expression evaluation of things that too complex to figure out automatically: - https://sourceware.org/gdb/onlinedocs/gdb/Pretty-Printing.html - https://sourceware.org/gdb/onlinedocs/gdb/Writing-an-Xmethod.html GCC, for example, provides such scripts for improved debugging of C++ standard library as part of its distribution. Writing something similar for DMD/GDC/LDC shouldn't be too hard.
Re: Blog post about printing associative arrays from GDB
On Wednesday, 23 October 2019 at 21:07:24 UTC, Dennis wrote:
Thanks for spitting through the GDB manual so I don't have to!
I would've guessed something like this was possible with GDB,
but never bothered until now.
On Wednesday, 23 October 2019 at 20:52:55 UTC, Johannes Riecken
wrote:
is there a Phobos function to automatically print expected and
actual values for failed assertions? In our company we use
ocean's test!("==").
Not a phobos function, a compiler switch. In recent LDC and
DMD, you can use -checkaction=context and an attempt is made to
print the actual values involved in the assertion. It is still
young so you might still encounter bugs or limitations, but it
does the job really well for most asserts.
That looks promising. In the version I have installed (dmd
2.087.0) compilation crashes when using the flag and also
stdio.writeln, but playing around with the newest version in
run.dlang.io, it seems to work well with the cases I've tried,
cool!
Re: Beta 2.089.0
On Thursday, 17 October 2019 at 06:02:33 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.089.0 release, ♥ to the 44 contributors. Second beta is live now. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.089.0.html As usual please report any bugs at https://issues.dlang.org -Martin
