Which language futures make D overcompicated?

[Suliman via Digitalmars-d]

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

[Suliman via Digitalmars-d]

- 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)?

[Timothee Cour via Digitalmars-d]

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

[Nick Sabalausky (Abscissa) via Digitalmars-d]

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.

[Issue 18407] debug should escape nothrow, @nogc, @safe (not just pure)

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18407

--- Comment #2 from Timothee Cour  ---
workaround suggested here by Adam Ruppe:
 https://forum.dlang.org/post/ojgxdtqodcamkqcrx...@forum.dlang.org
```
void foo() {}

@trusted nothrow @nogc void da(scope void delegate() a) {
auto hack = cast(void delegate() @nogc) a;
try
hack();
catch(Exception e)
assert(0, e.msg);
}

@safe nothrow @nogc pure void main() {
debug da({foo();});
}
```

--

[Issue 18407] debug should escape nothrow, @nogc, @safe (not just pure)

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18407

--- Comment #1 from Timothee Cour  ---
related forum threads:
* option -ignore_pure for temporary debugging (or how to wrap an unpure
function inside a pure one)?
* Should debug{} allow GC?
* Debug prints in @nogc

--

Re: #dbugfix Issue 18068 - No file names and line numbers in stack trace

[Nick Sabalausky (Abscissa) via Digitalmars-d]

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.

[Issue 18407] New: debug should escape nothrow @nogc safe (not just pure)

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18407

  Issue ID: 18407
   Summary: debug should escape nothrow @nogc safe (not just pure)
   Product: D
   Version: D2
  Hardware: x86
OS: Mac OS X
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: timothee.co...@gmail.com

```
void fun_nogc()@nogc{
  debug{
auto a1=new int(1); // Error: cannot use 'new' in @nogc function 'main.fun'
  } 
}

void fun_nothrow() nothrow{
  debug{
static int a;
import std.exception;
enforce(a==0);  //  Error: function std.exception.enforce!(Exception,
bool).enforce is not nothrow
  } 
}

static int temp(){
  static int a=0;
  a++;
  return a;
}

int fun_pure() pure{
  int ret;

  debug{
ret+=temp;  // ok this works
static int a2=0;
a2++;
ret+=a2;
  }
  return ret;
}

void fun_safe() @safe{
  debug{
int []a=[1];
if(false) a.ptr[0]++; // Error: a.ptr cannot be used in @safe code, use
[0] instead
  }
}

void main(){
  fun_nogc;
  fun_nothrow;
  fun_pure;
  fun_safe;
}

```

--

[Issue 18407] debug should escape nothrow, @nogc, @safe (not just pure)

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18407

Timothee Cour  changed:

   What|Removed |Added

 CC||timothee.co...@gmail.com
Summary|debug should escape nothrow |debug should escape
   |@nogc safe (not just pure)  |nothrow, @nogc, @safe (not
   ||just pure)

--

[Issue 18406] __traits( getOverloads ) doesn't accept module symbols as its aggregate parameter

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18406

Ethan Watson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Ethan Watson  ---
Turns out I'm just a rookie. You need to stringify the final parameter if
necessary...

--

[Issue 18406] New: __traits( getOverloads ) doesn't accept module symbols as its aggregate parameter

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18406

  Issue ID: 18406
   Summary: __traits( getOverloads ) doesn't accept module symbols
as its aggregate parameter
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: critical
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: goober...@gmail.com

Created attachment 1680
  --> https://issues.dlang.org/attachment.cgi?id=1680=edit
Code example

>From the documentation, "The first argument is an aggregate (e.g.
struct/class/module)."

This gets further complicated when doing an allMembers pass of a module with an
overloaded function - the function symbol will show up multiple times, but
since you cannot get the overloads you can only resolve the first overload
encountered by the compiler.

Code example attached. Uses __traits( parent ) to get the module symbol. Other
methods of obtaining the symbol, such as mixing in the name and assigning to an
alias, result in the exact same error.

Expected result: NumOverloads gets the value 2 assigned to it
Actual result: Error message: expression expected as second argument of
__traits getOverloads

--

mysql-native v2.0.0-rc3: Third release candidate

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

Hopefully the last.

Changes since RC2 listed in changelog:
https://github.com/mysql-d/mysql-native/blob/master/CHANGELOG.md

