On Thursday, 25 September 2014 at 07:04:43 UTC, Jacob Carlborg wrote:
> On 25/09/14 03:54, H. S. Teoh via Digitalmars-d wrote:
>
>> Well, Cliff & I (and whoever's interested) will see what we can do about
>> that. Perhaps in the not-so-distant future we may have a D build tool
>> that can serve as the go-to build tool for D projects.
>
> What problems do you see with Dub?

Here's one: having to manually generate the custom main file for unittest builds. There's no current way (or at least there wasn't when I brought it up in the dub forum) to tell it to autogenerate a D file from a dub package and list it as a dependency of the unittest build.

This is trivial in CMake. Instead I have to remember to run my dtest program every time I create a new file with unit tests when it should be done for me.

Atila

Am Wed, 24 Sep 2014 22:30:49 -0700
schrieb Walter Bright <newshound2@digitalmars.com>:

> There's more than that, but yeah. Most of my types I'll write a "pretty printer" for, and use that. No conceivable debugger can guess how I want to view my data.

You can call functions with GDB, but I guess you haven't used GDB much.

Breakpoint 1, D main () at main.d:5
(gdb) print a
$1 = (ABCD &) @0x7ffff7ebfff0: {<Object> = {__vptr = 0x4b8c60
<main.ABCD.vtbl$>, __monitor = 0x0}, <No data fields>}
(gdb) print a.toString()
$2 = "Hello World!"

On Thursday, 25 September 2014 at 03:55:22 UTC, Walter Bright wrote:
> No prob. The initiating post was an invitation to a wine festival, and that's what we have :-)

:D

On Thursday, 25 September 2014 at 00:52:25 UTC, Walter Bright wrote:
> On 9/24/2014 7:56 AM, Don wrote:
>> For example: We agreed *years* ago to remove the NCEG operators. Why haven't
>> they been removed yet?
>
> They do generate a warning if compiled with -w.

They should be gone completely. So should built-in sort.
I think there's something important that you haven't grasped yet. It was something I didn't really appreciate before working here.

 ** Keeping deprecated features alive is expensive. **

As long as deprecated features still exist, they impose a cost. Not just on the language maintainers, but also on the users. On anyone writing a language parser - so for example on text editors. On anyone training new employees.
And there's a little cognitive burden on all language users.

>
>>> What change in particular?
>> I've got a nasty feeling that you misread what he wrote. Every time we say,
>> "breaking changes are good", you seem to hear "breaking changes are bad"!
>
> It would be helpful having a list of what breaking changes you had in mind.

C-style declarations. Builtin sort and reverse. NCEG operators. Built-in complex types. float.min. @property.

Basically, anything where it has been decided that it should be removed. Some of these things have been hanging around for six years.

I'd also like to see us getting rid of those warts like assert(float.nan) being true. And adding a @ in front of pure, nothrow.

Ask yourself, if D had no users other than you, so that you break *anything*, what would you remove? Make a wishlist, and then find out what's possible. Remember, when you did that before, we successfully got rid of 'bit', and there was practically no complaint.

Any breaking change where it fails to compile, and where there's an essentially mechanical solution, are really not a problem. Subtle changes in semantics are the ones that are disastrous.

We want to pay the one-off cost of fixing our code, so that we can get the long term return-on-investment of a cleaner language.

On Thursday, 25 September 2014 at 03:55:22 UTC, Walter Bright
wrote:
> I make similar statements all the time. It doesn't result in action on anyone's part. I don't tell people what to do - they work on aspects of D that interest them.
>
> Even people who ask me what to work on never follow my suggestions. They work on whatever floats their boat. It's my biggest challenge working on free software :-)

One recurring theme appears to be people waiting on you to decide
on whether an idea is agreeable in principle before implementing
it.  It would help if you put up a list on the wiki of such
features, either that you want or that you agree with others
would be good to have, ie some sort of feature wish list that's
pre-approved by you and Andrei.

D enthusiasts shouldn't have to wade through a bunch of forum
postings and reddit comments to find out that C++ and gc are the
current priorities.  When this was pointed out to Andrei, he
asked that someone else put it on the wiki, and I see that
someone just added it to the agenda for 2.067.

I'm sorry but it's ridiculous for you two co-BDFLs not to put
these new priorities or pre-approved features (perhaps even a
list of features you'd automatically reject) in a list on the
wiki and maintain it yourselves.  It's the least you can do
considering the veto power you have.

Of course, such lists don't imply a hierarchy where you tell
everyone what to do, as the D community is always free to ignore
your agenda. ;) But it would enable clear and concise
communication, which is lacking now, and I suspect many would
take your approval as a signal for what to work on next.

For a concrete example, some in this thread have mentioned
cleaning up the language, presumably enabled by a dfix tool so
users can have their source automatically updated.  But even
Jacob seemed to think you two were against dfix, in the quote
below:

On Wednesday, 24 September 2014 at 06:16:07 UTC, Jacob Carlborg
wrote:
> On 23/09/14 20:32, David Nadlinger wrote:
>
>> Seriously, once somebody comes up with an automatic fixup tool, there is
>> hardly any generic argument left against language changes.
>
> Brain has already said that such a tool is fairly easy to create in many cases. Also that he is willing do to so if it will be used. But so far neither Andrei or Walter have shown any signs of willing to break code that can be fixed with a tool like this. I can understand that Brian doesn't want to create such a tool if it's not going to be used.

Andrei has voiced some support for a tool like this, though in
exactly what context is unclear.  I believe you once said it'd be
unworkable, then when Brian showed you an example using
libdparse, you took that back but did not say you wanted to start
cleaning up D using such a dfix tool.  Go has been doing this for
years using gofix and many of us have expressed a desire for such
language cleanup using automated source conversion:

http://blog.golang.org/introducing-gofix

I can understand why nobody builds a dfix tool if it's not going
to be used officially to clean up the language.  If you said
you'd go for it, I imagine Brian would build such a tool and find
stuff to fix.

Of course, sometimes people look to you two too much to decide.
I don't see why Vladimir can't build the autotester setup he
wants for third-party D projects and continuously run any
third-party projects he wants (all of code.dlang.org?) against
dmd/druntime/phobos from git for himself.  If others like it,
they will start using it for their own projects.  The only reason
to integrate it with the dmd autotester is to notify authors of
their pull requests that broke third-party code, but that can
wait till such a third-party autotester has been proven for the
third-party authors first.

To sum up, you can't tell people what to do in the D community,
but you can provide more clear direction on what the priorities
are and which future paths have the green light, especially since
you and Andrei are the gatekeepers for what gets into dmd.

On Thursday, 25 September 2014 at 07:28:10 UTC, Atila Neves wrote:
>
>> [...]
>>> If you have a passion and interest in this space and would like to
>>> collaborate, I would be thrilled.  We can also split this discussion
>>> off of this thread since it is not D specific.
>>
>> I'm interested. What about Atila?
>
> Definitely interested. BTW, I agree with everything you said about what would be desireable from a build system. Basically we had pretty much the same idea. :)

Glad to hear you guys are going to take a pass at this. :) You might want to check out ekam, a since-abandoned build tool that sounded similar, started by one of the guys behind Protocol Buffers:

