date:20171227


On 12/27/2017 1:23 PM, Atila Neves wrote:
However, my experience has been that D has fast builds from scratch, but is 
really really slow for incremental builds.
You can do fast incremental builds with D by not putting all the files on the 
command line. Just put one.

Re: D needs to publicize its speed of compilation

2017-12-27 Thread Joakim via Digitalmars-d


On Sunday, 24 December 2017 at 22:55:12 UTC, aberba wrote:

On Friday, 22 December 2017 at 10:06:18 UTC, Joakim wrote:
This one of the main strengths of D, it is what Walter focuses 
on, yet I have seen almost nothing on the D blog talking about 
this.  What brought me to emphasize this today is this recent 
post about how long it takes to compile the mostly-C++ 
Chromium web browser and the reddit discussion about it:


[...]


Memory consumption is a deal breaker.


The dmd frontend prioritized speed over memory, which can cause 
problems with large or CTFE-heavy projects on low-memory systems:


http://www.drdobbs.com/cpp/increasing-compiler-speed-by-over-75/240158941

On Wednesday, 27 December 2017 at 21:23:15 UTC, Atila Neves wrote:

I thought D did market itself that way.


It has historically been a selling point, but perhaps it has been 
taken for granted.  I'm saying it needs a marketing push now.


I just went and checked the front page of the website, and I see 
a new marketing slogan that was added a couple weeks ago, "write 
fast, read fast, and run fast.  Fast code, fast:"


https://github.com/dlang/dlang.org/pull/1965

However, "build fast" is not included in that list.  You could 
argue it's implied by "write fast" or the last "code, fast," but 
it's not mentioned in the list under "write fast" below.  So even 
the front page doesn't highlight build speed, one of the core 
advantages of D.


However, my experience has been that D has fast builds from 
scratch, but is really really slow for incremental builds. 
Here's the thing: personally I don't care about anything except 
incremental builds. It's great that Phobos compiles in seconds 
when I do a git fetch after months. Win! Oh wait, I'm working 
on a bug, changed one character and it still takes the same 
amount of time...


Given that I write D code every day now, this incremental 
compilation situation is driving me nuts, and I'm definitely 
going to do something about it.


It's getting so bad that the day at work I had to write C++ I 
was happy. Because the edit-compile-link-test cycle was 
_faster_. Think about that for a bit - I enjoyed writing C++ 
(!!! either it or Scala are the slowest languages to compile 
ever) because I got faster feedback. Epic fail.


It's also possible I use templates and CTFE more that the 
regular D programmer. But... they're some of the main reasons I 
use D in the first place! I don't want to write Java in D 
syntax.


What do you plan to do about it?

SDL_Quit after GC shutdown?

2017-12-27 Thread Ivan Trombley via Digitalmars-d

I believe that I should call SDL_Quit before my program 
terminates. However, some objects may be holding on to SDL 
resources and freeing these resources (particularly truetype 
resources) causes crashiness if SDL_Quit is called before. Is 
there a way to have SDL_Quit (and TTF_Quit) called after the GC 
has completed shutting down on program exit?


If not then it could make things very complex and messy to keep 
track of these resources.

[Issue 18099] betterC check throw statements error!

2017-12-27 Thread d-bugmail--- via Digitalmars-d-bugs

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #2 from Walter Bright  ---
https://github.com/dlang/dmd/pull/7539

--

[Issue 18115] [REG2.078-b1] case where && is not shortcut anymore in CTFE

2017-12-27 Thread d-bugmail--- via Digitalmars-d-bugs

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #5 from Walter Bright  ---
Rainer, not sure what you're saying. Is it invalid code in the test case, or a
compiler problem?

--

[Issue 18030] Segmentation fault with __traits(getProtection) on template function.

2017-12-27 Thread d-bugmail--- via Digitalmars-d-bugs

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

Walter Bright  changed:

   What|Removed |Added

   Keywords||ice
 CC||bugzi...@digitalmars.com

--- Comment #1 from Walter Bright  ---
https://github.com/dlang/dmd/pull/7537

--

