On Monday, 17 January 2022 at 22:33:02 UTC, Johan wrote:
> ...
> Also in code review, you can simply comment "clang-format" and all is clear. No more discussions about formatting :)
>
> -Johan

"we all think our code is a unique and beautiful snowflake..crafted over years...until we send it out for code review" - Chandler Carruth 2016

On Mon, Jan 17, 2022 at 11:42:50PM +0000, forkit via Digitalmars-d wrote: [...]
> 'just file a bug' is certainly the easiest response.. I get it.  ;-)
> 
> Also, if existing bugs have been discussed and found to be complex or time-consuming, or difficult in one way or another, fine.... I get that too.
> 
> But to have bugs sit their for 7 years, not discussed, not addressed in any way.. then.. from where does one get the motivation to file a new bug?

Which bugs in particular do you have in mind?

If it's something that's especially bugging you, periodically complaining loudly on the forums (and linking to the bug in question, hint, hint) helps draw attention to it.


> In such situations, it's actually a lot easier, and even makes more sense, to just not use that feature ;-)

Given the current scant manpower, it's a bit unrealistic to expect a timely response, even though nobody will argue that it would be a good thing.  In this situation, it's even the more important to file issues, 'cos otherwise you can be assured that the bug will unlikely to *ever* get noticed.


T

-- 
The best compiler is between your ears. -- Michael Abrash

On Monday, 17 January 2022 at 23:59:05 UTC, H. S. Teoh wrote:
>
> Given the current scant manpower, it's a bit unrealistic to expect a timely response, even though nobody will argue that it would be a good thing. ...

I think that argument ('scant manpower') is an over-simplification, and provides a distorted representation of the 'actual' problem.

It's really a chicken and egg problem.

More manpower will come from more people using D in larger code bases.

But code quality in larger code bases needs to *already* be high.

So the issue of 'bug management' is far more critical to D expanding its user-base, than constantly adding new features... this needed to planned for and managed at the beginning, with the highest priority given to that, rather than adding new features.

(back to the sibject of this thread though) .. Code review is an important component of bug management too, and without a good, reliable code-formatter, that becomes a more time-consuming activity than it needs to be.

C++/Go/Rust/Java/C#.... have all, already, learnt this lesson.

On Monday, 17 January 2022 at 23:59:05 UTC, H. S. Teoh wrote:
>
> Which bugs in particular do you have in mind?
>

The same one that I ran into myself, just a few days ago:

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

On Tue, Jan 18, 2022 at 12:40:17AM +0000, forkit via Digitalmars-d wrote: [...]
> https://issues.dlang.org/show_bug.cgi?id=14892

Alright.  Since you brought it up, I'm gonna try to take a look sometime and see if it's simple enough for me to fix.  I'm not very familiar with dmd's code, but I *have* fixed a bug or two before so I'm gonna take a shot at it.  No guarantees, though! ;-)


T

-- 
MAS = Mana Ada Sistem?

On Mon, Jan 17, 2022 at 05:01:53PM -0800, H. S. Teoh via Digitalmars-d wrote:
> On Tue, Jan 18, 2022 at 12:40:17AM +0000, forkit via Digitalmars-d wrote: [...]
> > https://issues.dlang.org/show_bug.cgi?id=14892
> 
> Alright.  Since you brought it up, I'm gonna try to take a look sometime and see if it's simple enough for me to fix.  I'm not very familiar with dmd's code, but I *have* fixed a bug or two before so I'm gonna take a shot at it.  No guarantees, though! ;-)
[...]

OK, first impressions: -profile=gc is a crock.  Not only it fails to detect GC allocations outside of built-in language constructs, it fails to create the profilegc.txt output file at all when it detects no allocations.  I wrote a test program that allocates an array with a literal, then commented it out to an empty main(), profilegc.txt was NOT updated. :-/

Honestly, at this point I'd recommend just doing this instead of using -profile=gc at all:

	import core.memory : GC;
	writeln(GC.stats);

That will tell you the real honest truth of what has actually been allocated on the GC, straight from the GC horse's mouth. No compiler lies.

I'll take a look at the code now to see if there's anything easily salvageable...  but at this point I'm ready to propose pulling the trigger on -profile=gc completely.  (Based on how I suspect it works, I'm expecting that it would not be easy to implement any useful output for allocations via druntime functions -- at best you'd just get some obscure file/line number inside druntime code which would be of no help locating where in *your* code the allocation happened.)


T

-- 
First Rule of History: History doesn't repeat itself -- historians merely repeat each other.

