www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Integrated code formatter

reply forkit <forkit gmail.com> writes:
So I use clang-format extensively...like all the time.

It makes such a difference, I can't imagine programming without 
it anymore.

But D doesn't have something integrated like this.

I am aware of dfmt.. but even on it's github page it says "dfmt 
is beta quality."

I wonder if it isn't time a code formatter for D became a more 
integrated product, into the release itself, so that people like 
me can actually rely on it to work as expected, and also, so that 
the formatter's needs were considered whenever making changes to 
D.

Or is D code now so variable and complex, that no formatter can 
reliably format it?
Jan 17 2022
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Jan 17, 2022 at 09:46:08PM +0000, forkit via Digitalmars-d wrote:

 So I use clang-format extensively...like all the time.
 
 It makes such a difference, I can't imagine programming without it
 anymore.
 
 But D doesn't have something integrated like this.
 
 I am aware of dfmt.. but even on it's github page it says "dfmt is
 beta quality."


So?  You can still use it.



 I wonder if it isn't time a code formatter for D became a more
 integrated product, into the release itself, so that people like me
 can actually rely on it to work as expected, and also, so that the
 formatter's needs were considered whenever making changes to D.
 
 Or is D code now so variable and complex, that no formatter can
 reliably format it?


Code formatting is an art, not a science. There are many cases where I
would NOT want an automatic formatter to mess with my code because it
would make it less readable.

For example, here's a snippet of an actual unittest in one of my
projects:

    auto expected = [
        [  1,  1,  Sqrt2, 1 ],
        [  1, -1,  Sqrt2, 1 ],
        [ -1,  1,  Sqrt2, 1 ],
        [ -1, -1,  Sqrt2, 1 ],

        [          1,  (1+Sqrt2),  0, 1 ],
        [          1, -(1+Sqrt2),  0, 1 ],
        [         -1,  (1+Sqrt2),  0, 1 ],
        [         -1, -(1+Sqrt2),  0, 1 ],
        [  (1+Sqrt2),          1,  0, 1 ],
        [  (1+Sqrt2),         -1,  0, 1 ],
        [ -(1+Sqrt2),          1,  0, 1 ],
        [ -(1+Sqrt2),         -1,  0, 1 ],
    ];

I would NOT want an auto code formatter to go, "hey, you have all those
ugly redundant spaces, let's compress them to a single space!", or "hey,
you can fit more array elements per line in your outer array, let's save
some space!" -- because that would destroy the visual symmetry that
actually makes this code readable.  If this were formatted the more
usual way, it would become much less readable because its large-scale
structure would be obscured.

But in other instances, I *would* want my arrays to be formatted more
compactly.  No automatic formatter can reliably guess when to format it
one way vs. another in such cases, and I'd prefer to just do it myself
(and not have the computer screw things up afterwards).

(Yes I know some code formatters have tags to suppress automatic
formatting, etc., but seriously, why do I need to explicitly ask the
computer not to do something I didn't want it to do in the first place?)

//

That said, if an automatic formatter works for you, why not give dfmt a
spin?  Don't be intimidated by the "beta" label (what does that even
mean anyway); try it out and see if it's really as bad as you imagine it
to be.  You might be pleasantly surprised.


T

-- 
If I were two-faced, would I be wearing this one? -- Abraham Lincoln
Jan 17 2022
next sibling parent reply forkit <forkit gmail.com> writes:
On Monday, 17 January 2022 at 22:19:51 UTC, H. S. Teoh wrote:

 That said, if an automatic formatter works for you, why not 
 give dfmt a spin?  Don't be intimidated by the "beta" label 
 (what does that even mean anyway); try it out and see if it's 
 really as bad as you imagine it to be.  You might be pleasantly 
 surprised.


 T


I think it's because I'm experiencing 'the let-down' effect...

the most recent one being: -profile=gc  (which isn't even 'beta').
Jan 17 2022
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Jan 17, 2022 at 10:27:54PM +0000, forkit via Digitalmars-d wrote:

 On Monday, 17 January 2022 at 22:19:51 UTC, H. S. Teoh wrote:

 
 That said, if an automatic formatter works for you, why not give
 dfmt a spin?  Don't be intimidated by the "beta" label (what does
 that even mean anyway); try it out and see if it's really as bad as
 you imagine it to be.  You might be pleasantly surprised.




[...]

 I think it's because I'm experiencing 'the let-down' effect...
 
 the most recent one being: -profile=gc  (which isn't even 'beta').


Yeah, I'd trust  nogc more than -profile=gc, tbh.


T

-- 
Insanity is doing the same thing over and over again and expecting different
results.
Jan 17 2022
prev sibling parent reply max haughton <maxhaton gmail.com> writes:
On Monday, 17 January 2022 at 22:27:54 UTC, forkit wrote:

 On Monday, 17 January 2022 at 22:19:51 UTC, H. S. Teoh wrote:

 That said, if an automatic formatter works for you, why not 
 give dfmt a spin?  Don't be intimidated by the "beta" label 
 (what does that even mean anyway); try it out and see if it's 
 really as bad as you imagine it to be.  You might be 
 pleasantly surprised.


 T


 I think it's because I'm experiencing 'the let-down' effect...

 the most recent one being: -profile=gc  (which isn't even 
 'beta').


Bug Reports?
Jan 17 2022
parent reply forkit <forkit gmail.com> writes:
On Monday, 17 January 2022 at 22:37:06 UTC, max haughton wrote:

 On Monday, 17 January 2022 at 22:27:54 UTC, forkit wrote:

 On Monday, 17 January 2022 at 22:19:51 UTC, H. S. Teoh wrote:

 That said, if an automatic formatter works for you, why not 
 give dfmt a spin?  Don't be intimidated by the "beta" label 
 (what does that even mean anyway); try it out and see if it's 
 really as bad as you imagine it to be.  You might be 
 pleasantly surprised.


 T


 I think it's because I'm experiencing 'the let-down' effect...

 the most recent one being: -profile=gc  (which isn't even 
 'beta').


 Bug Reports?


Mmmm...so they can sit there for the next 7 years? (like the 
existing ones).
Jan 17 2022
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Jan 17, 2022 at 11:04:08PM +0000, forkit via Digitalmars-d wrote:

 On Monday, 17 January 2022 at 22:37:06 UTC, max haughton wrote:

 On Monday, 17 January 2022 at 22:27:54 UTC, forkit wrote:




[...]

 the most recent one being: -profile=gc  (which isn't even 'beta').


 
 Bug Reports?


 
 Mmmm...so they can sit there for the next 7 years? (like the existing
 ones).


C'mon, it's not that bad. The ones that sit for a long time are usually
the ones that are harder to deal with / controversial in some way.

Besides, not filing them means the bugs will remain for ∞ years, which
is a lot worse than 7 years. ;-)


T

-- 
Just because you survived after you did it, doesn't mean it wasn't stupid!
Jan 17 2022
parent reply forkit <forkit gmail.com> writes:
On Monday, 17 January 2022 at 23:10:13 UTC, H. S. Teoh wrote:

 C'mon, it's not that bad. The ones that sit for a long time are 
 usually the ones that are harder to deal with / controversial 
 in some way.

 Besides, not filing them means the bugs will remain for ∞ 
 years, which is a lot worse than 7 years. ;-)


 T


'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?