http://kentonsprojects.blogspot.in/search/label/ekam

Maybe he had some ideas you'd want to steal.

On Thursday, 25 September 2014 at 11:30:52 UTC, Joakim wrote:
> On Thursday, 25 September 2014 at 03:55:22 UTC, Walter Bright
> wrote:
>> I make similar statements all the time. It doesn't result in action on anyone's part. I don't tell people what to do - they work on aspects of D that interest them.
>>
>> Even people who ask me what to work on never follow my suggestions. They work on whatever floats their boat. It's my biggest challenge working on free software :-)
>
> One recurring theme appears to be people waiting on you to decide
> on whether an idea is agreeable in principle before implementing
> it.  It would help if you put up a list on the wiki of such
> features, either that you want or that you agree with others
> would be good to have, ie some sort of feature wish list that's
> pre-approved by you and Andrei.
>
There is at least this bugzilla tag:
https://issues.dlang.org/buglist.cgi?keywords=preapproved&list_id=110116

...But its an awful short list!  Clear direction has been a common request for a while.

In the vein of what you're talking about, though, this seems a good place to leverage our existing infrastructure with Bugzilla.  Open tracker bugs that cover these areas and add any issues related to them as dependencies.  Looks something like this:
https://bugs.gentoo.org/show_bug.cgi?id=484436

-Wyatt

On 25/09/14 07:30, Walter Bright wrote:

> There's more than that, but yeah. Most of my types I'll write a "pretty
> printer" for, and use that. No conceivable debugger can guess how I want
> to view my data.

With LLDB you can implement your own custom formatters [1]. For example, in Xcode, Apple have added for Objective-C a formatter for NSImage. Within Xcode you can hover a variable of the type NSImage and it will show a small window with the image rendered.

Perhaps it's time to look at some modern alternatives and not be stuck with GDB ;)

[1] http://lldb.llvm.org/varformats.html

-- 
/Jacob Carlborg

Am Thu, 25 Sep 2014 11:08:23 +0000
schrieb "Don" <x@nospam.com>:

> They should be gone completely. So should built-in sort.
> I think there's something important that you haven't grasped yet.
> It was something I didn't really appreciate before working here.
> 
>   ** Keeping deprecated features alive is expensive. **
> 
> As long as deprecated features still exist, they impose a cost. Not just on the language maintainers, but also on the users. On anyone writing a language parser - so for example on text editors. On anyone training new employees.

This reminds me of a conversation on stackoverflow: http://stackoverflow.com/a/25864699

>> However, note that the built-in .sort property/function is on its way to being deprecated. Please use std.algorithm.sort instead, which shouldn't have this issue.

> I was aiming for std.algorithm.sort, I didn't realize there is a built-in one...

On 25/09/14 08:39, H. S. Teoh via Digitalmars-d wrote:

> In fact, one thing that impressed me immensely is the fact that building
> the dmd toolchain is as simple as it is. I know of no other compiler
> project that is comparable. Building gcc, for example, is a wondrous
> thing to behold -- when it works. When it doesn't (which is anytime you
> dare do the slightest thing not according to the meticulous build
> instructions)... it's nightmarish.

Yeah, I agree. It's a nice property of DMD.

> But even then, I *did* run into the problem of non-reproducible builds
> with dmd. So there's still a blemish there. :-P  Makes me want to alias
> `make` to `make clean; make` just for this alone

I don't think the "clean" action can be completely excluded. I recently tried to build a project, without running "clean", and got some unexpected errors. Then I remembered I had just installed a new version of the compiler.

-- 
/Jacob Carlborg