On 09/10/2014 10:15 pm, "Atila Neves via Digitalmars-d" < digitalmars-d@puremagic.com> wrote:
>
>
>> Debugging, ldc (for windows), and editor integrations (auto complete,
>> navigation, refactoring tools) are my impersonal (and hopefully
>> non-controversial) short list. They trump everything else I've
>
>
> I don't know how well DCD works with other editors, but in Emacs at least
(when DCD doesn't throw an exception, I need to chase those down), autocomplete and code navigation just work. _Including_ dub dependencies.

I haven't found a way to make use of dub yet; all my projects involve other
languages too.
Also, I'm a primary windows user, so I haven't tried DCD to any great
length.
Alexander's auto complete is getting better, but it still gets easily
confused, and the refactor and navigation tools are still basically missing.

I feel like it would all be much easier if dmd was a lib that tooling could make use of. It seems like a lot of redundant effort to rewrite the language parser over and over when dmd already does it perfectly...

Dan Murphy seemed to think ddmd would have some focus on usage as a lib?

>> The debugging experience is the worst of any language I've used since the 90's, and I would make that top priority.
>
>
> Debugging can definitely be improved on. Even with Iain's fork of gdb I
end up using writeln instead because it's frequently easier.

Iain's work doesn't help on windows sadly. But I think the biggest problem is the local scope doesn't seem to be properly expressed in the debug info. It's a compiler problem more than a back end problem. The step cursor is all over the shop, and local variables alias each other and confuse the debugger lots. Also I can't inspect the contents of classes.

On Monday, 6 October 2014 at 19:07:40 UTC, Andrei Alexandrescu wrote:
> On 10/6/14, 11:55 AM, H. S. Teoh via Digitalmars-d wrote:
>> On Mon, Oct 06, 2014 at 06:13:41PM +0000, Dicebot via Digitalmars-d wrote:
>>> On Monday, 6 October 2014 at 16:06:04 UTC, Andrei Alexandrescu wrote:
>> [...]
>>>> It would be terrific if Sociomantic would improve its communication
>>>> with the community about their experience with D and their needs
>>>> going forward.
>>>
>>> How about someone starts paying attention to what Don posts? That
>>> could be an incredible start. I spend great deal of time both reading
>>> this NG (to be aware of what comes next) and writing (to express both
>>> personal and Sociomantic concerns) and have literally no idea what can
>>> be done to make communication more clear.
>>
>> I don't remember who it was, but I'm pretty sure *somebody* at
>> Sociomantic has stated clearly their request recently: Please break our
>> code *now*, if it helps to fix language design issues, rather than
>> later.
>
> More particulars would be definitely welcome. I should add that Sociomantic has an interesting position: it's a 100% D shop so interoperability is not a concern for them, and they did their own GC so GC-related improvements are unlikely to make a large difference for them. So "C++ and GC" is likely not to be high priority for them. -- Andrei

Yes and this is exactly why I am that concerned about recent memory management policy thread. Don has already stated it in his talks but I will repeat important points:

1) We don't try to avoid GC in any way
2) However it is critical for performance to avoid creating garbage in a form of new GC roots
3) Worst part of Phobos is not GC allocations but specifically lot of temporarily garbage allocations

This is a very simple issue that will prevent us from using and contributing to majority of Phobos even when D2 port is finished.

Switch to input/output ranges as API fundamentals was supposed to fix it. Custom management policies as you propose won't fix it at all because garbage will still be there, simply managed in a different way.

This is especially dissapointing because it was a first time when declared big effort seemed to help our needs but it got abandoned after very first attempts.

On Wednesday, 8 October 2014 at 20:07:09 UTC, Walter Bright wrote:
> On 10/8/2014 4:17 AM, Don wrote:
>> As I said in my Dconf 2013 talk -- I advocate a focus on Return On Investment.
>> I'd love to see us chasing the easy wins.
>
> I love the easy wins, too. It'd be great if you'd start a thread about "Top 10 Easy Wins" from yours and Sociomantic's perspective.
>
> Note that I've done some work on the deprecations you've mentioned before.

That can possibly be done though it will take some efforts to formalize issues from the casual chat rants. More important issue is - what will happen next? I am pretty sure many of those easy wins are not easy at all in a sense that breaking changes are needed.

