November 29, 2014
On Fri, 28 Nov 2014 17:55:21 -0800
Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> This is more of an Ubuntu-y issue, but I'm having trouble getting it to link with ncurses. This used to work:
> 
> cc $(LDFLG)  -o med $(OBJ) -l :libncurses.so.5 -l phobos2 -l pthread -l m
> 
> but alas, no longer with the latest Ubuntu. (Linux people keep trying to get rid of termcap, it's a constant issue.) -lncurses fails, everything I try fails.
> 
> Any ideas?
this is the tcap.d issue.

first: move `char PC;` and `short ospeed;` out of `extern(C)` (that is
what drives ld mad).

second: kill that linker command and replace it with:

 gcc $(LDFLG) -o med $(OBJ) -lncurses -lphobos2 -lpthread -lm -lrt

this should be enough.


November 29, 2014
On Fri, 28 Nov 2014 18:08:27 -0800
"H. S. Teoh via Digitalmars-d" <digitalmars-d@puremagic.com> wrote:

> Hmm. Did you install libncurses5-dev (or libncursesw5-dev)? If not, try
> `apt-get install libncurses5-dev` (or libncursesw5-dev as appropriate).
> Otherwise, try -lncurses5 or -lncursesw5, perhaps?
no need to do that, D doesn't use C ncurses headers.


November 29, 2014
On Fri, 28 Nov 2014 18:15:30 -0800
"H. S. Teoh via Digitalmars-d" <digitalmars-d@puremagic.com> wrote:

> On Sat, Nov 29, 2014 at 04:12:05AM +0200, ketmar via Digitalmars-d wrote:
> > On Sat, 29 Nov 2014 01:39:44 +0000
> > bearophile via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> > 
> > > Walter Bright:
> > > 
> > > > Just for fun, I've decided to try and [...]
> > > 
> > > There's a pull in need of some love, I'd like to see this in D: https://github.com/D-Programming-Language/dmd/pull/3615
> 
> I'd like to see this in D too. AFAICT, everybody else has approved it, it's just Walter who has some reservations about it.
> 
> 
> > it needs just some cosmetix changes (afair) and that's all. i'm using
> > this patch from july and still alive. ;-)
> 
> What kind of cosmetic changes are needed?
i honestly can't remember. can't diff my version with original patch from github 'cause my version has alot of code style changes which makes diff spit out almost any line. that was really some cosmetic changes a-la "this line was split to two, so path can't find it anymore" and so on, nothing intrusive.

i don't even sure that those cosmetic changes was not caused by my other patches.


November 29, 2014
On 11/28/2014 5:57 PM, bearophile wrote:
> Walter Bright:
>> 1. renaming things to the latest fashion is an illusion of progress, not
>> actual progress, such as fnmatch => globMatch
> You are wrong. Having good function names is extremely important. Renaming badly
> named things with more clear and more meaningful names reduces pain for both old
> and new users, reduces coding time, and in some cases even avoids some troubles.

That's largely speculation. I doubt there's an objective case that "globMatch" is superior to "fnmatch". Not only that, "fnmatch" is a familiar and widely used name across diverse languages. Nobody else uses "globMatch".

And all these speculative benefits need to be set against the real costs of nothing compiles that is 2+ years old, the annoyed users, the people who got tired of constant code breakage and left, and the lack of a rich set of libraries because of bit rot.

November 29, 2014
On Saturday, 29 November 2014 at 02:35:16 UTC, Walter Bright wrote:

>
> And all these speculative benefits need to be set against the real costs of nothing compiles that is 2+ years old,

Ensuring 2 year old code compiles is easily managed by keeping a copy of the tools used to build the code.  Upgrade when you have the resources to manage the migration.

> the annoyed users,

Have them see the above comment.

> the people who got tired of constant code breakage and left,

Speculation without measurement.  But I'll have you know my usage of D has declined significantly because it is missing features I want/need.  It is also for this reason that I have not advocated its usage to my employer.  How many users have been lost because they tried it and found it lacking or inefficient, not because of code breakage?  I know of 2.

> and the lack of a rich set of libraries because of bit rot.

Yes, D's current business model is not sustainable.  It is lacking capable contributors and funds to keep the code maintained.

Mike
November 29, 2014
On 11/28/2014 6:59 PM, Mike wrote:
> But I'll have you know my usage of D has
> declined significantly because it is missing features I want/need.  It is also
> for this reason that I have not advocated its usage to my employer.  How many
> users have been lost because they tried it and found it lacking or inefficient,
> not because of code breakage?  I know of 2.

I doubt any of that situation is improved by changing names.


> It is lacking capable contributors and funds to keep the code maintained

Changing names makes the situation worse by consuming scarce resources.
November 29, 2014
On Saturday, 29 November 2014 at 03:13:37 UTC, Walter Bright wrote:

>
> I doubt any of that situation is improved by changing names.
>

I was referring to (breaking) changes in general.

But with regard to names, yes names are important, which is why they should be chosen carefully up front, and why I intervened on this pull request https://github.com/D-Programming-Language/druntime/pull/999.

Mike
November 29, 2014
On Sat, 29 Nov 2014 02:59:05 +0000
Mike via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> Speculation without measurement.  But I'll have you know my usage of D has declined significantly because it is missing features I want/need.  It is also for this reason that I have not advocated its usage to my employer.
same for me. i was gently pushing our development team towards D (heh, and i'm in position to do that) but now i put a veto on D (yet i'm still using heavily patched D for my own pet projects and have no plans to change that). contrary to what one may think i did that not for code breakage, but due to the developers that continuously rejecting to break our code. we already has the language which is riddled by legacy crap, there is no need to introduce another one.

as for now i see that "don't break the code" policy is:
a. not working, as the code still breaks.
b. turning off developers that want a language without legacy crap.
c. not attracting new users to D: new users has no code, so there is
nothing to break yet.

as for libraries: having native D libraries is good, but not really necessary, 'cause it's not that hard to create imports for C libraries, and we have ALOT of C libraries out here. what is *really* matters is having consistent and solid language to build our code base upon. and a language that progressively dropping legacy leftovers in favor of new and/or better designed features.


November 29, 2014
On 11/28/2014 7:22 PM, ketmar via Digitalmars-d wrote:
> same for me. i was gently pushing our development team towards D (heh,
> and i'm in position to do that) but now i put a veto on D (yet i'm
> still using heavily patched D for my own pet projects and have no plans
> to change that). contrary to what one may think i did that not for code
> breakage, but due to the developers that continuously rejecting to break
> our code. we already has the language which is riddled by legacy crap,

Please list your top two or three.

November 29, 2014
On Saturday, 29 November 2014 at 02:59:07 UTC, Mike wrote:

>
>> the people who got tired of constant code breakage and left,
>
> Speculation without measurement.  But I'll have you know my usage of D has declined significantly because it is missing features I want/need.  It is also for this reason that I have not advocated its usage to my employer.  How many users have been lost because they tried it and found it lacking or inefficient, not because of code breakage?  I know of 2.
>

Walter, I want you to know, that I love D.  It is an awesome language with enormous potential.  But it needs to break with a few of the decisions from the past (very few, but significant), and follow through on a few things (like the scope ref proposals).  IMO, it's *almost* there.  If I(we) can ever get it there, it will likely be the last language I ever use.

Mike