Menu
Search

Forums

Forum Index

May 03, 2021
Gravatar of DennisPosted by Dennis
in reply to Blatnik		Reply
Dennis
Gravatar of Dennis
Posted in reply to Blatnik


Reply

On Monday, 3 May 2021 at 13:17:29 UTC, Blatnik wrote:

>

Honestly another difficult thing to get is the file names themselves.

ty.d, ph2.d, mars.d, melf.d, fp.d, ee.d, e2ir.d, eh.d, el.d, I could go on and on hahaha.

I think this stems from Walter Bright making C/C++ compilers since the 80s.
In the MS DOS days the 8.3 filename was the norm, so you could not name eh.c exceptionhandling.c or exception.c even if you wanted to.

You can see the meaning of each file here:
https://github.com/dlang/dmd/tree/master/src/dmd#dmd-source-code

> 
struct loc_t
{
    elem *e;
    int flags; // LFxxxxx
}

Ahhh that's what the flags are, I totally get it now. Thanks comment! :P

Another archaism: C doesn't have proper enum types, so the comment says the flags are defined by the macros prefixed with LF.

Of course your point still stands that dmd is not commented well and not easy for new contributors get into, but a lot of the ugliness is there because of historic reasons.

May 03, 2021
Gravatar of DennisPosted by Dennis
in reply to Ola Fosheim Grøstad		Reply
Dennis
Gravatar of Dennis
Posted in reply to Ola Fosheim Grøstad


Reply

On Monday, 3 May 2021 at 13:35:20 UTC, Ola Fosheim Grøstad wrote:

>

Yes, you have to start in one end and focus on that end, then slowly move to other files to get the structure. Directories would help, better names would help. Doesn't take much time to do either, not sure why nobody has done it yet?

Walter is against it because of the command line tools he uses: https://github.com/dlang/dmd/pull/5730#issuecomment-223936450

He suggested to make a table of contents instead:
https://github.com/dlang/dmd/pull/9844#issuecomment-495951635

So I did:
https://github.com/dlang/dmd/pull/10904

I don't know how to improve the situation further as long as Walter's veto stands.

May 03, 2021
Gravatar of Ola Fosheim GrøstadPosted by Ola Fosheim Grøstad
in reply to Dennis		Reply
Ola Fosheim Grøstad
Gravatar of Ola Fosheim Grøstad
Posted in reply to Dennis


Reply

On Monday, 3 May 2021 at 14:34:52 UTC, Dennis wrote:

>

On Monday, 3 May 2021 at 13:35:20 UTC, Ola Fosheim Grøstad wrote:

>

Yes, you have to start in one end and focus on that end, then slowly move to other files to get the structure. Directories would help, better names would help. Doesn't take much time to do either, not sure why nobody has done it yet?

Walter is against it because of the command line tools he uses: https://github.com/dlang/dmd/pull/5730#issuecomment-223936450

Ok, I don't really understand why, but even if that is a good reason then one could simply use long prefixes instead of directories:

parser_token.d
parser_lex.d
parser_parse.d

etc

>

I don't know how to improve the situation further as long as Walter's veto stands.

I get that.

It would be nice if everyone just agreed on a common setup and tools then one could build a community around that with good tutorials, but I guess that is not very realistic.

For instance, when reading Mac tutorials, I find it very useful that they all use XCode. Even if there may be better editors, it really helps to have the same basic setup when getting started on something new.

May 03, 2021
Gravatar of Walter BrightPosted by Walter Bright
in reply to Imperatorn		Reply
Walter Bright
Gravatar of Walter Bright
Posted in reply to Imperatorn


Reply
On 5/3/2021 6:25 AM, Imperatorn wrote:
> Btw, just as a comparison (not trying to make a point) I looked at Crystal (because it was discussed earlier) and it actually has even less comments, not even trying in many places.

Interestingly, when I write initial code I know what I'm doing and think it is obvious, and rarely bother with comments.

The comments come in the second time I work on it, as I don't recall how it works and have to figure it out. I'll comment the non-obvious stuff I have to work out again.

The third, fourth, etc., times this happens is when the comments get even better.

It's an iterative process.

Also, quite a bit of the documentation in the code is not in the comments at all, it is in the coding style. For example, variable name `e` is for an Expression, `t` for Type, `td` for TemplateDeclaration, etc. This helps a lot.

There's a lot of compiler jargon used, too. Getting a copy of the "Dragon Book" will help with this.

https://www.amazon.com/Compilers-Principles-Techniques-Alfred-Aho/dp/0201100886
May 03, 2021
Gravatar of Walter BrightPosted by Walter Bright
in reply to Dennis		Reply
Walter Bright
Gravatar of Walter Bright
Posted in reply to Dennis