[Issue 18015] [Reg 2.075] link failure unknown [0] section `' in group [.group]

2017-12-27 Thread d-bugmail--- via Digitalmars-d-bugs

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #4 from Walter Bright  ---
The attachment is just:

  module arinas.platform.configuration;

  import vibe.data.json;

  static:

  Json defaultConfig;

The suspected PR:

  https://github.com/dlang/dmd/pull/6564

--

Re: Maybe D is right about GC after all !

On Thursday, 28 December 2017 at 04:49:04 UTC, Walter Bright 
wrote:

On 12/27/2017 8:29 AM, Russel Winder wrote:
This does not support the original claim that the design of D 
by you is
based on psychology. It may be based on your perception of 
other
programmers needs, which is fine per se, but that is not 
psychology-

based design.


All programming language design is based on human factors, i.e. 
psychology. If it was purely computer science based, it would 
be in binary.


01100010 01110101 01110100 0010 01001001 0010 01100011 
0111 01101110 0010 01110011 0111 01100101 0111 
01101011 0010 01100010 01101001 01101110 0111 01110010 
0001 0010 01101010 01110101 01110011 01110100 0010 
01100110 01101001 01101110 01100101 0011

[Issue 17994] [Reg 2.077] Token.isKeyword() segfaults

2017-12-27 Thread d-bugmail--- via Digitalmars-d-bugs

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

Walter Bright  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bugzi...@digitalmars.com
 Resolution|--- |WORKSFORME

--- Comment #2 from Walter Bright  ---
Feel free to reopen if it recurs.

--

Re: Maybe D is right about GC after all !


On 12/27/2017 8:29 AM, Russel Winder wrote:

This does not support the original claim that the design of D by you is
based on psychology. It may be based on your perception of other
programmers needs, which is fine per se, but that is not psychology-
based design.


All programming language design is based on human factors, i.e. psychology. If 
it was purely computer science based, it would be in binary.

Re: D as a betterC a game changer ?

On Wednesday, 27 December 2017 at 13:37:17 UTC, Adam D. Ruppe 
wrote:

On Wednesday, 27 December 2017 at 10:10:03 UTC, Pawn wrote:
It's been expressed that there are now too many codebases such 
that introducing "breaking changes" would upset many people 
and companies. D is a mature language, not a young one.


Just make it opt in at the module level and have the opposite 
attributes added. I suggest:


@strict module foo;


And that little @strict (or whatever name) thing indicates you 
want newer stuff for the entire module.


No breakage, no community split, very little hassle. Javascript 
has had a fair amount of success with opt in stuff like this.


Well, to advance the language, I think we need to start breaking 
some egss, but, we also need a magic wand.


Scott Meyers makes the case well, for C++.

http://scottmeyers.blogspot.com.au/2015/11/breaking-all-eggs-in-c.html

Someone needs to make the case for D too.

Re: Maybe D is right about GC after all !


On 12/27/2017 7:01 PM, rjframe wrote:

The MSVC compiler does buffer security checks, by default, in release
builds[1].


This is simply not checkable memory safety. All it is is setting aside some 
memory locations in strategic places with known values in that memory. If those 
values change, then some code somewhere must have a memory safety bug in it.


It's like picking two triangles and showing Pythagorean's theorem holds for 
them, vs proving Pythagorean's theorem works for all right triangles.

Re: D as a betterC a game changer ?

2017-12-27 Thread ChangLong via Digitalmars-d


On Thursday, 28 December 2017 at 03:31:19 UTC, ChangLong wrote:
On Wednesday, 27 December 2017 at 10:08:37 UTC, Walter Bright 
wrote:

On 12/27/2017 12:59 AM, Dan Partelly wrote:
All could have been prevented by going the C++ route of 0 
cost abstraction,
C++ is not 0 cost abstraction, despite the marketing. It's why 
C++ compilers have switches to disable things like EH and RTTI.


Hi Walter, Can you take a look at this betterC bug:  
https://issues.dlang.org/show_bug.cgi?id=18099


==
struct D()
{
struct V {
~this() {
}
}
auto get() {
V v ;
return v ;
}
}
alias T = D!();

Error: Cannot use throw statements with -betterC
a.d(12): Error: template instance a.D!() error instantiating


It is a block for implement auto RefCount in betterC.  Since 
there is no GC,  auto RefCount is the way to make D work far 
more useable then pure C, and it relay on this bug to be fixed.


With BetterC and Auto RefCount,  Simple template can simulation 
Rust Box, Arc behavior.


I has try made a BetterC lib to work with libuv,  Fiber(implement 
by struct),  Thread local storage(use libuv api with Thread in 
struct). There is noGc and Boxed data auto release by auto 
RefCount.



BetterC made D generate extreme fast and small binary execute 
code.  And the powerful template can easy simulation Rust Box and 
Go Channel.


If I add a D version to made the code at single thread mode,  the 
speed is even more fast since the Channel lock and Tls is removed 
without change code.


With D version Box template,  Boxed struct resource are allocate 
in a pool, and auto release into pool after the refCount to zero. 
 It make the code look like normal D Code without betterC,  and 
get the noGC benefit.


The defect is I can not use Class and Exception, It has be done 
with a custom  object.d.

[Issue 18099] betterC check throw statements error!

2017-12-27 Thread d-bugmail--- via Digitalmars-d-bugs

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

Mike Franklin  changed:

   What|Removed |Added

   Keywords||betterC
 CC||slavo5...@yahoo.com

--

Re: D as a betterC a game changer ?

2017-12-27 Thread ChangLong via Digitalmars-d

On Wednesday, 27 December 2017 at 10:08:37 UTC, Walter Bright 
wrote:

On 12/27/2017 12:59 AM, Dan Partelly wrote:
All could have been prevented by going the C++ route of 0 cost 
abstraction,
C++ is not 0 cost abstraction, despite the marketing. It's why 
C++ compilers have switches to disable things like EH and RTTI.


Hi Walter, Can you take a look at this betterC bug:  
https://issues.dlang.org/show_bug.cgi?id=18099


==
struct D()
{
struct V {
~this() {
}
}
auto get() {
V v ;
return v ;
}
}
alias T = D!();

Error: Cannot use throw statements with -betterC
a.d(12): Error: template instance a.D!() error instantiating


It is a block for implement auto RefCount in betterC.  Since 
there is no GC,  auto RefCount is the way to make D work far more 
useable then pure C, and it relay on this bug to be fixed.

Re: Maybe D is right about GC after all !


On Thursday, 28 December 2017 at 02:53:56 UTC, Dan Partelly wrote:
On Thursday, 28 December 2017 at 02:48:11 UTC, codephantom 
wrote:


https://www.youtube.com/watch?v=vYEKEIpM2zo


Thanks Ill watch it, but when I mentioned worse is better I 
didn't had C++ in mind. I thought at new language who gains 
traction lately but it is clearly inferior to D technically.


It was... Go.


I tried Go. I didn't like it. Syntax changes were not necessary, 
and I got the feeling that the philosophy of Go, is that 
programmers are incompetent and need training wheels. It wasn't 
for me.


I looked at Rust, but never tried it, as I found the syntax to 
pretty awful - and it reminded my too much of C++.


I looked at D, it looked nice. Syntax was familiar, and very C 
like (which is the best kind of syntax IMHO). I decided to try 
it.. and I just found it easy to work with...despite some bugs, 
which you kinda of have to accept for now..but it's getting a lot 
better.


Most importantly for me, is that it works on FreeBSD, otherwise 
I'll lose interest immediately. I still use C though, as C is 
still 'the' primary language on x..BSD, and will remains so for 
the forseeable future.


But gee.. I can do things in D so easily and quickly compare to 
C, and I don't feel like I giving up much for that convenience. 
Compare that to running dotnet ... g...you sit there just 
waiting for the program to load.


So everyone comes to a new language with their own requirements.

Work out what your's are... or just play with it.. and enjoy what 
it has to offer.

Re: TypeInfo_Class.interfaces[n].classinfo has TypeInfo_Class and not TypeInfo_Interface?

2017-12-27 Thread rjframe via Digitalmars-d

On Wed, 27 Dec 2017 23:28:27 +, Tofu Ninja wrote:

> On Sunday, 24 December 2017 at 05:21:44 UTC, Tofu Ninja wrote:
> 
> I guess I will just not get an answer to this, seems like just some
> weirdness of D that will just stick there. The typeinfo system seems
> really half baked and really provides very little in terms of
> usefulness.

What are you trying to do? Will std.traits.InterfacesTuple[1] or 
BaseTypeTuple[2] do what you need?


[1]: https://dlang.org/phobos/std_traits.html#.InterfacesTuple
[2]: https://dlang.org/phobos/std_traits.html#.BaseTypeTuple

Re: Maybe D is right about GC after all !

2017-12-27 Thread rjframe via Digitalmars-d

On Thu, 28 Dec 2017 00:57:41 +0100, Timon Gehr wrote:

> On 27.12.2017 16:37, rjframe wrote:
>> If the programmer opts-in to those checks... it's a +1 for pragmatism
>> but does make marketing the language a bit weird -- one-liners spawn
>> objections to the integrity of the claim (such as a portion of this
>> thread; if there are objections within the community, how much more
>> will we find objections outside it!).
> 
> Frankly, I can see no need to appeal to people who think that having a
> culture where people feel free to question claims they consider dubious
> somehow reflects badly on the community or the language (hint: it's the
> opposite).

I must not have explained my thoughts very well there.

My point is that if people that have already begun using the language 
aren't certain it's being accurately described, we can (should?) expect 
those who haven't chosen to learn the language to think the same. But if 
they think it's being misrepresented, they may just decide not to bother. 
We have to be careful to be accurate, and we unfortunately don't get to 
control the definitions of the words we use.

To say that D should become memory-safe by default (as many do) is to 
claim it is not currently memory-safe by default; so can D be called a 
memory-safe language? E.g., would the claim that "D is memory-safe" be 
commonly-interpreted to mean "D is memory-safe by default"?

The MSVC compiler does buffer security checks, by default, in release 
builds[1]. I believe clang lets you add bounds checks via a compiler flag. 
Do these make C++ a memory-safe language? (answer: definitely not)

I think the dlang.org home page description in the "Run Fast" section is 
perfect, or at least nearly so. But I don't think a simple "D is memory-
safe" is even true.

[1]: https://docs.microsoft.com/en-us/cpp/build/reference/gs-buffer-
security-check

Re: Maybe D is right about GC after all !


On Thursday, 28 December 2017 at 00:36:32 UTC, Dan partelly wrote:
On Wednesday, 27 December 2017 at 22:36:08 UTC, Walter Bright 
wrote:

On 12/27/2017 8:57 AM, Laeeth Isharc wrote:
It's much better to have a monopoly of some niche or set of 
niches and to use energy from success to expand out from 
there, than to have a small market share of an enormous 
market.


Back in the 80's, Zortech made a killing because we had the 
only C++ compiler that would generate 16 bit Windows code.


I found this out by asking the sales guys what feature of 
ZTC++ was closing the deal - X, Y, Z, all the features I held 
dear. They'd say nope. Customers wanted to use C++ for Win16, 
ZTC++ supported that, sold!


I learned a lot from that.


That a product which fulfils a need in a total void sells? No 
disrespect, but aint it a bit tautological ? Can you find a 
similar void today which is to be filled by D ? Better yet can 
you create one ?


Read Peter Thiel's Zero To One, and maybe Walter's point will 
become clear.  If you don't want to read it, that's fine too, but 
it's hard to have a discussion if someone isn't familiar with the 
background of how challengers very often tend to succeed and 
isn't interested to learn about it.


Yes, evidently enough  people using D believe it fills a need.  
See list of companies using D.  Most of them have better things 
to do than post in the forum however.


From my point of view, D already has a monopoly, as I don't see 
an alternative that's in the same league for what I want to do. 
I'm not going to spell out all the reasons here.


By far the best thing if you want to form an assessment of the 
language for your own needs is to watch a bunch of dconf videos, 
read the bits of Phobos that appeal to you, read lots of other D 
code and start trying to solve your own problems.


I don't think it's a language suitable for everyone, but I do 
think most people for whom it's suitable today will quickly get 
why if they take some of those steps I suggested...

Re: Maybe D is right about GC after all !


On Thursday, 28 December 2017 at 02:48:11 UTC, codephantom wrote:


https://www.youtube.com/watch?v=vYEKEIpM2zo


Thanks Ill watch it, but when I mentioned worse is better I 
didn't had C++ in mind. I thought at new language who gains 
traction lately but it is clearly inferior to D technically.


It was... Go.

Re: Maybe D is right about GC after all !


On Thursday, 28 December 2017 at 02:39:58 UTC, Dan Partelly wrote:


Id wish things would be so simple. Unfortunately, no, there is 
no void to be filled by a monopoly here.   It's a place full of 
competition, and to gain a spot (not bene, a spot, the monopoly 
doesnt exist) you have to demonstrate that you are a compelling 
enough improvement.


https://www.youtube.com/watch?v=vYEKEIpM2zo

Re: D as a betterC a game changer ?


On Thursday, 28 December 2017 at 02:21:09 UTC, Dan Partelly wrote:
On Thursday, 28 December 2017 at 01:09:34 UTC, codephantom 
wrote:


But honestly, the best way to learn about a programming 
language, is to start using it.


Sure ,  **if** you decide it worth to be learned. And honestly, 
almost everybody knows that to get better at a task you must 
perform the task itself.




So I ask you...what have you written in D lately?



My problem currently is that I have no freaking idea what niche 
D serves, since as I said I perceive multiple personalities in 
it. I like a lot in the language, but I do not like that I 
perceive it as a indecisive language.


This is one of the reasons I asked Walter in this thread what 
is the future of the language ?

Where does it to go ? No clear answer yet.


It's a practical language for getting stuff done in a way thats 
plastic, efficient, powerful.


So I think the ecological niche is restricted mostly by 
capabilities of the people using it (it wasn't designed as golang 
was as a restricted and simple language for people who have 
limited experience, though I personally found it easy enough to 
learn), by the tolerance people have for discomfort upfront, by 
the ability to pay upfront costs in wrapping any necessary 
libraries, by the ability to pick your own tools rather than 
needing to persuade others first.  It's not as polished as more 
mature languages. It has fewer targets, so for example it doesn't 
yet have a production ready ARM 64 or web assembly target, and if 
you run it on Alpine Linux, FreeBSD or SmartOS it will probably 
work but you might have some work to do yourself. Embedded 
targets will need you to do work. If it's super important not to 
use the GC probably you will have some work to do.  If you work 
with younger people who expect Python style docs and an abundance 
of Stack Overflow answers you may have some work to do there.


Beyond that, it's pretty good for many things,from scripting to 
applications to numerical code, to systems programming.  That's 
really the point.


It's also especially good as glue because of ctfe and compile 
time reflection.  Pegged and other parser generators mean that 
it's a pretty nice language for writing DSLs in.

Re: D as a betterC a game changer ?


On Thursday, 28 December 2017 at 02:28:20 UTC, Dan Partelly wrote:


This is marketing. Many times in marketing questions are used 
to try to pass a certain perspective as a fact to the target 
population. You guys here are all pretty smart, so prolly you 
all seen it ;-)


Yeah, true.. but Walter likes a debate too ;-)

So I agree, it was part marketing... but it was more .. what do 
you all think?

Re: Maybe D is right about GC after all !


On Thursday, 28 December 2017 at 02:16:03 UTC, codephantom wrote:



No need to create one. It already exists.

The need for highly flexible, portable, powerful, fast, 
compiled language, that is easy to understand and pleasant to 
work with.


Id wish things would be so simple. Unfortunately, no, there is no 
void to be filled by a monopoly here.   It's a place full of 
competition, and to gain a spot (not bene, a spot, the monopoly 
doesnt exist) you have to demonstrate that you are a compelling 
enough improvement.

And this is battle you can't won on technical grounds alone.

 Recall the need for an OS which is consistent, elegant , better 
than Unix ? And recall how the Plan 9 masterpiece failed in 
trying to fill that space ?


https://en.wikipedia.org/wiki/Worse_is_better [1]

Re: D as a betterC a game changer ?


On Thursday, 28 December 2017 at 02:21:09 UTC, Dan Partelly wrote:


Small snippets. I believe is the best way to start with a new 
language. Then you decide if you like it, and if it serves any 
purpose for you. Adopting a new language for anything serious 
is a big commitment.


This is what I do to. Only discovered D a few months ago..have 
300+ snippets and growing... It's the best way to learn about 
various features ...



My problem currently is that I have no freaking idea what niche 
D serves, since as I said I perceive multiple personalities in 
it. I like a lot in the language, but I do not like that I 
perceive it as a indecisive language.


I see it as an alternative to C++ - i.e a powerful and flexible 
compiled language that I can actually understand, and enjoy using.


This is one of the reasons I asked Walter in this thread what 
is the future of the language ?

Where does it to go ? No clear answer yet.


That really depends on what people (not just Walter) do with it, 
and want to do with it. This varies alot, and will continue to 
vary alot, as we don't all think the same way, or want to solve 
the same problems.


Clearly though, D is targetted as a better C, an increasingly 
better C++, as well as better general use, multiparadigm, 
powerful, flexible, fast, compiled langauge..that is 
understandable and pleasant to work with.


It that's not enough to get people interested in it, then what is?

Re: D as a betterC a game changer ?


On Thursday, 28 December 2017 at 01:21:42 UTC, codephantom wrote:



I am pretty sure Walter put a question mark after the wording, 
which makes it a question, not a statement ;-)





This is marketing. Many times in marketing questions are used to 
try to pass a certain perspective as a fact to the target 
population. You guys here are all pretty smart, so prolly you all 
seen it ;-)

Re: D as a betterC a game changer ?


On Thursday, 28 December 2017 at 01:09:34 UTC, codephantom wrote:


But honestly, the best way to learn about a programming 
language, is to start using it.


Sure ,  **if** you decide it worth to be learned. And honestly, 
almost everybody knows that to get better at a task you must 
perform the task itself.




So I ask you...what have you written in D lately?


Small snippets. I believe is the best way to start with a new 
language. Then you decide if you like it, and if it serves any 
purpose for you. Adopting a new language for anything serious is 
a big commitment.


My problem currently is that I have no freaking idea what niche D 
serves, since as I said I perceive multiple personalities in it. 
I like a lot in the language, but I do not like that I perceive 
it as a indecisive language.


This is one of the reasons I asked Walter in this thread what is 
the future of the language ?

Where does it to go ? No clear answer yet.

Re: Maybe D is right about GC after all !


On Thursday, 28 December 2017 at 00:36:32 UTC, Dan partelly wrote:

Can you find a similar void today which is to be filled by D ?
Better yet can you create one ?


No need to create one. It already exists.

The need for highly flexible, portable, powerful, fast, compiled 
language, that is easy to understand and pleasant to work with.

Re: Maybe D is right about GC after all !

On Wednesday, 27 December 2017 at 20:24:04 UTC, Walter Bright 
wrote:


This illustrates my point if it was unclear:

C++:
int foo(int* p) { return p[1]; }
int bar(int i) { return foo(); }

clang++ -c test.cpp -Wall


D:
@safe:
int foo(int* p) { return p[1]; }
int bar(int i) {return foo(); }

dmd -c test.d
test.d(3): Error: safe function 'test.foo' cannot index 
pointer 'p'
test.d(4): Error: cannot take address of parameter i in 
@safe function bar


Well,I can press the accelerator on my car to the floor, and 
crash the car.


But is that a problem with the car, or the way I used it 
(referring to the C++ portion of your example)? Would be better, 
and fairer, to write that portion in modern C++, and then make 
the comparison with D.


And sure, we can (and do) make cars that modify the acceleraton 
potential, but then you can't do burnouts ;-(


So safety certainly does have real value..but it always wants to 
take something away. (and unfortunately, we're becoming a very 
risk averse society, with more and more freedoms being taken away 
in the name of 'safety' - but I divert..)


Of course, the nice thing about D, is that we can (for the most 
part) switch it from one to the other...so I like that a lot.


But when I really want to put the pedal to the metal, I still 
look to C.


(although, one day the government will try to make C illegal too 
I guess).

Re: Maybe D is right about GC after all !

On Thursday, 28 December 2017 at 00:16:39 UTC, Walter Bright 
wrote:


Phobos has undergone several waves of grand renaming. At some 
point this has to stop and we need stability.


There is nothing better for a progamming language than stability.

There is nothing worse for a progamming language than stability.

DLang Tour : Functions as arguments

2017-12-27 Thread Tony via Digitalmars-d-learn


On this page:
https://tour.dlang.org/tour/en/basics/delegates

there is:

void doSomething(int function(int, int) doer) {
// call passed function
doer(5,5);
}

doSomething(add); // use global function `add` here
  // add must have 2 int parameters



I can't get it to compile unless it is:

doSomething();

Is this an okay representation of a dynamically sized Matrix, to be used for HMM matrices m = (A,B)

2017-12-27 Thread Enjoys Math via Digitalmars-d-learn




Code:

module matrix;

import std.array;


struct Matrix(E)
{
private:
   E[][];

   this() {
   }

   void deleteRow(int i)
   {
  E = E[0..i] ~ E[i..$];
   }

   void deleteColumn(int j)
   {
  for (int i=0; i < E.length; i++)
  {
 E[i] = E[i][0..j] ~ E[i][j..$];
  }
   }

   void insertRow(int i, E[] row)
   {
  if (E.length != 0)
 assert(E[0].length == row.length);
  E.insertInPlace(i, row);
   }

   void insertColumn(int j, E[] col)
   {
  for (int i=0; i < E.length; i++)
  {
 E[i].insertInPlace(j, col[i]);
  }
   }

   int numRows() { return E.length; }

   int numColumns() {
  if (E.length == 0)
 return 0;
  return E[0].length;
   }

}


Is there a more efficient way of doing this, knowing that I'll be 
inserting columns / rows every time we need to create a new 
hidden state so this matrix will be huge, for a good model.  By 
huge we'll probably use the full capacity of a long[] in D.  I've 
already tried doing this in MQL5 and we exceeded easily the max 
array capacity.

Re: D as a betterC a game changer ?

On Wednesday, 27 December 2017 at 18:32:43 UTC, Dan Partelly 
wrote:
On Wednesday, 27 December 2017 at 16:46:18 UTC, Russel Winder 
wrote:




(*) "Better C" is a specialist use case for Walter and the D 
backend.


Also, if betterC is a specialist use case for Walter only, why 
does Walter call it "a game changer for D" ?


I am pretty sure Walter put a question mark after the wording, 
which makes it a question, not a statement ;-)


-betterC (or as I prefer to call it, -slimD, since I also use C, 
which is the better C) is needed in D, because otherwise it would 
exclude a whole class of programmers, and problems that could not 
be solved. Its' not being forced on anyone. It's there to use if 
is suits your needs, or peaks your interest.


Is it a game changer? That remains an open question. But D 
certainly needs it, for those that want/need to use it (which is 
not just Walter).


But if you want to write 'System D', aka Dos (D operating 
system), then you will certainly need -slimD (aka -betterC) .. 
with all its enhancements to come.

Re: D as a betterC a game changer ?

On Wednesday, 27 December 2017 at 19:42:50 UTC, Dan Partelly 
wrote:
Im not here to save the world , the baby seals , or D (if it 
needs saving), or whatever other crusade. Im here because Im 
curious about D, curious enough to want to know future 
direction and what the bright people around here think on it. I 
ask nobody yet to implement anything, neither do I try to shift 
its development in any way. I gather cursory information and 
for the rest ... I simply don't care.. yet.


That is all. Dont try to see more.


Well, you're doing what most people do, when they hear about a 
new programming language - i.e. start comparing it to others 
there is a psychological basis for that phenomena - it's human.


But honestly, the best way to learn about a programming language, 
is to start using it.


So I ask you...what have you written in D lately?

Re: Maybe D is right about GC after all !

2017-12-27 Thread Timon Gehr via Digitalmars-d


On 28.12.2017 01:16, Walter Bright wrote:

On 12/27/2017 3:33 PM, Timon Gehr wrote:

_Phobos_ does not take this point into account though.

I.e., this seems like an excellent time to bring this up again:
https://issues.dlang.org/show_bug.cgi?id=4535



Phobos has undergone several waves of grand renaming. At some point this 
has to stop and we need stability.


This is both true and unrelated.

[Issue 18136] New: ICE in dmd/statement.d(426)

2017-12-27 Thread d-bugmail--- via Digitalmars-d-bugs

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

  Issue ID: 18136
   Summary: ICE in dmd/statement.d(426)
   Product: D
   Version: D2
  Hardware: x86_64
OS: All
Status: NEW
  Keywords: ice
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

```
void main()
{
import std.regex;
import std.algorithm : joiner, map;
string[] messages;

auto matchToRefs(M)(M m)
{
return m.captures[0].splitter(regex(`foo`));
}

auto issueRE = regex("foo");
messages.map!(
m => m.matchAll(issueRE)
  .map!matchToRefs
).joiner;
}
```

Stacktrace:


```
core.exception.AssertError@dmd/statement.d(426): Assertion failure

