Which language futures make D overcompicated?
I like D, but sometimes it's look like for me too complicated. Go have a lot of fans even it not simple, but primitive. But some D futures make it very hard to learning. Small list by me: 1. mixins 2. inout 3. too many attributes like: @safe @system @nogc etc Which language futures by your opinion make D harder?
Re: A betterC base
- import ... really, we are 2018 and people are still wasting our time to have standard libraries as imports. Its even more fun when you split, only to need import the array library. Please explain what do you mean by it?
Re: option -ignore_pure for temporary debugging (or how to wrap an unpure function inside a pure one)?
just filed https://issues.dlang.org/show_bug.cgi?id=18407
Issue 18407 - debug should escape nothrow, @nogc, @safe (not just pure)
On Thu, Feb 8, 2018 at 5:38 AM, Steven Schveighoffer via Digitalmars-d
wrote:
> On 2/8/18 8:32 AM, Steven Schveighoffer wrote:
>>
>> On 2/7/18 10:32 PM, Timothee Cour wrote:
>>>
>>> same question with how to wrap a gc function inside a nogc shell, if
>>> not, allowing a flag -ignore_nogc that'd enable this (again, for
>>> debugging purposes)
>>
>>
>> If you wrap the call in a debug block, it will work.
>>
>> int foo() pure
>> {
>> debug writeln("yep, this works");
>> }
>
>
> Gah, I see this was answered 2 other times, but for some reason, your
> replies turn out as new threads.
>
> Sorry for the extra noise.
>
> -Steve
Re: proposal: heredoc comments to allow `+/` in comments, eg from urls or documented unittests
On 02/08/2018 10:06 PM, Timothee Cour wrote: /"EOC This is a multi-line heredoc comment allowing /+ documented unittests containing nesting comments +/ That shouldn't be an issue as long as you're using /++ doc comments and not /** ones. If it IS a problem, I'd regard it as a bug. (If I were in change of the world, /** and /* both would be compiler errors, banned from all commits, and non-nesting block comments of all types would be prohibited from all langauges upon pain of...well, pain. They are spawn of satan and should never exist.) and weird urls like https://gcc.gnu.org/onlinedocs/libstdc++/faq.html *That* is a compelling point: Any embedded langauge (such as URL syntax) where +/ is valid. That, and maybe any code examples or discussions which, for any reason, intentially involve an unmatched end-of-comment.
Re: #dbugfix Issue 18068 - No file names and line numbers in stack trace
Hear, hear! It *used* to work, but doesn't anymore. I may be wrong, but in Linux-land at least I think may be related to PIC. Seemed to work fine until I installed an updated distro that has issues with non-PIC stuff.
Re: A betterC base
On Thursday, 8 February 2018 at 23:27:25 UTC, Adam D. Ruppe wrote: On Thursday, 8 February 2018 at 15:55:09 UTC, JN wrote: Citation needed on how garbage collection has been a smashing success based on its merits rather than the merits of the languages that use garbage collection. Who cares? Even if the success isn't because of GC per se, the ubiquity of it in the real world means it certainly isn't a deal breaker. GC is all about time/space tradeoffs. That's all one can say about it really. Yes, the 'ubiquity of it in the real world' (in popular and not so popular languages) suggest that most accept this tradeoff, in favour of using GC. But many still don't.. And many that do, might decide otherwise in the future... cause I'm not sure how well GC really scales...(in the future, the size of the heap might be terabytes..or more). That's not an argument for not defaulting to GC in D. It's an argument for when GC in D, could be a deal breaker. So it's good thing for the D community to consider these people as well - rather than saying 'who cares'. In the end, GC just adds to all the other bloat that's associated with programming in the modern era. The more we can reduce bloat, the -betterD. I'm glad there is alot of research in this area, and increasingly so - that's really important, cause the story of automatic memory management is far from over - even in D it seems.
Re: #dbugfix Issue 1983
On Thursday, 8 February 2018 at 07:26:55 UTC, Mike Franklin wrote: https://issues.dlang.org/show_bug.cgi?id=1983 A PR addressing this issue (https://github.com/dlang/dmd/pull/2130), is the oldest PR in the DMD repository. The issue also is almost a decade old. I'd love to see it finally resolved. Noted!
Re: A betterC base
On Friday, 9 February 2018 at 01:55:10 UTC, Benny wrote: People talk about the need for a clear design focus, leadership and ... things go on as before. That is D in a nutshell. People doing what they want, whenever and things stay the same. New features ( that is always fun ), a few people doing to grunt work and all the rest comes down to people complaining because they see no reason to put effort into D, as it feels like a wast of time. << want to bet that this is the only thing people will quote, instead of the rest. D does NOT need a top-down, authoritarian, corporation like vision imposed on it (which would solve all the issues you mention). D is an open source, meritocratic community of people, who drive the project forward. Some (like you apparently) seem to think that a lack of authoritarianism puts D at a disadvantage - I simply disagree. It may mean, that (some)things progress more slowly, and the overall vision is less certain - but that's exactly how I like it. D 'emerges' from its community. It's is not imposed on its community.
Re: proposal: heredoc comments to allow `+/` in comments, eg from urls or documented unittests
NOTE: the analog of documenting comments (/++ ...+/ and /** */) could be: /""EOC multiline comment EOC"/ (ie allow both `/""` and `/"` before reading in the heredoc token) On Thu, Feb 8, 2018 at 7:06 PM, Timothee Cour wrote: > same exact idea as motivation for delimited strings > (https://dlang.org/spec/lex.html#delimited_strings) > > ``` > > auto heredoc = q"EOS > This is a multi-line > heredoc string > EOS" > ; > > /"EOC > This is a multi-line > heredoc comment allowing > /+ documented unittests containing nesting comments +/ > and weird urls like https://gcc.gnu.org/onlinedocs/libstdc++/faq.html > EOS"/ > > ```
Re: #dbugfix Issue 18068 - No file names and line numbers in stack trace
On Friday, 9 February 2018 at 02:30:15 UTC, Mike Franklin wrote: https://issues.dlang.org/show_bug.cgi?id=18068 Noted!
proposal: heredoc comments to allow `+/` in comments, eg from urls or documented unittests
same exact idea as motivation for delimited strings (https://dlang.org/spec/lex.html#delimited_strings) ``` auto heredoc = q"EOS This is a multi-line heredoc string EOS" ; /"EOC This is a multi-line heredoc comment allowing /+ documented unittests containing nesting comments +/ and weird urls like https://gcc.gnu.org/onlinedocs/libstdc++/faq.html EOS"/ ```
Re: Somewhat OT: defining algebras in D
On 02/08/2018 04:37 PM, Amorphorious wrote: On Thursday, 8 February 2018 at 15:23:05 UTC, Simen Kjærås wrote: So I was bored in a meeting and decided to implement a generic template for defining complex numbers, dual numbers, quaternions and many other possible algebras by simply defining a set of rules and the components on which they act: source: https://gist.github.com/Biotronic/833680b37d4afe774c8562fd21554c6b Cool. Took me a while to start to understand it and still not 100% grokked (partly because I've never quite been able to fully grasp quaternion math (at least, beyond Unity3D's ultra-easy abstraction for it) and never heard of dual numbers before), but staring at the complex number example helped see how this works. It's a very cool idea! It would be nice if you learned how to document your code. It's not always easy for someone on the outside to be able to pick it up and it ultimately means your hard work will be less used as it could be. I know that sometimes comments can be redundant but it can also provide a better understanding. Well, that's the difference between a formal library package release vs sharing a working proof of concept jotted down to pass time ;)
#dbugfix Issue 18068 - No file names and line numbers in stack trace
https://issues.dlang.org/show_bug.cgi?id=18068 I tried to fix this one myself, but it beat me. It's also currently causing me friction when working on DMD. I would love to see it fixed. Interestingly, however, it works fine in the auto-tester. But, problem can be reproduced at https://run.dlang.io/ (e.g. https://run.dlang.io/is/hatIXE). Maybe it's dependent on the host compiler being used; I don't know. Mike
Re: A betterC base
On Thu, 08 Feb 2018 17:08:41 +, bachmeier wrote: > On Thursday, 8 February 2018 at 15:55:09 UTC, JN wrote: > >> Python was also a smashing success, but it doesn't use a garbage >> collector in it's default implementation (CPython). > > I'm pretty sure CPython uses a mark-and-sweep GC together with reference > counting. It does. Originally it was reference-counting only, but they added the (generational) GC to clean up cyclic references. Because they do reference counting as well, you can disable the GC entirely. https://docs.python.org/3.6/library/gc.html
Re: A betterC base
On Thursday, 8 February 2018 at 15:51:38 UTC, Adam D. Ruppe wrote: On Thursday, 8 February 2018 at 15:43:01 UTC, ixid wrote: That's been said over and over and the message has not gotten through. It is almost never said! We always play by their terms and implicitly concede by saying "but we can avoid it" or "look -betterC". Reddit invades our space, and we fall back. Rust assimilates entire worlds, and we fall back. Not again! The line must be drawn here! This far, no further! "Death is nothing, but to live defeated and inglorious is to die daily." - Napoleon 'D' Bonaparte Hey... logo idea for Munich 2018 -> Dman wearing a Napoleon hat - and riding a horse. Hey.. it's better than Dman lying on a death bed, dying of a stomach ulcer... I think we should have an annual D parade too...bring out all the might of D's machinery..and show the world how powerful we really are.
Re: A betterC base
On Thursday, February 08, 2018 23:57:45 Rubn via Digitalmars-d wrote: > On Thursday, 8 February 2018 at 18:06:38 UTC, Walter Bright wrote: > > I.e. it isn't an issue of us D guys being dumb about the GC. > > So you could say it's a design flaw of D, attempting to use a GC > where it isn't suited? You could say that, but many of us would not agree. Just because certain classes of GCs cannot be used with D does not mean that the fact that D has a GC built-in is not beneficial and ultimately a good design decision. Plenty of folks have been able to write very efficient code that uses D's GC. Obviously, there are use cases where it's better to avoid the GC, but for your average D program, the GC has been a fantastic asset. - Jonathan M Davis
Re: A betterC base
On Friday, 9 February 2018 at 00:08:56 UTC, Adam D. Ruppe wrote: On Thursday, 8 February 2018 at 23:50:29 UTC, Ali wrote: But D, unlike many other languages, promotes itself as primarily a system programming language I think that's a mistake too. I'd rebrand it as a "general purpose" programming language. One language you can use everywhere. It worked for node.js and electron... Plenty of "general purpose" programming languages. The issue being that very few offer classes, no GC, easy syntax, good tooling and editor support, ... I noticed a trend with languages with so many going to functional programming or semi-class based. From the outside D looks good but there are so many strange things in the D design, that just infuriate. - GC ... sure, if only it did not allocate so much on startup. It makes any other languages look better, by simply having a lower memory footprint on first comparison. C 0.1MB, C++ 0.2MB, Rust 0.4MB, D 1.4MB, ... Looks inefficient when its simply the whole 1MB allocation. But perception matters! - import ... really, we are 2018 and people are still wasting our time to have standard libraries as imports. Its even more fun when you split, only to need import the array library. Look how ridiculous C++ like "import std.algorithm, std.conv, std.functional, std.math, std.regex, std.stdio;" some of the example on the front page look like. I see people on Reddit sh*t all over PHP all the time and yet, its so darn easy and comfortable to not think about writing import all over the code, just to get default functionality!! Reddit is full of people who love to hate languages that simply work. - Tooling. I will say it again and again until i die, it simply sucks for Windows users. How fun is it to see dcd-server taking up between 90 to 120MB and seeing 10, 12, 15 instances loading into memory eating away 2GB memory. Or seeing VSC work with some of the plugins for 5 minutes and then break again, forcing you to constantly restart VSC. Or how competing languages seem to provide more cleaner and better working plugins, with cleaner tool tips ( source documentation ) - Even the example on the front page are so typical "scare away the newbies". It looks like a cleaner version of C++. D has always been a love/hate relationship for me. One can see the work that has gone into it but it feels like a Frankenstein's monster. Small details, big details, the lack of clear focus. BetterC just moves resources away from actually implementing a permanent solution. Instead of maintain one system, you deal with two. While default D still deals with regressions and issue, BetterC being incomplete is pushed as the next big thing. The library has design choices that date back a long time and nobody dares to touch. The whole constant GC debate is linked to those design choices. D can do a lot but the layer between both is so thin that at times you wonder if your dealing with compile or runtime features. CTFE or not. Talking about CTFE .. Stephan vanished for a long time busy with work and yet it feels reading the topics that very few people noticed him missing, despite working a year on the whole new CTFE engine. Not exactly motivating for people. I can talk until i turn blue. I already wrote "a wall of text" as some say, in the Go topic and that was not even technical issues. People talk about the need for a clear design focus, leadership and ... things go on as before. That is D in a nutshell. People doing what they want, whenever and things stay the same. New features ( that is always fun ), a few people doing to grunt work and all the rest comes down to people complaining because they see no reason to put effort into D, as it feels like a wast of time. << want to bet that this is the only thing people will quote, instead of the rest. But on-topic again: No GC, yay. Always a win because it makes a language stand out. Possible for D. NO! Too much design choices that limit the language. Another D3 rewrite will simply kill D. D is so tiring. Its the main reason for going with Go, simply tired of waiting. In this one+ year time watching D, i have seen blogs, betterC half finished being promoted when D is already overloaded with features and has already a higher learning curve. More regressions and bug fix releases because the new features keep breaking stuff. Some more examples on the front pages. Some nice external packages that only limited amount of people care about. And very few things to improving the issues people mentioned the year before and the year before and the year before. So again, why do people need to bother? The momentum D build up in 2016, seem to according tiobe really lost. I remember D hitting (23) 1% a year ago, now its ranking (29) 0.5%. Great another wall of text at 2.50 in the morning. Frankly, i can write a book about D issues, justified or not. It will probably read like gibberish a
Re: A betterC base
On Friday, 9 February 2018 at 01:31:41 UTC, Mike Franklin wrote: On Thursday, 8 February 2018 at 17:10:00 UTC, bachmeier wrote: What are D's limitations on do-it-yourself reference counting? * Types that are built into the language like dynamic arrays, associative arrays, and exceptions won't benefit from DIY reference counting. * Much of Phobos probably wouldn't be compatible with DIY reference counting. That being said, there may be a way to override some runtime hooks like _d_newclass (https://dlang.org/library/rt/lifetime/_d_newclass.html), etc... to make it work. But I haven't tried. Also, I think Walter is currently working on getting reference counted exceptions into the language: https://github.com/dlang/druntime/pull/1995 Mike Also, I think DIY reference counting is already done for us in the automem library https://dlang.org/blog/2017/04/28/automem-hands-free-raii-for-d/ Mike
Re: A betterC base
On Thursday, 8 February 2018 at 17:10:00 UTC, bachmeier wrote: What are D's limitations on do-it-yourself reference counting? * Types that are built into the language like dynamic arrays, associative arrays, and exceptions won't benefit from DIY reference counting. * Much of Phobos probably wouldn't be compatible with DIY reference counting. That being said, there may be a way to override some runtime hooks like _d_newclass (https://dlang.org/library/rt/lifetime/_d_newclass.html), etc... to make it work. But I haven't tried. Also, I think Walter is currently working on getting reference counted exceptions into the language: https://github.com/dlang/druntime/pull/1995 Mike
Re: Bye bye, fast compilation times
On 02/08/2018 06:21 AM, Martin Tschierschke wrote: Beginner question: How to split my project, to compile the regex part separately as a lib and just link them? Unfortunately that depends completely on what buildsystem you're using. But if you're just calling the compiler directly, then it's really easy: > dmd -lib -of=myLib.a [all other flags your project may need] fileYouWantInLib.d anyOtherFileYouAlsoWant.d > dmd myLib.a [your project's usual flags, and all the rest of your .d files] If on windows, then just replace ".a" with ".lib".
Re: A betterC base
On Thursday, 8 February 2018 at 23:50:29 UTC, Ali wrote: But D, unlike many other languages, promotes itself as primarily a system programming language I think that's a mistake too. I'd rebrand it as a "general purpose" programming language. One language you can use everywhere. It worked for node.js and electron... Though, of course, the GC is NOT a problem for those systems tasks. Even in the niches where it doesn't help, it doesn't actually hurt either. (in fact, the bigger problem we have in those niches are obligatory typeinfo generation and unnecessary bloat in the runtime implementation issues that Mike Franklin has made big progress on fixing already. and even those can be worked around, doing a serious system implementation is a bigger task than stubbing out a few functions.) https://en.wikipedia.org/wiki/System_programming_language A few of those languages have GCs... and GC languages have been used for all these tasks before. It's not a dealbreaker.
Re: A betterC base
On Thursday, 8 February 2018 at 17:32:53 UTC, ixid wrote: Do you really think sticking with the current course on GC would gain more users than very slightly changing tack and making it something you add to a simpler base? I think the second of those will gain more users. No, the current course - which IS the optional GC story you're talking about - is not good. I'm saying change course by embracing our advantages instead of constantly playing defense. D isn't going to beat Rust on compiler-enforced memory safety, so we shouldn't even play that game. Instead, pound them into the ground with our programmer productivity package. Destroy them with our familiar syntax that programmers already know.
Re: A betterC base
On Thursday, 8 February 2018 at 18:06:38 UTC, Walter Bright wrote: I.e. it isn't an issue of us D guys being dumb about the GC. So you could say it's a design flaw of D, attempting to use a GC where it isn't suited? If going malloc didnt lose you a bunch of features and bring a bunch of other stuff you need to be careful of, that might be a good argument too. With @nogc, you don't have to be careful about it. The compiler will let you know. @nogc has issues integrating with features like delegates, but no one seems to care about that with statements like this. It's more convenient to not use @nogc than dealing with the hassles of using it.
Re: A betterC base
On Thursday, 8 February 2018 at 23:27:25 UTC, Adam D. Ruppe wrote: On Thursday, 8 February 2018 at 15:55:09 UTC, JN wrote: Citation needed on how garbage collection has been a smashing success based on its merits rather than the merits of the languages that use garbage collection. Who cares? Even if the success isn't because of GC per se, the ubiquity of it in the real world means it certainly isn't a deal breaker. But D, unlike many other languages, promotes itself as primarily a system programming language https://en.wikipedia.org/wiki/System_programming_language So I would say yes, D's success does depend in a very large part on the Garbage Collector, and managing a system resources
Re: A betterC base
On Thursday, 8 February 2018 at 16:40:46 UTC, John Gabriele wrote: Regarding what you said about the implementation of the GC following in the footsteps of industry giants, what specifically about D's GC impl is patterned after other industry giant's GC's? The simple fact that it is a GC. These debates aren't about technical details. You don't see the reddit detractors actually arguing implementation details - they just equate GC with bad. But GC isn't bad. GC is used by virtually everyone, to big productivity and memory safety gains by most, and evidently, without seriously getting in the way by the majority of the remainder just like how D's specialized users who can't afford GC still manage to use D.
Re: A betterC base
On Thursday, 8 February 2018 at 15:55:09 UTC, JN wrote: Citation needed on how garbage collection has been a smashing success based on its merits rather than the merits of the languages that use garbage collection. Who cares? Even if the success isn't because of GC per se, the ubiquity of it in the real world means it certainly isn't a deal breaker.
Re: Somewhat OT: defining algebras in D
On Thursday, 8 February 2018 at 15:23:05 UTC, Simen Kjærås wrote:
So I was bored in a meeting and decided to implement a generic
template for defining complex numbers, dual numbers,
quaternions and many other possible algebras by simply defining
a set of rules and the components on which they act:
alias quaternion = Algebra!(
float,
"1,i,j,k",
op("1", any) = any,
op("i,j,k", self) = "-1",
op("i", "j") = "k".antiCommutative,
op("j", "k") = "i".antiCommutative,
op("k", "i") = "j".antiCommutative,
);
source:
https://gist.github.com/Biotronic/833680b37d4afe774c8562fd21554c6b
--
Simen
It would be nice if you learned how to document your code. It's
not always easy for someone on the outside to be able to pick it
up and it ultimately means your hard work will be less used as it
could be. I know that sometimes comments can be redundant but it
can also provide a better understanding.
For example, it seems that you are using a group presentation to
define the a algebra... but a few examples are not enough to
provide a complete context in what it can be used for besides the
example. This requires understanding the details in detail, which
can be too time consuming for some. For example, can it be used
to define an algebra on sets? If not, could it be modified to do
so easily? To answer that one probably has to know how the code
works in detail... which means spending time, which then goes to
if it is worth it over a new implementation, etc.
Re: A betterC base
On 2/8/2018 11:51 AM, bachmeier wrote: The developers working on .NET had the opportunity to learn from Java, yet they went with GC.[0] Anyone that says one approach is objectively better than the other is clearly not familiar with all the arguments - or more likely, believes their problem is the only real programming problem. [0] https://blogs.msdn.microsoft.com/brada/2005/02/11/resource-management/ That really is an informative article, thanks. The only issue with it is that it doesn't cover the newer C++ ref counting model, which has proved popular.
Re: missing HexString documentation
On 2/8/2018 10:42 AM, Steven Schveighoffer wrote: On 2/8/18 1:25 PM, Walter Bright wrote: "abc" is an array (it's an immutable(char)[]). There's no reason why ['a','b','c'] should be different than "abc" (other than the hidden null character, which is irrelevant here). ['a','b','c'] is mutable, a string literal is immutable. Perhaps the fact that using a string rather than an array causes code to fail should be addressed? That would be a language change proposal or bug report. By all means, please do so. How can this be a huge simplification? I mean you already have code that parses hex characters in a string array, all you need is one flag that assumes all character pairs have been preceded by \x. I think this will save probably 4 or 5 lines of code? hexStringConstant() was 79 lines of code, not including comments and blank lines. I also showed how: x"deadbeef" can be replaced with: hexString!"deadbeef" with no overhead. If you hate typing hexString, you can always write: alias x = hexstring; and then you've got: x"deadbeef" x!"deadbeef" which seems an inconsequential difference. (The generated code is the same.) It also doesn't preclude at all someone writing library code to make their own custom string syntax. You're right it doesn't. But people don't do it, because it is neither obvious that D can do such a thing (it relies on a combination of features) nor is it obvious how to do it correctly (as the earlier hexString implementation shows and nobody seemed able to fix it but me). What Phobos provides is working, professional quality code that should serve as a user resource for "how to do things and how to do them right". I.e. having hexString as a library function is a good advertisement for what D can do. After all, how many languages can do this sort of thing?
Re: A betterC base
On Thursday, 8 February 2018 at 18:06:38 UTC, Walter Bright wrote: On 2/8/2018 9:03 AM, Dave Jones wrote: If D had a decent garbage collector it might be a more convincing argument. 'Decent' GC systems rely on the compiler emitting "write gates" around every assignment to a pointer. These are justified in languages like Java and Go for which everything is GC allocated, but they would be a performance disaster for a hybrid language like D. More precise GC exacts heavy runtime penalties, too, which is why attempts to add them to D have had mixed results. I.e. it isn't an issue of us D guys being dumb about the GC. If going malloc didnt lose you a bunch of features and bring a bunch of other stuff you need to be careful of, that might be a good argument too. With @nogc, you don't have to be careful about it. The compiler will let you know. .NET, Eiffel, Modula-3 and the various Oberon variants are all examples where not everything is GC allocated. C# 8.0 with .NET Native is getting the features I mostly cared from D.
Re: A betterC base
On Thursday, February 08, 2018 11:28:52 H. S. Teoh via Digitalmars-d wrote: > On Thu, Feb 08, 2018 at 12:17:06PM -0700, Jonathan M Davis via Digitalmars-d wrote: > > On Thursday, February 08, 2018 14:54:19 Adam D. Ruppe via Digitalmars-d > > > wrote: > [...] > > > > Garbage collection has proved to be a smashing success in the > > > industry, providing productivity and memory-safety to programmers of > > > all skill levels. D's GC implementation follows in the footsteps of > > > industry giants without compromising expert's ability to tweak even > > > further. > > > > > > > > > > > > That's what we should be saying every single time someone mentions > > > GC. Including it was the RIGHT DECISION and we should own that. > > > > +1000 > > [...] > > /// ditto. :-P > > While I agree that we *should* make D as usable as possible for those > who don't want to use the GC, all too often that belies the benefits > that having a GC actually brings. It's true that the current GC could > be improved, and that we could reduce GC-dependence in Phobos, provide > better @nogc support, etc.. But we should not apologize for *having* a > GC, as if it was somehow a wrong decision. > > I think it's *great* to have a GC. It has saved me *so* much time, > energy, and frustration that would have been spent obsessing over memory > management every other line of code I write; now I can instead direct > that energy towards actually solving stuff in the problem domain that is > the entire purpose of the code in the first place. And for those times > when performance is an issue, GC.disable and GC.collect have proven > sufficient to clear the bottleneck in 95% of the cases. And besides, D > doesn't stop you from dropping back to malloc/free if you really need > to. Or, for that matter, RefCounted. I am completely fine with making more features pay-as-you-go so long as it doesn't require me to change any existing code (e.g. I shouldn't have to import the GC - but if no code in your program invokes the GC and that results in the GC not being linked in, that's fine with me). But whenever I see folks trying to push -betterC as the way to go or push to get the GC out of Phobos, I start getting worried about that negatively affecting normal D code. I totally agree that there are times when you don't want something on the GC heap, and there are times when you need to do stuff like reference-counting (e.g. for OS-level resources that need to be released deterministically), but on the whole, having the GC is fantastic, and for most stuff, it works wonderfully. We should strive to minimize the cost of nice stuff like the GC so that it's as much pay-as-you-go as is reasonable, but at some point, if you're not careful, you start losing out on nice features in your attempt to appease the folks who think that they can't afford the GC in their enivornment (whether they actually can or not). And I would much rather see folks have to go to a bit of extra work to turn off something that most programs are going to benefit from than to make it harder for your average D program to take advantage of all of D's great features. - Jonathan M Davis
Re: A betterC base
On Thursday, 8 February 2018 at 19:51:05 UTC, bachmeier wrote: The developers working on .NET had the opportunity to learn from Java, yet they went with GC.[0] Anyone that says one approach is objectively better than the other is clearly not familiar with all the arguments - or more likely, believes their problem is the only real programming problem. Reference counting isn't a general solution, and it is very slow when you allow flexible programming paradigms that generate lots of objects. So, it all depends on how much flexibility you want to allow for your programmers and still having reasonable performance. (The vast majority of high level programming languages use GC and has done so since the 60s.)
Re: A betterC base
On Thursday, 8 February 2018 at 19:34:20 UTC, Walter Bright wrote: On 2/8/2018 10:11 AM, JN wrote: I agree, however these languages would probably have been successful even without GC, using e.g. some form of automatic reference counting. If reference counting would work with Java, and was better, wouldn't the Java developers have done it decades ago? The developers working on .NET had the opportunity to learn from Java, yet they went with GC.[0] Anyone that says one approach is objectively better than the other is clearly not familiar with all the arguments - or more likely, believes their problem is the only real programming problem. [0] https://blogs.msdn.microsoft.com/brada/2005/02/11/resource-management/
Re: A betterC base
On Thu, Feb 08, 2018 at 12:17:06PM -0700, Jonathan M Davis via Digitalmars-d wrote: > On Thursday, February 08, 2018 14:54:19 Adam D. Ruppe via Digitalmars-d > wrote: [...] > > Garbage collection has proved to be a smashing success in the > > industry, providing productivity and memory-safety to programmers of > > all skill levels. D's GC implementation follows in the footsteps of > > industry giants without compromising expert's ability to tweak even > > further. > > > > > > > > That's what we should be saying every single time someone mentions > > GC. Including it was the RIGHT DECISION and we should own that. > > +1000 [...] /// ditto. :-P While I agree that we *should* make D as usable as possible for those who don't want to use the GC, all too often that belies the benefits that having a GC actually brings. It's true that the current GC could be improved, and that we could reduce GC-dependence in Phobos, provide better @nogc support, etc.. But we should not apologize for *having* a GC, as if it was somehow a wrong decision. I think it's *great* to have a GC. It has saved me *so* much time, energy, and frustration that would have been spent obsessing over memory management every other line of code I write; now I can instead direct that energy towards actually solving stuff in the problem domain that is the entire purpose of the code in the first place. And for those times when performance is an issue, GC.disable and GC.collect have proven sufficient to clear the bottleneck in 95% of the cases. And besides, D doesn't stop you from dropping back to malloc/free if you really need to. Or, for that matter, RefCounted. T -- If you want to solve a problem, you need to address its root cause, not just its symptoms. Otherwise it's like treating cancer with Tylenol...
Re: missing HexString documentation
On 2/8/2018 10:49 AM, Steven Schveighoffer wrote: On 2/8/18 1:42 PM, Ralph Doncaster wrote: On Thursday, 8 February 2018 at 18:31:06 UTC, Walter Bright wrote: db 0ffdeh,0ffadh,0ffbeh,0ffefh ; But it looks like they are all dchar, so 4x the space vs x"deadbeef"? The 'db' means 'define byte'. dw for words, dd for 32 bit words. I was looking at that too when I was testing the differences, but actually, it's the same when you use x"deadbeef". Yes. I wonder if it's an issue with how obj2asm prints it out? Surely, that data array must be contiguous, and they must be bytes. Otherwise the resulting code would be wrong. Yes. I just never bothered to fix it.
Re: A betterC base
On 2/8/2018 10:11 AM, JN wrote: I agree, however these languages would probably have been successful even without GC, using e.g. some form of automatic reference counting. If reference counting would work with Java, and was better, wouldn't the Java developers have done it decades ago?
Re: A betterC base
On Thursday, February 08, 2018 14:54:19 Adam D. Ruppe via Digitalmars-d wrote: > On Thursday, 8 February 2018 at 11:06:15 UTC, ixid wrote: > > It feels like D has not overcome at least two major issues in > > the public mind, the built-in GC > > D is a pragmatic language aimed toward writing fast code, fast. > Garbage collection has proved to be a smashing success in the > industry, providing productivity and memory-safety to programmers > of all skill levels. D's GC implementation follows in the > footsteps of industry giants without compromising expert's > ability to tweak even further. > > > > That's what we should be saying every single time someone > mentions GC. Including it was the RIGHT DECISION and we should > own that. +1000 - Jonathan M Davis
Re: missing HexString documentation
On Thursday, 8 February 2018 at 18:49:51 UTC, Steven Schveighoffer wrote: I wonder if it's an issue with how obj2asm prints it out? Surely, that data array must be contiguous, and they must be bytes. Otherwise the resulting code would be wrong. OK. I didn't even know about obj2asm until you mentioned it. objdump seems to work perfectly fine on the .o's that dmd generates, and I can tell that x"deadbeef" generates 4 contiguous bytes (objdump -D): Disassembly of section .rodata.str1.1: <_TMP0>: 0: de .byte 0xde 1: ad lods %ds:(%rsi),%eax 2: be .byte 0xbe 3: ef out%eax,(%dx) ...
Re: A betterC base
On Thursday, 8 February 2018 at 18:06:38 UTC, Walter Bright wrote: [snip] More precise GC exacts heavy runtime penalties, too, which is why attempts to add them to D have had mixed results. See, there's your problem right there. Now if you replace the current GC with the slowest possible GC you can think of and then replace that with a precise GC. Then all the comparisons are gonna come out roses. /s
Re: missing HexString documentation
On 2/8/18 1:42 PM, Ralph Doncaster wrote:
On Thursday, 8 February 2018 at 18:31:06 UTC, Walter Bright wrote:
On 2/8/2018 5:26 AM, Steven Schveighoffer wrote:
The extra data in the object file comes from the inclusion of the
hexStringImpl function, and from the template parameter (the symbol
_D3std4conv__T9hexStringVAyaa8_6465616462656566ZQBiyAa is in there as
well, which will always be larger than the actual string passed to
hexString).
I also see the data in there twice for some reason.
This is no longer the case with the PR.
import std.conv;
void test() {
__gshared immutable char[4] s = hexString!"deadbeef";
}
produces the following, with no sign of the template and the data is
there only once:
_DATA segment
_D5test24testFZ1syG4a:
db 0ffdeh,0ffadh,0ffbeh,0ffefh ;
_DATA ends
But it looks like they are all dchar, so 4x the space vs x"deadbeef"?
I was looking at that too when I was testing the differences, but
actually, it's the same when you use x"deadbeef".
I wonder if it's an issue with how obj2asm prints it out? Surely, that
data array must be contiguous, and they must be bytes. Otherwise the
resulting code would be wrong.
-Steve
Re: missing HexString documentation
On 2/8/18 1:25 PM, Walter Bright wrote: On 2/8/2018 7:07 AM, Steven Schveighoffer wrote: My concern in the hexString case is the sheer requirement of CTFE for something that is so easy to do in the compiler, already *done* in the compiler, and has another form specifically for hex strings (the "\xde\xad\xbe\xef" form) that isn't going away. It makes me laugh actually that Walter is now replacing the implementation with a mixin of that other form, incurring all the cost of CTFE so you can transform the string, while breaking existing code in the process: https://github.com/dlang/phobos/pull/6138 The breakage was due to the original implementation of hexString not producing a string literal like "abc", but producing an array literal like ['a', 'b', 'c'], which was not what the documentation said it did. And naturally, some uses wound up relying on the array behavior. "abc" is an array (it's an immutable(char)[]). There's no reason why ['a','b','c'] should be different than "abc" (other than the hidden null character, which is irrelevant here). Perhaps the fact that using a string rather than an array causes code to fail should be addressed? What the PR does is fix hexString so that hexString!"deadbeef" rewrites it to the string literal "\xde\xad\xbe\xef". It's classic "lowering". Isn't it amazing that D can even do this? It's great that D has this power, and would be really useful if D's language didn't already have a way to do this in a builtin way. Simplifying the compiler and pushing things off into the library makes the compiler and spec smaller and less buggy. It also has the nice feature of providing a simple path for anyone who wants to write their own custom string syntax, such as EBCDIC string literals (!). How can this be a huge simplification? I mean you already have code that parses hex characters in a string array, all you need is one flag that assumes all character pairs have been preceded by \x. I think this will save probably 4 or 5 lines of code? It also doesn't preclude at all someone writing library code to make their own custom string syntax. -Steve
Re: missing HexString documentation
On Thursday, 8 February 2018 at 18:31:06 UTC, Walter Bright wrote:
On 2/8/2018 5:26 AM, Steven Schveighoffer wrote:
The extra data in the object file comes from the inclusion of
the hexStringImpl function, and from the template parameter
(the symbol
_D3std4conv__T9hexStringVAyaa8_6465616462656566ZQBiyAa is in
there as well, which will always be larger than the actual
string passed to hexString).
I also see the data in there twice for some reason.
This is no longer the case with the PR.
import std.conv;
void test() {
__gshared immutable char[4] s = hexString!"deadbeef";
}
produces the following, with no sign of the template and the
data is there only once:
_DATA segment
_D5test24testFZ1syG4a:
db 0ffdeh,0ffadh,0ffbeh,0ffefh ;
_DATA ends
But it looks like they are all dchar, so 4x the space vs
x"deadbeef"?
Re: My choice to pick Go over D ( and Rust ), mostly non-technical
On 2/6/2018 1:51 AM, Atila Neves wrote: I tried Warp on a non-trivial C codebase. It didn't work (by which I mean the code wouldn't compile with it). I don't know how clang managed to build a (for all practical purposes I can see) bug-compatible preprocessor from scratch to gcc, but it did and in large projects it makes a difference. Warp successfully compiles all of Boost, including their advanced preprocessor metaprogramming library. So it's very, very compatible. If you have something that didn't work, I suspect it is because the user-defined list of predefined macros supplied to Warp wasn't correct. If that wasn't it, I'd appreciate it if you could boil down what went wrong.
Re: missing HexString documentation
On 2/8/2018 5:26 AM, Steven Schveighoffer wrote:
The extra data in the object file comes from the inclusion of the hexStringImpl
function, and from the template parameter (the symbol
_D3std4conv__T9hexStringVAyaa8_6465616462656566ZQBiyAa is in there as well,
which will always be larger than the actual string passed to hexString).
I also see the data in there twice for some reason.
This is no longer the case with the PR.
import std.conv;
void test() {
__gshared immutable char[4] s = hexString!"deadbeef";
}
produces the following, with no sign of the template and the data is there only
once:
_TEXT segment dword use32 public 'CODE' ;size is 0
_TEXT ends
_DATA segment para use32 public 'DATA';size is 4
_DATA ends
CONST segment para use32 public 'CONST' ;size is 14
CONST ends
_BSSsegment para use32 public 'BSS' ;size is 0
_BSSends
FLATgroup
extrn _D5test24testFZv
public _D5test24testFZ1syG4a
FMB segment dword use32 public 'DATA' ;size is 0
FMB ends
FM segment dword use32 public 'DATA' ;size is 4
FM ends
FME segment dword use32 public 'DATA' ;size is 0
FME ends
public _D5test212__ModuleInfoZ
_D5test24testFZvCOMDAT flags=x0 attr=x0 align=x0
_TEXT segment
assume CS:_TEXT
_TEXT ends
_DATA segment
_D5test24testFZ1syG4a:
db 0ffdeh,0ffadh,0ffbeh,0ffefh ;
_DATA ends
CONST segment
_D5test212__ModuleInfoZ:
db 004h,010h,000h,000h,000h,000h,000h,000h ;
db 074h,065h,073h,074h,032h,000h ;test2.
CONST ends
_BSSsegment
_BSSends
FMB segment
FMB ends
FM segment
dd offset FLAT:_D5test212__ModuleInfoZ
FM ends
FME segment
FME ends
_D5test24testFZvcomdat
assume CS:_D5test24testFZv
ret
_D5test24testFZvends
end
Re: missing HexString documentation
On 2/8/2018 7:07 AM, Steven Schveighoffer wrote: My concern in the hexString case is the sheer requirement of CTFE for something that is so easy to do in the compiler, already *done* in the compiler, and has another form specifically for hex strings (the "\xde\xad\xbe\xef" form) that isn't going away. It makes me laugh actually that Walter is now replacing the implementation with a mixin of that other form, incurring all the cost of CTFE so you can transform the string, while breaking existing code in the process: https://github.com/dlang/phobos/pull/6138 The breakage was due to the original implementation of hexString not producing a string literal like "abc", but producing an array literal like ['a', 'b', 'c'], which was not what the documentation said it did. And naturally, some uses wound up relying on the array behavior. What the PR does is fix hexString so that hexString!"deadbeef" rewrites it to the string literal "\xde\xad\xbe\xef". It's classic "lowering". Isn't it amazing that D can even do this? Simplifying the compiler and pushing things off into the library makes the compiler and spec smaller and less buggy. It also has the nice feature of providing a simple path for anyone who wants to write their own custom string syntax, such as EBCDIC string literals (!).
Re: A betterC base
On Thursday, 8 February 2018 at 18:08:59 UTC, Walter Bright wrote: On 2/8/2018 7:55 AM, JN wrote: Citation needed on how garbage collection has been a smashing success based on its merits rather than the merits of the languages that use garbage collection. You can't separate the two. The Java and Go language semantics are designed around the GC. I agree, however these languages would probably have been successful even without GC, using e.g. some form of automatic reference counting.
Re: A betterC base
On 2/8/2018 7:55 AM, JN wrote: Citation needed on how garbage collection has been a smashing success based on its merits rather than the merits of the languages that use garbage collection. You can't separate the two. The Java and Go language semantics are designed around the GC.
Re: A betterC base
On 2/8/2018 9:03 AM, Dave Jones wrote: If D had a decent garbage collector it might be a more convincing argument. 'Decent' GC systems rely on the compiler emitting "write gates" around every assignment to a pointer. These are justified in languages like Java and Go for which everything is GC allocated, but they would be a performance disaster for a hybrid language like D. More precise GC exacts heavy runtime penalties, too, which is why attempts to add them to D have had mixed results. I.e. it isn't an issue of us D guys being dumb about the GC. If going malloc didnt lose you a bunch of features and bring a bunch of other stuff you need to be careful of, that might be a good argument too. With @nogc, you don't have to be careful about it. The compiler will let you know.
Re: A betterC base
On Thursday, 8 February 2018 at 11:40:44 UTC, Seb wrote: On Thursday, 8 February 2018 at 11:06:15 UTC, ixid wrote: [...] https://github.com/dlang/druntime/pull/2057 [...] One of Andrei's student is working on this. I think she has been focusing on templated ==, <= and AAs so far and is now recently getting more into the GC business: [...] Accompanied by a root cause analysis and learning how/why these were implemented at first place that prompts a D2 -> D3 and how to avoid such mistakes again so that D3 -> D4 is not required. :) Just saying, techies can exhibit some managerial traits as well.
Re: My choice to pick Go over D ( and Rust ), mostly non-technical
On Thursday, 8 February 2018 at 17:24:31 UTC, Ralph Doncaster wrote: On Thursday, 8 February 2018 at 15:59:28 UTC, Nicholas Wilson wrote: On Wednesday, 7 February 2018 at 15:16:46 UTC, Ralph Doncaster wrote: On Wednesday, 7 February 2018 at 15:10:36 UTC, Ralph Doncaster wrote: On Wednesday, 7 February 2018 at 08:05:46 UTC, Nicholas Wilson wrote: For OpenCL I develop and maintain DCompute: http://code.dlang.org/packages/dcompute https://github.com/libmir/dcompute It has a much beautified interface to OpenCL (and is mostly consistent with its CUDA interface). You can also write kernels directly in D, however this requires that LDC is built against my fork of LLVM: https://github.com/thewilsonator/llvm It's still in dev but should be usable. Please let me know if you have issues using it. I saw your library before, but it looked like it is ONLY for native D on GPUs. I looked at it again, and don't see any documentation or example showing that it works with standard OpenCL kernels written in C. Yeah its a wrapper for OpenCL so as long as the names and signatures of the symbols match it should work. OK, maybe I'll take a closer look. p.s. since you seem to be a green team guy, you might not know that llvm optimization sucks on AMD. I use -legacy when building my kernels to get the good old compiler. "green team guy"? It that with the OpenCL C compiler? nVidia's logo is green, while AMD's logo is often red. Ah, I have no affiliation with any of the hardware vendors. The only reason DCompute supports CUDA is LLVM has a backend for it and I thought "it can't be too hard". I test (not nearly as frequently as I should) on a rather old Intel CPU and very old (CC2.1) Nvidia card, simply due to availability (i.e. I had them before I started). CI Testing is on my list of things to do but I just haven't got around to it yet. On Linux with AMDGPU-Pro 17 and up, the driver uses llvm/amdgpu. The driver still has the old gcc-based? compiler. The old compiler can be selected with clBuildProgram using the option "-legacy". Unfortunately I can't help much there but I should definitely test (and optimise) with AMD. Hopefully it catches up with the legacy one because DCompute is currently tied to LDC and hence LLVM. The mainlining of polly, region vectoriser and VPlan should boost perf all round.
Re: A betterC base
On Thursday, 8 February 2018 at 15:51:38 UTC, Adam D. Ruppe wrote: On Thursday, 8 February 2018 at 15:43:01 UTC, ixid wrote: That's been said over and over and the message has not gotten through. It is almost never said! We always play by their terms and implicitly concede by saying "but we can avoid it" or "look -betterC". Reddit invades our space, and we fall back. Rust assimilates entire worlds, and we fall back. Not again! The line must be drawn here! This far, no further! You're preaching to the choir here. Being able to add GC easily to a betterC base gives you the same utility and a much stronger story to tell people, optional GC sounds good. Do you really think sticking with the current course on GC would gain more users than very slightly changing tack and making it something you add to a simpler base? I think the second of those will gain more users.
Re: missing HexString documentation
On Thursday, 8 February 2018 at 17:06:55 UTC, H. S. Teoh wrote: On Thu, Feb 08, 2018 at 08:26:03AM -0500, Steven Schveighoffer via Digitalmars-d wrote: [...] The extra data in the object file comes from the inclusion of the hexStringImpl function, and from the template parameter (the symbol _D3std4conv__T9hexStringVAyaa8_6465616462656566ZQBiyAa is in there as well, which will always be larger than the actual string passed to hexString). [...] This is one area that really should be improved. Is there some easy way in the compiler to mark a template function as "only used in CTFE", and not emit it into the object file if there are no other runtime references to it? I'm thinking of some kind of boolean attribute that defaults to false, and gets set if the function is referenced by runtime code. During codegen, any function that doesn't have this attribute set will be skipped over. My speculation is that this would lead to a good amount of reduction in template bloat, given how pervasively CTFE is used in Phobos (and idiomatic D in general). Or maybe you can get away with just using a good compiler/linker that supports LTO. It's quite mature in GCC now, so it's probably worth trying with GDC. http://hubicka.blogspot.ca/2014/04/linktime-optimization-in-gcc-1-brief.html
Re: My choice to pick Go over D ( and Rust ), mostly non-technical
On Thursday, 8 February 2018 at 15:59:28 UTC, Nicholas Wilson wrote: On Wednesday, 7 February 2018 at 15:16:46 UTC, Ralph Doncaster wrote: On Wednesday, 7 February 2018 at 15:10:36 UTC, Ralph Doncaster wrote: On Wednesday, 7 February 2018 at 08:05:46 UTC, Nicholas Wilson wrote: For OpenCL I develop and maintain DCompute: http://code.dlang.org/packages/dcompute https://github.com/libmir/dcompute It has a much beautified interface to OpenCL (and is mostly consistent with its CUDA interface). You can also write kernels directly in D, however this requires that LDC is built against my fork of LLVM: https://github.com/thewilsonator/llvm It's still in dev but should be usable. Please let me know if you have issues using it. I saw your library before, but it looked like it is ONLY for native D on GPUs. I looked at it again, and don't see any documentation or example showing that it works with standard OpenCL kernels written in C. Yeah its a wrapper for OpenCL so as long as the names and signatures of the symbols match it should work. OK, maybe I'll take a closer look. p.s. since you seem to be a green team guy, you might not know that llvm optimization sucks on AMD. I use -legacy when building my kernels to get the good old compiler. "green team guy"? It that with the OpenCL C compiler? nVidia's logo is green, while AMD's logo is often red. On Linux with AMDGPU-Pro 17 and up, the driver uses llvm/amdgpu. The driver still has the old gcc-based? compiler. The old compiler can be selected with clBuildProgram using the option "-legacy".
Re: missing HexString documentation
On Thu, Feb 08, 2018 at 08:26:03AM -0500, Steven Schveighoffer via Digitalmars-d wrote: [...] > The extra data in the object file comes from the inclusion of the > hexStringImpl function, and from the template parameter (the symbol > _D3std4conv__T9hexStringVAyaa8_6465616462656566ZQBiyAa is in there as > well, which will always be larger than the actual string passed to > hexString). [...] This is one area that really should be improved. Is there some easy way in the compiler to mark a template function as "only used in CTFE", and not emit it into the object file if there are no other runtime references to it? I'm thinking of some kind of boolean attribute that defaults to false, and gets set if the function is referenced by runtime code. During codegen, any function that doesn't have this attribute set will be skipped over. My speculation is that this would lead to a good amount of reduction in template bloat, given how pervasively CTFE is used in Phobos (and idiomatic D in general). T -- He who does not appreciate the beauty of language is not worthy to bemoan its flaws.
Re: A betterC base
On Thursday, 8 February 2018 at 15:55:09 UTC, JN wrote: Python was also a smashing success, but it doesn't use a garbage collector in it's default implementation (CPython). I'm pretty sure CPython uses a mark-and-sweep GC together with reference counting.
Re: A betterC base
On Thursday, 8 February 2018 at 17:03:58 UTC, Dave Jones wrote: On Thursday, 8 February 2018 at 14:56:31 UTC, Adam D. Ruppe wrote: ooh better last sentence D's GC implementation follows in the footsteps of industry giants without compromising experts' ability to realize maximum potential from the machine. If D had a decent garbage collector it might be a more convincing argument. If going malloc didnt lose you a bunch of features and bring a bunch of other stuff you need to be careful of, that might be a good argument too. I mean a good quality GC and seamless integration of manual memory management would be a pretty good argument to make, but D has neither of those ATM. What are D's limitations on do-it-yourself reference counting?
Re: A betterC base
On Thursday, 8 February 2018 at 14:56:31 UTC, Adam D. Ruppe wrote: ooh better last sentence D's GC implementation follows in the footsteps of industry giants without compromising experts' ability to realize maximum potential from the machine. If D had a decent garbage collector it might be a more convincing argument. If going malloc didnt lose you a bunch of features and bring a bunch of other stuff you need to be careful of, that might be a good argument too. I mean a good quality GC and seamless integration of manual memory management would be a pretty good argument to make, but D has neither of those ATM.
Re: A betterC base
On Thursday, 8 February 2018 at 14:54:19 UTC, Adam D. Ruppe wrote: On Thursday, 8 February 2018 at 11:06:15 UTC, ixid wrote: It feels like D has not overcome at least two major issues in the public mind, the built-in GC D is a pragmatic language aimed toward writing fast code, fast. Garbage collection has proved to be a smashing success in the industry, providing productivity and memory-safety to programmers of all skill levels. D's GC implementation follows in the footsteps of industry giants without compromising expert's ability to tweak even further. That's what we should be saying every single time someone mentions GC. Including it was the RIGHT DECISION and we should own that. Yes, absolutely! It's the reason I chose to start writing programs in D, because I had a background in C and Java, and wanted a fast, compiled language that would take care of the details for me. You can write programs quickly, and it's quick enough when running them, and can of course be tuned further through managing allocations/collections of the GC etc.
Re: A betterC base
On Thursday, 8 February 2018 at 15:51:38 UTC, Adam D. Ruppe wrote: On Thursday, 8 February 2018 at 15:43:01 UTC, ixid wrote: That's been said over and over and the message has not gotten through. It is almost never said! We always play by their terms and implicitly concede by saying "but we can avoid it" or "look -betterC". Reddit invades our space, and we fall back. Rust assimilates entire worlds, and we fall back. Not again! The line must be drawn here! This far, no further! Woot! Love it. :) Will save that quote you provided to use elsewhere. Thanks. Regarding what you said about the implementation of the GC following in the footsteps of industry giants, what specifically about D's GC impl is patterned after other industry giant's GC's?
Re: My choice to pick Go over D ( and Rust ), mostly non-technical
On Wednesday, 7 February 2018 at 15:16:46 UTC, Ralph Doncaster wrote: On Wednesday, 7 February 2018 at 15:10:36 UTC, Ralph Doncaster wrote: On Wednesday, 7 February 2018 at 08:05:46 UTC, Nicholas Wilson wrote: For OpenCL I develop and maintain DCompute: http://code.dlang.org/packages/dcompute https://github.com/libmir/dcompute It has a much beautified interface to OpenCL (and is mostly consistent with its CUDA interface). You can also write kernels directly in D, however this requires that LDC is built against my fork of LLVM: https://github.com/thewilsonator/llvm It's still in dev but should be usable. Please let me know if you have issues using it. I saw your library before, but it looked like it is ONLY for native D on GPUs. I looked at it again, and don't see any documentation or example showing that it works with standard OpenCL kernels written in C. Yeah its a wrapper for OpenCL so as long as the names and signatures of the symbols match it should work. p.s. since you seem to be a green team guy, you might not know that llvm optimization sucks on AMD. I use -legacy when building my kernels to get the good old compiler. "green team guy"? It that with the OpenCL C compiler? DCompute goes through SPIR-V for OpenCL (although it would be nice to support SPIR. Unfortunately the official version SPIR 2.0 is based of is not supported by LDC), I dont know if this makes a difference. It would be nice to eventually support AMDGCN et. al. at some point but I don't have the time at the moment.
Re: A betterC base
On Thursday, 8 February 2018 at 14:54:19 UTC, Adam D. Ruppe wrote: Garbage collection has proved to be a smashing success in the industry, providing productivity and memory-safety to programmers of all skill levels. Citation needed on how garbage collection has been a smashing success based on its merits rather than the merits of the languages that use garbage collection. Python was also a smashing success, but it doesn't use a garbage collector in it's default implementation (CPython). Unless you mean garbage collection as in "not manual memory management"? But that still might not be as simple, because RAII would fall somewhere inbetween.
Re: Quora: Why hasn't D started to replace C++?
On Thursday, 8 February 2018 at 15:29:08 UTC, Ralph Doncaster wrote: On Wednesday, 7 February 2018 at 22:31:58 UTC, John Gabriele wrote: I'm not sure how long dub has been around, but having an easy to use CPAN-alike (online module repo) is HUGE. Dub is great for sales. The better dub and the repo gets, the more attractive D gets. I completely agree that the availability of libraries is a huge factor. I almost gave up on D because of the limited amount of 3rd party libs. I think just improving the search function would help. http://code.dlang.org/search?q=keccak Comes up with nothing, so I started porting a sha3/keccak lib from C to D. Then someone pointed out botan has sha3 support, which can be found if you search for "crypto" http://code.dlang.org/search?q=crypto The opposite situation you may see, when searching for mysql: You will get 9 packages listed. Which should I take? If you click on everyone, you will realize, that some of them are forks of other. And the version number of mysql-native at the top, just recently increased so strong, that it makes a different. The minimum additional information which should be listed - I think - is the number of downloads and GitHub stars. I know that there is work behind the scene to find some kind of weighted sort, this would be cool, but just displaying the GitHub voting might help a lot.
Re: A betterC base
On Thursday, 8 February 2018 at 15:43:01 UTC, ixid wrote: That's been said over and over and the message has not gotten through. It is almost never said! We always play by their terms and implicitly concede by saying "but we can avoid it" or "look -betterC". Reddit invades our space, and we fall back. Rust assimilates entire worlds, and we fall back. Not again! The line must be drawn here! This far, no further!
Re: A betterC base
On Thursday, 8 February 2018 at 14:56:31 UTC, Adam D. Ruppe wrote: ooh better last sentence D's GC implementation follows in the footsteps of industry giants without compromising experts' ability to realize maximum potential from the machine. That's been said over and over and the message has not gotten through. With a pay for what you use approach the GC is just as available as it is now, and yes, I completely agree it's very useful and that the reaction to it is ludicrous. This is an illogical argument that we've lost so needs a new approach.
Re: Quora: Why hasn't D started to replace C++?
On Wednesday, 7 February 2018 at 22:31:58 UTC, John Gabriele wrote: I'm not sure how long dub has been around, but having an easy to use CPAN-alike (online module repo) is HUGE. Dub is great for sales. The better dub and the repo gets, the more attractive D gets. I completely agree that the availability of libraries is a huge factor. I almost gave up on D because of the limited amount of 3rd party libs. I think just improving the search function would help. http://code.dlang.org/search?q=keccak Comes up with nothing, so I started porting a sha3/keccak lib from C to D. Then someone pointed out botan has sha3 support, which can be found if you search for "crypto" http://code.dlang.org/search?q=crypto
Somewhat OT: defining algebras in D
So I was bored in a meeting and decided to implement a generic
template for defining complex numbers, dual numbers, quaternions
and many other possible algebras by simply defining a set of
rules and the components on which they act:
alias quaternion = Algebra!(
float,
"1,i,j,k",
op("1", any) = any,
op("i,j,k", self) = "-1",
op("i", "j") = "k".antiCommutative,
op("j", "k") = "i".antiCommutative,
op("k", "i") = "j".antiCommutative,
);
source:
https://gist.github.com/Biotronic/833680b37d4afe774c8562fd21554c6b
--
Simen
Re: missing HexString documentation
On 2/8/18 9:44 AM, Adam D. Ruppe wrote: On Thursday, 8 February 2018 at 13:06:44 UTC, Steven Schveighoffer wrote: So you think it should go into druntime? I don't see why it wasn't in there in the first place to be honest. Yeah, probably. I might even publically import it when you import the posix header so it just works in the most common place. Of course, it is important then that the compile-time thing doesn't cause a link time error when you just import and don't compile it in but that should be the case anyway (and the other posts in this thread show Walter is working on that so yay) If you could have imported std.conv in druntime, it would have been done. That's my point. We keep clashing despite being on the same side! Your statement before: "it is 0o100 vs import std.conv" and "That is why it isn't used in druntime" I thought it meant there was some sort of decision made to not use the import because it would be too costly. But really, there was no decision to be made. Sorry about the misunderstanding! When I say the import is the problem, I don't mean the syntax or literal line of code. I mean the whole concept of depending on the Phobos module and all the stuff that brings. druntime can't have that dependency. Neither can a few other specialized low-level cases. And specialized low-level cases are where you find 95% of octal literals. (well ok 50% of octal literals, where the other 50% are bugs cuz someone wrote 010 to line up leading zeros... ) I agree, you could implement the octal template in druntime without too much issue. The octal!"100" would have been easy-to-parse, the octal!100 version would be more difficult, but nothing impossible that requires the whole of phobos to do so. My concern in the hexString case is the sheer requirement of CTFE for something that is so easy to do in the compiler, already *done* in the compiler, and has another form specifically for hex strings (the "\xde\xad\xbe\xef" form) that isn't going away. It makes me laugh actually that Walter is now replacing the implementation with a mixin of that other form, incurring all the cost of CTFE so you can transform the string, while breaking existing code in the process: https://github.com/dlang/phobos/pull/6138 -Steve
Re: A betterC base
ooh better last sentence D's GC implementation follows in the footsteps of industry giants without compromising experts' ability to realize maximum potential from the machine.
Re: A betterC base
On Thursday, 8 February 2018 at 11:06:15 UTC, ixid wrote: It feels like D has not overcome at least two major issues in the public mind, the built-in GC D is a pragmatic language aimed toward writing fast code, fast. Garbage collection has proved to be a smashing success in the industry, providing productivity and memory-safety to programmers of all skill levels. D's GC implementation follows in the footsteps of industry giants without compromising expert's ability to tweak even further. That's what we should be saying every single time someone mentions GC. Including it was the RIGHT DECISION and we should own that.
Re: missing HexString documentation
On Thursday, 8 February 2018 at 13:06:44 UTC, Steven Schveighoffer wrote: So you think it should go into druntime? I don't see why it wasn't in there in the first place to be honest. Yeah, probably. I might even publically import it when you import the posix header so it just works in the most common place. Of course, it is important then that the compile-time thing doesn't cause a link time error when you just import and don't compile it in but that should be the case anyway (and the other posts in this thread show Walter is working on that so yay) If you could have imported std.conv in druntime, it would have been done. That's my point. We keep clashing despite being on the same side! When I say the import is the problem, I don't mean the syntax or literal line of code. I mean the whole concept of depending on the Phobos module and all the stuff that brings. druntime can't have that dependency. Neither can a few other specialized low-level cases. And specialized low-level cases are where you find 95% of octal literals. (well ok 50% of octal literals, where the other 50% are bugs cuz someone wrote 010 to line up leading zeros... )
Re: missing HexString documentation
On Thursday, 8 February 2018 at 10:52:35 UTC, Kagamin wrote: Or have a function specifically for unix permissions, like int unix(int r, int w, int x, int gr, int gw, int gx, int ur, int uw, int ux); It might be even more readable. I actually personally prefer binary: 0b_1_111_101_000 which visually corresponds with ls's output: drwxr-xr-x. But octal is the way they are usually done in C. The comments in druntime are because that had to be translated from the common convention.
Re: option -ignore_pure for temporary debugging (or how to wrap an unpure function inside a pure one)?
On 2/8/18 8:32 AM, Steven Schveighoffer wrote:
On 2/7/18 10:32 PM, Timothee Cour wrote:
same question with how to wrap a gc function inside a nogc shell, if
not, allowing a flag -ignore_nogc that'd enable this (again, for
debugging purposes)
If you wrap the call in a debug block, it will work.
int foo() pure
{
debug writeln("yep, this works");
}
Gah, I see this was answered 2 other times, but for some reason, your
replies turn out as new threads.
Sorry for the extra noise.
-Steve
Re: option -ignore_pure for temporary debugging (or how to wrap an unpure function inside a pure one)?
On 2/7/18 10:32 PM, Timothee Cour wrote:
same question with how to wrap a gc function inside a nogc shell, if
not, allowing a flag -ignore_nogc that'd enable this (again, for
debugging purposes)
If you wrap the call in a debug block, it will work.
int foo() pure
{
debug writeln("yep, this works");
}
-Steve
Re: missing HexString documentation
On 2/8/18 1:10 AM, Walter Bright wrote: On 2/7/2018 9:45 PM, Ralph Doncaster wrote: > While the fix is a huge improvement, it doesn't match the code generated by the hex literals. hexString!"deadbeef" stores the null-terminated string in the data section of the object file, while x"deadbeef" only stores 4 bytes in the data section. string s = x"deadbeef"; stores a null terminated string, too. If you want only 4 bytes, __gshared immutable char[4] = hexString!"deadbeef"; just as you'd do for any string literal. The extra data in the object file comes from the inclusion of the hexStringImpl function, and from the template parameter (the symbol _D3std4conv__T9hexStringVAyaa8_6465616462656566ZQBiyAa is in there as well, which will always be larger than the actual string passed to hexString). I also see the data in there twice for some reason. -Steve
Re: missing HexString documentation
On 2/7/18 3:24 PM, Adam D. Ruppe wrote: On Wednesday, 7 February 2018 at 18:59:38 UTC, Steven Schveighoffer wrote: Not even close. Octal literals are a disaster, because putting a leading 0 should never change the base of a number. I agree the leading 0 is terrible. But that's not the real question here: it is 0o100 vs import std.conv. Note it isn't the syntax - octal!100 is quite nice to me - but rather the requirement to import. That is why it isn't used in druntime... and low level code interfacing with external OS or hardware APIs are the most common place for octal, and also where we can't use it. I fear hex will fall into the same pit. So you think it should go into druntime? I don't see why it wasn't in there in the first place to be honest. But there is no "decision" on whether to import or not, it's not possible in druntime to import from phobos. So saying the lack of use of octal in druntime is somehow a detraction on the import is incorrect. If you could have imported std.conv in druntime, it would have been done. This has its own problems (e.g. 0O) That's why I specifically wrote `0o`. I wouldn't allow `0O`, just like D doesn't allow `1l`: "Error: lower case integer suffix 'l' is not allowed. Please use 'L' instead" I'm still not in love with the little-o syntax, but this definitely would be necessary. The difference for me isn't how the problem is solved, but that there was a problem for octals (error prone sinister errors) but there isn't/wasn't one for hex strings. You and I are on the same side :) I also think they should stay (I just want to see them retyped as immutable(ubyte)[] instead of immutable(char)[], we always cast anyway). To me, it is a shortcut for specifying hex for every character. The cast isn't that horrible, and probably can be abstracted away into a function if you want. -Steve
Re: A betterC base
On Thursday, 8 February 2018 at 11:06:15 UTC, ixid wrote:
How difficult would it be for D at this point to move towards a
pay for what you use system that out of the box is betterC and
requires the garbage collector to be explicitly imported?
I'm not sure if this is what you're looking for, but I've been
trying to work on something like that, and have successfully
submitted a few PRs:
Opt-in ModuleInfo
https://github.com/dlang/dmd/pull/7395
https://github.com/dlang/dmd/pull/7768
Opt-in Throwable
https://github.com/dlang/dmd/pull/7786
Opt-in TypeInfo
https://github.com/dlang/dmd/pull/7799 (not yet merged; someone
please review it)
With all of the above PRs merged, the compiler will no longer
complain about the above missing runtime features if your code
doesn't use them. It also allows one to create really small
binaries with no dependencies.
Example 1
=
object.d
module object;
private alias extern(C) int function(char[][] args) MainFunc;
private extern (C) int _d_run_main(int argc, char** argv,
MainFunc mainFunc)
{
return mainFunc(null);
}
main.d
--
void main() { }
dmd -conf= -defaultlib= main.d object.d -of=main
size main
textdata bss dec hex filename
1403 584 162003 7d3 main
Example 2
This will avoid linking in the C standard library and C runtime.
But you have to provide your own replacements.
=
object.d
module object;
extern(C) void __d_sys_exit(long arg1)
{
asm
{
mov RAX, 60;
mov RDI, arg1;
syscall;
}
}
extern void main();
private extern(C) void _start()
{
main();
__d_sys_exit(0);
}
main.d
--
void main() { }
dmd -c -lib main.d object.d -of=main.o
ld main.o -o main
size main
textdata bss dec hex filename
56 0 0 56 38 main
If you are creating a library to be consumed by another language,
you just need to add an empty object.d file in your current
directory. I tried to remove that silly limitation, but it met
resistance: https://github.com/dlang/dmd/pull/7825
I have a changelog PR describing all this at
https://github.com/dlang/dmd/pull/7829, with the intention of it
being available in the next DMD release, but I need my other PRs
reviewed and merged before I can move forward.
This is just the tip of the iceberg, though. After this stage, I
would like to start tackling the overuse of TypeInfo in the
coupling between the compiler and the runtime. See this comment
(https://issues.dlang.org/show_bug.cgi?id=18312#c2) for more
about what I mean there.
Mike
Re: Heads-up: upcoming instabilities in std.experimental.allocator, and what to do
On Thursday, 30 November 2017 at 19:01:02 UTC, Andrei Alexandrescu wrote: So we may switch to ubyte[] Hooray!
Re: A betterC base
On Thursday, 8 February 2018 at 11:06:15 UTC, ixid wrote: How difficult would it be for D at this point to move towards a pay for what you use system that out of the box is betterC and requires the garbage collector to be explicitly imported? https://github.com/dlang/druntime/pull/2057 It feels like D has not overcome at least two major issues in the public mind, the built-in GC and, more ludicrously, the D1 library split. Would there not be significant value in making this a D3 transition? As non-breaking as possible but moving the run time elements into libraries One of Andrei's student is working on this. I think she has been focusing on templated ==, <= and AAs so far and is now recently getting more into the GC business: https://github.com/dlang/druntime/pulls?utf8=%E2%9C%93&q=is%3Apr+author%3Asomzzz and potentially taking the opportunity to invert the defaults for things like safe and pure. I think someone (Petar?) is working on a DIP for package-wide defaults. The idea is simple, you tell the compiler once: "Hey yo, listen up. I know that old code still needs to XXX (e.g. @system by default), but don't be a bad boy and let me opt-in into the cool new stuff by default, please" I don't recall the exact details though. Ideally it's like the -std=c++11 flag, i.e. you set it once in your dub.sdl and don't have to think about it again. The story of this D3 transition to the public would then address the 'issues' head on, creating an easily conveyable story that these have been resolved. This appears to be the level on which a lot of language adoption works, at least between hearing about and trying a language. At the moment it's painful to see the endless criticisms of the GC and library split crop up whenever D is discussed. D is progressing technically but needs a 'story'. I don't think D3 is going to happen anytime soon (except someone forks the language). Breaking changes are only done for critical things, e.g. when the compiler learns to detect new errors in your code. Regarding the 'story', there's e.g. the excellent GC Series now (https://dlang.org/blog/the-gc-series) and things are moving forward though of course PR has always been one of D's weakest points. --- Though if there's ever a D3, my list of things to be addressed is big - no auto-decoding - fix shared - attribute bloat - wrong defaults (e.g. @safe or final by default) - C behavior without compiler warnings - tuples (though it looks like they can be retro-actively added now that the use of the return of the comma operator is finally gone) - Redesign Phobos with @nogc in mind - remove the bloat from Phobos - std.io (with streams) - proper naming and structuring in Phobos (e.g. why is doesPointTo or RangePrimitive in std.exception), or "hello super-messy std.traits" ... Some of these actually can be fixed with little or no breakage, but for most - if addressed - hell would break loose.
Re: Bye bye, fast compilation times
On Wed, Feb 07, 2018 at 10:59:51PM -0500, Nick Sabalausky (Abscissa) via Digitalmars-d wrote: [...] > On 02/06/2018 08:47 PM, jmh530 wrote: > > > > Would it help to take the approach of mir, i.e. putting > > version(mir_test) before all the unittests? > > That used to be a very common idiom. (And I agree with Jonathan M > Davis: it's a STRONG sign the current design needs fixed). But newer > versions of dub, intelligently, will only compile the files in the > main project with -unittest, which solves the problem...*for dub > users*. Unfortunately, this means that the idiom above has become less > common and libraries have become less usable for anyone using a build > tool *other* than dub. :( Actually, it does *not* solve the problem for dub users. Compiling with -unittest causes unittests for imported modules to be instantiated too. (Otherwise, Phobos unittests wouldn't show up in a -unittest build since we never compile Phobos modules directly in a user project!) T -- ASCII stupid question, getty stupid ANSI.
Re: Bye bye, fast compilation times
On Monday, 5 February 2018 at 21:27:57 UTC, H. S. Teoh wrote:
One of my D projects for the past while has been taking
unusually long times to compile. This morning, I finally
decided to sit down and figure out exactly why. What I found
was rather disturbing:
--
import std.regex;
void main() {
auto re = regex(``);
}
--
Compile command: time dmd -c test.d
Output:
--
real0m3.113s
user0m2.884s
sys 0m0.226s
--
Comment out the call to `regex()`, and I get:
--
real0m0.285s
user0m0.262s
sys 0m0.023s
--
Clearly, something is wrong if the mere act of compiling a
regex causes a 4-line program to take *3 seconds* to compile,
where normally dmd takes less than a second.
Thank you for this finding!
I was wondering why my little vibe.d project started to take
approximately twice the
time to compile, and because of making a mistake in my test
setup, even my minimal
program still included the file containing the regex. So that
even reducing the used
code to a minimum the compilation time was ~7 sec compared to
less than 4 seconds.
Would be cool if we could get fast compilation of regex.
I am coming from using scripting languages (perl and ruby) using
regex a lot, so that this is really disappointing for me.
Beginner question:
How to split my project, to compile the regex part separately as
a lib and just link them?
A betterC base
How difficult would it be for D at this point to move towards a pay for what you use system that out of the box is betterC and requires the garbage collector to be explicitly imported? It feels like D has not overcome at least two major issues in the public mind, the built-in GC and, more ludicrously, the D1 library split. Would there not be significant value in making this a D3 transition? As non-breaking as possible but moving the run time elements into libraries and potentially taking the opportunity to invert the defaults for things like safe and pure. The story of this D3 transition to the public would then address the 'issues' head on, creating an easily conveyable story that these have been resolved. This appears to be the level on which a lot of language adoption works, at least between hearing about and trying a language. At the moment it's painful to see the endless criticisms of the GC and library split crop up whenever D is discussed. D is progressing technically but needs a 'story'.
Re: missing HexString documentation
Or have a function specifically for unix permissions, like int unix(int r, int w, int x, int gr, int gw, int gx, int ur, int uw, int ux); It might be even more readable.
Re: missing HexString documentation
On Wednesday, 7 February 2018 at 17:01:54 UTC, Adam D. Ruppe
wrote:
http://dpldocs.info/experimental-docs/source/core.sys.posix.fcntl.d.html#L123
version (X86)
{
enum O_CREAT= 0x40; // octal 0100
enum O_EXCL = 0x80; // octal 0200
enum O_NOCTTY = 0x100;// octal 0400
enum O_TRUNC= 0x200;// octal01000
Dunno, hex reads better here. Octal is only good for unix
permissions which are grouped by 3 bits, which is not the case
for io constants - these are usual ungrouped flags that are
always done with hex and are easier to understand in hex. If
you're desperate, octal can be also written as (1<<6)|(2<<3)|(4).
Re: Heads-up: upcoming instabilities in std.experimental.allocator, and what to do
On Friday, 1 December 2017 at 02:30:29 UTC, Seb wrote: On Thursday, 30 November 2017 at 19:01:02 UTC, Andrei Alexandrescu wrote: Hi all, Eduard, Alexandru Jercaianu and I are working on improving allocators' design and implementation. This entails a few breaking changes. In order to make matters easier for code using allocators, Sebastian Wilzbach created a dub package freezing the existing API: http://code.dlang.org/packages/stdx-allocator. Please use that until we work the kinks out of allocators - great things are coming! - and after that feel free to upgrade code to use the new and improved allocators. I just pushed a couple of fixes [1] for older Phobos versions and stdx-allocator now works down until 2.072.2. If someone needs an older Phobos version to work with stdx-allocator, please let me know. Also switching to stdx-allocator is rather easy, e.g.: ``` sed -i "s/std[.]experimental/stdx/g" **/*.d ``` [1] https://github.com/wilzbach/stdx-allocator/commit/d06e4f2bae2eee5d380d145221ecb9cab04c90d7 Just a friendly reminder to people that experimental isn't expected to be stable. 2.079 will come with this change, switch to stdx-allocator package if you prefer stability. stdx-allocator provides the current code and works down until 2.072. https://dlang.org/changelog/pending.html#std-experimental-allocator-rciallocator https://code.dlang.org/packages/stdx-allocator Also note that only vibe.d ~>= 0.8.3-alpha.1 and vibe-core ~>= 1.4.0-alpha.1 use this package. (though while most projects have been upgraded manually, I hope that we can get a new release of Vibe.d out there soon to avoid any issues - see [1]). [1] https://github.com/vibe-d/vibe.d/issues/2058
Re: Status status = __traits(compilesReportError, {string b=10; }) => status.msg=Error: cannot....
On Wednesday, 7 February 2018 at 20:29:44 UTC, Timothee Cour
wrote:
is there any way to get error from speculative execution
(`__traits(
compiles, ...)`)? would be useful in tests; If not currently
how hard
would that be to implement? eg:
```
struct Status{bool ok; string msg;}
Status status = __traits(compilesReportError, {string b=10;})
assert(!status.ok);
assert(status.msg==`main.d(15) Error: cannot implicitly convert
expression 10 of type int to string`);
```
static if(!__traits(compiles, $CODE)) {
$CODE
}
It's the same technique I use in concepts to produce an error
message if a struct you wanted to be, say isInputRange, isn't:
https://github.com/atilaneves/concepts
Atila
Re: Bye bye, fast compilation times
On Wednesday, 7 February 2018 at 22:00:48 UTC, Bastiaan Veelo wrote: On Wednesday, 7 February 2018 at 09:27:47 UTC, Stefan Koch wrote: Another Thing that can be done is reviewing the code and alerting me to potential problems. i.e. Missing or indecipherable comments as well as spelling mistakes. (with the correction please (just telling me something is wrong, will not help since I obliviously don't know how to spell it)) What is the preferred place for this? https://github.com/dlang/dmd/pull/7073 or do you want PRs against a fork of yours? Corrected link: https://github.com/UplinkCoder/dmd/tree/newCTFE_reboot
Re: Bye bye, fast compilation times
On Wednesday, 7 February 2018 at 22:00:48 UTC, Bastiaan Veelo wrote: On Wednesday, 7 February 2018 at 09:27:47 UTC, Stefan Koch wrote: Another Thing that can be done is reviewing the code and alerting me to potential problems. i.e. Missing or indecipherable comments as well as spelling mistakes. (with the correction please (just telling me something is wrong, will not help since I obliviously don't know how to spell it)) What is the preferred place for this? https://github.com/dlang/dmd/pull/7073 or do you want PRs against a fork of yours? I'd prefer a pr against https://github.com/UplinkCoder/dmd/newCTFE_reboot
