Re: Article: Finding memory bugs in D code with AddressSanitizer
On Friday, 5 January 2018 at 01:32:50 UTC, Walter Bright wrote: On 1/3/2018 4:46 PM, Walter Bright wrote: On 1/3/2018 3:16 PM, Martin Nowak wrote: https://issues.dlang.org/show_bug.cgi?id=18190 This is a stack overflow caused by having 4096 expression statements. The compiler joins them with a commaexpression, and then recursively traverses it. > Nothing in the D part, not too surprising given dmd's approach to memory management though ;). Stack overflow has nothing to do with memory management. I'm a little curious about the stack overflow. I thought Linux would automatically extend the stack if it overflowed? it will, but only up to the rlimit. then it will SIGSEGV. http://man7.org/linux/man-pages/man2/getrlimit.2.html
Re: Article: Finding memory bugs in D code with AddressSanitizer
On 1/3/2018 4:46 PM, Walter Bright wrote: On 1/3/2018 3:16 PM, Martin Nowak wrote: https://issues.dlang.org/show_bug.cgi?id=18190 This is a stack overflow caused by having 4096 expression statements. The compiler joins them with a commaexpression, and then recursively traverses it. > Nothing in the D part, not too surprising given dmd's approach to memory management though ;). Stack overflow has nothing to do with memory management. I'm a little curious about the stack overflow. I thought Linux would automatically extend the stack if it overflowed?
Re: D code on CodeOcean
On Thursday, 4 January 2018 at 20:38:00 UTC, Johan Engelen wrote: Hi all, I made two example "capsules" on CodeOcean.com that demonstrate how to use D on that platform. CodeOcean is a platform for publishing reproducible code accompanying scientific publications for example. Hello World: https://codeocean.com/2018/01/04/d-lpar-dlang-rpar-hello-world VectorFlow (using dub): https://codeocean.com/2018/01/04/vectorflow-mnist-example-lpar-dlang-dub-rpar So if any of you is using D code in publications (Andrei?), consider publishing your code there :) Cheers, Johan Hi all, Seth Green, Developer Advocate at Code Ocean here. We wrote up a brief help article on using D on the platform https://help.codeocean.com/tips-and-tricks/new-and-additional-languages/installing-and-using-d-on-code-ocean. Note that I am not a native D user myself, so feedback on my explanation, and the use of the language on the platform, is most welcome. I'm seth at codeocean dot com. Looking forward to seeing more published work in D!
D code on CodeOcean
Hi all, I made two example "capsules" on CodeOcean.com that demonstrate how to use D on that platform. CodeOcean is a platform for publishing reproducible code accompanying scientific publications for example. Hello World: https://codeocean.com/2018/01/04/d-lpar-dlang-rpar-hello-world VectorFlow (using dub): https://codeocean.com/2018/01/04/vectorflow-mnist-example-lpar-dlang-dub-rpar So if any of you is using D code in publications (Andrei?), consider publishing your code there :) Cheers, Johan
Re: Article: Finding memory bugs in D code with AddressSanitizer
On Wednesday, 3 January 2018 at 23:16:45 UTC, Martin Nowak wrote: On 12/25/2017 06:03 PM, Johan Engelen wrote: I've been writing this article since August, and finally found some time to finish it: http://johanengelen.github.io/ldc/2017/12/25/LDC-and-AddressSanitizer.html Just built dmd with AddressSanitizer and ran dmd's, druntime's, and phobos' test-suite. Nice. Plans to make it part of CI ? -Johan
Re: Release D 2.078.0
On Thursday, 4 January 2018 at 13:03:21 UTC, Mike Parker wrote:
https://dlang.org/blog/2018/01/04/dmd-2-078-0-has-been-released/
In normal D code, struct destructors are executed when an
instance goes out of scope. This is handled by DRuntime, […]
This is slightly inaccurate. Regular stack cleanup doesn't
involve the runtime at all; druntime only comes into play for
exception handling. Since destructors also need to be run when
the scope is left by an exception, they are implemented via `try
{} finally {}` internally. The EH part of these depends on
druntime, but not the regular path.
One of the seemingly obscure features dependent upon DRuntime
is the ModuleInfo type. It’s a type that works quietly behind
the scenes as one of the enabling mechanisms of reflection and
most D programmers will likely never hear of it.
This is somewhat confusingly worded as well. It's actually mostly
the other way around – druntime depends on ModuleInfo to be
emitted, crucially for static constructor, destructors and unit
tests to be run. At least without shared libraries in the
picture, it would be fairly easy to manually look up the set of
ModuleInfos in a druntime-less D program.
— David
Re: Release D 2.078.0
On Thursday, 4 January 2018 at 15:53:33 UTC, Mike Parker wrote: On a related note, the vision document for 2018H1 has not yet been created. It's a WIP. If I may make a suggestion, please make the vision documents smaller and more focused. The goals laid out are typically far too broad to actually accomplish in half a year. Instead, the document should give detailed milestones for two or three long term goals which the community should complete in the six months. E.g. @safety: we aim to enable large-scale uses of D with safety guarantees and Static introspection: We believe this is an important strategic advantage of D and we should continue to improve both compiler support and library support. These are not actionable and can't be achieved in just six months of work. Instead, something like To move toward a @safe Phobos, std.json, std.file, and std.stdio should all be 100% @safe by June. Static introspection: we believe this is an important strategic advantage of D, so X, Y, and Z feature should be added by June gives contributors goals they can start making PRs for.
Re: Release D 2.078.0
On Thursday, 4 January 2018 at 15:51:55 UTC, jmh530 wrote: I've been really liking the blog write-ups on the new releases. Thanks! On a related note, the vision document for 2018H1 has not yet been created. It's a WIP.
Re: Release D 2.078.0
On Thursday, 4 January 2018 at 13:03:21 UTC, Mike Parker wrote: Blog: https://dlang.org/blog/2018/01/04/dmd-2-078-0-has-been-released/ Reddit: https://www.reddit.com/r/programming/comments/7o2tcw/dmd_20780_has_been_released/ I've been really liking the blog write-ups on the new releases. On a related note, the vision document for 2018H1 has not yet been created.
iopipe v 0.0.3 released
Updated in this release: * The buffer manager is more sane about allocating memory. It will limit growth to doubling. Previously if you asked it to allocate enough memory to hold size_t.max, it would try to do it. I'm still mulling over how to handle specific requests (i.e. I *know* I want this much data to start out with). * Added support for using Allocator.realloc. This means if you use Mallocator as your buffer allocator, it will use realloc if possible. This can generate huge speedups as less copying may be necessary. * unzip now supports concatenated gzip streams. This was a bit complex, and I've only tested it on one file, so please report bugs if you find any. * Fixed some possible integer overflow bugs. -Steve http://code.dlang.org/packages/iopipe https://github.com/schveiguy/iopipe/releases/tag/v0.0.3
Re: Release D 2.078.0
On Thursday, 4 January 2018 at 15:22:03 UTC, Joakim wrote: Nice post, good explanations and code samples. Here's some phrases I'd change: quality of life -> quality-of-life stubbed out -> stubbed-out line, or an alternative -> line or an alternate D runtime dependent -> that depends DMD 2.80.0 -> DMD 2.080.0 Thanks!
Re: Release D 2.078.0
On Thursday, 4 January 2018 at 13:03:21 UTC, Mike Parker wrote: On Thursday, 4 January 2018 at 02:27:13 UTC, Mike Parker wrote: Awesome! I'll post the blog announcement and hit social media in ~12 hours. Blog: https://dlang.org/blog/2018/01/04/dmd-2-078-0-has-been-released/ Reddit: https://www.reddit.com/r/programming/comments/7o2tcw/dmd_20780_has_been_released/ Nice post, good explanations and code samples. Here's some phrases I'd change: quality of life -> quality-of-life stubbed out -> stubbed-out line, or an alternative -> line or an alternate D runtime dependent -> that depends DMD 2.80.0 -> DMD 2.080.0
Re: Release D 2.078.0
On Thursday, 4 January 2018 at 02:27:13 UTC, Mike Parker wrote: Awesome! I'll post the blog announcement and hit social media in ~12 hours. Blog: https://dlang.org/blog/2018/01/04/dmd-2-078-0-has-been-released/ Reddit: https://www.reddit.com/r/programming/comments/7o2tcw/dmd_20780_has_been_released/
Re: excel-d v0.2.16 - now with more @Async
On Friday, 22 December 2017 at 00:41:31 UTC, Atila Neves wrote:
excel-d lets you write plain D code that can be run from Excel
unmodified via the magic of compile-time reflection.
Other than bug fixes, the main new feature since 0.2.15 is
@Async. Slap it on a function like so:
@Async
double myfunc(double d) {
// ...
return ret;
}
And it will be executed in a separate thread. Useful for long
running calculations / tasks so that they don't block the UI or
other calculations in the worksheet.
Can't this UDA style be used to mimic async/await?
Atila
Re: DLang docker images for CircleCi 2.0
On Wednesday, 3 January 2018 at 13:12:48 UTC, Seb wrote: tl;dr: you can now use special D docker images for CircleCi 2.0 --- version: 2 jobs: build: docker: - image: dlang2/dmd-circleci --- [...] do you orchestrate your containers in deployment?
Re: Release D 2.078.0
On Thursday, 4 January 2018 at 08:15:50 UTC, Rainer Schuetze wrote: What's missing is probably legacy_stdio_definition.lib that has to be added to the linker command line for VS2015 or later. Yes, that is the case! Using -v flag I can see that dmd 2.077 invokes C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\\bin\link.exe /NOLOGO app /OUT:"app.exe" /OPT:NOICF /LIBPATH:"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\\lib\amd64" /LIBPATH:"C:\Program Files (x86)\Windows Kits\10\\lib\x64" /LIBPATH:"C:\Program Files (x86)\Windows Kits\10\\lib\10.0.10240.0\ucrt\x64" legacy_stdio_definitions.lib While the new 2.078 just C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\link.exe /NOLOGO app /OUT:"app.exe" /OPT:NOICF /LIBPATH:"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\lib\amd64" /LIBPATH:"C:\Program Files (x86)\Windows Kits\10\lib\10.0.10240.0\um\x64" Please try replacing the Environment64 section in sc.ini with just this: [Environment64] LIB=%@P%\..\lib64 DFLAGS=%DFLAGS% -L/OPT:NOICF I'm using the variant from 7z archive (not installer). Its sc.ini section already looks very much like this.
Re: Release D 2.078.0
On Wednesday, 3 January 2018 at 17:43:36 UTC, Martin Nowak wrote: Glad to announce D 2.078.0. This release comes with runtime detection of Visual Studio installation paths, an integral promotion transition for unary operations on byte and short sized integers, more -betterC features, and a couple of language and library tweaks. Thanks to everyone involved in this https://dlang.org/contributors.html. http://downloads.dlang.org/releases/2.x/2.078.0/ http://dlang.org/changelog/2.078.0.html - -Martin Thank you very much!
Re: Release D 2.078.0
On 04.01.2018 07:25, thedeemon wrote: On Wednesday, 3 January 2018 at 17:43:36 UTC, Martin Nowak wrote: Glad to announce D 2.078.0. This release comes with runtime detection of Visual Studio installation paths I've got a problem with linking phobos64.lib now. I run "Visual C++ 2015 x64 Native Build Tools Command Prompt", i.e. cmd.exe with environment set up. With dmd 2.077.0 I run "dmd app.d -m64 -ofapp.exe" and it all goes well, compiles and links successfully. With dmd 2.078.0 I run "dmd app.d -m64 -ofapp.exe" and get: phobos64.lib(stacktrace_196a_3e5.obj) : error LNK2019: unresolved external symbol snprintf referenced in function _D4core3sys7windows10stacktrace10StackTrace13resolveNoSyncFAxmZAAa phobos64.lib(parseoptions_bee_21b.obj) : error LNK2001: unresolved external symbol snprintf phobos64.lib(demangle_ab0_79b.obj) : error LNK2001: unresolved external symbol snprintf phobos64.lib(parseoptions_bee_21b.obj) : error LNK2019: unresolved external symbol sscanf referenced in function _D4core8internal12parseoptions5parseFNbNiAxaKANgaKfQkZb app.exe : fatal error LNK1120: 2 unresolved externals Error: linker exited with status 1120 What's missing is probably legacy_stdio_definition.lib that has to be added to the linker command line for VS2015 or later. You can verify this by checking how dmd invokes the linker by adding -v to the dmd command line. I suspect this happens due to the new VS detection in dmd that hasn't been followed up by an appropriate installer update (unfortunately it didn't make it into this release). Please try replacing the Environment64 section in sc.ini with just this: [Environment64] LIB=%@P%\..\lib64 DFLAGS=%DFLAGS% -L/OPT:NOICF