??:? _d_assert [0xce1a2ef0]
??:? void dmd.statement.__assert(int) [0xce09fba2]
??:? dmd.statement.ErrorStatement dmd.statement.ErrorStatement.__ctor()
[0xce09b4a7]
??:? _ZN16Semantic3Visitor5visitEP15FuncDeclaration [0xcdfd15c0]
??:? _ZN16ParseTimeVisitorI10ASTCodegenE5visitEP22FuncLiteralDeclaration
[0xce0a9459]
??:? _ZN22FuncLiteralDeclaration6acceptEP7Visitor [0xce02c568]
??:? _Z9semantic3P7DsymbolP5Scope [0xce09a2e0]
??:? _ZN25ExpressionSemanticVisitor5visitEP7FuncExp [0xce00f3ae]
??:? _ZN7FuncExp6acceptEP7Visitor [0xce001c20]
??:? _Z18expressionSemanticP10ExpressionP5Scope [0xce023716]
??:? _ZN10TypeTypeof7resolveE3LocP5ScopePP10ExpressionPP4TypePP7Dsymbolb
[0xce072c7e]
??:? _ZN19TypeSemanticVisitor5visitEP10TypeTypeof [0xce0a3e20]
??:? _ZN10TypeTypeof6acceptEP7Visitor [0xce072fb0]
??:? _Z12typeSemanticP4Type3LocP5Scope [0xce0a0c22]
??:? _ZN4Type11trySemanticE3LocP5Scope [0xce06795b]
??:? _ZN25ExpressionSemanticVisitor5visitEP5IsExp [0xce0139f7]
??:? _ZN5IsExp6acceptEP7Visitor [0xce002118]
??:? _Z18expressionSemanticP10ExpressionP5Scope [0xce023716]
??:? _ZN25ExpressionSemanticVisitor5visitEP10LogicalExp [0xce021647]
??:? _ZN10LogicalExp6acceptEP7Visitor [0xce006500]
??:? _Z18expressionSemanticP10ExpressionP5Scope [0xce023716]
??:? _ZN25ExpressionSemanticVisitor5visitEP10LogicalExp [0xce021535]
??:? _ZN10LogicalExp6acceptEP7Visitor [0xce006500]
??:? _Z18expressionSemanticP10ExpressionP5Scope [0xce023716]
??:? _ZN25ExpressionSemanticVisitor5visitEP10LogicalExp [0xce021535]
??:? _ZN10LogicalExp6acceptEP7Visitor [0xce006500]
??:? _Z18expressionSemanticP10ExpressionP5Scope [0xce023716]
??:? _ZN22DsymbolSemanticVisitor5visitEP14VarDeclaration [0xcdfd6a35]
??:? _ZN14VarDeclaration6acceptEP7Visitor [0xcdfa3998]
??:? _Z15dsymbolSemanticP7DsymbolP5Scope [0xcdfcee08]
??:? _ZN16TemplateInstance13expandMembersEP5Scope [0xcdff36eb]
??:? _ZN16TemplateInstance16tryExpandMembersEP5Scope [0xcdff3762]
??:? void
dmd.dsymbolsem.templateInstanceSemantic(dmd.dtemplate.TemplateInstance,
dmd.dscope.Scope*, dmd.root.array.Array!(dmd.expression.Expression).Array*)
[0xcdfe256b]
```

--

Re: Maybe D is right about GC after all !

2017-12-27 Thread Dan partelly via Digitalmars-d

On Wednesday, 27 December 2017 at 22:36:08 UTC, Walter Bright 
wrote:

On 12/27/2017 8:57 AM, Laeeth Isharc wrote:
It's much better to have a monopoly of some niche or set of 
niches and to use energy from success to expand out from 
there, than to have a small market share of an enormous market.


Back in the 80's, Zortech made a killing because we had the 
only C++ compiler that would generate 16 bit Windows code.


I found this out by asking the sales guys what feature of ZTC++ 
was closing the deal - X, Y, Z, all the features I held dear. 
They'd say nope. Customers wanted to use C++ for Win16, ZTC++ 
supported that, sold!


I learned a lot from that.


That a product which fulfils a need in a total void sells? No 
disrespect, but aint it a bit tautological ? Can you find a 
similar void today which is to be filled by D ? Better yet can 
you create one ?

[Issue 18135] [REG2.078] can't join RegexMatch anymore

2017-12-27 Thread d-bugmail--- via Digitalmars-d-bugs

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

--- Comment #2 from Seb  ---
See also: https://issues.dlang.org/show_bug.cgi?id=17066

--

[Issue 18135] [REG2.078] can't join RegexMatch anymore

2017-12-27 Thread d-bugmail--- via Digitalmars-d-bugs

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

--- Comment #1 from Seb  ---
This was introduced by https://github.com/dlang/phobos/pull/4286

--

Re: Maybe D is right about GC after all !


On 12/27/2017 3:33 PM, Timon Gehr wrote:

_Phobos_ does not take this point into account though.

I.e., this seems like an excellent time to bring this up again:
https://issues.dlang.org/show_bug.cgi?id=4535



Phobos has undergone several waves of grand renaming. At some point this has to 
stop and we need stability.

[Issue 18135] New: [REG2.078] can't join RegexMatch anymore

2017-12-27 Thread d-bugmail--- via Digitalmars-d-bugs

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

  Issue ID: 18135
   Summary: [REG2.078] can't join RegexMatch anymore
   Product: D
   Version: D2
  Hardware: x86_64
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

This used to compile, it doesn't anymore with 2.078.0:

```
import std.algorithm : joiner, map;

auto matchIssueRefs(string message)
{
import std.regex;

static auto matchToRefs(M)(M m)
{
enum splitRE = regex(`foo`);
return m.captures[0].splitter(splitRE);
}

enum issueRE = ctRegex!`foo`;
return message.matchAll(issueRE).map!matchToRefs;
}