On Tuesday, 18 January 2022 at 01:23:26 UTC, H. S. Teoh wrote:
> On Mon, Jan 17, 2022 at 05:01:53PM -0800, H. S. Teoh via Digitalmars-d wrote:
>> On Tue, Jan 18, 2022 at 12:40:17AM +0000, forkit via Digitalmars-d wrote: [...]
>> > https://issues.dlang.org/show_bug.cgi?id=14892
>> 
>> Alright.  Since you brought it up, I'm gonna try to take a look sometime and see if it's simple enough for me to fix.  I'm not very familiar with dmd's code, but I *have* fixed a bug or two before so I'm gonna take a shot at it.  No guarantees, though! ;-)
> [...]
>
> OK, first impressions: -profile=gc is a crock.  Not only it fails to detect GC allocations outside of built-in language constructs, it fails to create the profilegc.txt output file at all when it detects no allocations.  I wrote a test program that allocates an array with a literal, then commented it out to an empty main(), profilegc.txt was NOT updated. :-/
>
> Honestly, at this point I'd recommend just doing this instead of using -profile=gc at all:
>
> 	import core.memory : GC;
> 	writeln(GC.stats);
>
> That will tell you the real honest truth of what has actually been allocated on the GC, straight from the GC horse's mouth. No compiler lies.
>
> I'll take a look at the code now to see if there's anything easily salvageable...  but at this point I'm ready to propose pulling the trigger on -profile=gc completely.  (Based on how I suspect it works, I'm expecting that it would not be easy to implement any useful output for allocations via druntime functions -- at best you'd just get some obscure file/line number inside druntime code which would be of no help locating where in *your* code the allocation happened.)
>
>
> T

On Linux and anything with DTrace at least it might be possible to replace it with a some eBPF (or DTrace) code.

Profile=GC is still useful however. Catching *all* allocations isn't actually particularly important in steady state. The allocations that matter are nearly always extremely obvious. Profile=GC can do a better job than a normal heap profiler because it has access to the typeinfo.

-profile is total rubbish that should be gotten rid of entirely. No prisoners, no prisoners.

On Tue, Jan 18, 2022 at 01:30:56AM +0000, max haughton via Digitalmars-d wrote: [...]
> Profile=GC is still useful however. Catching *all* allocations isn't actually particularly important in steady state. The allocations that matter are nearly always extremely obvious. Profile=GC can do a better job than a normal heap profiler because it has access to the typeinfo.

Given the frequency of std.array.array in range-based D code, which currently is completely not tracked by -profile=gc, I honestly doubt how useful this is. Basically you'd only be detecting array literals, AA literals, and the odd array length changes. Anything constructed from ranges would be missed.  At least for the kind of code I write, that's like >80% of GC allocations, making this "feature" next to useless to me.

At the very least, the documentation should clearly state what is/isn't traced by -profile=gc.  The current misleading state of things is a big turn-off for newcomers.


> -profile is total rubbish that should be gotten rid of entirely. No prisoners, no prisoners.

I concur.  Last time I checked (this was a few years ago), it uses 16-bit counters internally to track function call counts. **16-bit** counters!!!  Makes it completely worthless for profiling anything that runs for non-trivial amounts of time.  The counters overflow in the steady state and produce useless garbled output.  It's a total sham. Kill it with fire, I say.


T

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

On Tuesday, 18 January 2022 at 01:23:26 UTC, H. S. Teoh wrote:
>
> I'll take a look at the code now to see if there's anything easily salvageable...

Surely I am not the only one that declares a dynamic array initialised using a Result set?

Is this not allocated on the GC managed heap?

How has that been excluded from the original implementation considerations of -profile=gc

And more to the point, excluded from considering adding it to this feature, for 7 years now.

I don't get it.

Am I also getting familar with the --DRT options, but still looking into this..

On 18/01/2022 2:46 PM, H. S. Teoh wrote:
>> -profile is total rubbish that should be gotten rid of entirely. No
>> prisoners, no prisoners.
> I concur.  Last time I checked (this was a few years ago), it uses
> 16-bit counters internally to track function call counts. **16-bit**
> counters!!!  Makes it completely worthless for profiling anything that
> runs for non-trivial amounts of time.  The counters overflow in the
> steady state and produce useless garbled output.  It's a total sham.
> Kill it with fire, I say.

The number of times of tried -profile and it simply didn't work, is far too high.

Either it needs a complete replacement or ditch it. Its not a good look for newcomers.