In such situations, it's actually a lot easier, and even makes 
more sense, to just not use that feature ;-)
Jan 17 2022
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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
Jan 17 2022
next sibling parent forkit <forkit gmail.com> writes:
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.
Jan 17 2022
prev sibling parent reply forkit <forkit gmail.com> writes:
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
Jan 17 2022
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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?
Jan 17 2022
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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.
Jan 17 2022
next sibling parent reply max haughton <maxhaton gmail.com> writes:
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.
Jan 17 2022
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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.
Jan 17 2022
parent rikki cattermole <rikki cattermole.co.nz> writes:
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.
Jan 17 2022
prev sibling next sibling parent reply forkit <forkit gmail.com> writes:
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..
Jan 17 2022
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Jan 18, 2022 at 01:46:58AM +0000, forkit via Digitalmars-d wrote:
[...]

 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?


Of course it is.



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


For historical reasons, I wager.  The earliest versions of D did not
have templates nor ranges.  Neither was there  nogc.  And IIRC, there
wasn't core.memory.GC either, or maybe it was there but not with the
entire API that we have today, I'm not sure.  At any rate, at the point
where -profile=gc was implemented I believe built-in constructs *were*
the only constructs to GC-allocate.  So it worked well at that time.

Since then, many things have changed, and it looks like -profile=gc has
bitrotted to its present sorry state.



 And more to the point, excluded from considering adding it to this
 feature, for 7 years now.
 
 I don't get it.


[...]

The problem with programming language design is that the design space is
exponential in the number of features. Every new feature added, every
language changed introduced, produces a ripple effect that percolates
throughout the language in exponentially-many combinations that are
impossible to exhaustively test.  So it's pretty much inevitable that
some combinations of features will be poorly-tested or not tested at
all.

On top of that, most bugs occur around boundary cases, and generally
people who have been using older versions of the language are less
likely to encounter these boundary cases, because they have become
habituated to older, well-worn idioms. So they're less likely to notice
these corner cases. Newcomers tend to find them more easily, though,
because they haven't acquired the old habits. (Which is another reason
it's important to file bugs: old-timers are less likely to encounter
these bugs again and fix them.)

That, and old-timers tend to know their way around better, and upon
encountering problems would resort to workarounds, avoiding the problem
feature, so the problems can linger.


None of this excuses the present sorry state of things, of course. My
inclination is to pull the trigger on -profile and -profile=gc. Or at
the very very least, put a big fat warning in flashing bold red letters
in the docs of the latter so that newcomers don't fall for it.


T

-- 
Bomb technician: If I'm running, try to keep up.
Jan 17 2022
parent reply forkit <forkit gmail.com> writes:
On Tuesday, 18 January 2022 at 03:39:10 UTC, H. S. Teoh wrote:

 None of this excuses the present sorry state of things, of 
 course. My inclination is to pull the trigger on -profile and 
 -profile=gc. Or at the very very least, put a big fat warning 
 in flashing bold red letters in the docs of the latter so that 
 newcomers don't fall for it.


 T


../druntime/src/rt/profilegc.d

