Re: The New CTFE Engine on the Blog
On 04/10/2017 06:07 AM, Mike Parker wrote:
Stefan has been diligently keeping us all updated on NewCTFE here in the
forums. Now, he's gone to the blog to say something to tell the world
about it.
The blog:
https://dlang.org/blog/2017/04/10/the-new-ctfe-engine/
Reddit:
https://www.reddit.com/r/programming/comments/64jfes/an_introduction_to_ds_new_engine_for_compiletime/
The first code sample is
private immutable ubyte[128] uri_flags = // indexed by character
({
// ...
})();
and the text says "The ({ starts a function-literal, the }) closes it.".
Why the extra parentheses? Just the curly brackets works, no?
private immutable ubyte[128] uri_flags = // indexed by character
{
// ...
}();
Ali
Re: automem v0.0.7 - C++ style smart pointers using std.experimental.allocator
On Tuesday, 11 April 2017 at 22:32:51 UTC, Martin Nowak wrote: On Monday, 10 April 2017 at 08:31:28 UTC, Atila Neves wrote: ```d import std.experimental.allocator.mallocator; UniqueArray!(int, Mallocator) a; a ~= [0,1]; ``` So the difference between std.container.Array and UniqueArray is that the latter supports allocators? That's the general idea, but I confess I didn't even look at Array. Atila
Re: automem v0.0.7 - C++ style smart pointers using std.experimental.allocator
On Monday, 10 April 2017 at 08:31:28 UTC, Atila Neves wrote: ```d import std.experimental.allocator.mallocator; UniqueArray!(int, Mallocator) a; a ~= [0,1]; ``` So the difference between std.container.Array and UniqueArray is that the latter supports allocators?
Re: GC blessed for C++ (again)
On Tuesday, 11 April 2017 at 16:50:20 UTC, jmh530 wrote: Is there a non-breaking way to do it that would increase the amount of flexibility while keeping the current behavior as a default? For instance, the equivalent of using std.experimental.allocator so that a user could switch between the default being GCAllocator or Mallocator, or something like that... From what I understand, the plan has always been to start to integrate std.experimental.allocator into Phobos when it stabilizes. There are some questions though: 1. How is this going to be done? Do we have the functions in Phobos allocate with theAllocator? Or, do we pass in an allocator type via template parameter? Or, do we pass in an allocator instance via function parameter? Each solution has it's own pros and cons. 2. How do you make it @safe? For the GC allocator, you can make allocation @safe, but not deallocation. So do you special case GCAllocator in Phobos code to not call GCAllocator.deallocate() and just let the GC collect? 3. How will @safe ref-counting play in with this? Andrei has his sights set on putting all strings in their own ref-counted store in order to make them @safe @nogc. Is RC going to be it's own allocator? I've never seen comprehensive plans or ideas about allocator integration. I've heard rumblings about a collections library that supposed to use it, but never seen anything.
Re: GC blessed for C++ (again)
On Tuesday, 11 April 2017 at 16:16:03 UTC, Jack Stouffer wrote: On Tuesday, 11 April 2017 at 07:02:19 UTC, Swoorup Joshi wrote: Breaking, you mean the standard library? or including user codebases? Taking the GC out of language constructs (e.g. ~=, AAs) would be a massive breaking change and would probably break the majority of D code in existence. Is there a non-breaking way to do it that would increase the amount of flexibility while keeping the current behavior as a default? For instance, the equivalent of using std.experimental.allocator so that a user could switch between the default being GCAllocator or Mallocator, or something like that...
Re: Call for arms: Arch Linux D package maintenance
On Thursday, 16 February 2017 at 19:58:47 UTC, Rory McGuire wrote: Hi, I am planning on asking to become TU for the dlang packages in community. I've been building and working with the current packages and making my own packages to make sure I know what I'm getting in to. LDC and GDC are matched with the system versions of llvm and gcc. If I can get TU approval I will put time in to these packages and hopefully make some Arch tools that use dlang to try and promote it more. To learn makepkg and nampac etc I built this [0], it is a set of PKGBUILD files that are loosely based on the way I use multiple official dmd compilers on my dev box. Some of my customers use older version of Vibe that do not build on current dmd. I actually normally use /usr/local/ and not /usr/lib for my dmd installation. It also has a little utility for switching between compilers versions, similar to archlinux-java. [0]: https://github.com/rjmcguire/archlinux-dmd Any news on this? The arch packages are listed as orphaned.
Re: GC blessed for C++ (again)
On Tuesday, 11 April 2017 at 07:02:19 UTC, Swoorup Joshi wrote: Breaking, you mean the standard library? or including user codebases? Taking the GC out of language constructs (e.g. ~=, AAs) would be a massive breaking change and would probably break the majority of D code in existence.
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On Tuesday, 11 April 2017 at 14:36:18 UTC, Ali Çehreli wrote: On 04/11/2017 02:35 AM, Joseph Rushton Wakeling wrote: will we see you at DConf? :-) Yes. I'm looking forward to it. :) Great! And, likewise :-)
Re: automem v0.0.7 - C++ style smart pointers using std.experimental.allocator
On Tuesday, 11 April 2017 at 10:24:08 UTC, Nicholas Wilson wrote: In LDC we have an attribute for that `allocSize` (https://github.com/ldc-developers/druntime/blob/ldc/src/ldc/attributes.d#L16) perhaps this attribute should be used across compilers and be in druntime? Nice, if pure required strong purity, it would be quite a huge hack, so a specific attribute seems friendlier.
Re: automem v0.0.7 - C++ style smart pointers using std.experimental.allocator
On Tuesday, 11 April 2017 at 08:09:15 UTC, Martin Nowak wrote: On Sunday, 9 April 2017 at 10:22:49 UTC, Atila Neves wrote: I did not. Thanks for telling me! The way I wrote it RefCounted!(shared T) works - RefCounted doesn't have to be shared itself, but I guess it could be. I think the other design is slightly more correct, having a single thread own a shared value => RefCounted!(shared T), having multiple threads own a value (which is transitively shared) => shared(RefCounted!T). The latter is also neede for `static shared RC!T rc;`. Unfortunately I later remembered that because it has a destructor it can't be shared and not shared with the sample implementation. And I'd really like to avoid having to have two different names like Rust does with Rc and Arc. Atila
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On Monday, April 10, 2017 23:08:16 Ali Çehreli via Digitalmars-d-announce wrote: > I will be presenting D as a time-saving tool at C++Now: > >http://cppnow.org/ > > I have to say it took me a very long time to come up with the title and > the abstract. How could I sell D to C++ experts? Luckily, I asked Manu > and among a long list of ideas he said "it's about saving time" and > "time is money". How can you argue with that? ;) > > Do you agree or disagree that D brings competitive advantage? Please let > me know. They may yet make it into C++ in some form or another, but the lack of ranges in C++ is one of the things that I find really frustrating when I doing stuff for work. In particular, it's incredibly quick and easy to write parsing code for stuff in D with Phobos, whereas it takes a lot more time and effort to write it in C++. But just in general, I find that putting stuff together in D is faster than using C++. C++ is very powerful, but it's also quite clunky. - Jonathan M Davis
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On Tuesday, 11 April 2017 at 09:35:39 UTC, Joseph Rushton Wakeling wrote: And the simple clarity of the syntax really helps compared to, say, C++. It's much easier to write and much easier to read and understand. So, once again, it's easier to move fast. As a D beginner I have to say that this one was very visible for me. I´m able to look at any D project read it and undertand it with ease. Very few times I was able to do it that easy looking on c++ sources.
Re: fluent-asserts released
On Sunday, 9 April 2017 at 13:30:54 UTC, Szabo Bogdan wrote:
Hi!
I just made an update to my fluent assert library. This is a
library that allows you to write asserts in a BDD style.
Right now, it contains only asserts that I needed in my
projects and I promise that I will add more in the future.
I would really appreciate any feedback that you can give me.
https://code.dlang.org/packages/fluent-asserts
Thanks!
I was looking for testing exceptions. It is not documented, but
the seems to be there. Still, it looks weird, because it does not
fit the style:
should.not.throwAnyException({
throw new Exception("test");
});
Re: automem v0.0.7 - C++ style smart pointers using std.experimental.allocator
On Tuesday, 11 April 2017 at 09:53:46 UTC, Martin Nowak wrote: I think we might be able to solve this problem in D by making IAllocator.allocate pure, which tells the compiler that this function returns a fresh piece of memory without any side-effect, i.e. enough information to optimize away allocations. Pure might be too restrictive for some allocators, but maybe this can be solved with a little type system hack (or at worse a compiler exemption). In LDC we have an attribute for that `allocSize` (https://github.com/ldc-developers/druntime/blob/ldc/src/ldc/attributes.d#L16) perhaps this attribute should be used across compilers and be in druntime?
Re: automem v0.0.7 - C++ style smart pointers using std.experimental.allocator
On Sunday, 9 April 2017 at 13:59:14 UTC, Andrei Alexandrescu wrote: . The allocator has to be specified as part of the type: this means the user can choose how to store it in the smart pointer, which for singletons (e.g. Mallocator) or stateless allocators means they can take up zero space. If a singleton (or the default theAllocator), the allocator doesn't need to be passed in to the constructor, otherwise it does. Specifying, e.g. Mallocator also means the relevant code can be marked @nogc. After extensively studying how C++ allocator framework works, I got to the notion that making the allocator part of the type is an antipattern. Just repeating an older argument of mine which didn't make it during the std.allocator discussions (http://forum.dlang.org/post/ubithltzbtdypaegn...@forum.dlang.org). Yes, we clearly want type erasure for the Allocator, because having the Allocator as part of the type tends to push Allocator choices/forwarding everywhere into the APIs. It also prevents conversion/copying values with different allocators. The obvious solution is to use an Allocator interface and/or a custom deleter function (deleter was needed for attribute correct destruction with polymorphic RC!Klass, see [¹]). Now as Chandler Carruth mentions, https://www.youtube.com/watch?v=fHNmRkzxHWs=3950 https://www.youtube.com/watch?v=fHNmRkzxHWs=4037 , an interface with dynamic dispatch would prevent optimizing away redundant allocations. Allocations are complex enough that I'm not too worried about the virtual call overhead itself. I think we might be able to solve this problem in D by making IAllocator.allocate pure, which tells the compiler that this function returns a fresh piece of memory without any side-effect, i.e. enough information to optimize away allocations. Pure might be too restrictive for some allocators, but maybe this can be solved with a little type system hack (or at worse a compiler exemption). [¹]: https://github.com/MartinNowak/phobos/commit/8cf0ec29ad65ac2a13bd6917b4ff3da0fdea5ab0#diff-4e008aedb3026d4a84f58323e53bf017R4896
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On 04/11/2017 08:50 AM, FreeSlave wrote: > D can't compete with C++ until it gets proper dynamic library support on > all platforms. As far as I understand there're still problems on Windows. Go fix it ;). Yes, we still need to make `export` work to replace `dllimport`/`dllexport`, then we can address the couple of low-level linking and TLS issues. Benjamin Thaut works on this and has a workable solution [¹]. Once this is done, DLL support should be on par with OSX/Linux/FreeBSD. Depending on what you want to do, you can already use D DLL's now, but atm. each DLL comes with it's own copy of the standard library, so different DLLs cannot talk to each other (see [²]). As with any ambitious project, we always want to do more than we have resources for, so things tend to not move as fast as everybody wants them to. -Martin [¹]: [pending PR dlang/DIPs#57](https://github.com/MartinNowak/DIPs/blob/fbad186cf9ac8dce335344e64d3b1d880bb750c0/DIPs/archive/DIP45.md) [²]: [Issue 7020 – Exception thrown across DLL is not caught.](https://issues.dlang.org/show_bug.cgi?id=7020)
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On Tuesday, 11 April 2017 at 06:08:16 UTC, Ali Çehreli wrote: Do you agree or disagree that D brings competitive advantage? Please let me know. Agree. There are different tradeoffs, obviously, and it won't suit all use-cases, but the ability to iterate fast through highly performant and provably correct code is very striking. If you manage your compile-time generics well -- i.e. using them to generalize for use cases that you definitely have, rather than premature generalization -- you can get a lot of power out of this that really helps with _effective_ code re-use. Compile time checks, contracts, and easy built-in unittests all make a big help in being able to make changes to code while maintaining confidence in its correctness -- again, making it faster to get things done. And the simple clarity of the syntax really helps compared to, say, C++. It's much easier to write and much easier to read and understand. So, once again, it's easier to move fast. Are you attending the conference? Not C++Now, I'm afraid. But will we see you at DConf? :-)
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On Tuesday, 11 April 2017 at 06:08:16 UTC, Ali Çehreli wrote: I will be presenting D as a time-saving tool at C++Now: http://cppnow.org/ I have to say it took me a very long time to come up with the title and the abstract. How could I sell D to C++ experts? Luckily, I asked Manu and among a long list of ideas he said "it's about saving time" and "time is money". How can you argue with that? ;) Do you agree or disagree that D brings competitive advantage? Please let me know. Safety (bounds checking, @safe, memory safety) is huge for debugging. You can probably steal a lot from Walters DConf Talk. Compilation time, because a quick iteration of edit-compile-test is significant for productivity and really underrated. C++ interop, so you can migrate from C++ to D in small steps and without building a C API bridge. Little things C++ lacks because it is too old: A package manager, a standard string type. Meta programming naturally, but "static if" might trail into discussions about concepts, so it is a little bit dangerous?
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On 2017-04-11 08:50, FreeSlave wrote: D can't compete with C++ until it gets proper dynamic library support on all platforms. As far as I understand there're still problems on Windows. And no official support on macOS. -- /Jacob Carlborg
Re: fluent-asserts released
On 2017-04-10 22:41, Atila Neves wrote: It'll work, but it won't end up reporting it the same way. If you'd like that to work seamlessly it's a question of having `version(Have_unit_threaded)` (or however it is it's spelled) that imports and throws `unit_threaded.should.UnitTestException`. Then Bob's your uncle. Ok, I see, thanks. On the other hand I just remembered that unit-threaded already have a very similar API for the assertions. -- /Jacob Carlborg
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On Tuesday, 11 April 2017 at 06:08:16 UTC, Ali Çehreli wrote: I will be presenting D as a time-saving tool at C++Now: http://cppnow.org/ Looks like C++Now has two keynotes. One keynote on D and one keynote on Rust. Maybe they should change their name. ;)
Re: D support for the Meson build system
On 04/11/2017 09:44 AM, Atila Neves wrote: > That's correct - __traits(getUnitTests) is broken unless compiling all > at once which is extremely unfortunate. I've filed a dmd bug already. > It's been on my TODO list for a while to fix it myself. [Issue 16995 – __traits(getUnittests) doesn't work with separate compilation](https://issues.dlang.org/show_bug.cgi?id=16995) Somewhat similar to [Issue 14894 – mangling of mixins and lambdas is not unique and depends on compilation flags](https://issues.dlang.org/show_bug.cgi?id=14894) Backlog Card: https://trello.com/c/YuW4JycJ/36-mangling-of-mixins-and-lambdas-can-change-w-unittest-or-other-versions
Re: automem v0.0.7 - C++ style smart pointers using std.experimental.allocator
On Sunday, 9 April 2017 at 08:56:52 UTC, Atila Neves wrote: http://code.dlang.org/packages/automem You might find my own containers interesting, especially https://github.com/nordlow/phobos-next/blob/master/src/array_ex.d Supports all the different ways I could think an array needs to work: https://github.com/nordlow/phobos-next/blob/master/src/array_ex.d#L64 https://github.com/nordlow/phobos-next/blob/master/src/array_ex.d#L90 https://github.com/nordlow/phobos-next/blob/master/src/array_ex.d#L1677 Does not (yet) support custom allocators, though. But that can be added, if requested. Are now in extensive use in my (non-public) applications.
Re: automem v0.0.7 - C++ style smart pointers using std.experimental.allocator
On Sunday, 9 April 2017 at 10:22:49 UTC, Atila Neves wrote: I did not. Thanks for telling me! The way I wrote it RefCounted!(shared T) works - RefCounted doesn't have to be shared itself, but I guess it could be. I think the other design is slightly more correct, having a single thread own a shared value => RefCounted!(shared T), having multiple threads own a value (which is transitively shared) => shared(RefCounted!T). The latter is also neede for `static shared RC!T rc;`.
Re: D support for the Meson build system
On Tuesday, 11 April 2017 at 07:34:58 UTC, Russel Winder wrote: On Mon, 2017-04-10 at 12:41 +, Matthias Klumpp via Digitalmars-d- announce wrote: […] I am not buying the necessity of not-splitbuilding for optimizations yet. If that would be the case, how do optimizations work with projects using GCC/Clang where splitbuilding is the default and often only option (like Mesa, Linux, lots of scientific stuff). […] It seems that unit-threaded cannot be built module at a time due to various reflection bits, the only solution is all source at once. That's correct - __traits(getUnitTests) is broken unless compiling all at once which is extremely unfortunate. I've filed a dmd bug already. It's been on my TODO list for a while to fix it myself. Atila
Re: D support for the Meson build system
On Mon, 2017-04-10 at 12:41 +, Matthias Klumpp via Digitalmars-d- announce wrote: > […] > I am not buying the necessity of not-splitbuilding for > optimizations yet. If that would be the case, how do > optimizations work with projects using GCC/Clang where > splitbuilding is the default and often only option (like Mesa, > Linux, lots of scientific stuff). […] It seems that unit-threaded cannot be built module at a time due to various reflection bits, the only solution is all source at once. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: GC blessed for C++ (again)
On Tuesday, 11 April 2017 at 07:02:19 UTC, Swoorup Joshi wrote: On Monday, 10 April 2017 at 04:49:34 UTC, Jack Stouffer wrote: On Monday, 10 April 2017 at 04:17:21 UTC, Swoorup Joshi wrote: On Wednesday, 28 September 2016 at 20:50:28 UTC, Ali Çehreli wrote: https://www.reddit.com/r/programming/comments/54xnbg/herb_sutters_experimental_deferred_and_unordered/ Ali Is it possible to have something similar as in library rather than GC in core language construct? Not without breaking changes. Breaking, you mean the standard library? or including user codebases? There's nothing stopping anyone from writing something similar in D. It just wouldn't make `new` not allocate on the GC heap. Atila
Re: GC blessed for C++ (again)
On Monday, 10 April 2017 at 04:49:34 UTC, Jack Stouffer wrote: On Monday, 10 April 2017 at 04:17:21 UTC, Swoorup Joshi wrote: On Wednesday, 28 September 2016 at 20:50:28 UTC, Ali Çehreli wrote: https://www.reddit.com/r/programming/comments/54xnbg/herb_sutters_experimental_deferred_and_unordered/ Ali Is it possible to have something similar as in library rather than GC in core language construct? Not without breaking changes. Breaking, you mean the standard library? or including user codebases?
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On Tuesday, 11 April 2017 at 06:08:16 UTC, Ali Çehreli wrote: I will be presenting D as a time-saving tool at C++Now: http://cppnow.org/ I have to say it took me a very long time to come up with the title and the abstract. How could I sell D to C++ experts? Luckily, I asked Manu and among a long list of ideas he said "it's about saving time" and "time is money". How can you argue with that? ;) Do you agree or disagree that D brings competitive advantage? Please let me know. Are you attending the conference? Ali D can't compete with C++ until it gets proper dynamic library support on all platforms. As far as I understand there're still problems on Windows.
"Competitive Advantage with D" is one of the keynotes at C++Now 2017
I will be presenting D as a time-saving tool at C++Now: http://cppnow.org/ I have to say it took me a very long time to come up with the title and the abstract. How could I sell D to C++ experts? Luckily, I asked Manu and among a long list of ideas he said "it's about saving time" and "time is money". How can you argue with that? ;) Do you agree or disagree that D brings competitive advantage? Please let me know. Are you attending the conference? Ali