Reply
On 5/3/2021 7:25 AM, Dennis wrote:
> On Monday, 3 May 2021 at 13:17:29 UTC, Blatnik wrote:
>> Honestly another difficult thing to get is the file names themselves.
>>
>> `ty.d`, `ph2.d`, `mars.d`, `melf.d`, `fp.d`, `ee.d`, `e2ir.d`, `eh.d`, `el.d`, I could go on and on hahaha.
> 
> I think this stems from Walter Bright making C/C++ compilers since the 80s.
> In the MS DOS days the [8.3 filename](https://en.wikipedia.org/wiki/8.3_filename) was the norm, so you could not name `eh.c` `exceptionhandling.c` or `exception.c` even if you wanted to.

You're right about 8.3. I learned programming back when it was 6.3, and some old habits persist.

But also, when you're going to be typing those filenames tens of thousands of times, shorter is better :-)

Things always get optimized for the long term users, not newbies. For example, nobody says International Business Machines, they say IBM. San Francisco is Frisco. The United States is "the States". Oxycontin is Oxy. Elizabeth is Liz. The University of Washington is just "the dub" around here. It's not a problem.


> Of course your point still stands that dmd is not commented well and not easy for new contributors get into, but a lot of the ugliness is there because of historic reasons.

Parts of it date back to 1982, when C compilers were rather primitive.
May 03, 2021
Gravatar of Walter BrightPosted by Walter Bright
in reply to 12345swordy		Reply
Walter Bright
Gravatar of Walter Bright
Posted in reply to 12345swordy


Reply
On 5/3/2021 6:02 AM, 12345swordy wrote:
> expresstionsem.d comes to mind.

One thing I've been doing now that my editor supports hyperlinks is for semantic implementations I add a link to the spec content for the semantics. For assembly instructions I'll add links to online descriptions of the instructions.

Awkward things often have a link to the bugzilla issue that spawned it for an explanation.

I even rant about PRs that introduce new functions that do not include Ddoc descriptions of the function interface. Such PRs should not pass review.
May 06, 2021
Gravatar of Andrei AlexandrescuPosted by Andrei Alexandrescu
in reply to WebFreak001		Reply
Andrei Alexandrescu
Gravatar of Andrei Alexandrescu
Posted in reply to WebFreak001


Reply
On 5/3/21 4:05 AM, WebFreak001 wrote:
> On Sunday, 2 May 2021 at 18:23:16 UTC, 12345swordy wrote:
>> The lack of comments in dmd makes it extremely difficult for newcomers such as myself to contribute.
>>
>> -Alex
> 
> the wiki contains some stuff to getting started:
> 
> - https://wiki.dlang.org/Starting_as_a_Contributor
> - https://github.com/dlang/dmd/blob/master/CONTRIBUTING.md
> - https://wiki.dlang.org/DMD_Source_Guide
> - https://wiki.dlang.org/Contributing_to_Phobos
> - https://wiki.dlang.org/Get_involved
> 
> The forums and chats might help you when you get stuck.

Would be really nice if dmd had some substantial ddoc-generated documentation.
May 06, 2021
Gravatar of Adam D. RuppePosted by Adam D. Ruppe
in reply to Andrei Alexandrescu		Reply
Adam D. Ruppe
Gravatar of Adam D. Ruppe
Posted in reply to Andrei Alexandrescu


Reply
On Thursday, 6 May 2021 at 13:15:18 UTC, Andrei Alexandrescu wrote:
> Would be really nice if dmd had some substantial ddoc-generated documentation.

fun fact my website generates it:

http://dmd.dpldocs.info/dmd.html

This is *significantly* better than it was a couple years ago, where if there were any comments at all, it was just "compiler implementation for the D programming language", but it could use more.

Still worth recognizing the recent improvement.



My site also wastes a bunch of time generating stuff in the test folder, i should prolly go ahead and skip those files. but that's my problem
May 06, 2021
Gravatar of Ola Fosheim GrøstadPosted by Ola Fosheim Grøstad
in reply to Adam D. Ruppe		Reply
Ola Fosheim Grøstad
Gravatar of Ola Fosheim Grøstad
Posted in reply to Adam D. Ruppe


Reply
On Thursday, 6 May 2021 at 13:27:43 UTC, Adam D. Ruppe wrote:
> On Thursday, 6 May 2021 at 13:15:18 UTC, Andrei Alexandrescu wrote:
>> Would be really nice if dmd had some substantial ddoc-generated documentation.
>
> fun fact my website generates it:
>
> http://dmd.dpldocs.info/dmd.html

Nice effort, but when I look at the lexer and parser modules they seem to be empty... so not helpful at this stage (for me).
May 06, 2021
Gravatar of Adam D. RuppePosted by Adam D. Ruppe
in reply to Ola Fosheim Grøstad		Reply
Adam D. Ruppe
Gravatar of Adam D. Ruppe
Posted in reply to Ola Fosheim Grøstad


Reply
On Thursday, 6 May 2021 at 13:46:31 UTC, Ola Fosheim Grøstad wrote:
> Nice effort, but when I look at the lexer and parser modules they seem to be empty... so not helpful at this stage (for me).

You might have a cached version since they're not empty at all anymore, hit refresh in your browser.

That said there are a bunch of undocumented things. I can't generate what isn't in the source. But there's at least something.

http://dmd.dpldocs.info/dmd.lexer.Lexer.html
http://dmd.dpldocs.info/dmd.parse.Parser.html

My search engine indexed the names too:
http://search.dpldocs.info/?q=semantic2
« First   ‹ Prev
1 2 3
Next ›   Last »