On Thursday, 9 October 2014 at 09:37:29 UTC, Danni Coy via Digitalmars-d wrote:
> It might be unfair but it is still a massive problem. The tooling
> compared to what I have with say C++ and Qt is not a fun experience.
> The language is nicer but the difference in tooling is making the
> difference seem a lot smaller than it should be.

This tooling does not exist in C++ magically. It exists there because many people were willing to work on it and much more were willing to pay for it. So unless you personally are ready to do one of those things those expectations will never come true.

Dicebot wrote:

> Switch to input/output ranges as API fundamentals was supposed to fix it. Custom management policies as you propose won't fix it at all because garbage will still be there, simply managed in a different way.


Would it be impractical to support multiple approaches through
templates? There seemed to be clear use cases where supplying
memory to a function was a good idea and some where it wasn't.

On Thursday, 9 October 2014 at 14:38:08 UTC, ixid wrote:
> Dicebot wrote:
>
>> Switch to input/output ranges as API fundamentals was supposed to fix it. Custom management policies as you propose won't fix it at all because garbage will still be there, simply managed in a different way.
>
>
> Would it be impractical to support multiple approaches through
> templates? There seemed to be clear use cases where supplying
> memory to a function was a good idea and some where it wasn't.

Multiple approaches for what? Adnrei proposal is not fundamentally incompatible with range-fication our using our array parameters, it simply moves the focus in a different direction (which is of no use to us).

Looking at http://wiki.dlang.org/Stuff_in_Phobos_That_Generates_Garbage I also feel that ranges + reusable exceptions pools (needs refcounting for exceptions to implement) alone can take care of majority of issue, new proposal being more of a niche thing.

On Thursday, 9 October 2014 at 14:47:00 UTC, Dicebot wrote:
> On Thursday, 9 October 2014 at 14:38:08 UTC, ixid wrote:
>> Dicebot wrote:
>>
>>> Switch to input/output ranges as API fundamentals was supposed to fix it. Custom management policies as you propose won't fix it at all because garbage will still be there, simply managed in a different way.
>>
>>
>> Would it be impractical to support multiple approaches through
>> templates? There seemed to be clear use cases where supplying
>> memory to a function was a good idea and some where it wasn't.
>
> Multiple approaches for what? Adnrei proposal is not fundamentally incompatible with range-fication our using our array parameters, it simply moves the focus in a different direction (which is of no use to us).
>
> Looking at http://wiki.dlang.org/Stuff_in_Phobos_That_Generates_Garbage I also feel that ranges + reusable exceptions pools (needs refcounting for exceptions to implement) alone can take care of majority of issue, new proposal being more of a niche thing.

Multiple approaches to how library functions can handle memory.

"Manu via Digitalmars-d" <digitalmars-d@puremagic.com> wrote in message news:mailman.559.1412859804.9932.digitalmars-d@puremagic.com...

> Dan Murphy seemed to think ddmd would have some focus on usage as a lib?

Yes, but it's a long way off. 

On Thursday, 9 October 2014 at 15:00:02 UTC, ixid wrote:
> Multiple approaches to how library functions can handle memory.

As long as it allows us avoid creating new GC roots and keep using GC for all allocations at the same time.

On 10/9/14, 7:09 AM, Dicebot wrote:
> Yes and this is exactly why I am that concerned about recent memory
> management policy thread. Don has already stated it in his talks but I
> will repeat important points:
>
> 1) We don't try to avoid GC in any way
> 2) However it is critical for performance to avoid creating garbage in a
> form of new GC roots
> 3) Worst part of Phobos is not GC allocations but specifically lot of
> temporarily garbage allocations

What would be a few good examples of (3)? Thanks.

> This is a very simple issue that will prevent us from using and
> contributing to majority of Phobos even when D2 port is finished.
>
> Switch to input/output ranges as API fundamentals was supposed to fix
> it.

Unfortunately it doesn't. RC does. Lazy computation relies on escaping ranges all over the place (i.e. as fields inside structs implementing the lazy computation). If there's no way to track those many tidbits, resources cannot be reclaimed timely.

Walter and I have only recently achieved clarity on this.

> Custom management policies as you propose won't fix it at all
> because garbage will still be there, simply managed in a different way.

I'm not sure I understand this.

> This is especially dissapointing because it was a first time when
> declared big effort seemed to help our needs but it got abandoned after
> very first attempts.

It hasn't gotten abandoned; it's on the back burner. Lazification is a good thing to do, but won't get us closer to taking the garbage out.


Andrei