from:
  fprintf(fp, "bytes allocated, allocations, type, function, 
file:line\n");

to:
  char[] WARNING = "-profile=gc is presently in a sorry state. You 
should consider not even using it."
  fprintf(fp, "%s\nbytes allocated, allocations, type, function, 
file:line\n", WARNING);
Jan 17 2022
parent forkit <forkit gmail.com> writes:
On Tuesday, 18 January 2022 at 04:05:05 UTC, forkit wrote:

 ../druntime/src/rt/profilegc.d

 from:
  fprintf(fp, "bytes allocated, allocations, type, function, 
 file:line\n");

 to:
  char[] WARNING = "-profile=gc is presently in a sorry state. 
 You should consider not even using it."
  fprintf(fp, "%s\nbytes allocated, allocations, type, function, 
 file:line\n", WARNING);


oops...should be:

const char *WARNING = "-profile=gc is presently in a sorry state. 
You should consider not even using it.";
             fprintf(fp, "%s\nbytes allocated, allocations, type, 
function, file:line\n", WARNING);
Jan 17 2022
prev sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 1/17/22 8:23 PM, H. S. Teoh wrote:


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


Something like that might still be of help. At least it wouldn't lie and 
say *no allocations* happened.

But can't we just tag with a UDA a GC allocating function, and then the 
highest-level tag is registered with the profiler? Like:

```d
 gcprofile void bar()
{
    auto x = new int; // not flagged as allocating.
}

 gcprofile void foo()
{
    bar(); // not flagged as allocating.
}

void main()
{
    foo(); // flagged as allocating.
    bar(); // flagged as allocating.
}
```
-Steve
Jan 18 2022
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Jan 17, 2022 at 05:23:26PM -0800, H. S. Teoh via Digitalmars-d wrote:
[...]

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


[...]

Outlined a few possible approaches to fix this here:

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

I'm not sure I have the compiler chops to actually fix this myself,
though.  This is a little beyond my level of familiarity with dmd code.
Would be nice if somebody picked this up.

Also, druntime/src/rt/profilegc.d seriously needs to be fixed to
*always* write to the file profilegc.txt when compiled with -profile=gc
(https://issues.dlang.org/show_bug.cgi?id=19601). Added a note there
also re: possible fixes.


T

-- 
It is impossible to make anything foolproof because fools are so ingenious. --
Sammy
Jan 18 2022
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Jan 18, 2022 at 07:37:42AM -0800, H. S. Teoh via Digitalmars-d wrote:
[...]

 Outlined a few possible approaches to fix this here:
 
 	https://issues.dlang.org/show_bug.cgi?id=14892#c1
 
 I'm not sure I have the compiler chops to actually fix this myself,
 though.  This is a little beyond my level of familiarity with dmd
 code.  Would be nice if somebody picked this up.


[...]

OK, so to *completely* fix this may be a little beyond me, but a partial
fix that at least covers std.array.array was within reach.  So I changed
dmd to set a new predefined version D_ProfileGC, extended rt/tracegc.d
to wrap the specific druntime call std.array.array uses, and modified
Phobos to call the wrapped function instead when version=D_ProfileGC.

With these changes, I successfully got -profile=gc to detect allocations
from std.array.array!

However, this fix is not complete yet, because currently profilegc.txt
shows the allocation coming from some obscure line deep inside Phobos
internals, which is very user-unfriendly. It will take a bit more work
to properly propagate file/line/function information from user code down
to the point of allocation.


T

-- 
English is useful because it is a mess. Since English is a mess, it maps well
onto the problem space, which is also a mess, which we call reality. Similarly,
Perl was designed to be a mess, though in the nicest of all possible ways. --
Larry Wall
Jan 18 2022
parent reply H. S. Teoh <hsteoh quickfur.ath.cx> writes:
On Tuesday, 18 January 2022 at 17:12:35 UTC, H. S. Teoh wrote:

 On Tue, Jan 18, 2022 at 07:37:42AM -0800, H. S. Teoh via 
 Digitalmars-d wrote: [...]

 Outlined a few possible approaches to fix this here:
 
 	https://issues.dlang.org/show_bug.cgi?id=14892#c1
 
 I'm not sure I have the compiler chops to actually fix this 
 myself, though.  This is a little beyond my level of 
 familiarity with dmd code.  Would be nice if somebody picked 
 this up.


 [...]

 OK, so to *completely* fix this may be a little beyond me, but 
 a partial fix that at least covers std.array.array was within 
 reach.


[...]

I surprise myself sometimes.  I've managed to ferret out enough 
of the -profile=gc implementation that I now have a fix that 
covers allocations via core.memory.GC.* as well:

     https://github.com/dlang/druntime/pull/3691

So essentially, this fixes the entire bug.  Well, almost:

1) It still doesn't cover direct calls to the C API `gc_malloc`, 
but I'm just gonna pretend for now that that doesn't exist, 
because normal D code is supposed to call the GC via 
core.memory.GC instead of invoking the C API directly.  (I 
suppose this could be documented, though. Maybe I'll post a doc 
PR for that.)

2) GC API allocations inside Phobos will show up as some obscure 
internal private Phobos function, which is probably unhelpful in 
determining where in the user's code the allocation happened. 
This part is tricky to fix without adding runtime penalties when 
not compiling with -profile=gc, so I'm reluctant to touch this at 
the moment.  But anyway, I see that as a further enhancement 
request; the core issue in 14892 is essentially fixed by the 
above PR and my previous PRs which have already been merged.


--T
Jan 19 2022
parent M.M. <matus email.cz> writes:
On Wednesday, 19 January 2022 at 19:42:23 UTC, H. S. Teoh wrote:

 On Tuesday, 18 January 2022 at 17:12:35 UTC, H. S. Teoh wrote:

 [...]


 [...]

 I surprise myself sometimes.  I've managed to ferret out enough 
 of the -profile=gc implementation that I now have a fix that 
 covers allocations via core.memory.GC.* as well:

 [...]


nice... that's live bugfixing
Jan 19 2022
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Monday, 17 January 2022 at 23:42:50 UTC, forkit wrote:


 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?


Razvan Nitu was hired as a PR/Issue manager last year precisely 
to bring some method to our bug fixing madness. Prior to that, 
bugs were fixed by anyone who took an interest in them. If no one 
did, they didn't get fixed.

In the year+ since he took on the role, Razvan has assembled 
strike teams for the major repositories. Together, they have 
trimmed the PR queues and begun to make a dent on the Bugzilla 
database.

There are still old issues there, yes, and many of them will 
still remain there for quite a while longer. It takes time to go 
through such a big backlog. But new issues have a better chance 
of getting fixed sooner now.  The second PR/Issue manager 
position is being filled soon, which will bring another pair of 
paid eyes and hands to bear on Bugzilla.

That said, some issues will still linger because there isn't an 
obvious way to fix them, or they're judged a lower priority, or 
for whatever reason. They may be forgotten. Posting about a 
specific issue here in the forums is one way to do bring 
attention to it. Another is to tweet about it with the #dlang 
hashtag. Anytime I see something like that, I email Razvan about 
it to see if he can do something about it or find someone who 
can. Usually, they get closed in a few days.

My point: issues that aren't reported aren't fixed, and those 
that are reported have a better chance of getting fixed sooner 
these days than they used to.

I've never believed that "it might stay there for 7 years" is a 
valid reason to avoid reporting a bug, but it's even less so now.

Please report your issues. And if they aren't fixed in a 
reasonable amount of time, shout about them to bring attention to 
them. Even with the increase in manpower Symmetry's sponsorship 
has brought us, D is still a community effort. Reporting an 
issue, then reminding people it's there, is one of the simplest 
ways to contribute to that effort.
Jan 18 2022
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Although many have proposed it, we don't delete bugzilla issues just because 
they are old.


 issues that aren't reported aren't fixed


I want the emphasize that. Many times, people say this or that bug is not
fixed. 
I ask if it is in bugzilla, they say no. This is even from longtime community 
members.

Reporting bugs on the forums doesn't work, unless it is *also* reported on
bugzilla.

It's got to go into bugzilla.

For example, not too long ago, there were some major frustrations posted about 
the compiler's bad error messages. No examples were given, and no bugzilla 
entries had been posted. There's nothing anyone who wants to help can do about
that.
Jan 18 2022
next sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Tuesday, 18 January 2022 at 09:21:11 UTC, Walter Bright wrote:

 For example, not too long ago, there were some major 
 frustrations posted about the compiler's bad error messages. No 
 examples were given, and no bugzilla entries had been posted. 
 There's nothing anyone who wants to help can do about that.


If you actually used D for any real work, you wouldn't need a 
bugzilla issue to know the error messages are really bad.
Jan 18 2022
next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 18 January 2022 at 12:58:17 UTC, Adam D Ruppe wrote:

 On Tuesday, 18 January 2022 at 09:21:11 UTC, Walter Bright 
 wrote:

 For example, not too long ago, there were some major 
 frustrations posted about the compiler's bad error messages. 
 No examples were given, and no bugzilla entries had been 
 posted. There's nothing anyone who wants to help can do about 
 that.


 If you actually used D for any real work, you wouldn't need a 
 bugzilla issue to know the error messages are really bad.


Walter: Please file bug reports about bad error messages so that 
they can get improved
Forum: But error messages are so bad.
Repeat
Jan 18 2022
parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Tuesday, 18 January 2022 at 14:18:15 UTC, jmh530 wrote:

 Walter: Please file bug reports about bad error messages so 
 that they can get improved
 Forum: But error messages are so bad.
 Repeat


Open issues reported by me (39) ranging from 2014-02-25 through 
2021-09-13

Specifically about error messages:

[diagnostic] Name suggest for override should only list virtual 
functions 	2019-08-23
Improve inferred attribute error message 	2021-08-16
[regression] opDispatch error disappears! 	2020-08-05
deprecation warning on reflection should be suppressed or at 
least suppressable 	2021-05-04


Fewer than half my reported bugs have ever been fixed. Of the old 
error message ones, two have been fixed: one from 2013 and one 
from 2021.... only because I did it myself.

Bugzilla has plenty of issues in it.
Jan 18 2022
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/18/2022 7:47 AM, Adam D Ruppe wrote:

 Fewer than half my reported bugs have ever been fixed. Of the old error
message 
 ones, two have been fixed: one from 2013 and one from 2021.... only because I 
 did it myself.


I fix plenty of bugs that I filed myself :-)



 Bugzilla has plenty of issues in it.


Bugzilla has lots of issues. Please don't make us guess what you're referring 
to. If you want to bring up a specific issue here, please provide a link.
Jan 18 2022
parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Tuesday, 18 January 2022 at 19:39:11 UTC, Walter Bright wrote:

 Please don't make us guess what you're referring to. If you 
 want to bring up a specific issue here, please provide a link.


I gave titles there, the search ought to find the link instantly.

But, ok, here's a few more:

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

*12 years old*

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

*10 years old*

Both of those are examples of where the compiler just vomits 
irrelevant messages. If you know the compiler already, the first 
message is actually useful enough - you know to look at the first 
one and the line it gives or the one immediately before.

But it still could just do something better.

And here's another big one:

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

*11 years old*

And hey, look, a comment I left there two years ago - often, when 
I go to put it in bugzilla and find something already there, I'll 
comment instead of making a duplicate.

Those first ones are fairly minor, I've gotten used to them and 
they only take a few seconds. But that brace mismatch one 
actually eats a *significant* amount of time every time it 
happens.

At least the overload and template constraint messages have 
gotten better recently though they're still pretty bad. And those 
opDispatch messages are so unbelievably bad it sometimes doesn't 
even issue them and just generates invalid code instead! 
<https://issues.dlang.org/show_bug.cgi?id=20808> (2 years old - 
and it worked before that, hence why it is a regression) But even 
when it does issue an error, it is just "no such property" which 
is well-known.

Or the new attributes issue errors at the wrong place 
<https://issues.dlang.org/show_bug.cgi?id=17374> (5 years old!) 
making using them with inferred templates much harder than it 
needs to be.

And it isn't just me getting these - error messages come up a lot 
in new user support.
Jan 18 2022
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Thanks for providing examples.
Jan 19 2022
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/18/2022 1:37 PM, Adam D Ruppe wrote:

 https://issues.dlang.org/show_bug.cgi?id=8102
 
 *10 years old*


This was fixed a while ago.
Jan 19 2022
next sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Wednesday, 19 January 2022 at 19:45:40 UTC, Walter Bright 
wrote:

 On 1/18/2022 1:37 PM, Adam D Ruppe wrote:

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


 This was fixed a while ago.


Apparently *very* recently, since the error message is still 
broken in v2.098.

I do see the new thing in git master though.


 dlang-bot
dlang-bot committed 5 days ago

There it is.

Well, better late than never.

thanks!
Jan 19 2022
next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 19 January 2022 at 20:35:18 UTC, Adam D Ruppe wrote:

 [snip]

 There it is.

 Well, better late than never.

 thanks!


Yeah, that's one I've been hit by too. Thanks for bringing some 
attention on these.
Jan 19 2022
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Jan 19, 2022 at 09:06:33PM +0000, jmh530 via Digitalmars-d wrote:
[...]

 Yeah, that's one I've been hit by too. Thanks for bringing some
 attention on these.


This thread has done a lot of good in bringing attention to bugs that
have been bothering people. We should do this more often.

(1) File all the bugs you find.
(2) If a bug is being neglected, complain about it on the forums until
somebody takes action.


T

-- 
Today's society is one of specialization: as you grow, you learn more and more
about less and less. Eventually, you know everything about nothing.
Jan 19 2022
parent reply forkit <forkit gmail.com> writes:
On Wednesday, 19 January 2022 at 21:17:40 UTC, H. S. Teoh wrote:

 On Wed, Jan 19, 2022 at 09:06:33PM +0000, jmh530 via 
 Digitalmars-d wrote: [...]

 Yeah, that's one I've been hit by too. Thanks for bringing 
 some attention on these.


 This thread has done a lot of good in bringing attention to 
 bugs that have been bothering people. We should do this more 
 often.

 (1) File all the bugs you find.
 (2) If a bug is being neglected, complain about it on the 
 forums until
 somebody takes action.


 T


If that's what it takes to get a bug actioned, we really do need 
a separate section under Community -> NeglectedBugComplaints

btw. thanks for your great efforts with this -profile=gc issue, 
really appreciated :-)
Jan 19 2022
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Jan 19, 2022 at 09:33:23PM +0000, forkit via Digitalmars-d wrote:

 On Wednesday, 19 January 2022 at 21:17:40 UTC, H. S. Teoh wrote:


[...]

 (1) File all the bugs you find.
 (2) If a bug is being neglected, complain about it on the forums
 until somebody takes action.




[...]

 If that's what it takes to get a bug actioned, we really do need a
 separate section under Community -> NeglectedBugComplaints


Nah, you don't want to do that.  Once bug complaints are shuffled off to
their own corner, people start ignoring that corner and we wind up back
where we started. :-P



 btw. thanks for your great efforts with this -profile=gc issue, really
 appreciated :-)