auto getIssueRefs(string[] commits)
{
return commits
.map!matchIssueRefs
.joiner;
}
```

with:

```
/home/seb/dlang/phobos/std/algorithm/iteration.d(2504): Error: cannot modify
struct this._current MapResult!(matchToRefs, RegexMatch!string) with immutable
members
test.d(21): Error: template instance
std.algorithm.iteration.joiner!(MapResult!(matchIssueRefs, string[])) error
instantiating
```

--

Re: Maybe D is right about GC after all !

2017-12-27 Thread Amorphorious via Digitalmars-d


On Tuesday, 19 December 2017 at 09:54:05 UTC, Walter Bright wrote:

"C, Python, Go, and the Generalized Greenspun Law"

http://esr.ibiblio.org/?p=7804


"Maybe D is right about GC after all"

or maybe not...

Re: Maybe D is right about GC after all !

2017-12-27 Thread Timon Gehr via Digitalmars-d


On 27.12.2017 16:37, rjframe wrote:

If the programmer opts-in to those checks... it's a +1 for pragmatism but
does make marketing the language a bit weird -- one-liners spawn
objections to the integrity of the claim (such as a portion of this
thread; if there are objections within the community, how much more will
we find objections outside it!).


Frankly, I can see no need to appeal to people who think that having a 
culture where people feel free to question claims they consider dubious 
somehow reflects badly on the community or the language (hint: it's the 
opposite).

Re: How do I set a class member value by its name in a string?

2017-12-27 Thread Biotronic via Digitalmars-d-learn


On Wednesday, 27 December 2017 at 21:42:53 UTC, Mengu wrote:

On Wednesday, 27 December 2017 at 21:39:49 UTC, Mengu wrote:

On Wednesday, 27 December 2017 at 20:54:17 UTC, bitwise wrote:

[...]


there's also a simple workaround for fields with the same 
type: https://run.dlang.io/is/dsFajq


import std.stdio;

struct S {
  int x;
  int y;
}

auto setValue(ref S s, string field, int value) {
  foreach (fieldName; __traits(allMembers, S)) {
if (fieldName == field) {
  __traits(getMember, s, fieldName) = value;
  break;
}
  }
}

void main() {
  S s;
  s.setValue("x", 5);
  s.setValue("y", 25);
  writeln(s);
}


you can play with it to make it more generic. you can also 
create a mixin template that would generate setters for each 
field you would need a setter for and then in the run time 
you'd just be able to call them.


return type should just be void. that's just my muscle memory. 
:-D


More generic, for more better:

void setValue(T, V)(auto ref T aggregate, string field, V value)
{
import std.traits : FieldNameTuple;
import std.meta : Alias;
switch (field)
{
foreach (fieldName; FieldNameTuple!T)
{
case fieldName:
static if (is(typeof(__traits(getMember, 
aggregate, fieldName) = value)))

{
__traits(getMember, aggregate, fieldName) = 
value;

return;
}
else assert(false, T.stringof ~ "."~field~" 
cannot be assigned from a "~V.stringof~".");

}
default:
assert(false, T.stringof ~ " has no field named 
"~field~".");

}
}

unittest {
import std.exception : assertThrown;
import core.exception : AssertError;

static struct S {
int x;
string s;
}

S s;
s.setValue("x", 14);
assert(s.x == 14);
assertThrown!AssertError(s.setValue("q", 14));
assertThrown!AssertError(s.setValue("s", 14));
s.setValue("s", "abc123");
assert(s.s == "abc123");
}

unittest {
import std.exception : assertThrown;
import core.exception : AssertError;

static class C {
int x;
string s;
}

C c = new C;
c.setValue("x", 14);
assert(c.x == 14);
assertThrown!AssertError(c.setValue("q", 14));
assertThrown!AssertError(c.setValue("s", 14));
c.setValue("s", "abc123");
assert(c.s == "abc123");

(new C).setValue("x", 143);
}

--
  Biotronic

Re: Maybe D is right about GC after all !

2017-12-27 Thread Timon Gehr via Digitalmars-d


On 27.12.2017 21:48, Walter Bright wrote:


Another is it is known that people have cognitive problems with 
negation. It often just does not register in the mind.


_Phobos_ does not take this point into account though.

I.e., this seems like an excellent time to bring this up again:
https://issues.dlang.org/show_bug.cgi?id=4535

(The action starts at Comment 7.)

Re: TypeInfo_Class.interfaces[n].classinfo has TypeInfo_Class and not TypeInfo_Interface?

2017-12-27 Thread Tofu Ninja via Digitalmars-d


On Sunday, 24 December 2017 at 05:21:44 UTC, Tofu Ninja wrote:
I didn't get any response in learn for this so I will ask it 
here.


TypeInfo_Class.interfaces[n].classinfo has TypeInfo_Class and 
not TypeInfo_Interface?


Is this correct? Or is it a bug?
Doesn't make much sense to me.

Also the following code prints false so there are some 
consequences to this.

# # 
import std.stdio;
void main(string[] args) {
	writeln(typeid(c).interfaces[0].classinfo == typeid(i)); // 
false

}
interface i {}
class c : i {}

What is the proper way to handle this mismatch?
Is this mismatch intended or just some implementation detail?
Peoples thoughts on this?


I guess I will just not get an answer to this, seems like just 
some weirdness of D that will just stick there. The typeinfo 
system seems really half baked and really provides very little in 
terms of usefulness.

Re: Please do not use 'auto' return types without thoroughly describing the interface

2017-12-27 Thread H. S. Teoh via Digitalmars-d

On Tue, Dec 26, 2017 at 01:50:06AM +, Neia Neutuladh via Digitalmars-d 
wrote:
> On Monday, 25 December 2017 at 22:48:39 UTC, H. S. Teoh wrote:
> > The exact type does not and should not need to be known by user
> > code.
> 
> It's a public type reported by some of the documentation but not other
> parts. Its capabilities are given vaguely in the docs for the
> functions that return it.
> 
> This is a documentation problem, but concrete return types will put a
> hard limit on how bad the documentation situation can be.

Then the documentation needs to be fixed.  Resorting to concrete return
types seems to me to be a pessimistic approach, when we should rather be
improving the code / docs.

> > It's an implementation detail.
> 
> The fact that there is a named type involved is not shocking. If there
> is not a named type, we can use something like:
> 
>   public alias Regex(Char) = typeof(regex([Char.init]));
> 
> I can add it in my own code too. Pretty much no chance of breakage.
> 
> The fact that two functions return values of the same type is perhaps
> an implementation detail, but there's no way to ensure you don't break
> user code that way besides using a unique type for each (hello,
> std.typecons.Typedef).

If more than one function is returning the same type, then that's
reasonable grounds to ask for a named return type.

OTOH, there's the case where the API may reasonably return distinct
types, but just so happens that the present implementation reuses the
same type, in which case user code should not rely on the return types
being compatible with each other.  Your example below of matchFirst vs.
matchAll could, arguably, be an example of this category, since
conceivably, matchFirst could return a type that encapsulates a single
match, whereas matchAll could return a range of such matches.  Then
potentially a future version of the library could use different return
types, even if the current implementation does reuse the same type.
Assuming that the return types are compatible is an iffy proposition at
best.

Keeping the return types opaque helps to discourage this sort of
misplaced assumption in user code.

> Like I might read the docs and, quite reasonably, write:
> 
>   auto capture = needFirst ? matchFirst(str, regex) : matchAll(str,
> regex).skip(3).front;
>   auto process = asShell ? spawnShell("echo hi") :
> spawnProcess(["/bin/echo", "hi"]);

I think you're missing some context there, I'm not sure what the second
line of code has to do with `capture` in the first line. Care to
clarify?

> And that's suddenly going to stop compiling some day. Maybe. Except
> that would be bonkers because nobody's going to write two different
> `Captures` structs to be used in nearly identical circumstances. It
> would be pointless work to have two different types with the same
> interface for processes.

Not necessarily, if matchFirst returns a single Match type, say, and
matchAll returns a range of Match elements. Then you could very well
have different, incompatible return types here.

> The fact that it's somehow absolutely essential to maintain this
> option in all current cases, but not so essential as to motivate
> anyone to deprecate public types for anything or use Typedef
> everywhere, is kind of worrying.

I wouldn't say it's *absolutely essential*, just that imposing the least
amount of constraints on the code (including possible future changes) is
a desirable thing to have.

T

-- 
If you're not part of the solution, you're part of the precipitate.

[Issue 15391] Problems loading libcurl.so and running datetime unittest on NixOS package build

2017-12-27 Thread d-bugmail--- via Digitalmars-d-bugs

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

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

https://github.com/dlang/phobos/commit/735b360c4215720adf3b64b76c274ce1094538f9
Fix Issue 15391 - Add possibility to specify custom path to TZDatabaseDir

--

[Issue 15391] Problems loading libcurl.so and running datetime unittest on NixOS package build

2017-12-27 Thread d-bugmail--- via Digitalmars-d-bugs

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

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

Re: Maybe D is right about GC after all !


On 12/27/2017 8:57 AM, Laeeth Isharc wrote:
It's much better to have a monopoly of some niche or set of niches and to use 
energy from success to expand out from there, than to have a small market share 
of an enormous market.


Back in the 80's, Zortech made a killing because we had the only C++ compiler 
that would generate 16 bit Windows code.


I found this out by asking the sales guys what feature of ZTC++ was closing the 
deal - X, Y, Z, all the features I held dear. They'd say nope. Customers wanted 
to use C++ for Win16, ZTC++ supported that, sold!


I learned a lot from that.

Re: Maybe D is right about GC after all !


On 12/27/2017 1:00 PM, Atila Neves wrote:
I nearly always reorganise my code so that my `if` statements are positive 
precisely because of this. The only times I don't is when the negative branch is 
a lot shorter, so I "get it out of the way" sooner. Even then I try to rename 
the boolean value to not require negation.


I had a hard time convincing my colleagues at my previous job that this was an 
issue. Then again I had a hard time convincing them unit tests were a good idea, 
so there's that.


I once talked to a real estate agent who told me his proxy for a well-built 
house was whether the screw slots on the electrical outlets lined up or not.

Re: How do I set a class member value by its name in a string?

2017-12-27 Thread Mengu via Digitalmars-d-learn


On Wednesday, 27 December 2017 at 21:39:49 UTC, Mengu wrote:

On Wednesday, 27 December 2017 at 20:54:17 UTC, bitwise wrote:

[...]


there's also a simple workaround for fields with the same type: 
https://run.dlang.io/is/dsFajq


import std.stdio;

struct S {
  int x;
  int y;
}

auto setValue(ref S s, string field, int value) {
  foreach (fieldName; __traits(allMembers, S)) {
if (fieldName == field) {
  __traits(getMember, s, fieldName) = value;
  break;
}
  }
}

void main() {
  S s;
  s.setValue("x", 5);
  s.setValue("y", 25);
  writeln(s);
}


you can play with it to make it more generic. you can also 
create a mixin template that would generate setters for each 
field you would need a setter for and then in the run time 
you'd just be able to call them.


return type should just be void. that's just my muscle memory. :-D

Re: How do I set a class member value by its name in a string?

2017-12-27 Thread Mengu via Digitalmars-d-learn


On Wednesday, 27 December 2017 at 20:54:17 UTC, bitwise wrote:

On Wednesday, 27 December 2017 at 20:04:29 UTC, Marc wrote:
I'd like to set the members of a class by its name at runtime, 
I would do something like this:



__traits(getMember, myClass, name) = value;


but since name is only know at runtime, I can't use 
__traits(). What's a workaround for this?


I think you could write something using a combination of these 
two things:


https://dlang.org/phobos/std_traits.html#FieldNameTuple
https://dlang.org/phobos/std_traits.html#Fields

or maybe '.tupleof':

https://dlang.org/spec/struct.html#struct_properties


there's also a simple workaround for fields with the same type: 
https://run.dlang.io/is/dsFajq


import std.stdio;

struct S {
  int x;
  int y;
}

auto setValue(ref S s, string field, int value) {
  foreach (fieldName; __traits(allMembers, S)) {
if (fieldName == field) {
  __traits(getMember, s, fieldName) = value;
  break;
}
  }
}

void main() {
  S s;
  s.setValue("x", 5);
  s.setValue("y", 25);
  writeln(s);
}


you can play with it to make it more generic. you can also create 
a mixin template that would generate setters for each field you 
would need a setter for and then in the run time you'd just be 
able to call them.

[Issue 18134] New: BitArray <<= broken when length % 32 = 0

2017-12-27 Thread d-bugmail--- via Digitalmars-d-bugs

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

  Issue ID: 18134
   Summary: BitArray <<= broken when length % 32 = 0
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: simen.kja...@gmail.com

unittest
{
import std.bitmanip : BitArray;
import std.range : repeat;
import std.array : array;
BitArray ba = true.repeat(64).array;
ba >>= 1;
assert((cast(uint[])ba)[$-1] == 0x7FFF_);
}

When a BitArray covers exactly 32, 64, 96 and so on number of bits, the bit
shifting operation fills the last word with zeroes. The test above should pass,
but doesn't.

--

Re: D needs to publicize its speed of compilation

2017-12-27 Thread Atila Neves via Digitalmars-d

On Friday, 22 December 2017 at 10:06:18 UTC, Joakim wrote:
This one of the main strengths of D, it is what Walter focuses
on, yet I have seen almost nothing on the D blog talking about
this. What brought me to emphasize this today is this recent
post about how long it takes to compile the mostly-C++ Chromium
web browser and the reddit discussion about it:

https://lobste.rs/s/iri1te/chromium_has_compilation_time_problem
https://www.reddit.com/r/programming/comments/7ktzog/chromium_has_a_compilation_time_problem/

I'm tempted to call BS on that 6-7 hour build time, as I used
to contribute to the Chromium project, and I think it used to
take me 20 minutes for a release build in a FreeBSD jail on a
fairly weak, 2008-vintage mini-desktop, a dual-core Celeron
with 2 GBs of RAM (don't hold me to that build time, just a
vague recollection, but probably in the ballpark). Of course,
the last time I built Chromium was more than 5 years ago, and a
lot has likely changed since then, such as now using LTO to
speed up the browser apparently, and maybe the
cross-compilation toolchain for ARM is slower, though others
note similar times for native x64 compilation also.

That still implies a slowdown of 2-3 orders of magnitude over
the last 5 years, given the much more powerful hardware he's
using, which is nuts.

D really needs the community to write blog posts talking about
how fast it is, publicizing that there is an alternative to
these glacial build times: who wants to do this? It doesn't
need to be on the D blog, could just be on your personal blog,
but it is a message that really needs to be spread.

I thought D did market itself that way.

However, my experience has been that D has fast builds from
scratch, but is really really slow for incremental builds. Here's
the thing: personally I don't care about anything except
incremental builds. It's great that Phobos compiles in seconds
when I do a git fetch after months. Win! Oh wait, I'm working on
a bug, changed one character and it still takes the same amount
of time...

Given that I write D code every day now, this incremental
compilation situation is driving me nuts, and I'm definitely
going to do something about it.

It's getting so bad that the day at work I had to write C++ I was
happy. Because the edit-compile-link-test cycle was _faster_.
Think about that for a bit - I enjoyed writing C++ (!!! either it
or Scala are the slowest languages to compile ever) because I got
faster feedback. Epic fail.

It's also possible I use templates and CTFE more that the regular
D programmer. But... they're some of the main reasons I use D in
the first place! I don't want to write Java in D syntax.

Atila

[Issue 18133] New: BitArray prints bits in wrong order

2017-12-27 Thread d-bugmail--- via Digitalmars-d-bugs

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

  Issue ID: 18133
   Summary: BitArray prints bits in wrong order
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: simen.kja...@gmail.com

unittest
{
import std.bitmanip : BitArray;
import std.format : format;
enum input = "0b1100_11010010";
auto ba = BitArray([mixin(input)], 16);
assert(format("0b%b", ba) == input);
}

Since D has binary literals, it's non-intuitive and thus bug-prone that the
output of BitArray.toString prints the bits in the opposite order that's used
in said literals.

--

Re: D as a betterC a game changer ?

2017-12-27 Thread John Gabriele via Digitalmars-d

On Wednesday, 27 December 2017 at 20:53:46 UTC, Dan Partelly 
wrote:
On Wednesday, 27 December 2017 at 19:13:15 UTC, John Gabriele 
wrote:


Although I don't know D very well yet, it sounds like Russel 
hits the nail precisely on the head here. FWICT, folks have 
lately used scripting languages (ex. Python, Perl, Ruby) for 
larger and larger programs (and even JS+Node for local apps),


Resulting in terrible software. Take text editors written in 
JS+Electron. Slow bloated crap. {snip}


Maybe I wasn't being very clear there. Also, my unedited comment 
on that was:


Although I don't know D very well yet, it sounds like Russel 
hits the nail precisely on the head here. FWICT, folks have 
lately used scripting languages (ex. Python, Perl, Ruby) for 
larger and larger programs (and even JS+Node for local apps), 
but it seems to me like the pendulum is swinging back the other 
way as everyone wants optional types and also JIT 
implementations like [PyPy](http://pypy.org/).


with my point being that I think we're seeing many scripting 
language users now wanting the features that D already has 
(types, type inference, high performance and less resource usage 
(natively compiled)). I think it's a good time for D to attract 
those users.

Re: Maybe D is right about GC after all !

2017-12-27 Thread Atila Neves via Digitalmars-d

On Wednesday, 27 December 2017 at 20:48:12 UTC, Walter Bright 
wrote:

On 12/27/2017 8:38 AM, Laeeth Isharc wrote:
On Wednesday, 27 December 2017 at 07:44:30 UTC, Walter Bright 
wrote:


The psychological cognitive issues around negation are known, 
but I rarely see deliberate efforts by programmers to deal with 
that issue. D kinda forces it, and I get resistance to it, but 
it is worthwhile to push it because the results are worth it.


I nearly always reorganise my code so that my `if` statements are 
positive precisely because of this. The only times I don't is 
when the negative branch is a lot shorter, so I "get it out of 
the way" sooner. Even then I try to rename the boolean value to 
not require negation.


I had a hard time convincing my colleagues at my previous job 
that this was an issue. Then again I had a hard time convincing 
them unit tests were a good idea, so there's that.


Atila

Re: D as a betterC a game changer ?

On Wednesday, 27 December 2017 at 19:13:15 UTC, John Gabriele 
wrote:


Although I don't know D very well yet, it sounds like Russel 
hits the nail precisely on the head here. FWICT, folks have 
lately used scripting languages (ex. Python, Perl, Ruby) for 
larger and larger programs (and even JS+Node for local apps),


Resulting in terrible software. Take text editors written in 
JS+Electron. Slow bloated crap.Noticeable slow on a 2 core i5 
MacBook Pro with 8Gb RAM. Press key , notice delay, see char on 
sceen. Really  I mean, REALLY ?  I had a 8086 which could 
edit text with no issue. Had a C64 with 64kb or RAM too which was 
up to the task of editing text.  Look at how slow Visual Studio 
became in time as more and more of it was written in managed 
languages and non-native code.  Android is pitifully slow , and 
not because of Linux.


Democratization of programming through JS/ PhP / Perl and other 
scripts was great for society because it empowered a lot of 
humans. But also created means to write bloated, inefficient, 
terribly slow software.  Nuclear weapons used where a surgeon's 
tool is mandated.

Re: How do I set a class member value by its name in a string?

2017-12-27 Thread bitwise via Digitalmars-d-learn


On Wednesday, 27 December 2017 at 20:04:29 UTC, Marc wrote:
I'd like to set the members of a class by its name at runtime, 
I would do something like this:



__traits(getMember, myClass, name) = value;


but since name is only know at runtime, I can't use __traits(). 
What's a workaround for this?


I think you could write something using a combination of these 
two things:


https://dlang.org/phobos/std_traits.html#FieldNameTuple
https://dlang.org/phobos/std_traits.html#Fields

or maybe '.tupleof':

https://dlang.org/spec/struct.html#struct_properties

Re: BitArray shift left/right confusion.

2017-12-27 Thread Biotronic via Digitalmars-d-learn

On Wednesday, 27 December 2017 at 18:08:19 UTC, Bastiaan Veelo 
wrote:

I suppose the following is not a bug, but confusing it is:

```
void main()
{
import std.stdio;
import std.bitmanip;
BitArray ba = [1, 1, 1, 1, 1, 1, 1, 1];
writeln(ba);// [1, 1, 1, 1, 1, 1, 1, 1]
ba >>= 4; // right shift
writeln(ba);// [1, 1, 1, 1, 0, 0, 0, 0] bits shifted left
}```

I suppose this is because the array is printed left-to-right, 
whereas the bits in a byte are typically ordered right-to-left. 
I suppose I should interpret the bits in the array to increase 
in significance with increasing index (little endian) and that 
right-shift means a shift towards less significance (which is 
to the right in big endian).


The documentation of <<= and >>= [1] however just talks about 
left and right, without defining left and right or clarifying 
that the directions are reversed from how the array is printed.


Is there something I have missed?

[1] 
https://dlang.org/phobos/std_bitmanip.html#.BitArray.opOpAssign.2


BitArray is apparently a mess. As you've pointed out it prints 
the bits in the wrong order. I won't mince words here, since D 
has binary literals on the form 0b1000. Put that in a 
BitArray and print it with the format string "0b%b", and you'll 
get 0b0001. While it may have been intentional, it's bug 
prone and confusing, and so definitely a bug.


It also fucks up royally when it has an exact multiple of 32 bits 
in its buffer, overwriting the last word with 0s when you try and 
shift it in any way.


It also doesn't remove set bits outside of its covered area when 
cast to size_t[]. That is, if I do 
cast(size_t[])(BitArray([1,1,1,1,1,1,1,1]) << 4), the result will 
be something like [4080], which corresponds to 
[0b___].


Lastly (and this is pointed out explicitly in the documentation, 
but still smells if you ask me), it will overwrite bits in the 
words it covers, even if it does not cover those exact bits.


The first two are definitely bugs. The last two are results of 
the intended use case for BitArray, I believe. The documentation 
doesn't explicitly point this out, but it seems BitArray is 
intended to give a bit-by-bit view of an area of memory that is 
actually some other type. Something like this:


struct S {
   int n;
   float f;
}

void foo(ref S s) {
import std.bitmanip;
auto a = BitArray(()[0..1], S.sizeof);
a[7] = true; // Actually sets the corresponding bit in s.
}

--
  Biotronic

tooling/help for rewriting C projects with betterC

2017-12-27 Thread yawniek via Digitalmars-d

is there any tooling or tutorials on how one would approach a 
(partial) rewrite for bigger C projects that use e.g. cmake ?


is there a way parts of it could be automated (if so which parts) 
?


this might help D a lot if people that want to learn/rewrite a 
library would get support and appropriate tooling.
also best practices and help on how C patterns can be transformed 
to (safe!) d code.

Re: Maybe D is right about GC after all !

2017-12-27 Thread Benjamin Thaut via Digitalmars-d-learn


On 12/27/2017 8:38 AM, Laeeth Isharc wrote:

On Wednesday, 27 December 2017 at 07:44:30 UTC, Walter Bright wrote:

On 12/26/2017 4:18 AM, Russel Winder wrote:

All of which brings us full circle: when it comes to programming
languages and software development, it is all about advocacy,
prejudice, and belief, there is very, very little science happening –
and most of the science that is happening is in the psychology of
programming, about which most developers of programming languages know
nothing.


If you're hinting that I know nothing about the topic, you're mistaken :-)

A fair amount of D's design is based on psychology.


I'd love to hear more about this sometime.


One fun example is our quest to find the right keyword for read only data. A 
long list of words were examined, like readonly, invariant, etc. Some had 
various baggage connotations, some weren't clear what they meant.


We found ourselves constantly saying things like: "readonly means immutable", 
"invariant means immutable", etc. Finally we got hit with a clue-by-four - 
everyone understood what "immutable" meant, so why not just use "immutable"?


Pure psychology, and nothing to do with computer science.

---

Another is it is known that people have cognitive problems with negation. It 
often just does not register in the mind. This is why version statements in D do 
not have negation. It more or less forces one to think of using positive version 
identifiers:


version (hasFeature) { ... }

as opposed to:

version (!hasFeature) { ... }

or even worse (yes I've seen it):

version (!doesNotHaveFeature) { ... } // :-(

In order to do negation, one must resort to:

version (hasFeature) { } else { ... }

Having converted a lot of C code to D and dealing with things like:

#if !__OSX__
   ... call X ...

having to redesign the case to use positive features:

version (hasX)
   ... call X ...

makes the code a lot more readable. It's worth it.

The psychological cognitive issues around negation are known, but I rarely see 
deliberate efforts by programmers to deal with that issue. D kinda forces it, 
and I get resistance to it, but it is worthwhile to push it because the results 
are worth it.

[Issue 17994] [Reg 2.077] Token.isKeyword() segfaults

2017-12-27 Thread d-bugmail--- via Digitalmars-d-bugs

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

Rainer Schuetze  changed:

   What|Removed |Added

 CC||r.sagita...@gmx.de

--- Comment #1 from Rainer Schuetze  ---
Nightlies are back up and working, at least since 2.077.1 Can this be closed?

--

Re: How do I set a class member value by its name in a string?


On Wednesday, 27 December 2017 at 20:04:29 UTC, Marc wrote:
I'd like to set the members of a class by its name at runtime, 
I would do something like this:



__traits(getMember, myClass, name) = value;


but since name is only know at runtime, I can't use __traits(). 
What's a workaround for this?


You will have to use a combination of compile time and runtime 
methologies.


Essentially what you want is this:

void setMemberValue(string name, int value)
{
  switch(name)
  {
case "member1":
  member1 = value;
  break;
case "member2":
  member2 = value;
  break:
...
  }
}

As you don't want to write this for all members by hand you 
should write a function which generates the source code for this 
switch using static foreach and __traits(allMembers) and then 
mixin the generated string into the setMemberValue method. If 
your members can have different types you will also need runtime 
type that can hold multiple types. For simplicity I just used 
"int" in the above example. You could use "std.variant" for this.

[Issue 18097] [REG2.077] Unittest function is undefined identifier

2017-12-27 Thread d-bugmail--- via Digitalmars-d-bugs

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

--- Comment #2 from Atila Neves  ---
I have a potential fix but am waiting on another PR of mine since there will be
merge conflicts.

--

Re: Maybe D is right about GC after all !


On 12/27/2017 8:34 AM, Russel Winder wrote:

On Tue, 2017-12-26 at 14:54 -0800, Walter Bright via Digitalmars-d
wrote:

That's right. C++ is based on faith in the programmer using best
practices. D is
not based on faith, it can be automatically checked.


"Can be" is not the same as "is". Perhaps all D compilers should
enforce the "can be" as "is", with options to switch it off if need be?


This illustrates my point if it was unclear:

C++:
int foo(int* p) { return p[1]; }
int bar(int i) { return foo(); }

clang++ -c test.cpp -Wall


D:
@safe:
int foo(int* p) { return p[1]; }
int bar(int i) {return foo(); }

dmd -c test.d
test.d(3): Error: safe function 'test.foo' cannot index pointer 'p'
test.d(4): Error: cannot take address of parameter i in @safe function bar

How do I set a class member value by its name in a string?

2017-12-27 Thread Marc via Digitalmars-d-learn

I'd like to set the members of a class by its name at runtime, I 
would do something like this:



__traits(getMember, myClass, name) = value;


but since name is only know at runtime, I can't use __traits(). 
What's a workaround for this?

[Issue 18115] [REG2.078-b1] case where && is not shortcut anymore in CTFE

2017-12-27 Thread d-bugmail--- via Digitalmars-d-bugs

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

--- Comment #4 from Rainer Schuetze  ---
if you change the test to

int test()
{
if (test.stringof.length < 7)
return 0;
return test.stringof[$-7..$] == "1234567";
}

enum a = test();


it fails for older versions, too. That's caused by the semantic analysis
already trying to optimize expressions. I guess it must not do this in case of
errors but defer it to the runtime error.

--

[Issue 18115] [REG2.078-b1] case where && is not shortcut anymore in CTFE

2017-12-27 Thread d-bugmail--- via Digitalmars-d-bugs

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

Rainer Schuetze  changed:

   What|Removed |Added

 CC||r.sagita...@gmx.de

--- Comment #3 from Rainer Schuetze  ---
The reduced test case fails for older versions, too, but that's because you are
substracting 7 there instead of 6.

--

Re: D as a betterC a game changer ?

On Wednesday, 27 December 2017 at 19:11:14 UTC, Laeeth Isharc 
wrote:
'Competition is for losers', according to Peter Thiel.  It's 
completely the wrong mindset >to succeed in a free society.  
What you're supposed to do is create a monopoly that you >earn 
and keep earning every day.  Economic quasi-rent, or pure profit,


I dont really know who Peter Thiel guys is but economic 
quasi-rent assumes that you already have something of value, 
which feels a real void. For example Gabe Newell and his Steam 
store.  In each one of us there is lazy rentier, it is only 
natural to cash in without doing any real effort(altough today;s 
rentiers are not like the nobles of the past, they do work 12h / 
day , but yeah .. ). But this destroys innovation, and in the 
long run is of little value to society since it doesn't produce 
more advances.


D shouldn't compete against anything any more than it has tried 
to compete in the past.  >The way to success is to listen to 
people who like what you are doing anyway and would >like you to 
develop along


D doesnt exist in a void where it can form a natural 
monopoly.Also, in this world things do not sell themselves, no 
matter how good they are. Try what you suggest, no marketing, 
just excellent decisions and D will kill itself.



On Wednesday, 27 December 2017 at 19:11:14 UTC, Laeeth Isharc 
wrote:


It's open source!  It doesn't work like that.

If you want people to work on something, write a proof of 
concept and talk about it.  T..  do the work in a community 
of highly intelligent, spirited, and independent-minded people?


Don't put the carriage before the horses. I understand enthusiasm 
but this is too much. You
cannot in good faith ask anyone which is interested in your cause 
to contribute his time in development or organize fund raising. 
Im not here to save the world , the baby seals , or D (if it 
needs saving), or whatever other crusade. Im here because Im 
curious about D, curious enough to want to know future direction 
and what the bright people around here think on it. I ask nobody 
yet to implement anything, neither do I try to shift its 
development in any way. I gather cursory information and for the 
rest ... I simply don't care.. yet.


That is all. Dont try to see more.

Re: D as a betterC a game changer ?

2017-12-27 Thread Neia Neutuladh via Digitalmars-d-announce

On Wednesday, 27 December 2017 at 18:23:37 UTC, Dan Partelly 
wrote:
On Wednesday, 27 December 2017 at 16:46:18 UTC, Russel Winder 
wrote:


It is all about differentiation. Forget competing against C, 
C++, and

Rust. D is the   C++ inspired language with GC that isn't Go.


So what I hear is: if D wants a future embrace one personality 
only. Given current state of affairs, it should compete against 
the like of Java, C# and Eiffel. Embrace GC and forget anything 
like better C and competing against zero cost abstraction 
languages. For this to happen D must focus all its energy on 
implementation of a second to none GC.


This of course , has both sense and sensibility, but given that 
D has been unable to commit to one personality in it's 
life-spawn, how likely is to happen ?


Walter, what says you ? Where do you actually want to go with D 
? What you and D foundation wants, not Russel or I or whatever 
else ?


'Competition is for losers', according to Peter Thiel.  It's 
completely the wrong mindset to succeed in a free society.  What 
you're supposed to do is create a monopoly that you earn and keep 
earning every day.  Economic quasi-rent, or pure profit, is the 
reward for noticing ways to better organise resources to serve 
customers needs in a way that others have overlooked.  (See the 
work of Israel Kirzner and Schumpeter).


D shouldn't compete against anything any more than it has tried 
to compete in the past.  The way to success is to listen to 
people who like what you are doing anyway and would like you to 
develop along the path of development that already exists and 
maybe are willing to encourage that in some way.  [Of course 
stealing useful ideas that fit what you are doing is always good, 
patent and IP law permitting].


If you do that, it becomes a ridiculous question to ask 'how are 
you differentiated from other languages; what is your edge?' 
because it's obvious to anyone with eyes and the willingness to 
study a bit what that is.


In my view, this is also good career advice I have taken myself 
and that I have found personally to be profitable, as well as the 
right way for a language to develop.


And it's what Walter has done anyway based on his long experience 
in flourishing as a one-man band in a market where Microsoft - 
with its very large resources - was then the dominant player.


People also continue to think and write as if the D Foundation 
has this inexhaustible fund of resources (pecuniary and people) 
that it can command to work on whatever Andrei and Walter think 
best.


It's open source!  It doesn't work like that.

If you want people to work on something, write a proof of concept 
and talk about it.  Talking to the aether about what people ought 
to be doing will be less effective than finding one guy who 
agrees with you and working on the project together.  And if not 
working on it yourself, then organising a fund and making an 
initial contribution towards a prize for someone who will.


And if one isn't willing either to work on something oneself, or 
to contribute financially towards its development, just how 
likely is it you will persuade somebody else to do the work in a 
community of highly intelligent, spirited, and independent-minded 
people?

Re: D as a betterC a game changer ?

2017-12-27 Thread John Gabriele via Digitalmars-d

On Wednesday, 27 December 2017 at 16:46:18 UTC, Russel Winder 
wrote:
On Wed, 2017-12-27 at 08:59 +, Dan Partelly via 
Digitalmars-d wrote:



[…]
I could not agree more with this. It is unfortunate D has 
dependencies on a garbage collector in language proper and in 
std.


Given the current situation, D's best route to traction is to 
embrace GC and ignore all complaints other than "give us a 
better GC". (*)


It is all about differentiation. Forget competing against C, 
C++, and

Rust. D is the   C++ inspired language with GC that isn't Go.


[…]


(*) "Better C" is a specialist use case for Walter and the D 
backend.


Although I don't know D very well yet, it sounds like Russel hits 
the nail precisely on the head here. FWICT, folks have lately 
used scripting languages (ex. Python, Perl, Ruby) for larger and 
larger programs (and even JS+Node for local apps), but it seems 
to me like the pendulum is swinging back the other way as 
everyone wants optional types and also JIT implementations like 
[PyPy](http://pypy.org/).


I think the D wiki would benefit from an article on how D 
competes-with/differs-from Go.


Also, as a related aside, another language that D competes with 
is Vala. Now that D is part of GCC, I wonder if D could replace 
Vala.

Re: Blog post: using dynamic libraries in dub


On Monday, 25 December 2017 at 08:57:09 UTC, Jacob Carlborg wrote:
If I knew exactly what would need to be done I would most 
likely have done it already :). Perhaps Martin that implemented 
the support on Linux or David that, I think, implemented it for 
LDC on macOS would be better suited for such a bugzilla issue.


If you know that it doesn't work, please file an issue; a bug 
that just says "this doesn't work" is more valuable than its 
absence.


If you have a test case, that is valuable; "what would need to be 
done" is to make the test case work.


If you know that it works with LDC, that is also valuable; "what 
would need to be done" is to port over LDC's fixes.


I haven't used a Mac since 2012 (an experience that I am anxious 
to avoid repeating), so I don't even know whether TLS works with 
dynamic libraries on OSX. I can't test fixes. All I could do is 
report that there's a rumor.

[Issue 11714] Improve error message for wrongly initialized thread-local class instances

2017-12-27 Thread d-bugmail--- via Digitalmars-d-bugs

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

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

https://github.com/dlang/dmd/commit/eef26d042b3692af21e3692c257ceeb69d177ffc
Fix Issue 11714 - Improve error message for wrongly initialized thread-local
class and pointer to struct instances

https://github.com/dlang/dmd/commit/8f679b5ac6033088e03026481f4d544083943e35
Merge pull request #7508 from ibuclaw/issue11714

Fix Issue 11714 - Improve error message for wrongly initialized thread-local
class and pointer to struct instances
merged-on-behalf-of: Sebastian Wilzbach 

--

[Issue 11714] Improve error message for wrongly initialized thread-local class instances

2017-12-27 Thread d-bugmail--- via Digitalmars-d-bugs

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

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--

Re: Maybe D is right about GC after all !


On Sunday, 24 December 2017 at 21:27:12 UTC, Russel Winder wrote:
On Sun, 2017-12-24 at 16:58 +, Laeeth Isharc via 
Digitalmars-d wrote:
Programming languages are tools for solving problems, and 
people face different problems and they also have different 
capabilities and tastes, which means even for people facing 
identical problems, the right tool for the job may not be the 
same because they aren't identical as groups and as 
individuals.


Thinking of a programming language as a domain specific 
language for solving problems in a domain helps with this. 
Along with can a language enable creation of a DSL for solving 
my problems. Creating functions is creating a DSL in any 
language.


That's an extremely odd way to conceive of D, IMO, like 
conceiving of a banana as being like an apple, only it tastes 
like a banana and has a different shape.


If a general purpose programming language is to be conceived of 
as a domain specific language, what's the difference between a 
true domain specific language and a regular programming language?


That's really the whole point about D.  It's an era where people 
start out assuming that using the right tool for the job means 
that one tool can't do two different kinds of job well.  But, as 
Walter has said elsewhere I think, in some cases that's because 
the tools people are used to using are limited, whereas in fact 
there's no need for that - just use one tool that's good at both. 
 It's going to be a struggle to recognise such a tool if you 
start with the presumption it cannot exist.  And talking about 
languages as identical with DSLs only encourages this 
misconception, I think.



How does prestige develop?  From tangible consequences 
produced by able and virtuous people acting together to create 
something. There's a long lead time on that one, but it's not 
something that can be rushed.


And sales and marketing. Arguably C was the last language that 
got traction based solely on technical benefit and tribalism. 
All other languages with traction since have had serious 
marketing behind them.


I don't think I suggested that tribalism in the everyday sense of 
the word is favourable to the adoption of a language.  But that 
aside, C is quite a big example, and I don't see that it has no 
relevance to the present, even though conditions are of course 
different.  Was Python adopted because of a big marketing budget? 
 If so, I didn't know that - who paid for it?  How about R?


I think you also need to consider consequences of beliefs if you 
are wrong and the choices available in circumstances (unless you 
can figure out how to create new choices).  You write as if 
adoption is flatlining.  It isn't - it's growing at a healthy 
pace, as best I can see.  Human perception doesn't deal very well 
with compound growth.  It's disappointing for a long time, and 
all of a sudden it's surprising.


It's by far best at this point to get across successful stories 
about the adoption of D to people who are already receptive to 
them because they have some problems that D might help with than 
to try to get people to listen to you who have no interest in 
listening.  Persuasion works when people are ready to move 
towards you.  You can't compel that.

Re: Please do not use 'auto' return types without thoroughly describing the interface

2017-12-27 Thread Neia Neutuladh via Digitalmars-d


On Wednesday, 27 December 2017 at 16:36:59 UTC, H. S. Teoh wrote:
The best we can do currently, which unfortunately won't show up 
in the docs, is to use a static assert to force compilation 
failure when the return type doesn't match expectations, e.g.:

[...]

static assert(isInputRange!Result);


I'm more concerned about types that are specific to a purpose 
with an interface that is not standard and widely used across a 
lot of D code. Which is why I'm talking about std.regex.Captures 
and not std.algorithm.iteration.MapResult: MapResult is just a 
range implementation, and ranges are a core concept in D today.


And this is about documentation, so a static assert inside the 
implementation doesn't really help.

Re: D as a betterC a game changer ?

On Wednesday, 27 December 2017 at 16:46:18 UTC, Russel Winder 
wrote:




(*) "Better C" is a specialist use case for Walter and the D 
backend.


Also, if betterC is a specialist use case for Walter only, why 
does Walter call it "a game changer for D" ?

Re: D as a betterC a game changer ?

On Wednesday, 27 December 2017 at 16:46:18 UTC, Russel Winder 
wrote:


It is all about differentiation. Forget competing against C, 
C++, and

Rust. D is the   C++ inspired language with GC that isn't Go.


So what I hear is: if D wants a future embrace one personality 
only. Given current state of affairs, it should compete against 
the like of Java, C# and Eiffel. Embrace GC and forget anything 
like better C and competing against zero cost abstraction 
languages. For this to happen D must focus all its energy on 
implementation of a second to none GC.


This of course , has both sense and sensibility, but given that D 
has been unable to commit to one personality in it's life-spawn, 
how likely is to happen ?


Walter, what says you ? Where do you actually want to go with D ? 
What you and D foundation wants, not Russel or I or whatever else 
?

Re: D as a betterC a game changer ?

2017-12-27 Thread Paolo Invernizzi via Digitalmars-d

On Wednesday, 27 December 2017 at 18:01:46 UTC, Russel Winder 
wrote:
On Wed, 2017-12-27 at 16:50 +, Paolo Invernizzi via 
Digitalmars-d wrote:

[…]

That's another things I really don't understand...


The community know of C, obviously. They know of C++ and have 
consciously ignored it. They know of Rust and have embraced it. 
They have never heard of D.


I still think that's just a matter of doing well the homework.

If you are searching for alternatives to C, D is not so hidden, 
if alone I alone managed to find it, long ago...


/**
 * KickStart provides logic to upgrade\start\watchdog a target 
process.

 *
 * Author: Paolo Invernizzi
 * Date: Jun 26, 2006
 *
 * License: All rights are reserved. Reproduction or transmission 
in whole or
 * in part, in any form or by any means, electronic, mechanical 
or otherwise, is
 * prohibited without prior written permission of the copyright 
owner.

 *
 */
module kickstart.kickstart;

Re: Maybe D is right about GC after all !

2017-12-27 Thread Bastiaan Veelo via Digitalmars-d-learn

On Wed, 2017-12-27 at 16:57 +, Laeeth Isharc via Digitalmars-d
wrote:
> 
[…]
> It's much better to have a monopoly of some niche or set of 
> niches and to use energy from success to expand out from there, 
> than to have a small market share of an enormous market.  And 
> niche in this case is not something simple - it's people who have 
> a certain set of kinds of problems and certain capabilities and 
> who have the ability to make decisions on merits for them rather 
> than primarily social factors.

Witness that it is likely that Kotlin will take over from Java as the
primary language of Android application development.

In the end this is that the programming language offers something very
significant to allow a change in the extant market leader.

> See Peter Thiel's Zero to One for another expression of the same 
> point.
> 
>  From a strategic perspective, it's by far better for the 
> challenger not to be taken seriously for the longest possible 
> time until the moment is ripe, if it's possible to achieve that.

But the challenger must offer something that the extant market leader
does not that the majority of the people in the game value. Without an
obvious an unassailable value there will be no change in market leader.

> It takes a long time for a programming language to be adopted.  
> And the more ambitious the language, perhaps the longer it takes 
> to mature and the longer it will be for it to achieve wide 
> adoption.  D is a pretty ambitious language!

Experimentally it takes 10 years for a language to achieve status these
days. Exceptions prove the rule!

The challenger has to offer something that the community value. Rust
offers memory safety over C. D offers "better C++". This is the wrong
message to achieve traction. D must offer something that C++ does not
offer.

> I can appreciate that if one's business involves teaching people 
> a language then this is frustrating.  But I'd suggest taking a 
> step back and looking at things from the point of view of the 
> language itself, which is an organic creature not wholly under 
> the control of its creators.  (See node.js).

But as of 2017-03-30 I have no hidden agenda, i.e. I retired. :-) This
mjeans I am just doing what I want, which currently is organising ACCU
conference, organising DevoxxUK conferences and programming DVB-T and
DAB clients. D has failed to get traction at ACCU, has no chance at all
at DevoxxUK, and has lost to Rust in DVB-T and DAB applications.

-- 
Russel.
==
Dr Russel Winder  t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

signature.asc
Description: This is a digitally signed message part

BitArray shift left/right confusion.


I suppose the following is not a bug, but confusing it is:

```
void main()
{
import std.stdio;
import std.bitmanip;
BitArray ba = [1, 1, 1, 1, 1, 1, 1, 1];
writeln(ba);// [1, 1, 1, 1, 1, 1, 1, 1]
ba >>= 4; // right shift
writeln(ba);// [1, 1, 1, 1, 0, 0, 0, 0] bits shifted left
}```

I suppose this is because the array is printed left-to-right, 
whereas the bits in a byte are typically ordered right-to-left. I 
suppose I should interpret the bits in the array to increase in 
significance with increasing index (little endian) and that 
right-shift means a shift towards less significance (which is to 
the right in big endian).


The documentation of <<= and >>= [1] however just talks about 
left and right, without defining left and right or clarifying 
that the directions are reversed from how the array is printed.


Is there something I have missed?

[1] 
https://dlang.org/phobos/std_bitmanip.html#.BitArray.opOpAssign.2

Re: D as a betterC a game changer ?

On Wed, 2017-12-27 at 16:50 +, Paolo Invernizzi via Digitalmars-d
wrote:
> […]
> 
> That's another things I really don't understand...

The community know of C, obviously. They know of C++ and have
consciously ignored it. They know of Rust and have embraced it. They
have never heard of D.

-- 
Russel.
==
Dr Russel Winder  t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

signature.asc
Description: This is a digitally signed message part

Re: D as a betterC a game changer ?

On Wed, 2017-12-27 at 17:46 +, 12345swordy via Digitalmars-d wrote:
> 
[…]
> Competing in terms of what exactly?

Having enough people who give a  that the programming language is
not simply a side show of history.
 
-- 
Russel.
==
Dr Russel Winder  t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk


signature.asc
Description: This is a digitally signed message part

Re: D as a betterC a game changer ?

2017-12-27 Thread 12345swordy via Digitalmars-d

On Wednesday, 27 December 2017 at 16:46:18 UTC, Russel Winder 
wrote:


Given the current situation, D's best route to traction is to 
embrace GC and ignore all complaints other than "give us a 
better GC". (*)


I disagree strongly with this. Otherwise D won't have @nogc 
attributes, and functions like emplace for instance. GC is best 
to view as useful tool in certain situations that require it 
while other situations require manual memory management.


There no reason why D can't have the best of both worlds.

It is all about differentiation. Forget competing against C, 
C++, and

Rust. D is the   C++ inspired language with GC that isn't Go.



Competing in terms of what exactly?

Re: Maybe D is right about GC after all !

On Wednesday, 27 December 2017 at 16:53:16 UTC, Dan Partelly
wrote:
On Wednesday, 27 December 2017 at 16:38:35 UTC, Laeeth Isharc
wrote:

A fair amount of D's design is based on psychology.

I'd love to hear more about this sometime.

I never thought of this in the context of programming
languages, but behavior is strongly modulated genetically,
epi-genetically, and ***environmentally** (this includes the
social component).

Japanese cars were dismissed and laughed at for the longest time.
When the price of energy went bananas in the 1970s US auto
makers were not laughing any more. (And strategically it would
have been terrible for the Japanese if US manufacturers had taken
them seriously earlier).

So big relative price shocks have something to do with adoption.

https://www.quora.com/Python-programming-language-1/Why-is-Python-so-popular-despite-being-so-slow/answer/Laeeth-Isharc

https://queue.acm.org/detail.cfm?id=2874238

"For the entire careers of most practicing computer scientists, a
fundamental observation has consistently held true: CPUs are
significantly more performant and more expensive than I/O
devices. The fact that CPUs can process data at extremely high
rates, while simultaneously servicing multiple I/O devices, has
had a sweeping impact on the design of both hardware and software
for systems of all sizes, for pretty much as long as we've been
building them.

***This assumption, however, is in the process of being
completely invalidated.***

Re: Maybe D is right about GC after all !


On Sunday, 24 December 2017 at 20:58:51 UTC, Russel Winder wrote:
On Sun, 2017-12-24 at 17:13 +, Laeeth Isharc via 
Digitalmars-d wrote:

[…]

New things grow at the fringes.  See the work of Clayton 
Christensen and his book the Innovator's Dilemma.  A head-on 
assault is ill-advised.  People looking for salvation are 
easier to talk to than those who don't see anything wrong with 
what they're doing currently.


Not my experience in the JVM-related community, and to an 
extent the Python community, at least in the UK. Head on 
collisions create debate, and get you remembered. The debate 
generally leads to change, even if not the change initially 
envisaged. At least the status quo gets perturbed.


Just dealing with the fringes and solving their problems rarely 
get serious traction. cf. Golo, Gosu, Fantom, Crystal, Pony, 
all of which solve definite problems but none of which have any 
serious traction to move programming on.


It's much better to have a monopoly of some niche or set of 
niches and to use energy from success to expand out from there, 
than to have a small market share of an enormous market.  And 
niche in this case is not something simple - it's people who have 
a certain set of kinds of problems and certain capabilities and 
who have the ability to make decisions on merits for them rather 
than primarily social factors.


See Peter Thiel's Zero to One for another expression of the same 
point.


From a strategic perspective, it's by far better for the 
challenger not to be taken seriously for the longest possible 
time until the moment is ripe, if it's possible to achieve that.


It takes a long time for a programming language to be adopted.  
And the more ambitious the language, perhaps the longer it takes 
to mature and the longer it will be for it to achieve wide 
adoption.  D is a pretty ambitious language!


I can appreciate that if one's business involves teaching people 
a language then this is frustrating.  But I'd suggest taking a 
step back and looking at things from the point of view of the 
language itself, which is an organic creature not wholly under 
the control of its creators.  (See node.js).

Re: Maybe D is right about GC after all !

On Wednesday, 27 December 2017 at 16:38:35 UTC, Laeeth Isharc 
wrote:



A fair amount of D's design is based on psychology.


I'd love to hear more about this sometime.


I never thought of this in the context of programming languages, 
but behavior is strongly modulated genetically, epi-genetically, 
and environmentally (this includes the social component).


Some of the forces modulating behaviors are terrifyingly 
powerful. Psycho-social biases and social forces are prime among 
those. So powerful they are that they can make individuals do 
things without even realizing. Conformity, obedience , influence, 
cognitive dissonance,  hundreds (Im not kidding) of social 
biases, in group / out group politics , pride, fear.


No one is immune not even the smartest of us and most exact of 
us. PhD to 8 classes only we are all influenced by those. 
Powerfully.


So it's not really exactly something unexpected that success of a 
programming language is powerfully modulated by this phenomena. 
Everything is. Including how you vote, what is your opinion on 
the right to bear weapon, on wars, on who is the friend and who 
is the enemy and

what is moral or imoral.

Re: D as a betterC a game changer ?

2017-12-27 Thread Paolo Invernizzi via Digitalmars-d

On Wednesday, 27 December 2017 at 16:42:49 UTC, Russel Winder 
wrote:


D wasn't an  option here due to lack of knowledge by the 
GStreamer crew.


That's another things I really don't understand...

/Paolo

Re: Maybe D is right about GC after all !

On Wednesday, 27 December 2017 at 16:44:25 UTC, Laeeth Isharc 
wrote:
On Wednesday, 27 December 2017 at 16:29:02 UTC, Russel Winder 
wrote:
On Wed, 2017-12-27 at 02:13 -0800, Walter Bright via 
Digitalmars-d

wrote:
[…]


Builtin unittests and Ddoc, for example. There's a big 
psychological

advantage
to having them built in rather than requiring an external 
tool. The

closeness to
C syntax is no accident, for another.

I've been in the compiler biz since the early 80s, working 
with

customers, doing
tech support. That results in experience in what works for 
people and

what
doesn't, even if it is not scientific or better from a CS 
point of

view.


This does not support the original claim that the design of D 
by you is based on psychology. It may be based on your 
perception of other programmers needs, which is fine per se, 
but that is not psychology- based design.


That's like saying the way George Soros trades is not based on 
psychology because he doesn't refer to the literature in making 
and articulating his decision-making process.  Instead people 
write papers about how he thinks, because it's not yet in the 
literature!


If published knowledge were what was most important or valuable 
then anyone intelligent with an interest in a subject would be 
part of a war of all against all, because how is it possible to 
have an edge?  But I don't think human expertise can be 
described in that manner.  Karl Polanyi's work is quite 
interesting:


https://en.wikipedia.org/wiki/Tacit_knowledge


On Soros:
http://marketfocusing.com/downloads/soros.pdf

Re: Please do not use 'auto' return types without thoroughly describing the interface

2017-12-27 Thread H. S. Teoh via Digitalmars-d

On Tue, Dec 26, 2017 at 11:28:56AM +, Mark via Digitalmars-d wrote:
> On Monday, 25 December 2017 at 22:48:39 UTC, H. S. Teoh wrote:
> > While I agree that all template parameters ought to be documented
> > and all auto return types thoroughly described, I disagree with
> > explicit naming of auto return types. The whole point of auto return
> > types is to return an *opaque* type that user code should not depend
> > on, apart from what the documentation says you can do with the type.
> > It's a matter of encapsulation, i.e., "you can do X, Y, Z with the
> > return value of this function, everything else is none of your
> > business". Or, in other words, if your code can't possibly work
> > without knowing the explicit type of the return value, then you're
> > doing something wrong (using the function wrongly).
> > 
> > T
> 
> Maybe we can document the interface of the return type using signature
> constraints? For instance, for the function:
> 
> auto map(Range)(Range r) if (isInputRange!(Unqual!Range));
> 
> we'd add the following to its constraints:
> 
> isInputRange!(ReturnType!(map!R))
> 
> However, this does not compile at the moment. I'm not sure why.

I'm not sure why either, but signature constraints are intended to be
used for constraining the range of incoming template arguments that the
template will accept. It's not intended to establish a contract on what
the template is going to produce when instantiated with those arguments,
though this could well be an enhancement request. Perhaps this should be
filed in bugzilla so that it won't get forgotten.

The best we can do currently, which unfortunately won't show up in the
docs, is to use a static assert to force compilation failure when the
return type doesn't match expectations, e.g.:

auto myFunc(Args...)(Args args) {
struct Result {
...
}
static assert(isInputRange!Result);
return Result(args);
}

Or similarly:

auto myFunc(Args...)(Args args) {
return ...;
assert(is(typeof(return) == ExpectedType));
}


T

-- 
The easy way is the wrong way, and the hard way is the stupid way. Pick one.

Re: D as a betterC a game changer ?

On Wed, 2017-12-27 at 14:06 +, Dan Partelly via Digitalmars-d
wrote:
> 
[…]
> By comparison, D is young, and had the advantage it had no 
> 
[…]

In the grand scheme of programming languages, D is old-ish. Bit this is
not a problem per se.

--
Russel.
==
Dr Russel Winder  t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk


signature.asc
Description: This is a digitally signed message part

Re: D as a betterC a game changer ?

On Wed, 2017-12-27 at 08:59 +, Dan Partelly via Digitalmars-d
wrote:
> 
[…]
> I could not agree more with this. It is unfortunate D has 
> dependencies on a garbage collector in language proper and in std.

Given the current situation, D's best route to traction is to embrace
GC and ignore all complaints other than "give us a better GC". (*)

It is all about differentiation. Forget competing against C, C++, and
Rust. D is the   C++ inspired language with GC that isn't Go.

> […]

(*) "Better C" is a specialist use case for Walter and the D backend.
-- 
Russel.
==
Dr Russel Winder  t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

signature.asc
Description: This is a digitally signed message part

Re: Maybe D is right about GC after all !

On Wednesday, 27 December 2017 at 16:29:02 UTC, Russel Winder 
wrote:
On Wed, 2017-12-27 at 02:13 -0800, Walter Bright via 
Digitalmars-d

wrote:
[…]


Builtin unittests and Ddoc, for example. There's a big 
psychological

advantage
to having them built in rather than requiring an external 
tool. The

closeness to
C syntax is no accident, for another.

I've been in the compiler biz since the early 80s, working with
customers, doing
tech support. That results in experience in what works for 
people and

what
doesn't, even if it is not scientific or better from a CS 
point of

view.


This does not support the original claim that the design of D 
by you is based on psychology. It may be based on your 
perception of other programmers needs, which is fine per se, 
but that is not psychology- based design.


That's like saying the way George Soros trades is not based on 
psychology because he doesn't refer to the literature in making 
and articulating his decision-making process.  Instead people 
write papers about how he thinks, because it's not yet in the 
literature!


If published knowledge were what was most important or valuable 
then anyone intelligent with an interest in a subject would be 
part of a war of all against all, because how is it possible to 
have an edge?  But I don't think human expertise can be described 
in that manner.  Karl Polanyi's work is quite interesting:


https://en.wikipedia.org/wiki/Tacit_knowledge

Re: D as a betterC a game changer ?

On Wed, 2017-12-27 at 01:39 +, bachmeier via Digitalmars-d wrote:
> On Tuesday, 26 December 2017 at 19:34:35 UTC, Mike Franklin wrote:
> 
> > Rust is an example of a language that got it right.
> 
> Rust got it right for a single, very specialized use case. The 
> cost is that the language is of interest to the tiny fraction of 
> programmers for whom that use case is relevant. Most don't want 
> to read a dissertation on memory management to write Hello World, 
> and having a weirder syntax than Haskell doesn't help either. D 
> is a programming language appropriate for many use cases.

Don't you believe it. Rust is attracting a lot of people and financial
support from people who used C and failed to be interested in C++
because it didn't add memory safety. The example I am interested in is
GStreamer. It's a C system that has C++, Python, D, etc. bindings but
had no interested in not being a C system until Rust arrived. Now there
is a huge push to it being a Rust system, exactly because Rust provides
something C doesn't have and C++ didn't support. D wasn't an option
here due to lack of knowledge by the GStreamer crew. Now D has no
future in this arena despite GtkD providing a D binding, it is all
Rust-bound.

-- 
Russel.
==
Dr Russel Winder  t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

signature.asc
Description: This is a digitally signed message part

Re: Strange vibe.d build error

2017-12-27 Thread H. S. Teoh via Digitalmars-d

On Sat, Dec 23, 2017 at 10:39:37AM +, Petar via Digitalmars-d wrote:
> On Thursday, 21 December 2017 at 21:10:39 UTC, H. S. Teoh wrote:
> > After pulling from vibe.d git master today, my vibe.d project doesn't
> > compile anymore. `dub build` dies with:
> > 
> > /usr/src/d/vibe.d/stream/vibe/stream/memory.d(56,42): Error:
> > constructor vibe.utils.array.AllocAppender!(ubyte[],
> > ubyte).AllocAppender.this (IAllocator alloc, ubyte[] initial_buffer =
> > null) is not callable using argument types (IAllocator)
> > 
> > No idea where to even start looking, because the error message
> > doesn't make sense. The ctor is stated to take an IAllocator as
> > first parameter, and an optional second parameter defaulting to
> > null. So why does calling the ctor with an instance of IAllocator
> > fail?!
[...]
> Most likely, it's because of this:
> https://github.com/vibe-d/vibe.d/pull/1983

Ah, figures!


> If you use dmd nightly you should see a better error message, courtesy of:
> https://github.com/dlang/dmd/pull/7405
> https://github.com/dlang/dmd/pull/7441
> https://github.com/dlang/dmd/pull/7448

I was using dmd git master.


T

-- 
Everybody talks about it, but nobody does anything about it!  -- Mark Twain

Re: Maybe D is right about GC after all !

On Wednesday, 27 December 2017 at 07:44:30 UTC, Walter Bright 
wrote:

On 12/26/2017 4:18 AM, Russel Winder wrote:
All of which brings us full circle: when it comes to 
programming

languages and software development, it is all about advocacy,
prejudice, and belief, there is very, very little science 
happening –
and most of the science that is happening is in the psychology 
of
programming, about which most developers of programming 
languages know

nothing.


If you're hinting that I know nothing about the topic, you're 
mistaken :-)


A fair amount of D's design is based on psychology.


I'd love to hear more about this sometime.  I think that's what 
people who assess languages based on checklists miss - it's the 
gestalt of the features and how they are organised and the 
consequence of this for the pattern of the code as it emerges, 
rather than particular tickbox features that's appealing.  (I 
agree with code phantom that an adaptation to how people chunk is 
one of those benefits).

Re: Maybe D is right about GC after all !