--

Incidentally, when you're sticking to semantic versioning, utilizing 
release candidates and git branches REALLY comes in handy ;)  Highly 
recommend. Work on v2.1.0 is progressing while v2.0.0 is stabilizing. 
Plus, some of the work on v2.1.0 has revealed needs that are best 
included in v2.0.0 to avoid an imminent bump to v3+. Nice.

[Issue 18351] integrate dub changelog with changed.d tool

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18351

--- Comment #4 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dlang.org

https://github.com/dlang/dlang.org/commit/161730855cf247fb9f0d6bfd2860a90d419d397d
Issue 18351 - integrate dub changelog with changed.d tool

https://github.com/dlang/dlang.org/commit/4480f07026312738a1aeb23ff3dfb88af53b4b61
Merge pull request #2163 from wilzbach/18351

Issue 18351 - integrate dub changelog with changed.d tool
merged-on-behalf-of: Vladimir Panteleev 

--

Re: A betterC base

[psychoticRabbit via Digitalmars-d]

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.

[Issue 519] Invariant not called from autogenerated class/struct constructor/destructor

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=519

--- Comment #19 from Walter Bright  ---
Rebooted as: https://github.com/dlang/dmd/pull/7536/

--

Re: #dbugfix Issue 1983

[Mike Parker via Digitalmars-d]

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: Official Dub package for DWT

[Brian via Digitalmars-d-announce]

Thanks!

But, How to use x64?

Re: A betterC base

[psychoticRabbit via Digitalmars-d]

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

[Timothee Cour via Digitalmars-d]

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

[Mike Parker via Digitalmars-d]

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

[Timothee Cour via Digitalmars-d]

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