Spoiler: I'm just another random D user with a bit of spare time. *You*
can probably contribute to fixing bugs in D too.[*] If everyone would
take action instead of waiting around for somebody else to do it, we'd
probably be in a better place today.

([*] If you have a working knowledge of D, you probably know enough to
be able to fix bugs in druntime or Phobos. Or even implement a new
feature or two.  IME, they are orders of magnitude more readable than
the majority of standard libraries out there (I tried reading glibc
source code once -- never again!).  DMD is a little trickier, depending
on where a problem is, but it's still a more pleasant experience than,
say, firefox source code or something.  Or, God forbid, gcc. That one I
don't even dare touch with a 50-foot pole.)


T

-- 
I think Debian's doing something wrong, `apt-get install pesticide', doesn't
seem to remove the bugs on my system! -- Mike Dresser
Jan 19 2022
parent reply forkit <forkit gmail.com> writes:
On Wednesday, 19 January 2022 at 22:15:49 UTC, H. S. Teoh wrote:

 Spoiler: I'm just another random D user with a bit of spare 
 time. *You* can probably contribute to fixing bugs in D too.[*] 
 If everyone would take action instead of waiting around for 
 somebody else to do it, we'd probably be in a better place 
 today.


My contribution to D, will be almost certainly be limited to 
using D ;-)

contributing to fixing bugs should never be a prerequiste for 
using D.

having said that, I understand it's an ongoing community project, 
so if I can, I certainly will (but at the moment I'm focused on 
using it, not fixing bugs).
Jan 19 2022
next sibling parent forkit <forkit gmail.com> writes:
On Wednesday, 19 January 2022 at 22:31:33 UTC, forkit wrote:


oh. actually.. I am focused on fixing bugs too, but the bugs in 
my own code.. due to not yet understanding many aspects of D...

that's taking up enough of my time ;-)



 Jan 19 2022



prev sibling next sibling parent reply Bastiaan Veelo <Bastiaan Veelo.net>  writes:


On Wednesday, 19 January 2022 at 22:31:33 UTC, forkit wrote:

 On Wednesday, 19 January 2022 at 22:15:49 UTC, H. S. Teoh wrote:

 Spoiler: I'm just another random D user with a bit of spare 
 time. *You* can probably contribute to fixing bugs in D 
 too.[*] If everyone would take action instead of waiting 
 around for somebody else to do it, we'd probably be in a 
 better place today.


 My contribution to D, will be almost certainly be limited to 
 using D ;-)


I like how the bar for contributing is made really really low. 
With the “Improve this page” link that exist on every page of the 
documentation, editing is almost as easy as on a wiki. I’m not a 
wizard but I can spot a typo or a dead link, and it is fun to fix 
those right away. These fixes also get merged quickly (the review 
is easy). And once you are in the source code you can’t help but 
look at the implementation, and notice how readable most of it 
is, really. It is nice to have a few of those trivial fixes under 
my belt, because now I know the process and thus it is a little 
more likely that I might contribute more materially, some day.

— Bastiaan.



 Jan 19 2022



  parent  forkit <forkit gmail.com>  writes:


On Wednesday, 19 January 2022 at 22:59:03 UTC, Bastiaan Veelo 
wrote:

 I like how the bar for contributing is made really really low. 
 With the “Improve this page” link that exist on every page of 
 the documentation, editing is almost as easy as on a wiki....


you know, I never noticed that:

	'Report a bug' 'Improve this page'

Thanks for pointing that out ;-)



 Jan 19 2022



prev sibling  parent  "H. S. Teoh" <hsteoh quickfur.ath.cx>  writes:


On Wed, Jan 19, 2022 at 10:31:33PM +0000, forkit via Digitalmars-d wrote:

 On Wednesday, 19 January 2022 at 22:15:49 UTC, H. S. Teoh wrote:

 
 Spoiler: I'm just another random D user with a bit of spare time.
 *You* can probably contribute to fixing bugs in D too.[*] If
 everyone would take action instead of waiting around for somebody
 else to do it, we'd probably be in a better place today.
 


 
 My contribution to D, will be almost certainly be limited to using D
 ;-)
 
 contributing to fixing bugs should never be a prerequiste for using D.


[...]

Never said it was a prerequisite.  Rather, it's a way to take control
and fix problems yourself, and in the process benefit other D users as
well. As opposed to, y'know, begging or hoping that the Powers That Be
would take notice of your plight and condescend to make your life a
little better -- the way things are when dealing with proprietary
software.

No one *has* to, of course.  But all I'm saying is, you *can*.


T

-- 
He who laughs last thinks slowest.



 Jan 19 2022



prev sibling  parent  Ben Jones <fake fake.fake>  writes:


On Wednesday, 19 January 2022 at 20:35:18 UTC, Adam D Ruppe wrote:


Probably needs some improvements, but here's a start for fixing 


https://github.com/dlang/dmd/pull/13552



 Jan 19 2022



prev sibling  parent  forkit <forkit gmail.com>  writes:


