January 19, 2022
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.


January 18, 2022

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:

@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

January 19, 2022
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.
January 20, 2022
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 ;)
January 19, 2022
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

January 19, 2022
Thanks for providing examples.
January 19, 2022
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
January 19, 2022
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.
January 19, 2022
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
January 19, 2022
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.

Merge pull request #13459 from WalterBright/semicolon
@dlang-bot
dlang-bot committed 5 days ago

There it is.

Well, better late than never.

thanks!