digitalmars.D - Please stop doing this.
- Brian Schott (11/11) Oct 30 2013 Stop modifying the language without also modifying the language
- Timothee Cour (5/15) Oct 30 2013 actually the author of Dscanner would probably feel the same:
- Dicebot (3/8) Oct 30 2013 Just in case : Brian is the author of Dscanner ;)
- Michael (6/6) Oct 30 2013 We need to go deeper...
- =?UTF-8?B?QWxpIMOHZWhyZWxp?= (3/5) Oct 30 2013 Agreed. Your tool should be incorporated into the build (or release) ste...
- Ary Borenszweig (2/7) Oct 31 2013 As well as every other tool that uses D.
- Dicebot (4/5) Oct 31 2013 It has been already discussed as impractical. While easy CI for D
- Ary Borenszweig (6/10) Oct 31 2013 I wasn't serious.
- Brian Schott (2/9) Oct 31 2013 I'm not sure how it would be useful there.
- =?UTF-8?B?QWxpIMOHZWhyZWxp?= (7/18) Oct 31 2013 I imagined using it as a tool to make sure that the new dmd will not
- Kagamin (2/2) Nov 01 2013 Scintilla has lexer tests which work by marking up the output and
Stop modifying the language without also modifying the language spec. Seriously. Stop it. Pull requests that modify the parser should be rejected unless they also have the corresponding changes to the language grammar. I spend a decent amount of my spare time on D development tooling and I'm getting sick of the "Your parser rejects X", "X isn't in the language spec", "DMD accepts X" cycle. The current situation is that the only REAL documentation on D's syntax is the front-end source code, and this is ridiculous.
Oct 30 2013
actually the author of Dscanner would probably feel the same: I've reported a number of issues that were due to mismatch bw D spec and dmd: https://github.com/Hackerpilot/Dscanner/issues?state=open On Wed, Oct 30, 2013 at 12:04 PM, Brian Schott <briancschott gmail.com>wrote:Stop modifying the language without also modifying the language spec. Seriously. Stop it. Pull requests that modify the parser should be rejected unless they also have the corresponding changes to the language grammar. I spend a decent amount of my spare time on D development tooling and I'm getting sick of the "Your parser rejects X", "X isn't in the language spec", "DMD accepts X" cycle. The current situation is that the only REAL documentation on D's syntax is the front-end source code, and this is ridiculous.
Oct 30 2013
On Wednesday, 30 October 2013 at 20:00:00 UTC, Timothee Cour wrote:actually the author of Dscanner would probably feel the same: I've reported a number of issues that were due to mismatch bw D spec and dmd: https://github.com/Hackerpilot/Dscanner/issues?state=openJust in case : Brian is the author of Dscanner ;)
Oct 30 2013
We need to go deeper... That is recursive reference... It's not stoppable... Real guys write binary code directly and then source code as documentation. ;)
Oct 30 2013
On 10/30/2013 12:04 PM, Brian Schott wrote:Pull requests that modify the parser should be rejected unless they also have the corresponding changes to the language grammar.Agreed. Your tool should be incorporated into the build (or release) steps. Ali
Oct 30 2013
On 10/30/13 6:09 PM, Ali Çehreli wrote:On 10/30/2013 12:04 PM, Brian Schott wrote: > Pull requests that modify the parser should be rejected unless they also > have the corresponding changes to the language grammar. Agreed. Your tool should be incorporated into the build (or release) steps. AliAs well as every other tool that uses D.
Oct 31 2013
On Thursday, 31 October 2013 at 16:57:24 UTC, Ary Borenszweig wrote:As well as every other tool that uses D.It has been already discussed as impractical. While easy CI for D projects is important, it should be in separate test suite.
Oct 31 2013
On 10/31/13 2:15 PM, Dicebot wrote:On Thursday, 31 October 2013 at 16:57:24 UTC, Ary Borenszweig wrote:I wasn't serious. What I'm saying, the solution isn't "DScanner should be incorporated into the build step". The simplest solution is to go slower, paying attention to these details and maintaining consistency in the language and the specs.As well as every other tool that uses D.It has been already discussed as impractical. While easy CI for D projects is important, it should be in separate test suite.
Oct 31 2013
On Wednesday, 30 October 2013 at 21:09:09 UTC, Ali Çehreli wrote:On 10/30/2013 12:04 PM, Brian Schott wrote:I'm not sure how it would be useful there.Pull requests that modify the parser should be rejectedunless they alsohave the corresponding changes to the language grammar.Agreed. Your tool should be incorporated into the build (or release) steps. Ali
Oct 31 2013
On 10/31/2013 11:46 AM, Brian Schott wrote:> On Wednesday, 30 October 2013 at 21:09:09 UTC, Ali Çehreli wrote:I imagined using it as a tool to make sure that the new dmd will not break existing parsing or language spec. Although I am not sure what kind of test can verify that, the idea would be to notice that some perhaps implicit spec is about to be changed. AliOn 10/30/2013 12:04 PM, Brian Schott wrote:I'm not sure how it would be useful there.Pull requests that modify the parser should be rejectedunless they alsohave the corresponding changes to the language grammar.Agreed. Your tool should be incorporated into the build (or release) steps. Ali
Oct 31 2013
Scintilla has lexer tests which work by marking up the output and comparing with etalon string.
Nov 01 2013