On Wednesday, 19 January 2022 at 19:45:40 UTC, Walter Bright 
wrote:

 On 1/18/2022 1:37 PM, Adam D Ruppe wrote:

 https://issues.dlang.org/show_bug.cgi?id=8102
 
 *10 years old*


 This was fixed a while ago.


Thanks for your ongoing efforts too :-)



 Jan 19 2022



prev sibling next sibling parent reply bachmeier <no spam.net>  writes:


On Tuesday, 18 January 2022 at 12:58:17 UTC, Adam D Ruppe wrote:

 On Tuesday, 18 January 2022 at 09:21:11 UTC, Walter Bright 
 wrote:

 For example, not too long ago, there were some major 
 frustrations posted about the compiler's bad error messages. 
 No examples were given, and no bugzilla entries had been 
 posted. There's nothing anyone who wants to help can do about 
 that.


 If you actually used D for any real work, you wouldn't need a 
 bugzilla issue to know the error messages are really bad.


I'm inclined to say there's a lower standard for error messages 
if you're the one that wrote the compiler.



 Jan 18 2022



  parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx>  writes:


On Tue, Jan 18, 2022 at 03:32:14PM +0000, bachmeier via Digitalmars-d wrote:

 On Tuesday, 18 January 2022 at 12:58:17 UTC, Adam D Ruppe wrote:

 On Tuesday, 18 January 2022 at 09:21:11 UTC, Walter Bright wrote:

 For example, not too long ago, there were some major frustrations
 posted about the compiler's bad error messages. No examples were
 given, and no bugzilla entries had been posted. There's nothing
 anyone who wants to help can do about that.


 
 If you actually used D for any real work, you wouldn't need a
 bugzilla issue to know the error messages are really bad.


 
 I'm inclined to say there's a lower standard for error messages if
 you're the one that wrote the compiler.


It's the familiarity syndrome.  If you're the one who wrote the
compiler, you already have a deep understanding of how it works
internally, and that understanding colors your perception of the error
mesage.  However, someone who *didn't* write the compiler has no idea
where the compiler is coming from, so to speak, and so what's obvious to
you may be completely opaque to him.

Familiarity also biases you, so that you fail to see flaws that are
obvious to everyone else, because you have been acclimatized to expect
certain things and unconsciously assume they are there even when they're
actually missing.  Just like how spectators to a chess game often notice
things that the heavily-invested players may miss, because they're too
focused on seeing the game from one particular viewpoint and thus may
neglect some other aspect.


T

-- 
Never trust an operating system you don't have source for! -- Martin Schulze



 Jan 18 2022



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 1/18/2022 7:45 AM, H. S. Teoh wrote:

 It's the familiarity syndrome.  If you're the one who wrote the
 compiler, you already have a deep understanding of how it works
 internally, and that understanding colors your perception of the error
 mesage.  However, someone who *didn't* write the compiler has no idea
 where the compiler is coming from, so to speak, and so what's obvious to
 you may be completely opaque to him.
 
 Familiarity also biases you, so that you fail to see flaws that are
 obvious to everyone else, because you have been acclimatized to expect
 certain things and unconsciously assume they are there even when they're
 actually missing.  Just like how spectators to a chess game often notice
 things that the heavily-invested players may miss, because they're too
 focused on seeing the game from one particular viewpoint and thus may
 neglect some other aspect.



You're right, and that's *exactly* why bugzilla issues need to be filed, along 
with sample code.

I cannot read other peoples' minds.



 Jan 18 2022



prev sibling  parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 1/18/2022 4:58 AM, Adam D Ruppe wrote:

 If you actually used D for any real work, you wouldn't need a bugzilla issue
to 
 know the error messages are really bad.


"Everybody knows" is not a substitute for putting issues on bugzilla. Besides, 
dmd has what, 500 error messages? Guessing which one is somebody else's issue
is 
not a productive use of time. Guessing what code they had that triggered the 
message is also a complete waste of time. I can't read anybody's mind.

P.S. I use D for real work, every day.



 Jan 18 2022



prev sibling  parent reply SealabJaster <sealabjaster gmail.com>  writes:


On Tuesday, 18 January 2022 at 09:21:11 UTC, Walter Bright wrote:

 ...


For what it's worth I did try to help out with getting better 
error messages, but the PR seems to have stalled for reasons 
beyond me: https://github.com/dlang/dmd/pull/12526



 Jan 18 2022



  parent  "H. S. Teoh" <hsteoh quickfur.ath.cx>  writes:


On Tue, Jan 18, 2022 at 04:40:11PM +0000, SealabJaster via Digitalmars-d wrote:

 On Tuesday, 18 January 2022 at 09:21:11 UTC, Walter Bright wrote:

 ...


 
 For what it's worth I did try to help out with getting better error
 messages, but the PR seems to have stalled for reasons beyond me:
 https://github.com/dlang/dmd/pull/12526


Took a quick look, apparently there's one pending change requested by
Iain?  Maybe ping him to review this to see if it's resolved?

Also, autotester is failing. Should probably look into that, or explain
why it's not relevant.


T

-- 
My father told me I wasn't at all afraid of hard work. I could lie down right
next to it and go to sleep. -- Walter Bright



 Jan 18 2022



prev sibling next sibling parent reply forkit <forkit gmail.com>  writes:


On Tuesday, 18 January 2022 at 08:42:17 UTC, Mike Parker wrote:

 I've never believed that "it might stay there for 7 years" is a 
 valid reason to avoid reporting a bug, but it's even less so 
 now.

 Please report your issues. And if they aren't fixed in a 
 reasonable amount of time, shout about them to bring attention 
 to them. Even with the increase in manpower Symmetry's 
 sponsorship has brought us, D is still a community effort. 
 Reporting an issue, then reminding people it's there, is one of 
 the simplest ways to contribute to that effort.


Well it's not that it 'might' stay there for 7 years, it's that 
it 'has' stayed there for 7 years:

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

I'd just be reporting the same thing... so not much point.

I got know idea whatsoever on how to fix it. If I did, I'd do it.

The best I could work out, was how to add a warning into the 
header of the profilegc.log stating how completely useless it is 
;-)

My real point, is that -profile=gc seems like such a useful 
tool...how could it not get anyones attention, after 7 years??

I presume nobody uses it, because they know about this issue ??

But as soon as newcomers arrive, use it, expecting it to what it 
says it does, they soom fine out it's completely useless too, and 
everyone has known for 7 years...so now the newcomer stops using 
it.. ... and then the next newcomer comes along... and....

btw.  nogc is not an alternative as some have suggested.



 Jan 18 2022



  parent reply Mike Parker <aldacron gmail.com>  writes:


On Tuesday, 18 January 2022 at 09:52:43 UTC, forkit wrote:


 Well it's not that it 'might' stay there for 7 years, it's that 
 it 'has' stayed there for 7 years:

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

 I'd just be reporting the same thing... so not much point.


I thought you were talking about a new issue. In this case, you 
can add to the existing issue by leaving a comment about your use 
case. And then you can bring more attention to it by posting a 
link in the forums, as you now have done. And now H. S. Teoh has 
sumbitted a few PRs to fix it, most of which have already been 
merged. I've also emailed Razvan about it to make sure it's on 
his radar.


 My real point, is that -profile=gc seems like such a useful 
 tool...how could it not get anyones attention, after 7 years??

 I presume nobody uses it, because they know about this issue ??


Who knows? Maybe people have used it and didn't notice or 
encounter the problem, or maybe people really aren't using it. Or 
maybe people encountered it and just did nothing about it. It 
doesn't matter, really. What matters is that circumstances have 
led to the issue remaining open for 7 years and you have now 
encountered it. So in that situation the choice is to do nothing, 
in which case it remains unfixed longer, or do something, in 
which case it may well get fixed.