[Nick Sabalausky (Abscissa) via Digitalmars-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

[Mike Franklin via Digitalmars-d]

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

[rjframe via Digitalmars-d]

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

[psychoticRabbit via Digitalmars-d]

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

[Jonathan M Davis via Digitalmars-d]

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

[Issue 14964] __traits(isAlias, foo)

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14964

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #6 from Walter Bright  ---
I see this is a feature that could lead to a lot of unforeseen consequences.
The language semantics very much rely on an alias being indistinguishable from
the target.

As for the size_t example, it's not even possible to serialize it as a size_t.
It will go out as int or long. Name mangle a size_t, and there is no size_t
mangling, it's int or long.

> __traits(getAllMembers, funcs)

Perhaps a better solution is to have getAllMembers ignore aliases, as aliases
are members only for the purpose of symbol lookup.

--

Re: A betterC base

[Benny via Digitalmars-d]

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 

Re: A betterC base

[Mike Franklin via Digitalmars-d]

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

[Issue 18405] New: std.getopt should support std.typecons.Flag out of the box

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18405

  Issue ID: 18405
   Summary: std.getopt should support std.typecons.Flag out of the
box
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: bootcamp
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

I know that the following works already:

---
import std.getopt, std.typecons, std.stdio;
void main()
{
auto args = ["foo", "-u"];
alias U =Flag!"foo";
U flag = U.no;
getopt(args, "u", { flag = U.yes; }, );
flag.writeln;
}
---

https://run.dlang.io/is/46u8Rx


But Flag is such a common type and "built-in" in Phobos, s.t. getopt should
really support it.

--

Re: A betterC base

[Mike Franklin via Digitalmars-d]

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

[Issue 18398] std.datetime.stopwatch documented examples could be better

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18398

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/602c3ede713e626cc0147f81db24cfaaf426e060
Issue 18398 - std.datetime.stopwatch documented examples could be better

https://github.com/dlang/phobos/commit/7c1e10d82f5d71a85fda1a7936751574318739e0
Merge pull request #6139 from n8sh/issue-18398-stopwatch-doc

Issue 18398 - std.datetime.stopwatch documented examples could be better
merged-on-behalf-of: Sebastian Wilzbach 

--

Re: Bye bye, fast compilation times

[Nick Sabalausky (Abscissa) via Digitalmars-d]

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

[Adam D. Ruppe via Digitalmars-d]

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

[Adam D. Ruppe via Digitalmars-d]

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

[Rubn via Digitalmars-d]

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

[Ali via Digitalmars-d]

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

[Issue 18404] New: Allow selective printing of -vgc output

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18404

  Issue ID: 18404
   Summary: Allow selective printing of -vgc output
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: bachm...@yahoo.com

It is not practical to use -vgc to catch accidental gc allocations.

Based on this post:
https://www.reddit.com/r/programming/comments/7vw0gj/vanquish_forever_these_bugs_that_blasted_your/dtygfde/

"If you use no GC at all, anywhere, it can be helpful, yes.

If you rarely use GC (e.g: when throwing exceptions, because D makes it very
inconvenient not to use GC there, and it's less important), then you will
always get that as noise that's hard to filter out."

The user should have a way to exclude printing of some of the warnings.

--

Re: A betterC base

[Adam D. Ruppe via Digitalmars-d]

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

[Adam D. Ruppe via Digitalmars-d]

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: free func "front" is not picked up as a candidate when doing range.front(...)

[Jonathan M Davis via Digitalmars-d-learn]

On Thursday, February 08, 2018 21:58:39 aliak via Digitalmars-d-learn wrote:
> On Thursday, 8 February 2018 at 19:32:42 UTC, Jonathan M Davis
>
> wrote:
> > On Thursday, February 08, 2018 08:18:20 aliak via
> >
> > Digitalmars-d-learn wrote:
> >> On Thursday, 8 February 2018 at 07:16:43 UTC, Jonathan M Davis
> >>
> >> wrote:
> >> > It would be a disaster if free functions could override
> >> > member functions. For starters, it would be impossible to
> >> > call the member function if that were allowed, whereas you
> >> > can always call a free function by not using UFCS. And in
> >> > general, it's far more desirable to have member function
> >> > functions override free functions, because then you can do
> >> > stuff like have have a range override find if it can provide
> >> > a more efficient implementation than std.algorithm.find.
> >>
> >> That could be fixed with a precedence rule though no? Then
> >> member find will be preferred over free find. And it won't be
> >> impossible to call member functions.
> >
> > That's exactly how it works now. If you call a function as if
> > it were a member function, and that type has that member
> > function, then it's that member function that gets called. If
> > that type doesn't have that member function, then free
> > functions are checked.
>
> Wait no, that's not how it works now. Right now if a member
> function with the same name exists, then free functions are not
> even checked. Whereas if there's a precedence rule that prefers
> member functions, then free functions will still be checked if no
> member function with that name can be deduced as a viable
> candidate. How it is now disregards free functions without any
> consideration (if I've understood correctly), whereas I'm asking
> why free functions are not even considered if a member function
> is not an actual candidate. I'm not asking about overriding
> member functions with free functions.
>
> i.e. in my original post, the free function front(int) does not
> exist in type FilterResult.

D tends to be very picky about what it puts in overload sets in order to
avoid function hijacking - e.g. it doesn't even include base class functions
in an overload set once you've declared one in a derived class unless you
explicitly add an alias to the base class function in the derived class.

Also, D doesn't support "best match" with function overloads. The matches
have to be exact - e.g. as soon as implicit conversions come into play,
there can only be one match. If there's ever a conflict, you get a
compilation error (unlike in C++, which tries to figure out what it thinks
the best match is and go with that, sometimes with surprising results). And
having both the member functions and free functions in the same overload set
would basically require the compiler to go with the "best match," which
simply isn't how D deals with overloads. Sometimes, that's annoying, but it
also prevents a lot of subtle bugs that tend to crop up in C++ code.

https://dlang.org/spec/function.html#function-overloading
https://dlang.org/articles/hijack.html

- Jonathan M Davis

[Issue 18403] [REG2.078.2] Access violation when dmd tries to print highlighted code

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18403

ag0ae...@gmail.com changed:

   What|Removed |Added

   Keywords||ice
 CC||ag0ae...@gmail.com
Summary|Access violation when   |[REG2.078.2] Access
   |deprecated feature  |violation when dmd tries to
   |encountered |print highlighted code

--- Comment #1 from ag0ae...@gmail.com ---
Also happens on other errors. Seems to be related to code highlighting via
backticks in the error message.

For example, a source file that's just "foo" also fails. But this works as
expected even though it prints a deprecation message (but it doesn't have
highlighted code):


void main() { shared int x; ++x; }


Never fails when dmd is invoked with `-color=off`.

The diff between 2.078.1 and 2.078.2 is really small [1], and I can't spot
anything that's related to code highlighting.


[1] https://github.com/dlang/dmd/compare/v2.078.1...v2.078.2

--

Re: free func "front" is not picked up as a candidate when doing range.front(...)

[aliak via Digitalmars-d-learn]

On Thursday, 8 February 2018 at 19:32:42 UTC, Jonathan M Davis 
wrote:
On Thursday, February 08, 2018 08:18:20 aliak via 
Digitalmars-d-learn wrote:

On Thursday, 8 February 2018 at 07:16:43 UTC, Jonathan M Davis

wrote:
> It would be a disaster if free functions could override 
> member functions. For starters, it would be impossible to 
> call the member function if that were allowed, whereas you 
> can always call a free function by not using UFCS. And in 
> general, it's far more desirable to have member function 
> functions override free functions, because then you can do 
> stuff like have have a range override find if it can provide 
> a more efficient implementation than std.algorithm.find.


That could be fixed with a precedence rule though no? Then 
member find will be preferred over free find. And it won't be 
impossible to call member functions.


That's exactly how it works now. If you call a function as if 
it were a member function, and that type has that member 
function, then it's that member function that gets called. If 
that type doesn't have that member function, then free 
functions are checked.


Wait no, that's not how it works now. Right now if a member 
function with the same name exists, then free functions are not 
even checked. Whereas if there's a precedence rule that prefers 
member functions, then free functions will still be checked if no 
member function with that name can be deduced as a viable 
candidate. How it is now disregards free functions without any 
consideration (if I've understood correctly), whereas I'm asking 
why free functions are not even considered if a member function 
is not an actual candidate. I'm not asking about overriding 
member functions with free functions.


i.e. in my original post, the free function front(int) does not 
exist in type FilterResult.


Cheers,
- Ali

Re: what's the point of function template declarations if they can't be defined?

[Jonathan M Davis via Digitalmars-d-learn]

On Thursday, February 08, 2018 20:16:22 Marc via Digitalmars-d-learn wrote:
> What's a di file? (sorry google didn't help with that)

I"m not sure where the documentation for it is, but it's the D equivalent of
a header file. Basically, it's essentially the same as a .d file except that
it's only imported, never compiled. So, it just contains declarations and
stuff that has to be defined in order to be used when importing (e.g.
templates and anything used during CTFE has to be in the .di file). It's
essentially a stripped down version of the .d file.

So, if a library is going to use a .di file, it declares a .d file as per
normal, and that's compiled into the library, but then a .di file is
distributed with the library instead of a .d file, and that's what a program
using the library would import instead of the .d file. The import itself
doesn't change in any way, but the program then only sees what's declared in
the .di version of the module instead of the .d version.

The whole reason that .di files exist is to provide a way for someone to
distribute a library without distributing the full source (which is
something that companies often like to do). It's a pretty restrictive
feature though, since templates still have to be in the .di file, and if
something isn't defined in the .di file instead of just declared, then it
can't be used with CTFE. And with how much templates and CTFE gets used in a
lot of D code, that tends to mean that either you give up on those features,
or you're forced to put a lot of your implementation in the .di file anyway,
making them kind of useless. So, most of use don't go anywhere near .di
files, and personally, I wish that the feature didn't exist, but it's the
kind of thing that some companies insist on.

- Jonathan M Davis

Re: Somewhat OT: defining algebras in D

[Amorphorious via Digitalmars-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.

[Issue 18403] New: Access violation when deprecated feature encountered

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18403

  Issue ID: 18403
   Summary: Access violation when deprecated feature encountered
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: regression
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: nay...@abv.bg

Hello everyone and excuse me for everything wrong with this thread,
I upgraded the dmd from version 2.078.1 to 2.078.2. Everything was working
correctly in 2.078.1, but now my project won't build with 2.078.2, the dmd
compiler exits with this message
E:\bugtest>dub build
Performing "debug" build using C:\D\dmd2\windows\bin\dmd.exe for x86.
bugtest ~master: building configuration "application"...
source\app.d(4,4): Deprecation:
object.Error@(0): Access Violation

0x0065445A
0x006548FE
0x0064DBD3
0x0064DE3F
C:\D\dmd2\windows\bin\dmd.exe failed with exit code 1.

E:\bugtest>

Minimal reproduction example:
void main()
{
ushort i;
i=~i;
}


Yes, i'm using a feature which was deprecated.
Again, excuse me if there is something wrong with this bug report

--

Debugging on Windows

[JN via Digitalmars-d-learn]

Hi,

is there any way to debug binaries on Windows? I'd at least like 
to know which line of code made it crash. If it's D code, I get a 
call trace usually, but if it's a call to a C library, I get a 
crash and that's it. I am using VSCode and I'd prefer to debug in 
it if possible, but using other IDEs is a possibility for me if 
that will help.

Re: A betterC base

[Walter Bright via Digitalmars-d]

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: String to binary conversation

[Marc via Digitalmars-d-learn]

On Monday, 5 February 2018 at 18:40:40 UTC, Steven Schveighoffer 
wrote:

On 2/5/18 1:27 PM, Vino wrote:

Hi All,

Request your help on how to convert a string to binary,eg 
"test" to 01110100 01100101 01110011 01110100.


import std.stdio, std.string;
writefln("%(%b %)", "test".representation);

-Steve


whoa, what isn't built-in in D...

Re: missing HexString documentation

[Walter Bright via Digitalmars-d]

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: what's the point of function template declarations if they can't be defined?

[Adam D. Ruppe via Digitalmars-d-learn]

On Thursday, 8 February 2018 at 20:16:22 UTC, Marc wrote:

What's a di file? (sorry google didn't help with that)


A di file is just a D file that, by convention, only has function 
signatures without bodies.

Re: Debugging bad requests with vibe

[Nicholas Wilson via Digitalmars-d-learn]

On Thursday, 8 February 2018 at 17:09:44 UTC, Nicholas Wilson 
wrote:
I have set up a vibe.d rest interface (on a server) and have a 
client on my machine.


struct Observation
{
string desc;
DateTime time;
}

interface Obsever
{
@property void observe(Observation ra);
}

void main()
{
auto test = Observation("a duck", 
cast(DateTime)Clock.currTime(UTC()));


auto client = new RestInterfaceClient! 
Obsever("http://example.com/observation;);

client. observe = test; // 400
}

I' pretty sure the url is correct because other ones give 404.

Is there a way I can see/log what requests are being made? I 
can change both the client and server.


Never mind, it was because I was accidentally shadowing that path 
with a get on the server.

Re: Vibe.d rest & web service?

[Nicholas Wilson via Digitalmars-d-learn]

On Wednesday, 7 February 2018 at 18:47:05 UTC, Steven 
Schveighoffer wrote:

Yes you can, but it's not pretty.

interface MyInterface
{
   void postGiveMeData(SomeData d);
}

class MyInterfaceImpl : MyInterface
{
   void postGiveMeData(SomeData d) { ... }
   void getPage() { ... }
   void index() { ... }
}

auto myI = new MyInterfaceImpl;
router.registerRestInterface(myI);
router.get("/route/to/getPage", );
router.get("/route/to/index", );

This worked for me, but note that my "non-rest" function was 
static, so I didn't need to worry about instances. I'm not sure 
if the above works exactly right for you.


However, I would recommend actually not doing this for your 
purpose. My case was different -- I still wanted routes that 
were REST routes, but I wanted to control the result streaming 
(the vibe.d return value doesn't work with ranges, so I would 
have had to construct essentially my entire database in an 
array so I could return it).


In your case, I think you are better off using 2 classes, and 
one shared data storage area.


-Steve


Thanks! (Some how I missed your post).

[Issue 18402] New: rdmd: make -f posix.mak -j8 test => core.exception.AssertError@rdmd_test.d(373): Assertion failure

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18402

  Issue ID: 18402
   Summary: rdmd: make -f posix.mak -j8 test =>
core.exception.AssertError@rdmd_test.d(373): Assertion
failure
   Product: D
   Version: D2
  Hardware: x86
OS: Mac OS X
Status: NEW
  Severity: normal
  Priority: P1
 Component: tools
  Assignee: nob...@puremagic.com
  Reporter: timothee.co...@gmail.com

--

Re: A betterC base

[Paulo Pinto via Digitalmars-d]

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: what's the point of function template declarations if they can't be defined?

[Marc via Digitalmars-d-learn]

On Thursday, 8 February 2018 at 07:21:05 UTC, Jonathan M Davis 
wrote:
On Wednesday, February 07, 2018 13:39:55 Timothee Cour via 
Digitalmars-d- learn wrote:

[...]


It's useful with stuff like version(Ddoc).


[...]




What's a di file? (sorry google didn't help with that)
It's been my understanding that it's always been illegal to 
provide a definition for a function that was declared 
previously unless it was declared in a .di file, in which case, 
you're not really both declaring and defining it, but the .d 
file is used when the module is compiled, and the .di file is 
used by other modules which use that module, so the declaration 
and definition are not seen by the same run of the compiler.


- Jonathan M Davis

Re: A betterC base

[Jonathan M Davis via Digitalmars-d]

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

[Issue 18401] New: Auto-generate rdmd man page + HTML documentation

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18401

  Issue ID: 18401
   Summary: Auto-generate rdmd man page + HTML documentation
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: tools
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

These pages have a tendency to get outdated:

https://github.com/dlang/tools/blob/master/man/man1/rdmd.1
https://dlang.org/rdmd.html

We should generate them like we do for dmd.

They are even outdated atm - search for `--shebang` on the man page.

--

[Issue 18400] New: Add an man page for ddemangle

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18400

  Issue ID: 18400
   Summary: Add an man page for ddemangle
   Product: D
   Version: D2
  Hardware: All
OS: Linux
Status: NEW
  Keywords: bootcamp
  Severity: enhancement
  Priority: P1
 Component: tools
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

See also: https://github.com/dlang/dmd/tree/master/docs and
https://github.com/dlang/tools/blob/master/man/man1/rdmd.1

--

Re: A betterC base

[Ola Fosheim Grøstad via Digitalmars-d]

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

[bachmeier via Digitalmars-d]

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: what's the point of function template declarations if they can't be defined?

[Timothee Cour via Digitalmars-d-learn]

makes sense to show these (version X11), but that could be done using
dmd and a special flag instead of having to rely on a new parser
(which would need to be kept updated)



On Thu, Feb 8, 2018 at 6:49 AM, Adam D. Ruppe via Digitalmars-d-learn
 wrote:
> On Thursday, 8 February 2018 at 09:42:08 UTC, Timothee Cour wrote:
>>
>> I guess you mean `version(StdDdoc)` ?
>>
>> On that note, I see things like this, which are not DRY:
>
>
> This is actually one of the reasons why I abandoned dmd for my dpldocs.info
> fork and used an independent parser.
>
> dmd tries to build docs as it builds the program, but these are slightly
> contradictory - when building the program, you need to honor versioned out
> blocks. When building the docs, you just want it documented, not ignored.
> dmd is (rightfully) prioritized toward building actual code, but that leaves
> doc generation a bit second-hand.
>
> To work around dmd's clashing goals, version(StdDdoc) manually makes a
> separate doc branch.
>
> Whereas my doc generator just shows them all, bringing the version into the
> definition.
> http://dpldocs.info/experimental-docs/arsd.simpledisplay.XDisplayConnection.html
>

Re: A betterC base

[H. S. Teoh via Digitalmars-d]

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

[Walter Bright via Digitalmars-d]

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

[Walter Bright via Digitalmars-d]

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: free func "front" is not picked up as a candidate when doing range.front(...)

[Jonathan M Davis via Digitalmars-d-learn]

On Thursday, February 08, 2018 08:18:20 aliak via Digitalmars-d-learn wrote:
> On Thursday, 8 February 2018 at 07:16:43 UTC, Jonathan M Davis
>
> wrote:
> > It would be a disaster if free functions could override member
> > functions. For starters, it would be impossible to call the
> > member function if that were allowed, whereas you can always
> > call a free function by not using UFCS. And in general, it's
> > far more desirable to have member function functions override
> > free functions, because then you can do stuff like have have a
> > range override find if it can provide a more efficient
> > implementation than std.algorithm.find.
>
> That could be fixed with a precedence rule though no? Then member
> find will be preferred over free find. And it won't be impossible
> to call member functions.

That's exactly how it works now. If you call a function as if it were a
member function, and that type has that member function, then it's that
member function that gets called. If that type doesn't have that member
function, then free functions are checked.

> Also, in this case where it's an overload, and not an override,
> it's very clear what should be called isn't it?
>
> In the case of an override I "feel" it may indeed be a disaster,
> but not for the reasons you've stated above though, also not for
> any reasons I can think of :) Hijacking maybe? But then again, if
> I have a free function and then decide to make a member function
> I'm hijacking the free function... hmm.

D has a lot of decisions geared towards avoiding function hijacking, and
when UFCS was added to the language, it was very purposefully decided that
member functions would win over free functions. It is highly unlikely that
that's going to change. Any such change would require a DIP which explained
in detail the pros and cons of the change and why it either wouldn't break
any existing code or why the code breakage would be worth it and how the
transition would work.

- Jonathan M Davis

Re: A betterC base

[Jonathan M Davis via Digitalmars-d]

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

[Ralph Doncaster via Digitalmars-d]

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

[jmh530 via Digitalmars-d]

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

[Steven Schveighoffer via Digitalmars-d]

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

[Steven Schveighoffer via Digitalmars-d]

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

[Ralph Doncaster via Digitalmars-d]

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

[Walter Bright via Digitalmars-d]

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

[Walter Bright via Digitalmars-d]

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

[Walter Bright via Digitalmars-d]

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

[JN via Digitalmars-d]

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

[Walter Bright via Digitalmars-d]

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

[Walter Bright via Digitalmars-d]

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

[Arun Chandrasekaran via Digitalmars-d]

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

[Nicholas Wilson via Digitalmars-d]

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

[ixid via Digitalmars-d]

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

[Ralph Doncaster via Digitalmars-d]

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

[Ralph Doncaster via Digitalmars-d]

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

[H. S. Teoh via Digitalmars-d]

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.

flycheck-dmd-dub v0.12 - Emacs on-the-fly syntax checking for D

[Atila Neves via Digitalmars-d-announce]

https://melpa.org/#/flycheck-dmd-dub

flycheck already works with D, but the problem is setting the 
right compiler flags for your project in order to able to compile 
properly. flycheck-dmd-dub does this automatically for dub 
projects.


This new release fixes bugs and speeds up opening files by using 
`--nodeps --skip-registry=all` if the dependent packages have 
already been downloaded.


Atila

Re: A betterC base

[bachmeier via Digitalmars-d]

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

[bachmeier via Digitalmars-d]

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?

Debugging bad requests with vibe

[Nicholas Wilson via Digitalmars-d-learn]

I have set up a vibe.d rest interface (on a server) and have a 
client on my machine.


struct Observation
{
string desc;
DateTime time;
}

interface Obsever
{
@property void observe(Observation ra);
}

void main()
{
auto test = Observation("a duck", 
cast(DateTime)Clock.currTime(UTC()));


auto client = new RestInterfaceClient! 
Obsever("http://example.com/observation;);

client. observe = test; // 400
}

I' pretty sure the url is correct because other ones give 404.

Is there a way I can see/log what requests are being made? I can 
change both the client and server.

Re: A betterC base

[Dave Jones via Digitalmars-d]

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.

[Issue 18388] std.experimental.logger slow performance

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18388

--- Comment #3 from Arun Chandrasekaran  ---
(In reply to anonymous4 from comment #2)
> AFAIK, default logger implementations are simplistic and are not meant to be
> very fast. Fast logging requires a bit of design and is supposed to be 3rd
> party library, while std.experimental.logger provides a way to integrate it.

Thanks, but that's weird. If that's the case, why would anyone want to use
std.experimental.logger after all? Everyone will default to using their own
logger implementations not derived out of std.experimental.logger, knowing that
it is *slow*. I'm pretty sure that's not the goal of Phobos. May be something
was overlooked in the design or implementation that causes this slowness?

--

Re: A betterC base

[Michael via Digitalmars-d]

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

[John Gabriele via Digitalmars-d]

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

[Nicholas Wilson via Digitalmars-d]

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

[JN via Digitalmars-d]

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++?

[Martin Tschierschke via Digitalmars-d]

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

[Adam D. Ruppe via Digitalmars-d]

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!

[Issue 16685] template instantiation rejected when passing member of enum struct in value parameter

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16685

Nick Treleaven  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||n...@geany.org
 Resolution|--- |FIXED

--

Re: A betterC base

[ixid via Digitalmars-d]

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++?

[Ralph Doncaster via Digitalmars-d]

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

[Simen Kjærås via Digitalmars-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