On 9/25/14, 4:08 AM, Don wrote:
> C-style declarations. Builtin sort and reverse. NCEG operators. Built-in
> complex types. float.min. @property.

That's a good list I agree with. FWIW I'm glad no random name changes. I've recently used Rust a bit and the curse of D users as of 6-7 years ago reached me: most code I download online doesn't compile for obscure reasons, it's nigh impossible to figure out what the fix is from the compiler error message, searching online finds outdated documentation that tells me the code should work, and often it's random name changes (from_iterator to from_iter and such, or names are moved from one namespace to another).

For the stuff we eliminate we should provide good error messages that recommend the respective idiomatic solutions.


Andrei

On 25/09/14 09:38, Atila Neves wrote:

> 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.

Hmm, I haven't used Dub to run unit tests. Although, DMD has a "-main" flag that adds an empty main function.

-- 
/Jacob Carlborg

On 25/09/14 09:38, Atila Neves wrote:

> 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.

BTW, I would say that's a minor issue, far from begin enough to create a completely new build system.

-- 
/Jacob Carlborg

On 9/25/14, 4:30 AM, Joakim wrote:
> 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.

That's sensible. We have the "preapproved" tag at http://issues.dlang.org exactly for that kind of stuff. (I should note, however, that sometimes it backfires - I've added https://issues.dlang.org/show_bug.cgi?id=13517 with preapproved knowing it's sensible and entirely noncontroversial and got unexpected pushback for it.)


Andrei

On 9/25/14, 5:41 AM, Wyatt wrote:
> 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.

I'll make a pass, also please post here specific issues you need to be looked at.

Andrei

On Thursday, 25 September 2014 at 13:31:24 UTC, Jacob Carlborg wrote:
>
> Perhaps it's time to look at some modern alternatives and not be stuck with GDB ;)
>
I might look at the "modern alternative" once it supports debugging 64-bit executables. :/

-Wyatt

On Thu, Sep 25, 2014 at 03:47:22PM +0200, Jacob Carlborg via Digitalmars-d wrote:
> On 25/09/14 08:39, H. S. Teoh via Digitalmars-d wrote:
[...]
> >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.
[...]

That's the hallmark of make-based projects. SCons projects, OTOH, almost never needs to do that (except if you totally screwed up your SCons scripts). The super-complicated SCons script that I described in another post? I don't even remember that last *year* when I had to do the equivalent of a clean. I've been updating, branching, merging the workspace for years now, and it Just Builds -- correctly at that.


T

-- 
Famous last words: I *think* this will work...

On Thursday, 25 September 2014 at 13:50:10 UTC, Jacob Carlborg wrote:
> On 25/09/14 09:38, Atila Neves wrote:
>
>> 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.
>
> Hmm, I haven't used Dub to run unit tests. Although, DMD has a "-main" flag that adds an empty main function.

Andrei spoke about an idiom that they constantly use at Facebok, because there aparrently nobody runs *main and unittests*. So they keep a special empty main for the -unittest version.

If tha time to clean up D has come, maybe it is the time to make that idiom the default behaviour of the flag. He posted that thing somewhere in the forum, but cannot find it right now.

Real usage is good for learning.

Am 25.09.2014 07:30, schrieb Walter Bright:
> On 9/24/2014 9:43 PM, H. S. Teoh via Digitalmars-d wrote:
>> printf debugging FTW! :-P
>
> 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.
>
> For example, I can pretty-print an Expression as either a tree or in
> infix notation.
>

In Visual Studio I can define formatters for data structures. Most of the STL containers are already configured out of the box.

Additionally, I don't know another IDE that matches Visual Studio debugging capabilities for multi-core and graphics programming.

And C++ debugger is still catching with what .NET debugger can do for multi-core programming.

--
Paulo

25-Sep-2014 01:12, Andrei Alexandrescu пишет:
> On 9/24/14, 1:10 PM, H. S. Teoh via Digitalmars-d wrote:
>> That's unfortunate indeed. I wish I could inspire them as to how cool a
>> properly-done build system can be.
> [snip]
>
> That's all nice. However: (1) the truth is there's no clear modern build
> tool that has "won" over make;

Pretty much any of them is better, and will easily handle the size of phobos/druntime/dmd projects.

> oh there's plenty of them, but each has
> its own quirks that makes it tenuous to use;

Somehow must indicate that make doesn't have them (and in incredible capacity)?

Most of my Scons scripts are under 10 lines, in fact 2-3 LOCs.

I had an "insanely" complicated one could handle 2 platforms, 3 emulators and a few custom build steps (including signing binaries), cleaning, tracking dependencies with minimal rebuilds. For instance, binary need not to be signed again if it's bit for bit the same.
All of the above was done in about 50 lines, never braking as the project progressed, I think it changed only 2-3 times over a year.

I was never able to make a good makefile that wouldn't shit on me in some way, like not properly cleaning something or handling errors . I'm not even talking about the 10+ LOCs for anything barely useful.

> (2) any build system for a
> project of nontrivial size needs a person/team minding it - never saw
> such a thing as it's just all automated and it works;

The question is amount of work, size of file and frequency of changes. For instance, Scons easily allows not to change a makefile on every single added module, I can't say if make could pull it off.

> (3) especially if
> the build system is not that familiar, the role of the build czar is all
> the more important.

Somebody (Russel?) was working on D Scons support, how about start to capitalize on this work? I'd gladly try to make a scons script for phobos/druntime if there
is even a tiny chance of apporval.

> So the reality is quite a bit more complicated than the shiny city on a
> hill you describe.

Most people using make/autotools say build systems are hard, it need not to be true but I'm obviously biased.

-- 
Dmitry Olshansky