Happily, you've done something (brought attention to it) and it 
is being fixed. Thanks :-)



 Jan 18 2022



 next sibling parent  forkit <forkit gmail.com>  writes:


On Wednesday, 19 January 2022 at 03:11:26 UTC, Mike Parker wrote:

 Happily, you've done something (brought attention to it) and it 
 is being fixed. Thanks :-)


Well, it really does seem like a very useful tool, so it does 
surprise me that nobody has paid attention to it for 7 years.

In any case, better to fix than wait till the 
million-more-D-users you wanting to attract, discover it ;-)

I'd also suggest it is categorised wrongly.

IMO it's not an enhancement. It's a bug.

After all.. its:

-profile=gc

not

-profile=gc_some_but_not_others

Happy that it's getting attention though .. much appreciated.



 Jan 18 2022



prev sibling  parent  Walter Bright <newshound2 digitalmars.com>  writes:


I want to add that the age of a bug has no bearing on priority of fixing it.

The priority of a bug is some combination of (in no particular order):

1. number of users affected by the bug
2. is the bug preventing those users from getting work done
3. how costly the bug is to users
4. the time it takes to fix the bug
5. is the bug clearly specified and reproducible



 Jan 19 2022



prev sibling  parent reply matheus <matheus gmail.com>  writes:


On Tuesday, 18 January 2022 at 08:42:17 UTC, Mike Parker wrote:

 On Monday, 17 January 2022 at 23:42:50 UTC, forkit wrote:
 ...
 My point: issues that aren't reported aren't fixed, and those 
 that are reported have a better chance of getting fixed sooner 
 these days than they used to.

 Please report your issues...


Hi Parker,

First of all forkit excuse for hijacking your post, I was about 
to create a topic about this, but I decided to try here instead. 
I have this idea for awhile.

Wouldn't be possible to have a new Group in this "Forum" called 
"Bugs"? So instead of new users need to create an account just to 
file a bug on bugzilla, It only would be needed to post there, 
and someone would look around and set that (Via automation of 
course) to open o bug report on bugzilla through that post. Since 
this forum is pretty much an e-mail server I think this wouldn't 
be difficult to handle.

Why is that? There are a lot of developers asking for help 
testing their software, but every time is hassle to open 
different accounts in different places.

I think this idea would be pretty neat and easy to contribute and 
we could visit the topic later to ask for updates.

What do you think?

Matheus.



 Jan 18 2022



 next sibling parent reply Paul Backus <snarwin gmail.com>  writes:


On Wednesday, 19 January 2022 at 00:31:35 UTC, matheus wrote:

 Wouldn't be possible to have a new Group in this "Forum" called 
 "Bugs"? So instead of new users need to create an account just 
 to file a bug on bugzilla, It only would be needed to post 
 there, and someone would look around and set that (Via 
 automation of course) to open o bug report on bugzilla through 
 that post. Since this forum is pretty much an e-mail server I 
 think this wouldn't be difficult to handle.


There already is such a group:

https://forum.dlang.org/group/issues

However, it mostly just contains automated emails about bugzilla 
issues, so most people don't pay much attention to it.



 Jan 18 2022



  parent reply matheus <matheus gmail.com>  writes:


On Wednesday, 19 January 2022 at 00:59:27 UTC, Paul Backus wrote:

 On Wednesday, 19 January 2022 at 00:31:35 UTC, matheus wrote:

 Wouldn't be possible to have a new Group in this "Forum" 
 called "Bugs"? So instead of new users need to create an 
 account just to file a bug on bugzilla, It only would be 
 needed to post there, and someone would look around and set 
 that (Via automation of course) to open o bug report on 
 bugzilla through that post. Since this forum is pretty much an 
 e-mail server I think this wouldn't be difficult to handle.


 There already is such a group:

 https://forum.dlang.org/group/issues

 However, it mostly just contains automated emails about 
 bugzilla issues, so most people don't pay much attention to it.


Well I know about that Group, but I think it is just a mirror or 
generated from the Bugzilla issues. What I'm proposing is 
different. Like going from Here (Forum) to There (Bugzilla), 
"iff" it was marked or reviewed by someone.

Matheus.



 Jan 18 2022



  parent reply Paul Backus <snarwin gmail.com>  writes:


On Wednesday, 19 January 2022 at 01:13:05 UTC, matheus wrote:

 Well I know about that Group, but I think it is just a mirror 
 or generated from the Bugzilla issues. What I'm proposing is 
 different. Like going from Here (Forum) to There (Bugzilla), 
 "iff" it was marked or reviewed by someone.


Should the D Language Foundation expect a donation from you to 
fund this position of "someone"? :)

If reporting bugs on issues.dlang.org is too difficult, then we 
should make it easier. Adding a second place to report bugs, and 
requiring "someone" to do a bunch of extra work to keep the two 
in sync, is just going to make the situation worse.



 Jan 18 2022



  parent reply matheus <matheus gmail.com>  writes:


On Wednesday, 19 January 2022 at 02:16:41 UTC, Paul Backus wrote:

 On Wednesday, 19 January 2022 at 01:13:05 UTC, matheus wrote:

 Well I know about that Group, but I think it is just a mirror 
 or generated from the Bugzilla issues. What I'm proposing is 
 different. Like going from Here (Forum) to There (Bugzilla), 
 "iff" it was marked or reviewed by someone.


 Should the D Language Foundation expect a donation from you to 
 fund this position of "someone"? :)


Well looking over the Bugzilla, there is always "someone" 
checking and marking the issues as duplicated right? So there is 
always "someone" handling things anyway.

Now what I'm saying is NOT that "someone" here will have to 
analyze anything, just need to check if it's not a spam or some 
idiocy before the "BOT" collect the issue from the Forum to open 
there in the Bugzilla.


 If reporting bugs on issues.dlang.org is too difficult, then we 
 should make it easier.


I didn't say it was difficult, but there is a hassle to open 
account that maybe be used only once just to help pointing some 
problem which members over here are requiring to help the 
language.


 Adding a second place to report bugs, and requiring "someone" 
 to do a bunch of extra work to keep the two in sync, is just 
 going to make the situation worse.


I think you misunderstood me, there is no second place. The forum 
would be a shortcut and the the extra work is just to make sure 
the issue is valid (Not a spam or some kind of joke). I'm pretty 
sure that even in the Bugzilla "someone" need to filter things 
over there.

Again there is no syncing, you open the bug in the Forum and 
"someone" do a glance over it and check if it's not a joke/spam 
and just marked to be created on the Bugzilla.

Interesting enough that you even pointed about the "sync" since 
there is the "Group Issue" where the Bugzilla issues are opened 
here as well, why not have the opposite?

Matheus.



 Jan 18 2022



  parent  forkit <forkit gmail.com>  writes:


On Wednesday, 19 January 2022 at 02:45:44 UTC, matheus wrote:

 Again there is no syncing, you open the bug in the Forum and 
 "someone" do a glance over it and check if it's not a joke/spam 
 and just marked to be created on the Bugzilla.


I think it's certainly worthwhile to think about, having a 
feature that allows anonymous submission of a 'possible' bug, 
just through the forum (where someone on the forum is already 
logged in). This has the advantage of not 'requiring' that user 
to go off and find some website and create an account (although 
there is nothing stopping them from doing that).

The main advantage is that possible issues in a discussion don't 
get lost in that discussion just because there's no immediate, 
convenient way to raise the issue.

An issues once submitted anonmously (i.e. using forum login 
details), would need to be triaged by someone.

