Re: LDC 1.1.0-beta6
On Tuesday, 13 December 2016 at 21:30:05 UTC, Andrei Alexandrescu wrote: On 12/13/2016 02:37 PM, kinke wrote: Hey all, on behalf of the LDC team I am proud to announce the new 1.1.0-beta6 release! It's based on the 2.071.2 frontend and standard library and supports LLVM 3.5 up to current trunk (4.0). This is awesome! Could you please tell what the expected lag time is between a dmd release and an ldc release? Also, obviously what we could do to improve that. Thanks! -- Andrei Do you mean the time it takes for LDC master to reach DMD release parity, or do you mean e.g. LDC 1.0.0 -> 1.1.0? The former is dependent on merging the ddmdfe in ours and the dealing with any conflicts in the changes we make to ddmdfe, (we bracket these in version(IN_LLVM) and version(IN_LLVM_MSVC) blocks to ease this). Johan is usually pretty quick, but identifying and dealing with any regressions that arise takes longer. The latter depends on the feature set we intend to implement and bugs and regressions and user feedback. For example 1.1.0-beta3 introduced a regression with dub causing all dub projects to fail to build, we got that report but not much else because hardly anyone was using beta3. Someone (was it you?) suggested splitting the ddmdfe off (or was it have everything under the dlang repo?), and have it be a dependency for each of the backends, so that the frontend stays in lockstep and we can identify regressions earlier, not sure how this would impact GDC. We also maintain druntime in a similar fashion to ddmdfe, although with a lot more additions for llvm features, probably less worth doing but still worth considering. This would also have the advantage of increased cross-visibility thus reducing regression times. The same repo solution would also increase the number of people familiar with the LDC codebase and therefore likely to help report and fix issues.
Re: DIP 1003: remove `body` as a keyword
On Thursday, 24 November 2016 at 14:06:40 UTC, Jonathan M Davis wrote: Personally, I don't care much about having body as a usable symbol. It occasionally would be useful, but I can live without it. However, I _do_ find it very annoying that it's required for the function body when you have contracts. After all, it's not required when you write the function normally. Why should it be required when you have contracts on the function? The braces after the contracts are clearly for the function body. They couldn't be for anything else. The compiler always requires that the body be last after the in and out contracts, making the body keyword totally redundant. So, I've never understood why the body keyword was required. As far as I can tell, it fixes no ambiguity. It's just extra typing, and it makes contracts that much more verbose, which makes me that much more inclined to just not bother with them and put the assertions in the function body - particularly when I'm already of the opinion that they add no value outside of inheritance, because assertions at the beginning of the function take care of in contracts, and unit tests are really what covers the out contract case anyway (particularly since it's very rare that you can have a general test for the out contract rather than testing that specific input results in specific output). - Jonathan M Davis General tests of output are not so rare. The premise of property-based testing is being able to write such tests. Going over the functions in std.algorithm, for almost every one of them I can find a nontrivial property that any output should satisfy (for a valid input).
Re: Mir Blog: Writing efficient numerical code in D
On Monday, 12 December 2016 at 21:58:23 UTC, Relja Ljubobratovic wrote: [1] http://blog.mir.dlang.io/ndslice/algorithm/optimization/2016/12/12/writing-efficient-numerical-code.html [2] https://github.com/libmir/dcv [3] https://github.com/libmir/dcv/pull/58 Very impressive work.
Re: LDC 1.1.0-beta6
On 12/13/2016 02:37 PM, kinke wrote: Hey all, on behalf of the LDC team I am proud to announce the new 1.1.0-beta6 release! It's based on the 2.071.2 frontend and standard library and supports LLVM 3.5 up to current trunk (4.0). This is awesome! Could you please tell what the expected lag time is between a dmd release and an ldc release? Also, obviously what we could do to improve that. Thanks! -- Andrei
Re: Fix suggestions for missing imports // code-d 0.15.0 & workspace-d 2.9.1 released
On Monday, 12 December 2016 at 21:42:50 UTC, WebFreak001 wrote:
[...]
I cannot for the life of me get it to work on Arch. I have
workspace-d from the AUR and the rest of dcd, dscanner, dfmt, dub
etc from the official repositories. They're all reachable via
$PATH so I haven't touched the path settings in vscode.
dlang sources on Arch are placed all wonky, right next to each
other in /usr/include/dlang/dmd (with no subdirectory distinction
for phobos/druntime), so I have a local copy of them in
~/src/dlang/{phobos,druntime}. The settings point there.
"d.stdlibPath": [
"/home/zorael/src/dlang/druntime/import",
"/home/zorael/src/dlang/phobos"
],
What does work is dcd on the current file, so I get local
autocompletion but nothing from imports. Aside from syntax
highlighting that's all I can see happening. Should there be a
menu for D things here somewhere?
When trying to install it manually, the last node command exits
with errors. I'm not sure if that's relevant to when installing
it through vscode itself.
$ node ./node_modules/vscode/bin/compile
The vscode extension module got updated to TypeScript 2.0.x.
Please see
https://code.visualstudio.com/updates/v1_6#_extension-authoring
for instruction on how to migrate your extension.
$ echo $?
1
What am I doing wrong?
Re: Fix suggestions for missing imports // code-d 0.15.0 & workspace-d 2.9.1 released
On Tuesday, 13 December 2016 at 14:09:53 UTC, WebFreak001 wrote: On Tuesday, 13 December 2016 at 00:25:27 UTC, Soulsbane wrote: On Monday, 12 December 2016 at 21:42:50 UTC, WebFreak001 wrote: I recently released workspace-d¹ 2.9.1 with many new additions and I released code-d² 0.15.0 just a few hours ago. [...] Question, will(or perhaps there already is an option and I missed it) there be an option to disable dfmt? I don't care anything about using it. I don't have it installed and everytime I open vscode it complains about it missing. Ah good idea, for now you can just set "d.dfmtPath": "echo" or any other executable which does basically nothing and that should work too. Next update will probably include this then. Cool, I'll give that a try thank! This is definitely my favorite D editor extension to use thanks for the hard work.
LDC 1.1.0-beta6
Hey all, on behalf of the LDC team I am proud to announce the new 1.1.0-beta6 release! It's based on the 2.071.2 frontend and standard library and supports LLVM 3.5 up to current trunk (4.0). Beta 6 is what beta 4 should have been, but early testing revealed some issues (thanks for reporting!) before official announcements were made, so we're at beta 6 now and looking forward to a final release, depending on your feedback! The highlights of this release are Link-Time Optimization, DLL exports on Windows and, as always, a multitude of bugfixes. This time, we only provide binaries for Linux, OS X and Windows; the usual FreeBSD and Linux/ARM (armv7hf) ones are missing due to limited manpower. Changelog and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.1.0-beta6 Please be sure to report any bugs at https://github.com/ldc-developers/ldc/issues, and feel free to drop by at the digitalmars.D.ldc forums (http://forum.dlang.org/group/digitalmars.D.ldc) for any questions or comments. Thanks to everybody involved in making this happen! Regards, kinke
Re: SecureD - A simple cryptography library for D
On 2016-12-13 09:20, Adam Wilson wrote: ld: in ../../.dub/packages/botan-1.12.8/botan/.dub/build/full-unittest-posix.osx-x86_64-dmd_2072-0D593375D53C36354213ADF6E4F6A036/libbotan_base.a(unique_40d1_3b6.o), in section __TEXT,__textcoal_nt reloc 2: symbol index out of range for architecture x86_64 Hmm, interesting. -- /Jacob Carlborg
Re: Mir Blog: Writing efficient numerical code in D
On Tuesday, 13 December 2016 at 15:31:00 UTC, Mike Parker wrote: https://www.reddit.com/r/programming/comments/5i42vc/writing_efficient_numerical_code_in_d/ Thank you, Mike!
Re: Mir Blog: Writing efficient numerical code in D
On Tuesday, 13 December 2016 at 09:58:09 UTC, Mike Parker wrote: On Tuesday, 13 December 2016 at 05:27:01 UTC, Andrei Alexandrescu wrote: This is awesome! Mike, could you please post to reddit about 11 hours from now if possible. Yes, I intend to post it to both reddit and FB, but it will have to be a couple of hours earlier than that (Korea is UTC+9). https://www.reddit.com/r/programming/comments/5i42vc/writing_efficient_numerical_code_in_d/
Re: Getters/setters generator
On Sunday, 11 December 2016 at 06:55:22 UTC, Mike Parker wrote: On Sunday, 11 December 2016 at 03:15:55 UTC, Mike Bierlee wrote: I was under the impression that you could only access methods as if they were fields using the @property attribute. After carefully reading the documentation I see this is not the case (UFCS does this). Still there are some added benefits from using @property to completely threat them as fields. It would be nice if you could add @property to the generated getters/setters. Right, any no-arg function can be called without parentheses, and single-arg functions can be called as 'func = foo'. At this point, I don't think think @property is ever going to be fixed to work as origiInally intended (and digging through the newsgroups will turn up several discussions on why, if you're interested). I don't bother with it anymore myself. DUB used to compile with it enabled by default, but no longer. I use it for intent. And I think it might affect overload sets? For example in my reflection library, I have a getValue function that returns metadata for a field or property, while getMethod would return it for just any old method.
Re: Fix suggestions for missing imports // code-d 0.15.0 & workspace-d 2.9.1 released
On Tuesday, 13 December 2016 at 00:25:27 UTC, Soulsbane wrote: On Monday, 12 December 2016 at 21:42:50 UTC, WebFreak001 wrote: I recently released workspace-d¹ 2.9.1 with many new additions and I released code-d² 0.15.0 just a few hours ago. [...] Question, will(or perhaps there already is an option and I missed it) there be an option to disable dfmt? I don't care anything about using it. I don't have it installed and everytime I open vscode it complains about it missing. Ah good idea, for now you can just set "d.dfmtPath": "echo" or any other executable which does basically nothing and that should work too. Next update will probably include this then.
Re: Mir Blog: Writing efficient numerical code in D
On Tuesday, 13 December 2016 at 05:27:01 UTC, Andrei Alexandrescu wrote: This is awesome! Mike, could you please post to reddit about 11 hours from now if possible. Yes, I intend to post it to both reddit and FB, but it will have to be a couple of hours earlier than that (Korea is UTC+9).
Re: Mir Blog: Writing efficient numerical code in D
On Monday, 12 December 2016 at 21:58:23 UTC, Relja Ljubobratovic wrote: http://blog.mir.dlang.io/ndslice/algorithm/optimization/2016/12/12/writing-efficient-numerical-code.html Awesome!
Re: SecureD - A simple cryptography library for D
Jacob Carlborg wrote: On 2016-12-12 08:07, Adam Wilson wrote: On OSX you need to use LDC or the linker will fail. What linker errors do you get using DMD? ld: in ../../.dub/packages/botan-1.12.8/botan/.dub/build/full-unittest-posix.osx-x86_64-dmd_2072-0D593375D53C36354213ADF6E4F6A036/libbotan_base.a(unique_40d1_3b6.o), in section __TEXT,__textcoal_nt reloc 2: symbol index out of range for architecture x86_64 -- Adam Wilson IRC: LightBender //quiet.dlang.dev
