https://wiki.dlang.org/api.php?action=feedcontributions&user=Cauterite&feedformat=atomD Wiki - User contributions [en]2024-03-28T10:21:18ZUser contributionsMediaWiki 1.31.2https://wiki.dlang.org/?title=Pull_Requests&diff=6892Pull Requests2015-10-30T11:57:42Z<p>Cauterite: clarify</p>
<hr />
<div>The source code of the D compiler (dmd), runtime library (druntime), and standard library (Phobos), are all available at [https://github.com/D-Programming-Language GitHub].<br />
<br />
==Fork the project==<br />
<br />
To contribute to the D compiler, runtime library, or standard library, you need to create an account on GitHub, and then navigate to the [https://github.com/D-Programming-Language D programming language] page, select the project you wish to contribute to, and create a fork of that project.<br />
<br />
For example, if you wish to submit a patch to the D compiler, you should navigate to [https://github.com/D-Programming-Language/dmd D-Programming-Language/dmd], then click on the "Fork" button at the top right corner of the page. This will clone the D compiler sources into your list of projects.<br />
<br />
==Check out the sources==<br />
<br />
{{seealso|Using Git on Windows}}<br />
<br />
Once you have forked the project you wish to contribute to, use git to checkout a local copy of the project.<br />
<br />
Generally, you should checkout a copy of at least dmd, druntime, and phobos in order to have a working compiler toolchain that you can use to test your changes.<br />
<br />
Note: if you are intending to fix a regression for the current version for a point release, you must use the [[#Stable Branch|stable branch]] of the code. See the section on the stable branch for more information.<br />
<br />
After checking out the sources, you will probably want to [[Building DMD|build DMD]].<br />
<br />
==Make your changes in a branch==<br />
<br />
{{seealso_url|http://dlang.org/dstyle.html|D coding style}}<br />
<br />
Generally, it is preferred that any changes you wish to contribute should be made in its own dedicated topic branch. For example, if you have a fix for issue 1234 in the D compiler, you might want to do something like this:<br />
<br />
<syntaxhighlight lang="bash"><br />
cd /usr/src/d/dmd/src<br />
git checkout -b issue_1234<br />
vim expression.c # make your changes here<br />
make -f posix.mak<br />
... # test your changes here<br />
git commit -a # commit to the branch named 'issue_1234'<br />
git push -u origin # push changes to your fork of DMD<br />
</syntaxhighlight><br />
<br />
If you are fixing a specific bugzilla issue, then putting "Fix Issue NNNN" in the commit message will automatically add a message to the bug report when the commit is merged.<br />
<br />
==Test your changes==<br />
<br />
Before you submit your changes, it's a good idea to test it thoroughly first. It's also a good idea to run the unittests for druntime and phobos:<br />
<br />
<syntaxhighlight lang=bash><br />
cd /usr/src/d/druntime<br />
make -f posix.mak unittest<br />
cd ../phobos<br />
make -f posix.mak unittest<br />
</syntaxhighlight><br />
<br />
Pull requests that fail unittests will not be accepted by the maintainers, except under special circumstances.<br />
<br />
'''TBD:''' add instructions on running dmd's unittests.<br />
<br />
==Create a pull request==<br />
<br />
Once you have tested all your changes and pushed them to your fork on GitHub, you are ready to submit a pull request.<br />
<br />
# Navigate to your fork of the project on GitHub.<br />
# '''Important''': Select the branch that you made your changes in, say issue_1234.<br />
# Click on the "Pull Request" button.<br />
<br />
This will submit your changes for review by the D maintainers. If your changes are approved, they will be merged into the master branch. Otherwise, if the maintainers have some comments or feedback, you can refine your changes by editing and testing in your local workspace, and pushing the new changes to the same git branch. The new changes will be automatically included in your pull request.<br />
<br />
Choose a title for your pull request that clearly states what it does. When fixing a bug, the usual thing to do is to use the summary from the bugzilla report. Eg a title like "Fix 3797" or "Issue 3797" contains much less information than "Fix Issue 3797 - Regression(2.038): Implicit conversion between incompatible function pointers" and requires a lot more effort for the reviewers to determine if it is something they are interested in.<br />
<br />
Pull request descriptions should contain a hyperlink to the [[Bugzilla]] issue that is being fixed. This is usually added at the end of the description.<br />
<br />
After the pull request is created, add the 'pull' keyword to the corresponding bugzilla issue and a link to the pull request posted in a comment.<br />
<br />
===Autotester===<br />
<br />
Pull requests are automatically picked up by the [[Git Commit Tester|autotester]], which compiles the code in the pull request and runs it through the dmd, druntime, and phobos unittests on all supported platforms. Generally, pull requests must pass all tests before they will be merged. The status of the tests can be monitored through the pull request page.<br />
<br />
Every user must be manually approved before the autotester will start testing their pull requests. Users can be approved by anyone with commit access.<br />
<br />
===Rebasing===<br />
<br />
Sometimes, if a particular change you are working on is taking a long time, or if you encounter a problem that is fixed by a new commit upstream, you may need to sync your local branch with master in order to keep the code up-to-date. In this case, it is recommended that you use git rebase to apply your changes ''on top of'' the latest git master, so that when you submit a pull request, the change history will be easier for the reviewers to follow. Using git merge is ''not'' recommended, as it may produce a lot of merge commits that may not be relevant to your changes.<br />
<br />
For example, you may be working on your changes:<br />
<br />
<syntaxhighlight lang=bash><br />
cd /usr/src/d/phobos<br />
git checkout mybranch<br />
vim std/algorithm.d # apply lots of cool changes here<br />
</syntaxhighlight><br />
<br />
First, before you resync with master, make sure all your changes are checked in (or stashed):<br />
<br />
<syntaxhighlight lang=bash><br />
git commit -a<br />
</syntaxhighlight><br />
<br />
If you forked from the official D programming language repositories you may need to add an upstream remote to pull in the latest official changes. If this is the case you can add an upstream remote like this:<br />
<br />
<syntaxhighlight lang=bash><br />
git remote add upstream git@github.com:D-Programming-Language/phobos<br />
</syntaxhighlight><br />
<br />
This adds another remote to your repository called upstream and only needs to be done once. Once the upstream remote is added, you can update your repository's master branch by running the following:<br />
<br />
<syntaxhighlight lang=bash><br />
git checkout master<br />
git pull --ff-only upstream master<br />
</syntaxhighlight><br />
<br />
The --ff-only option is to ensure that your master branch is identical to the official D sources' master branch, since otherwise you will end up with a very messy history that will be hard to clean up (and the reviewers will probably reject your pull request due to having unrelated merge commits).<br />
<br />
Now go back to your branch and rebase it:<br />
<br />
<syntaxhighlight lang=bash><br />
git checkout mybranch<br />
git rebase master<br />
</syntaxhighlight><br />
<br />
Now your sources should be up-to-date. Recompile and test everything to make sure it all works.<br />
<br />
Note that after rebasing, you will need to force an update to your fork on GitHub with the -f flag, otherwise it will fail because the histories don't match anymore:<br />
<br />
<syntaxhighlight lang=bash><br />
git push -f origin mybranch<br />
</syntaxhighlight><br />
<br />
You may wish to read up on [http://git-scm.com/book/en/Git-Branching-Rebasing how git rebase works] if you're not familiar with the concept.<br />
<br />
If, during the 'git rebase' command, you encounter conflicts, you may want to learn [http://stackoverflow.com/questions/8780257/git-rebase-a-branch-onto-master-failed-how-to-resolve how to resolve a conflict during git rebase].<br />
<br />
==Stable Branch==<br />
<br />
If you are working on a fix for a regression, chances are it should go into the next point release, and not the next major version (e.g. 2.067.1 instead of 2.068). In this case, you should check out the stable branch of each subproject BEFORE you create your topic branch:<br />
<br />
<syntaxhighlight lang=bash><br />
cd dmd<br />
git checkout stable<br />
cd ../druntime<br />
git checkout stable<br />
cd ../phobos<br />
git checkout stable<br />
</syntaxhighlight><br />
<br />
Then follow the instructions for [[#Make your changes in a branch|making a branch]].<br />
<br />
If you forget to do this, or didn't realize it, It's not possible to simply re-target your branch for pulling into the stable branch. Github will let you do this, but your branch will include many of the changes from the unstable branch!<br />
<br />
In order to fix such a problem, you can [[#Rebasing|rebase]] your changes from master on top of the stable branch. First you need to pull in the stable branch from your fork on github:<br />
<br />
<syntaxhighlight lang=bash><br />
git checkout stable<br />
</syntaxhighlight><br />
<br />
Then, you go back to your branch, and replay the changes from master using rebase:<br />
<br />
<syntaxhighlight lang=bash><br />
git checkout mybranch<br />
git fetch upstream<br />
git rebase --onto upstream/stable upstream/master mybranch<br />
</syntaxhighlight><br />
<br />
You may have to follow the instructions in the [[#Rebasing|Rebasing section]] on adding the upstream branch, substituting stable for master, if you need to update to the latest stable changes.<br />
<br />
This sometimes may not work, as the changes between the stable and master are too drastic. In this case, you may have to re create your changes after a clean checkout of the stable branch.<br />
<br />
When creating a pull request, you need to tell github to target the stable branch instead of master on the upstream repository. This is done via a drop-down at the top of the page, make sure to do this before submitting your pull request as this cannot be changed after the PR is created (you will have to close the PR and create a new one).<br />
<br />
If you notice in your PR a whole slew of changes that seem to have nothing to do with your changes, it's likely because you forgot one of these steps.<br />
<br />
==Reviews==<br />
<br />
Any pull requests that make language changes must be approved by Walter and Andrei. This includes druntime changes that implement the specification.<br />
<br />
Any pull requests that make significant changes to code should be reviewed by more than one person. This means that at least two people need to approve the pull request before it is merged. One person must be a person with commit rights, but the other need not be, as long as that person is trusted within the developer community.<br />
<br />
Pull requests that are trivial (typos, obvious minor bug fixes, etc.) may be pulled without a second review.<br />
<br />
Please note that any updates pushed to the candidate branch do not automatically notify a subscribed person. If you update your branch to correct an issue, please also put in a comment indicating it.<br />
<br />
==Copyright assignment==<br />
<br />
Please note that all contributions to DMD source code require that the copyright to that code be assigned to Digital Mars.<br />
<br />
<br />
[[Category: Contribution Guidelines]]</div>Cauteritehttps://wiki.dlang.org/?title=Debuggers&diff=6830Debuggers2015-10-25T09:48:50Z<p>Cauterite: +ollydbg</p>
<hr />
<div>To debug D programs you need to use a debugger that understands the format of the debug symbols information that your chosen compiler produces.<br />
The quality of the debug symbols information might vary depending on which compiler you use and its underlying debug format. For example, some compiler configurations may present the names of variables and/or functions in it's C mangled form, instead of the natural D name.<br />
<br />
== Debugging support by compiler ==<br />
<br />
{| class="wikitable"<br />
|-<br />
! Compiler+Platform<br />
! Format<br />
! Debugger<br />
! Supported functionality<br />
|-<br />
|rowspan="4"| '''DMD-Win32''' <br />
|rowspan="4"| OMF<br />
| [http://www.dsource.org/projects/visuald Mago/VisualD]<br />
| Good support: Breakpoints; Stack frames; Mostly pretty names ('.' shows up as '@'); Variable inspection; Visual Studio based.<br />
|-<br />
| [http://dlang.org/download.html WinDbg]<br />
| Supplied with the main D compiler zip file download. [http://dlang.org/windbg.html Overview]<br />
|-<br />
| [http://ddbg.mainia.de ddbg]<br />
| Doesn't seem to be working well. Project no longer maintained.<br />
|-<br />
| [http://www.ollydbg.de/version2.html OllyDbg 2]<br />
| Reasonable support when assisted by [https://github.com/rainers/cv2pdb cv2pdb]; stack frames; mangled symbols; shows source code alongside disassembly. Note: v2.01 has a bug that may cause frequent crashes when reading PDB files. Details and patch [http://forum.dlang.org/post/mgyggejmutshptyycwze@forum.dlang.org here].<br />
|-<br />
| '''DMD-Win64''' <br />
| COFF<br />
| [http://www.dsource.org/projects/visuald Mago/VisualD]<br />
| TODO: same level of support as for win32?<br />
|-<br />
|rowspan="2"|<br />
'''DMD-Linux''' <br/><br />
'''GDC-Linux''' <br/><br />
'''LDC-Linux''' <br/><br />
'''GDC-Win32/64'''<br />
|rowspan="2"| DWARF<br />
| [https://sourceware.org/gdb/onlinedocs/gdb/D.html#D GDB]<br />
| Good support: Breakpoints; Stack frames; Pretty names; Variable inspection;<br />
|-<br />
| [http://zerobugs.codeplex.com/ ZeroBUGS]<br />
| "Modular debugger for C/C++/D programming languages (and virtually anything else that supports Stabs/DWARF debug formats)". Supported debugging functionality??<br />
|-<br />
| '''LDC-MinGW''' <br />
| DWARF<br />
| -<br />
| DWARF debug symbol info seems to be broken for LLVM compiled with MinGW [http://forum.dlang.org/post/qsttkqzbtnhyrogekppn@forum.dlang.org note]<br />
|-<br />
|rowspan="2"| <br />
'''DMD-MacOS''' <br/><br />
'''GDC-MacOS''' <br/><br />
'''LDC-MacOS''' <br />
|rowspan="2"| ?<br />
| GDB<br />
| Limited/outdated support? According to Jacob Carlberg:<br />
"D symbols need to be prefixed with an extra underscore."<br />
"Line numbers don't work."<br />
|-<br />
| LLDB<br />
| ?<br />
|}<br />
<br />
[[Category:Stand-alone applications]]<br />
<br />
== Graphical debugger frontends ==<br />
Frontends providing support to a command-line debugger mentioned in the previous section.<br />
<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
! Debugger<br />
! Frontend<br />
! Description<br />
! Platform<br />
|-<br />
| GDB<br />
| [[Mono-D]]<br />
| MonoDeveloped-based full D IDE. Has integration with the GDB debugger. <br />
"Debugging (using MonoDevelop’s integrated gdb support on Linux currently)"<br />
| Linux?<br />
|-<br />
| GDB<br />
| [http://code.google.com/p/ddt/ '''DDT''']<br />
| Eclipse-based IDE. Has [https://github.com/bruno-medeiros/DDT/blob/latest/documentation/Features.md#debugging-functionality integration with the GDB debugger], including D support. (Debugging support is based on Eclipse CDT) <br />
| Linux, Windows, MacOS<br />
|-<br />
| GDB<br />
| [http://projects.gnome.org/nemiver/ '''Nemiver''']<br />
| Graphical frontend to the GDB debugger, which supports full D syntax from version 7.2.<br />
| Linux<br />
|-<br />
| GDB<br />
| [http://cgdb.github.com/ '''CGDB''']<br />
| Command line frontend to the GDB debugger, which supports full D syntax from version 7.2.Shows code and the GDB console in split windows.<br />
| Linux, MacOS<br />
|-<br />
| GDB<br />
| [http://www.gnu.org/software/ddd/ '''DDD''']<br />
| GNU DDD is a graphical front-end for command-line debuggers such as GDB. Usual front-end features such as viewing source code, viewing variables, etc.<br />
| Linux<br />
|-<br />
| GDB<br />
| [http://www.affinic.com/?page_id=109 '''Affinic Debugger''']<br />
| Affinic Debugger GUI .aka. ADG, is designed as a graphical user interface for various debuggers. This version is specifically targeted on GDB, the GNU debugger.<br />
| Linux, Windows, MacOS<br />
|}</div>Cauteritehttps://wiki.dlang.org/?title=Vision/2015H2&diff=6814Vision/2015H22015-10-21T16:33:11Z<p>Cauterite: </p>
<hr />
<div>== Meta ==<br />
<br />
This document discusses the high-level vision for D. It is revised every six months (January and July of every year). This (2015H2) instance is four months late.<br />
<br />
Note: This document focuses on goals the D leadership will personally enable or make happen. Other contributions that don't require their help are always welcome.<br />
<br />
== Progress in H1 2015 ==<br />
<br />
* Adoption has been growing year over year, with seasonal fluctuations (summer is slower). The 28-day trailing average of daily downloads was 1081 on June 30 2015, compared to 701 exactly one year prior (54.2% increase). [http://erdani.com/d/downloads.daily.png See chart].<br />
<br />
* [https://github.com/pulls?utf8=%E2%9C%93&q=is%3Apr+user%3AD-Programming-Language+created%3A2015-01-01..2015-06-30 1871 pull requests] have been created in H1 2015 (1796 closed, 71 open). This marks a 21.7% growth over H2 2014 ([https://github.com/pulls?q=is%3Apr+user%3AD-Programming-Language+created%3A2014-07-01..2014-12-31 1538 pull requests]) and a 31.8% growth year-over-year compared to H1 2014 ([https://github.com/pulls?utf8=%E2%9C%93&q=is%3Apr+user%3AD-Programming-Language+created%3A2014-01-01..2014-06-30 1419 pull requests]).<br />
<br />
* [http://dconf.org/2015 DConf 2015] held at Utah Valley University has been a success. However attendance rate (about 50) has been stagnating compared to previous years.<br />
<br />
* Work on the D Language Foundation has proceeded. We secured an attorney.<br />
<br />
* Porting the D compiler to D has been making good progress.<br />
<br />
== H2 2015 Priorities ==<br />
<br />
Because of delays in drafting this document, some items are past work (as noted) instead of intended work.<br />
<br />
;The D Language Foundation<br />
<br />
:The Foundation has been incorporated during H2 with the state of Washington, USA. The employer ID is 47-5352856. The plan is to file for non-profit status by the end of H2 (approval takes up to 6 months).<br />
<br />
;Porting the reference compiler to D<br />
<br />
:The front-end has been ported. There is work on porting the backend as well.<br />
<br />
;Continue fostering brand awareness<br />
<br />
:This remains a priority going forward. "This Week in D" has become a community staple, but we currently have no viewership statistics. DConf 2016 in Berlin is slated to be a larger event than before. Regional meetups are also important for branding: [http://www.meetup.com/London-D-Programmers/ London], [http://www.meetup.com/Berlin-D-Programmers/ Berlin], [http://www.meetup.com/D-Lang-Sillicon-Valley Silicon Valley].</div>Cauterite