Either it is an a possible issue, in which case the person 
triaging it submits it as one, formally, or it's not an issue, in 
which case it's marked as such, or not enough info to decide, in 
which case it's left there, but marked as triagged, so people 
know it hasn't been ignored.

In essence, it's like 1st level helpdesk, whereas bugzilla is 
next level.



 Jan 18 2022



prev sibling  parent reply Mike Parker <aldacron gmail.com>  writes:


On Wednesday, 19 January 2022 at 00:31:35 UTC, matheus wrote:


 Wouldn't be possible to have a new Group in this "Forum" called 
 "Bugs"? So instead of new users need to create an account just 
 to file a bug on bugzilla, It only would be needed to post 
 there, and someone would look around and set that (Via 
 automation of course) to open o bug report on bugzilla through 
 that post. Since this forum is pretty much an e-mail server I 
 think this wouldn't be difficult to handle.

 Why is that? There are a lot of developers asking for help 
 testing their software, but every time is hassle to open 
 different accounts in different places.

 I think this idea would be pretty neat and easy to contribute 
 and we could visit the topic later to ask for updates.

 What do you think?


I'm not sure that would make anything better. We're looking into 
moving away from Bugzilla later this year and handling all of our 
issues on GitHub, so Bugzilla accounts will no longer be needed.

And we already have Razvan as PR/Issue manager. Part of his job 
is to triage new issues.  With a second person on the job to 
share the load, that should become more efficient.



 Jan 18 2022



  parent reply matheus <matheus gmail.com>  writes:


On Wednesday, 19 January 2022 at 02:59:08 UTC, Mike Parker wrote:

 ...
 I'm not sure that would make anything better. We're looking 
 into moving away from Bugzilla later this year and handling all 
 of our issues on GitHub, so Bugzilla accounts will no longer be 
 needed.


In any case, I think that having this feature to create an issue 
here on this Forum and later going through either Bugzilla or 
Github would be welcome.


 And we already have Razvan as PR/Issue manager. Part of his job 
 is to triage new issues.  With a second person on the job to 
 share the load, that should become more efficient.


Well if you don't mind my poor English, I could do this "job" FOR 
FREE, I mean handling the posts about "Bugs" on the Forum an 
analyze their merit to be created automatic on Bugzilla or later 
on Github.

If you're interested and think this can be done we could talk 
privately over e-mail, just reply how to reach you.

Matheus.



 Jan 19 2022



  parent  rikki cattermole <rikki cattermole.co.nz>  writes:


Its quite normal to get (fairly) new(-ish) users on many medias (forums, 
IRC, Discord ext.) and those that help will typically make bug reports 
for these people on their behalf.

So if there is someone keeping an eye on these different communications 
mediums, looking for bugs to file, that would be a huge help.

If that is a role that you would like to fill, jump in, you just gotta 
be everywhere looking ;)



 Jan 19 2022



prev sibling  parent reply Johan <j j.nl>  writes:


On Monday, 17 January 2022 at 22:19:51 UTC, H. S. Teoh wrote:

 (Yes I know some code formatters have tags to suppress 
 automatic formatting, etc., but seriously, why do I need to 
 explicitly ask the computer not to do something I didn't want 
 it to do in the first place?)


The way I use clang-format (default with the sublime plugin by 
llvm) is that it only reformats your selection or current line, 
and sometimes one extra line of context around it.
clang-format is indeed something I very much miss for D. 
Precisely this "only reformat this small fragment" functionality 
is extremely time saving.
Also in code review, you can simply comment "clang-format" and 
all is clear. No more discussions about formatting :)

-Johan



 Jan 17 2022



 next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx>  writes:


On Mon, Jan 17, 2022 at 10:33:02PM +0000, Johan via Digitalmars-d wrote:

 On Monday, 17 January 2022 at 22:19:51 UTC, H. S. Teoh wrote:

 
 (Yes I know some code formatters have tags to suppress automatic
 formatting, etc., but seriously, why do I need to explicitly ask the
 computer not to do something I didn't want it to do in the first
 place?)


 
 The way I use clang-format (default with the sublime plugin by llvm)
 is that it only reformats your selection or current line, and
 sometimes one extra line of context around it.


Ah, well that would be nice indeed. ;-)



 clang-format is indeed something I very much miss for D. Precisely
 this "only reformat this small fragment" functionality is extremely
 time saving.


Does dfmt not do this?



 Also in code review, you can simply comment "clang-format" and all is
 clear.  No more discussions about formatting :)


[...]

Point.  I remember when I used to be more active on the Phobos PR queue,
a sad amount of time was spent over formatting issues (the right amount
ought to be zero. :-D).


T

-- 
Genius may have its limitations, but stupidity is not thus handicapped. --
Elbert Hubbard



 Jan 17 2022



 next sibling parent reply rikki cattermole <rikki cattermole.co.nz>  writes:


On 18/01/2022 11:46 AM, H. S. Teoh wrote:

 clang-format is indeed something I very much miss for D. Precisely
 this "only reformat this small fragment" functionality is extremely
 time saving.


 Does dfmt not do this?


Doesn't appear to.

Keep in mind it uses libdparse to actually ya know, parse the code.

So a small fragment probably wouldn't format properly beyond some basic 
rules anyway.



 Jan 17 2022



  parent reply deadalnix <deadalnix gmail.com>  writes:


On Tuesday, 18 January 2022 at 01:59:25 UTC, rikki cattermole 
wrote:

 On 18/01/2022 11:46 AM, H. S. Teoh wrote:

 clang-format is indeed something I very much miss for D. 
 Precisely
 this "only reformat this small fragment" functionality is 
 extremely
 time saving.


 Does dfmt not do this?


 Doesn't appear to.

 Keep in mind it uses libdparse to actually ya know, parse the 
 code.

 So a small fragment probably wouldn't format properly beyond 
 some basic rules anyway.


This approach is fundamentally flawed, as keeping all the info 
you need through an AST is pretty much impossible.

Modern formatter, such as clang-format, use a parser, but the 
parser generates an IR that as nothing to do with the traditional 
AST you'd get out of a regular parser.

To get an idea of what these IR looks like: 
http://journal.stuffwithstuff.com/2015/09/08/the-hardest-program-ive-ever-written/



 Jan 17 2022



 next sibling parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 1/17/2022 6:06 PM, deadalnix wrote:

 Modern formatter, such as clang-format, use a parser, but the parser generates 
 an IR that as nothing to do with the traditional AST you'd get out of a
regular 
 parser.


What comes to mind is what to do with the comments.



 Jan 17 2022



 next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx>  writes:


On Mon, Jan 17, 2022 at 07:30:53PM -0800, Walter Bright via Digitalmars-d wrote:

 On 1/17/2022 6:06 PM, deadalnix wrote:

 Modern formatter, such as clang-format, use a parser, but the parser
 generates an IR that as nothing to do with the traditional AST you'd
 get out of a regular parser.


 
 What comes to mind is what to do with the comments.


They should be explicitly represented. Ignored by the part that deals
with language grammar, but remain in place to be accounted for during
formatting.


T

-- 
Verbing weirds language. -- Calvin (& Hobbes)



 Jan 17 2022



  parent  deadalnix <deadalnix gmail.com>  writes:


On Tuesday, 18 January 2022 at 05:47:29 UTC, H. S. Teoh wrote:

 On Mon, Jan 17, 2022 at 07:30:53PM -0800, Walter Bright via 
 Digitalmars-d wrote:

 On 1/17/2022 6:06 PM, deadalnix wrote:

 Modern formatter, such as clang-format, use a parser, but 
 the parser generates an IR that as nothing to do with the 
 traditional AST you'd get out of a regular parser.


 
 What comes to mind is what to do with the comments.


 They should be explicitly represented. Ignored by the part that 
 deals with language grammar, but remain in place to be 
 accounted for during formatting.


 T


