Re: LDC 1.17.0
On Sunday, 25 August 2019 at 14:00:08 UTC, kinke wrote: Glad to announce LDC 1.17: * Based on D 2.087.1. * The DMD fix wrt. 'local templates can now receive local symbols' hasn't been ported yet. * LLVM upgraded to v8.0.1. * Fix for v1.16.0 regression when returning void expressions. * Init symbols, TypeInfos and vtables of non-exported aggregates are now hidden with `-fvisibility=hidden`. * Don't ignore some options like `-lowmem` in response files. * Proper Unicode support for LDC/LDMD itself on Windows. * More fixes... Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.17.0 Thanks to all contributors! Thank you!
Re: LDC 1.16.0
On Friday, 21 June 2019 at 14:22:16 UTC, Martino wrote:
On Thursday, 20 June 2019 at 17:36:45 UTC, kinke wrote:
Glad to announce LDC 1.16:
* Based on D 2.086.1.
* Non-Windows x86: Faster `real` versions of
std.math.{tan,expi}.
* Windows: Fix linking DLLs with MinGW-based libs.
* WebAssembly: No need for an explicit `-L--export-dynamic`
anymore.
Full release log and downloads:
https://github.com/ldc-developers/ldc/releases/tag/v1.16.0
Thanks to all contributors!
The linux-armhf is no longer available? The last I know is for
the 1.13.0 version...
I made this docker image
https://hub.docker.com/r/rracariu/ldc-linux-armhf useful for
cross-compile.
One could modify it to build a native ARM version also.
Re: LDC 1.16.0
On Thursday, 20 June 2019 at 17:36:45 UTC, kinke wrote:
Glad to announce LDC 1.16:
* Based on D 2.086.1.
* Non-Windows x86: Faster `real` versions of
std.math.{tan,expi}.
* Windows: Fix linking DLLs with MinGW-based libs.
* WebAssembly: No need for an explicit `-L--export-dynamic`
anymore.
Full release log and downloads:
https://github.com/ldc-developers/ldc/releases/tag/v1.16.0
Thanks to all contributors!
Thanks!
Re: LDC 1.15.0
On Saturday, 6 April 2019 at 17:40:39 UTC, kinke wrote:
Glad to announce LDC 1.15:
* Based on D 2.085.1.
* Support for LLVM 8.0. The prebuilt packages ship with LLVM
8.0.0 and include the Khronos SPIRV-LLVM-Translator, so that
dcompute can now emit OpenCL too.
* New -lowmem switch to enable the GC for the front-end,
trading compile times for less required memory (in some cases,
by more than 60%).
* New generic @llvmAttr("name") parameter UDAs, incl. @restrict
with C-like semantics.
* Dropped support for 32-bit macOS. Min macOS version for
prebuilt package raised to 10.9.
* Prebuilt packages don't depend on libtinfo/libedit and don't
require SSSE3 anymore.
* Fix: functions annotated with `pragma(inline, true)` are
implicitly cross-module-inlined again.
[...]
Thank you!
Re: Visual D 0.49.0 released
On Sunday, 7 April 2019 at 19:41:43 UTC, Rainer Schuetze wrote: Hello, the new release of Visual D has just been uploaded. Some major improvements of 0.49.0: * support for Visual Studio 2019 * parallel compilation supported by VC projects * catch up with recent language changes * new "Language" configuration page for -transition=/-preview=/-revert= options See http://rainers.github.io/visuald/visuald/VersionHistory.html for the full list of changes. Visual D is a Visual Studio extension that adds D language support to VS2008-2019. It is written in D, its source code can be found on github: https://github.com/D-Programming-Language/visuald, pull requests welcome. The installer can be found at http://rainers.github.io/visuald/visuald/StartPage.html Rainer Great work, thanks! Found some issues in Visual Studio 2019 when debugging I get an occasional crash. Will post a bug once I can isolate the issue.
Re: D mention and mini-demo at FOSDEM in the RISC-V room
On Thursday, 14 March 2019 at 10:52:15 UTC, Iain Buclaw wrote: In-case it was missed, D running on RISC-V was used as part of a small demo (taken from https://dlang.org/wc.html) at FOSDEM last month in the Fedora Rawhide talk. Of other note, a couple of items in the Few (potentially annoying?) bits slide were discovered when I was porting D runtime with David. Video and Slides: https://fosdem.org/2019/schedule/event/riscvfedora/ Iain. Awesome that D got to be used for the demo part, nice job!
Re: Project Highlight: Spasm
On Friday, 1 March 2019 at 08:22:24 UTC, Sebastiaan Koppe wrote: On Friday, 1 March 2019 at 07:28:06 UTC, Radu wrote: Dip1000 would make reference counting safe. Memory management should be handled by reference counting. RC should delegate malloc, free to an allocator. I see. Yeah, RC could work. Sure. Hence my suggestion to implement a typed malloc. Probably an allocator and memcpy friends that works in betterc without any C dependencies would worth its own dub package :) :) dip1000 is usable right? yes, dip1000 is usable, albeit poorly documented.
Re: Project Highlight: Spasm
On Thursday, 28 February 2019 at 20:36:57 UTC, Sebastiaan Koppe wrote: On Thursday, 28 February 2019 at 12:47:32 UTC, Radu wrote: Re. the memory management section, I wonder if reference counting using dip1000 would work for memory management. At least partly. One memory issue spasm has is to release JS objects once D code is done with them. The approach I am likely to take is to simply disallow more than 1 reference to a JS object, and then when that reference is destroyed, to also destroy the JS object. Basically a non-copyable struct with a destructor. Over time this can be expanded with dip1000 to allow having more references to the same JS object as long as the compiler can prove it doesn't escape and has shorter lifetime. I don't see how dip1000 can help free memory though. You could also use the type system information for a D malloc implementation that uses free lists for known sizes. Something in line with https://github.com/JinShil/memcpyD I saw memcpyD before. In fact I used part of the implementation in a (uncompleted) wasm port of druntime. But again, I don't see how it would help with freeing unused objects. It is quite interesting to see that WebAssembly lines up pretty close to bare metal programming, maybe there are some synergies here that can be exploited and create the minimum runtimes for both. Definitely. Dip1000 would make reference counting safe. Memory management should be handled by reference counting. RC should delegate malloc, free to an allocator. Hence my suggestion to implement a typed malloc. Probably an allocator and memcpy friends that works in betterc without any C dependencies would worth its own dub package :) The complexity of the allocator and ref counting is drastically reduced as there is no multithreading involved.
Re: Project Highlight: Spasm
On Thursday, 28 February 2019 at 12:24:27 UTC, Mike Parker wrote: You may have seen Sebastiaan Koppe's announcements about his work with D and WebAssembly, the most recent regarding his project, Spasm. He sent me a great deal of information about the project, from which I was able to put together the first Project Highlight of 2019. He talks about how the project came about, what it does, and where it's going. The Blog: https://dlang.org/blog/2019/02/28/project-highlight-spasm/ Reddit: https://www.reddit.com/r/programming/comments/avqioi/spasm_d_to_webassembly_for_single_page_apps/ Nice! Re. the memory management section, I wonder if reference counting using dip1000 would work for memory management. You could also use the type system information for a D malloc implementation that uses free lists for known sizes. Something in line with https://github.com/JinShil/memcpyD It is quite interesting to see that WebAssembly lines up pretty close to bare metal programming, maybe there are some synergies here that can be exploited and create the minimum runtimes for both.
Re: LDC 1.14.0
On Sunday, 17 February 2019 at 15:46:01 UTC, kinke wrote: Glad to announce LDC 1.14: * Based on D 2.084.1. * Linking WebAssembly doesn't require an integrated LLD linker anymore (e.g., also working with distro packages and wasm-ld linker). * 32-bit LTO-able druntime/Phobos newly bundled with prebuilt Windows packages. * AddressSanitizer support for fibers. * Various fixes. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.14.0 Thanks to all contributors! Awesome! Thank you!
Re: Release D 2.084.1
On Monday, 11 February 2019 at 02:25:43 UTC, evilrat wrote: On Sunday, 10 February 2019 at 19:21:10 UTC, Martin Nowak wrote: Glad to announce D 2.084.1, ♥ to the 6 contributors. For some reason Windows installer is not signed, UAC shows this warning screen and there is no publisher specified. https://issues.dlang.org/show_bug.cgi?id=19670 Probably this needs a test after building the installer, so that it verifies the correct signature is present in the build artifact.
Re: Last Year in D
On Thursday, 24 January 2019 at 13:58:59 UTC, Mike Parker wrote: I said in my annual D Blog retrospective that I wanted to do a similar post focused on D at large. Sebastian Wilzbach sent me a tremendously helpful info dump of all sorts of goings on, most of which I knew nothing about. When I sat down to write the post, it occurred to me that since Adam Ruppe had recently revived 'This Week in D', it would be fun to have him write up a 'Last Year in D'. I asked, he accepted, I sent him Seb's data (thanks Seb!) and the result is now live on the blog. The blog: https://dlang.org/blog/2019/01/24/last-year-in-d/ Reddit: https://www.reddit.com/r/d_language/comments/ajclv0/last_year_in_d_the_d_blog/ No GDC merged in GCC mentions? Should count as a big thing IMHO.
Re: LDC 1.13.0
On Sunday, 16 December 2018 at 15:57:25 UTC, kinke wrote: Glad to announce LDC 1.13: * Based on D 2.083.1. * The Windows packages are now fully self-sufficient, i.e., a Visual Studio/C++ Build Tools installation isn't required anymore. * Substantial debug info improvements. * New command-line option `-fvisibility=hidden` to hide functions/globals not marked as export, to reduce the size of shared libraries. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.13.0 New Wiki page highlighting cross-compilation: https://wiki.dlang.org/Cross-compiling_with_LDC Thanks to all contributors! Awesome, thanks! How can the old visual studio linker be enabled? I tried to specify it trough -linker but it collides with the dmd linker.exe.
Re: Beta 2.082.0
On Saturday, 18 August 2018 at 08:30:31 UTC, Mike Franklin wrote: On Saturday, 18 August 2018 at 08:22:54 UTC, Mike Franklin wrote: It's a little old, but from what I'm reading we need "reputation" with Microsoft or an EV certificate, or publish on the Windows Store. I'm also reading that once the executable has been downloaded a number of times from different IP addresses, it will be registered as safe in Microsoft's database. Maybe we just need to wait for more people to download it and run it. Mike Yes, it needs to build up reputation trough multiple downloads and installations. This can take up to a week.
docker images
Created a couple of docker images useful for dlang dev. LDC cross compiler for ARM - https://hub.docker.com/r/rracariu/ldc-linux-armhf/ This image allows one to easily cross compile to ARM. Main use-case is continuous integration servers. - https://hub.docker.com/r/rracariu/dub-registry/ Allows easily running a private dub repository on cloud.
Re: Visual D 0.47.0 released
On Sunday, 24 June 2018 at 13:08:53 UTC, Rainer Schuetze wrote: Hi, a new release of Visual D has just been uploaded. Major changes are * improved Visual C++ project integration: better dependencies, automatic libraries, name demangling * new project wizard * mago debugger: show vtable, dynamic type of interfaces, symbol names of pointer address See http://rainers.github.io/visuald/visuald/VersionHistory.html for the full version history. Visual D is a Visual Studio extension that adds D language support to VS2008-2017. It is written in D, its source code can be found on github: https://github.com/D-Programming-Language/visuald, pull requests welcome. An installer can be found at http://rainers.github.io/visuald/visuald/StartPage.html Happy coding, Rainer Great work, Rainer! Thanks!
Re: LDC 1.9.0 beta
On Monday, 23 April 2018 at 09:18:07 UTC, Suliman wrote: What about Webassembly support? Latest LLVM suppport it, so LDC should support also. Might be interesting for game devs to have webassembly support, but no one pitched in to making it happen. One could start by getting `betterC` mode working and be fully supported on LDC/Webassembly, this will make D/LDC and interesting platform to develop on, and you can use a bunch of C/C++ libs also. Stage 2 is getting a webrutime (with minimal D runtime support) that targets webassembly and its peculiarities, like DOM and related bindings. Implementing `extern(ecmascript)` would also be a nice thing to have. All this needs a champion to make it happen :D
Re: LDC 1.9.0 beta
On Tuesday, 24 April 2018 at 15:53:23 UTC, Joakim wrote: On Monday, 23 April 2018 at 09:18:07 UTC, Suliman wrote: What about Webassembly support? Latest LLVM suppport it, so LDC should support also. We don't support a lot of platforms that llvm supports. It will require someone to work on the port, which hasn't happened. I've said before that I don't think it's worth it, because the web has been declining as a platform: https://forum.dlang.org/post/unqvdzopebfksnxwh...@forum.dlang.org On Tuesday, 24 April 2018 at 08:47:49 UTC, Radu wrote: On Sunday, 22 April 2018 at 15:56:49 UTC, kinke wrote: Hi everyone, on behalf of the LDC team, I'm glad to announce the first beta for LDC 1.9. The highlights of this version in a nutshell: * Based on D 2.079.1, including new `-i` switch and support for a minimal (d)runtime. * Support for LLVM 6, used for all prebuilt packages (except for Win32). * `-link-internally` able to (cross-)link Windows, Linux and macOS binaries. * Prebuilt Linux and macOS packages now shipping with LTO-able druntime/Phobos. * Improved support for MIPS targets and the uClibc runtime library. * Various fixes, incl. druntime/Phobos/ldc-jit .dylib issues on macOS. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.9.0-beta1 Thanks to all contributors! Looks that not all my druntime and phobos PR got in. Is this because they were not included in 2.0.79 mainline release? Yes, ldc releases are the same as dmd releases, with some ldc-specific changes. We generally don't backport features from upstream. ATM uClibc is not usable as is, it doesn't even compile because of various missing pieces, bummer :( Yeah, this beta doesn't even have a MIPS backend. How much of the testsuite do you have working on MIPS/uClibc? If you have it pretty far along, we can probably cherry-pick what you need and ship it with 1.9 for people to try. I realized that those PRs are not going to get in :(. Unfortunately it is pretty hard to contribute something that has a big impact. It looks that I need to wait another 2 releases to get all those changes in LDC as I might miss the 2.8.0 window for 1 PR, not counting additional patches for fixes that might come later on... uClibc fully passes druntime unit tests on ARM had float (armv7). phobos test runner segfaults on std.mathspecial, commenting out mathspecial - I get some asserts on formatting code related to double and some math asserts on some constants. Overall looks good and the formatting issues for double and math special segfault are not a priority for me, yet. on uClibc MIPS, druntime test hangs on everything after running core.runtime test at `void* z = pureMalloc(size_t.max - 2);`, malloc calls will fail after this (overcommit). Versioning it out I get the druntime unittest passing with an assert on core.atomic for double and some assert when allocating 390mb of memory in gc.impl.conservative.gc (way to much for my board). Overall druntime looks good. I don't have the details for phobos, but most of it passes. MIPS is a bit special as the vendor toolchain for my HW is pretty old and misses some supporting libs like libbacktrace, a math function etc.. had to stub them out. I think MIPS will require more tinkering from people trying it out.
Re: LDC 1.9.0 beta
On Sunday, 22 April 2018 at 15:56:49 UTC, kinke wrote: Hi everyone, on behalf of the LDC team, I'm glad to announce the first beta for LDC 1.9. The highlights of this version in a nutshell: * Based on D 2.079.1, including new `-i` switch and support for a minimal (d)runtime. * Support for LLVM 6, used for all prebuilt packages (except for Win32). * `-link-internally` able to (cross-)link Windows, Linux and macOS binaries. * Prebuilt Linux and macOS packages now shipping with LTO-able druntime/Phobos. * Improved support for MIPS targets and the uClibc runtime library. * Various fixes, incl. druntime/Phobos/ldc-jit .dylib issues on macOS. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.9.0-beta1 Thanks to all contributors! Looks that not all my druntime and phobos PR got in. Is this because they were not included in 2.0.79 mainline release? ATM uClibc is not usable as is, it doesn't even compile because of various missing pieces, bummer :(
Re: Vision document for H1 2018
On Friday, 16 March 2018 at 18:15:02 UTC, David Nadlinger wrote: On Thursday, 15 March 2018 at 10:48:45 UTC, Radu wrote: You have to remember that the really big first client of betterC(++) was DMD, porting DMD from C++ was a big undertaking. Right now both DMD and LDC use a form of betterC, so it is critical to have it finalized. This is entirely wrong. DMD and LDC rely extern(C++), but this has nothing to do with -betterC whatsoever. Both compilers link and initialise the runtime as normal (and then disable the GC at runtime). — David I stand corrected. I remembered something about druntime being used but last time I checked front end code was filled with strcpm and strlen, wrongly assumed that druntime was not used. Oh well... Still, probably D compilers will benefit from fixing mangling bugs and allow more integration with C++ std, right?
Re: Vision document for H1 2018
On Thursday, 15 March 2018 at 09:05:52 UTC, Kagamin wrote: On Sunday, 11 March 2018 at 04:06:13 UTC, Nick Sabalausky (Abscissa) wrote: First of all, betterC is about far more than interfacing with C. In fact, interop with C isn't really what betterC is about at all - that's a separate aspect of the language. (And those C/C++ users who still haven't come to D - for many of them the holdout is *because* of the issues betterC aims to address. What is that issue? Runtime? It can be solved with minimal runtime that one can write in an evening, compare it to betterC effort that has no end in sight. Make no mistake, for all the stockholm syndrome in the C and C++ worlds, there *are* a lot people openly wanting to jump ship but don't have a sufficient option yet. I'm afraid a sufficient option for them is proper C++ superset, betterC is only the first excuse, but not last. Personally, better DLL support have little to no impact on me. Obviously it does for you, and I sympathise. FWIW DLL support was always good enough for me. It is much more than runtime or no runtime. First of all, that goal (better interoperability) has been on the foundation priority list for several years, it is about time to "finish it up". You have to remember that the really big first client of betterC(++) was DMD, porting DMD from C++ was a big undertaking. Right now both DMD and LDC use a form of betterC, so it is critical to have it finalized. Second, it is a really good tool for validating a constraint environment, running D code with minimal runtime and compiler guarantees is very good thing to have in a system level programming language. Third, since it was introduced, it really helped better abstracting compiler internals and removing dependencies between compiler and runtime. People don't solve problems they don't have, hence introducing a new restriction added some stress that shaped a better version of D. As stated, D is a *system level programming language*, this means that ultimately needs to offer tools for embedded developers and OS kernel driver writers. betterC is one of those tools, and ultimately is part of the philosophy of pay-as-you-go, or a driving force to be better at it. Also, I think it fits nicely into "turtles all the way down" approach, as it makes the language orthogonal and more glued together vs. offering some vague advice on how to approach constraint systems, it provides rules and methods of enforcement. Lastly, the objective is a bit vague - there is no scope attached to it, maybe this needs clarifications. Even if it means fixing all the logged bugs related to it, it is a great step, at least for me.
Re: Article: Why Const Sucks
On Monday, 5 March 2018 at 10:57:35 UTC, Jonathan M Davis wrote: Here's something I wrote up on const: http://jmdavisprog.com/articles/why-const-sucks.html I suppose that it's not exactly the most positive article, but I feel that it's accurate. - Jonathan M Davis Spot on article, and touches some of my pain points when working with const/immutable structs. Recently I tried to create a ref-counted immutable struct, oh boi... This later use case is of tremendous value for safe concurrent code that's @nogc. Unfortunately I couldn't find a way to make it work efficiently and in the same time not look like a disgusting hack. I suspect a possible solution is to allow immutable(const) postblit overloads as well as immutable dtors that will act as an escape hatch for unsafe work and in the same time provide hints that you are operating on an immutable(const) this.
Re: Beta 2.079.0
On Monday, 19 February 2018 at 15:58:57 UTC, Joakim wrote: On Monday, 19 February 2018 at 15:45:30 UTC, bachmeier wrote: On Monday, 19 February 2018 at 10:49:03 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.079.0 release, ♥ to the 77 contributors for this release. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.079.0.html As usual please report any bugs at https://issues.dlang.org - This is probably the most feature-laden 2 month release ever. ... This looks good, but I'm not sure the many new features go well with the "2 month release" thing. I hope there are plans for a longer than usual testing period. Your announcement reads to me like it's going to be a regression bug release. 17. Allow multiple selective imports from different modules in a single import statement I have a bad feeling that that one is going to be a source of a raft of bugs for years to come. Indeed, I had a bad feeling about it when reading the change log, didn't made sense first time I read it, and had to parse the line 2 times to understand what's up with it. In the light of pretty much heated arguments following your post I think it should be wise to deffer releasing this feature for a future time, maybe drag it through a DIP? This should also serve as a lesson to Walter and Andrei on how to handle this kind of changes, now that the community is a bit larger simple changes (at surface) have a bigger ripple effect. Thanks.
Re: Release D 2.078.1
On Wednesday, 24 January 2018 at 20:05:42 UTC, Martin Nowak wrote: On Wednesday, 24 January 2018 at 13:30:42 UTC, Radu wrote: Just want to bring to your attention a major regression introduced in 2.078, and still present on current master, re. the new __equals template. https://issues.dlang.org/show_bug.cgi?id=18252 Comparing arrays of associative arrays is broken! Not to be insulting, but hoping for better understanding. Why, even when the compiler almost directly points to the problem at hand (a missing check for associative arrays :o, https://github.com/dlang/druntime/blob/a66f9fa78f2e295146fb2b3fc8e567983c9e9aed/src/object.d#L3486), doesn't this simply convert to a small pull request to fix the problem (https://github.com/dlang/druntime/pull/2058)? First of all, thanks for fixing it! No injuries suffered :D, but here is a list: - not so confident I understood the whole issue form that implementation, count it as lack of experience. - if wanting to get hands dirty - setting up the whole D dev env (compiler, runtime, tests) on a new machine it takes a while, at least the way I count it. - even if I get that running and make a change that runs on my machine, the outlook of time spent in ping-pong with the reviewers/auto-testers on a PR is daunting. To wrap it up - it is not `easy as pie` for random contributor to make even a simple PR because of the perceived overhead both in engineering and social aspects, that or I'm to lazy :O
Re: run.dlang.io - a modern way to run D code
On Thursday, 14 December 2017 at 15:46:03 UTC, Walter Bright wrote: On 12/12/2017 10:37 AM, Seb wrote: After it has been in stealth mode for quite a while, I'm happy to announce that there's https://run.dlang.io Very impressive! Nice work! Can I add a suggestion? Have an option to show the assembler created. Being able to quickly look at the assembler output is a great way to learn the 'cost' of writing code in various ways. (This is invaluable for someone wanting to be an A-list programmer.) You can use this one for nice assembly outputs https://d.godbolt.org/
Re: Visual D 0.46.0 released - more VS2017 and LDC integration
On Saturday, 2 December 2017 at 16:31:00 UTC, Rainer Schuetze wrote: Hi, I have just released version 0.46 of Visual D, see http://rainers.github.io/visuald/visuald/StartPage.html This release doesn't come with major new features, but a list of bug fixes and incremental improvements, those with the largest impact: * improved VS 2017 integration * improved LDC support * support for new symbol mangling and parsing 'static foreach' See http://rainers.github.io/visuald/visuald/VersionHistory.html for the full version history. Visual D is a Visual Studio extension that adds D language support to VS2008-2017. It is written in D, its source code can be found on github: https://github.com/D-Programming-Language/visuald, pull requests welcome. Happy coding, Rainer Cool stuff, thanks!
Re: dmd Backend converted to Boost License
On Friday, 7 April 2017 at 15:14:40 UTC, Walter Bright wrote: https://github.com/dlang/dmd/pull/6680 Yes, this is for real! Symantec has given their permission to relicense it. Thank you, Symantec! Glorious day for D and Dlangers. Congrats Walter for the tenacity and thanks Symantec for coming to senses:) Also, big up for the whole community as there is a big positive vibe around the news and nobody is complaining about basic stuff missing line website, docs, infrastructure etc. Cheers!
Re: Project Highlight: Visual D
On Friday, 12 August 2016 at 14:27:48 UTC, Mike Parker wrote: Rainer took some time out of his busy schedule to send me quite a bit of information regarding the development of Visual D. The post is now live at [1]. In the interest of space, I couldn't use it all of his content. If anything feels unclear or disjointed, that's on me and not Rainer. For the record, I'm quite excited about the upcoming VC project integration. As usual, the reddit link is at [2]. [1] https://dlang.org/blog/2016/08/12/project-highlight-visual-d/ [2] https://www.reddit.com/r/programming/comments/4xdr4y/from_the_d_blog_project_highlight_visual_d/ Mike, Just wanted to say you are doing an awesone work with your blog posts, greatly appreciated! Many thanks for Rainer's hard work also. Visual D is a very important piece of the D language ecosystem and something I use with pleasure on my D projects. Kudos to both of you!
Re: LDC 1.0.0 has been released!
On Monday, 6 June 2016 at 07:00:56 UTC, Kai Nacke wrote: Hi everyone, It is a great pleasure to announce that version 1.0.0 of LDC, the LLVM-based D compiler, is now available for download! The release is based on the 2.070.2 frontend and standard library and supports LLVM 3.5-3.8. We provide binaries for Linux, OX X, Win32 & Win64, Linux/ARM (armv7hf). :-) As usual, you can find links to the changelog and the binary packages over at digitalmars.D.ldc: http://forum.dlang.org/post/lwsnqbravjqbnnryv...@forum.dlang.org Regards, Kai Congrats!
Re: LLVM 3.8 released - and LDC is already able to use it!
On Tuesday, 8 March 2016 at 19:12:57 UTC, Kai Nacke wrote: Hi all! LLVM 3.8 has been released half an hour ago! See the release notes here: http://www.llvm.org/releases/3.8.0/docs/ReleaseNotes.html Downloads: http://www.llvm.org/releases/download.html#3.8.0 Also note that LDC is mentioned in the release notes as the only external project who is already supporting LLVM 3.8. Just recompile LDC using master or ltsmaster branch from GitHub to use this new LLVM release. This is the 8th time that LDC and D are mentioned in the LLVM release notes! Regards, Kai Awesome job guys!
Re: Graillon 1.0, VST effect fully made with D
On Friday, 27 November 2015 at 17:12:05 UTC, Jonny wrote: On Thursday, 26 November 2015 at 15:48:48 UTC, Guillaume Piolat wrote: [...] You have no idea what you are talking about! It is mentalities like yours that cause headaches for musicians and engineers who work with RT audio. [...] Dude, you missed the point completely. He did all RT stuff without a GC, he said that the GC can be made irelevant by using some clever optimizations and using the tools the language provides. I also suspect you don't really know how D's GC works.
Re: Walter and I talk about D in Romania
On Friday, 2 October 2015 at 11:25:44 UTC, Andrei Alexandrescu wrote: Walter and I will travel to Brasov, Romania to hold an evening-long event on the D language. There's been strong interest in the event with over 300 registrants so far. http://curiousminds.ro Scott Meyers will guest star in a panel following the talks. We're all looking forward to it! Andrei Awesome! To bad I will not be in Romania at the time, I bet will be a great event. Mult succes!