Yes, but it's not that simple. See for instance.

int a; // This is an int.
int b;

vs

int a;
// This is an int.
int b;

We understand the comment to be attached to a in the first case, 
while we understand it is attached to b in the second.



 Jan 18 2022



prev sibling next sibling parent reply user1234 <user1234 12.de>  writes:


On Tuesday, 18 January 2022 at 03:30:53 UTC, Walter Bright wrote:

 On 1/17/2022 6:06 PM, deadalnix wrote:

 Modern formatter, such as clang-format, use a parser, but the 
 parser generates an IR that as nothing to do with the 
 traditional AST you'd get out of a regular parser.


 What comes to mind is what to do with the comments.


They must be kept, which is what dfmt does as it follows the 
token stream and *not* the AST.



 Jan 18 2022



  parent reply deadalnix <deadalnix gmail.com>  writes:


On Tuesday, 18 January 2022 at 08:36:18 UTC, user1234 wrote:

 On Tuesday, 18 January 2022 at 03:30:53 UTC, Walter Bright 
 wrote:

 On 1/17/2022 6:06 PM, deadalnix wrote:

 Modern formatter, such as clang-format, use a parser, but the 
 parser generates an IR that as nothing to do with the 
 traditional AST you'd get out of a regular parser.


 What comes to mind is what to do with the comments.


 They must be kept, which is what dfmt does as it follows the 
 token stream and *not* the AST.


See 
https://forum.dlang.org/post/givmbzmvnjnweozrexgm forum.dlang.org



 Jan 18 2022



  parent reply user1234 <user1234 12.de>  writes:


On Tuesday, 18 January 2022 at 12:51:33 UTC, deadalnix wrote:

 On Tuesday, 18 January 2022 at 08:36:18 UTC, user1234 wrote:

 On Tuesday, 18 January 2022 at 03:30:53 UTC, Walter Bright 
 wrote:

 On 1/17/2022 6:06 PM, deadalnix wrote:

 Modern formatter, such as clang-format, use a parser, but 
 the parser generates an IR that as nothing to do with the 
 traditional AST you'd get out of a regular parser.


 What comes to mind is what to do with the comments.


 They must be kept, which is what dfmt does as it follows the 
 token stream and *not* the AST.


 See 
 https://forum.dlang.org/post/givmbzmvnjnweozrexgm forum.dlang.org


yeah dfmt does works like I say 
https://github.com/dlang-community/dfmt/blob/master/src/dfmt/formatter.d.



 Jan 18 2022



  parent  user1234 <user1234 12.de>  writes:


On Tuesday, 18 January 2022 at 17:09:46 UTC, user1234 wrote:

 On Tuesday, 18 January 2022 at 12:51:33 UTC, deadalnix wrote:

 On Tuesday, 18 January 2022 at 08:36:18 UTC, user1234 wrote:

 On Tuesday, 18 January 2022 at 03:30:53 UTC, Walter Bright 
 wrote:

 On 1/17/2022 6:06 PM, deadalnix wrote:

 Modern formatter, such as clang-format, use a parser, but 
 the parser generates an IR that as nothing to do with the 
 traditional AST you'd get out of a regular parser.


 What comes to mind is what to do with the comments.


 They must be kept, which is what dfmt does as it follows the 
 token stream and *not* the AST.


 See 
 https://forum.dlang.org/post/givmbzmvnjnweozrexgm forum.dlang.org


 yeah dfmt does works like I say 
 https://github.com/dlang-community/dfmt/blob/master/src/dfmt/formatter.d.


It's certainly not an AST walker ;)



 Jan 18 2022



prev sibling  parent  deadalnix <deadalnix gmail.com>  writes:


On Tuesday, 18 January 2022 at 03:30:53 UTC, Walter Bright wrote:

 On 1/17/2022 6:06 PM, deadalnix wrote:

 Modern formatter, such as clang-format, use a parser, but the 
 parser generates an IR that as nothing to do with the 
 traditional AST you'd get out of a regular parser.


 What comes to mind is what to do with the comments.


Yes, this is the most obvious ones, but then you have, what to do 
with whitespaces? There is a ton of semantic conveyed in 
whitespace, for instance, one new line or two new lines? It gets 
worse when you want to add features such as "don't format that 
specific chunk of code" because now you need ot be able to encode 
EVERYTHING in the AST, and it gets very teddious.



 Jan 18 2022



prev sibling  parent  Rumbu <rumbu rumbu.ro>  writes:


On Tuesday, 18 January 2022 at 02:06:01 UTC, deadalnix wrote:

 This approach is fundamentally flawed, as keeping all the info 
 you need through an AST is pretty much impossible.


It is not impossible. Roslyn has a SyntaxTree build dynamically 
(on expand) which includes every character in the source code (as 
slices). This tree allows operations on source code as formatting 
or code refactoring.

In parallel, it has a SemanticModel tree which is built 
separately stripped of any irellevant information for the 
semantic analysis. This tree is used to emit CIL code or enabling 
features like edit and continue.

Both trees use as backstore a minimal AST (green nodes) which is 
dynamically regenerated and its nodes reused on any text change.



 Jan 18 2022



prev sibling  parent  rikki cattermole <rikki cattermole.co.nz>  writes:


On 18/01/2022 11:46 AM, H. S. Teoh wrote:

 Point.  I remember when I used to be more active on the Phobos PR queue,
 a sad amount of time was spent over formatting issues (the right amount
 ought to be zero. :-D).


I totally agree with this.

When it comes to PR's into a repo of any given size, they should all be 
run through a formatter automatically.

No exclusions, just automatic, either the output is right or needs to be 
sanified, or with local disabling of formatting.



 Jan 17 2022



prev sibling  parent  forkit <forkit gmail.com>  writes:


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



 Jan 17 2022



prev sibling  parent reply deadalnix <deadalnix gmail.com>  writes:


On Monday, 17 January 2022 at 21:46:08 UTC, forkit wrote:

 So I use clang-format extensively...like all the time.

 It makes such a difference, I can't imagine programming without 
 it anymore.

 But D doesn't have something integrated like this.

 I am aware of dfmt.. but even on it's github page it says "dfmt 
 is beta quality."

 I wonder if it isn't time a code formatter for D became a more 
 integrated product, into the release itself, so that people 
 like me can actually rely on it to work as expected, and also, 
 so that the formatter's needs were considered whenever making 
 changes to D.

 Or is D code now so variable and complex, that no formatter can 
 reliably format it?


You might want to have a go at sdfmt.

1/ clone https://github.com/snazzy-d/SDC
2/ Go in it and make -j bin/sdfmt
3/ bin/sdfmt -i myfile

It is very much work in progress, but uses an approach similar to 
clang format (contrary to dfmt which IMO uses an approach that 
doesn't lend itself to get the same level of quality).

You'll almost certainly run into weird stuff, and I'd be happy to 
hear about them so they can get ironed out.



 Jan 17 2022



  parent  Johan <j j.nl>  writes:


On Tuesday, 18 January 2022 at 02:03:32 UTC, deadalnix wrote:

 You might want to have a go at sdfmt.

 1/ clone https://github.com/snazzy-d/SDC
 2/ Go in it and make -j bin/sdfmt
 3/ bin/sdfmt -i myfile


This is great news! I have been very tempted to start create 
something myself, but it's much easier to contribute somewhere, 
thanks!


 It is very much work in progress, but uses an approach similar 
 to clang format (contrary to dfmt which IMO uses an approach 
 that doesn't lend itself to get the same level of quality).


+1

-Johan



 Jan 19 2022