From magnus.ihse.bursie at oracle.com Tue May 5 21:53:31 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 05 May 2015 23:53:31 +0200 Subject: RFR(XS): 7901298: jcheck should check that every file ends with exactly one newline In-Reply-To: <554937B1.3040803@oracle.com> References: <554936C7.1060804@oracle.com> <554937B1.3040803@oracle.com> Message-ID: <55493BDB.9070108@oracle.com> On 2015-05-05 23:35, Jonathan Gibbons wrote: > > On 05/05/2015 02:31 PM, Magnus Ihse Bursie wrote: >> On 2015-02-13 12:01, Volker Simonis wrote: >>> Hi, >>> >>> could somebody please review and sponsor the following small change >>> which adds a test for exactly one newline at the and of a file to >>> check: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/2015/7901298/ >>> https://bugs.openjdk.java.net/browse/CODETOOLS-7901298 >> >> Found this mail again now, when I wondered why it was not already fixed. >> >> The fix looks good to me, and I wish it was already in place :-). I'm >> not a formal jcheck reviewer though. :( >> >> /Magnus > > Magnus, > > Please see the follow-up discussion on hg-tools-dev. > http://mail.openjdk.java.net/pipermail/hg-tools-dev/2015-April/thread.html > Quoting that discussion: > Do all of the changesets (-r 0:tip) in all existing forests where > jcheck is enabled pass with this change? Is it really the case that there can be no changes to jcheck which do not make all existing changesets in all existing forests pass? How on earth are we then ever going to be able to raise the bar for quality? /Magnus From iris.clark at oracle.com Wed May 6 21:05:59 2015 From: iris.clark at oracle.com (Iris Clark) Date: Wed, 6 May 2015 14:05:59 -0700 (PDT) Subject: RFR(XS): 7901298: jcheck should check that every file ends with exactly one newline In-Reply-To: <55493BDB.9070108@oracle.com> References: <554936C7.1060804@oracle.com> <554937B1.3040803@oracle.com> <55493BDB.9070108@oracle.com> Message-ID: <040387ea-703c-4b7c-82d9-7d40df256506@default> Hi, Magnus. > Is it really the case that there can be no changes to jcheck which do not make all existing changesets in all existing forests pass? How on earth are we then ever going to be able to raise the bar for quality? Theoretically, I don't think that there's a problem with modifying jcheck to improve the quality of the code. The issue is that as the tool is currently written and used, there is no migration path for a higher bar. The provided patch does not include a solution to this problem. Thanks, iris -----Original Message----- From: Magnus Ihse Bursie Sent: Tuesday, May 05, 2015 2:54 PM To: Jonathan Gibbons; code-tools-dev at openjdk.java.net; hg-tools-dev at openjdk.java.net Subject: Re: RFR(XS): 7901298: jcheck should check that every file ends with exactly one newline On 2015-05-05 23:35, Jonathan Gibbons wrote: > > On 05/05/2015 02:31 PM, Magnus Ihse Bursie wrote: >> On 2015-02-13 12:01, Volker Simonis wrote: >>> Hi, >>> >>> could somebody please review and sponsor the following small change >>> which adds a test for exactly one newline at the and of a file to >>> check: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/2015/7901298/ >>> https://bugs.openjdk.java.net/browse/CODETOOLS-7901298 >> >> Found this mail again now, when I wondered why it was not already fixed. >> >> The fix looks good to me, and I wish it was already in place :-). I'm >> not a formal jcheck reviewer though. :( >> >> /Magnus > > Magnus, > > Please see the follow-up discussion on hg-tools-dev. > http://mail.openjdk.java.net/pipermail/hg-tools-dev/2015-April/thread. > html > Quoting that discussion: > Do all of the changesets (-r 0:tip) in all existing forests where > jcheck is enabled pass with this change? Is it really the case that there can be no changes to jcheck which do not make all existing changesets in all existing forests pass? How on earth are we then ever going to be able to raise the bar for quality? /Magnus From volker.simonis at gmail.com Thu May 7 09:25:22 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 7 May 2015 11:25:22 +0200 Subject: RFR(XS): 7901298: jcheck should check that every file ends with exactly one newline In-Reply-To: <040387ea-703c-4b7c-82d9-7d40df256506@default> References: <554936C7.1060804@oracle.com> <554937B1.3040803@oracle.com> <55493BDB.9070108@oracle.com> <040387ea-703c-4b7c-82d9-7d40df256506@default> Message-ID: Hi Iris, can you please explain what you mean with "On push to a server, the entire repository is checked for compliance to jcheck, not just the pushed changesets". Is this really the case for every push - i.e. if I push a change to lets say jdk9/dev/hotspot does this mean that jcheck is really run on the revision range 0:tip? And if that's the case, what's the reason for it? I don't understand what that should be good for, because commited changes can not be changed anyway. I also doubt that 'hg jcheck --rev 0:tip' is really run on every push simply because of performance reasons. When I push a change that's usually a matter of seconds. But when I tested 'hg jcheck --rev 0:tip' as I wrote in one of my previous mails that took more than 10 minutes on the hotspot repository. So if it would turn out that 'hg jcheck --rev 0:tip' is only used in special scenarios, would it be acceptable to use jcheck with a special command line switch in these scenarios which turns the test for proper EOF format off? I could add such a command line option if that would make sense. But in my opinion, this new check only makes sense if it will be enabled by default, otherwise nobody would use it. Regards, Volker On Wed, May 6, 2015 at 11:05 PM, Iris Clark wrote: > Hi, Magnus. > >> Is it really the case that there can be no changes to jcheck which do not make all existing changesets in all existing forests pass? How on earth are we then ever going to be able to raise the bar for quality? > > Theoretically, I don't think that there's a problem with modifying jcheck to improve the quality of the code. The issue is that as the tool is currently written and used, there is no migration path for a higher bar. The provided patch does not include a solution to this problem. > > Thanks, > iris > > -----Original Message----- > From: Magnus Ihse Bursie > Sent: Tuesday, May 05, 2015 2:54 PM > To: Jonathan Gibbons; code-tools-dev at openjdk.java.net; hg-tools-dev at openjdk.java.net > Subject: Re: RFR(XS): 7901298: jcheck should check that every file ends with exactly one newline > > On 2015-05-05 23:35, Jonathan Gibbons wrote: >> >> On 05/05/2015 02:31 PM, Magnus Ihse Bursie wrote: >>> On 2015-02-13 12:01, Volker Simonis wrote: >>>> Hi, >>>> >>>> could somebody please review and sponsor the following small change >>>> which adds a test for exactly one newline at the and of a file to >>>> check: >>>> >>>> http://cr.openjdk.java.net/~simonis/webrevs/2015/7901298/ >>>> https://bugs.openjdk.java.net/browse/CODETOOLS-7901298 >>> >>> Found this mail again now, when I wondered why it was not already fixed. >>> >>> The fix looks good to me, and I wish it was already in place :-). I'm >>> not a formal jcheck reviewer though. :( >>> >>> /Magnus >> >> Magnus, >> >> Please see the follow-up discussion on hg-tools-dev. >> http://mail.openjdk.java.net/pipermail/hg-tools-dev/2015-April/thread. >> html >> > > Quoting that discussion: >> Do all of the changesets (-r 0:tip) in all existing forests where >> jcheck is enabled pass with this change? > > Is it really the case that there can be no changes to jcheck which do not make all existing changesets in all existing forests pass? How on earth are we then ever going to be able to raise the bar for quality? > > /Magnus From chris.hegarty at oracle.com Thu May 7 09:35:42 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 7 May 2015 10:35:42 +0100 Subject: RFR(XS): 7901298: jcheck should check that every file ends with exactly one newline In-Reply-To: References: <554936C7.1060804@oracle.com> <554937B1.3040803@oracle.com> <55493BDB.9070108@oracle.com> <040387ea-703c-4b7c-82d9-7d40df256506@default> Message-ID: <8FB4AEC6-C515-4E23-BC13-F61CBFE93068@oracle.com> Volker, I cannot answer the questions about the operation of the mercurial server, others better positioned than I should do that, but if jcheck is to ever evolve in a manner like you are suggesting then a repository may need a way to indicate to jcheck what level of checks should be done for certain regions of its history. Say, the .jcheck/conf file in the repo had an entry with a value of a changeset from where jcheck would enable this ?new? stricter checking. It would be opt in by the repo/project and could be configurable to its local history ( i.e. enable from this changeset hash onward ). Previous changsets would be checked as they are today. -Chris. On 7 May 2015, at 10:25, Volker Simonis wrote: > Hi Iris, > > can you please explain what you mean with "On push to a server, the > entire repository is checked for compliance to jcheck, not just the > pushed changesets". Is this really the case for every push - i.e. if I > push a change to lets say jdk9/dev/hotspot does this mean that jcheck > is really run on the revision range 0:tip? And if that's the case, > what's the reason for it? I don't understand what that should be good > for, because commited changes can not be changed anyway. > > I also doubt that 'hg jcheck --rev 0:tip' is really run on every push > simply because of performance reasons. When I push a change that's > usually a matter of seconds. But when I tested 'hg jcheck --rev 0:tip' > as I wrote in one of my previous mails that took more than 10 minutes > on the hotspot repository. > > So if it would turn out that 'hg jcheck --rev 0:tip' is only used in > special scenarios, would it be acceptable to use jcheck with a special > command line switch in these scenarios which turns the test for proper > EOF format off? I could add such a command line option if that would > make sense. > > But in my opinion, this new check only makes sense if it will be > enabled by default, otherwise nobody would use it. > > Regards, > Volker > > > On Wed, May 6, 2015 at 11:05 PM, Iris Clark wrote: >> Hi, Magnus. >> >>> Is it really the case that there can be no changes to jcheck which do not make all existing changesets in all existing forests pass? How on earth are we then ever going to be able to raise the bar for quality? >> >> Theoretically, I don't think that there's a problem with modifying jcheck to improve the quality of the code. The issue is that as the tool is currently written and used, there is no migration path for a higher bar. The provided patch does not include a solution to this problem. >> >> Thanks, >> iris >> >> -----Original Message----- >> From: Magnus Ihse Bursie >> Sent: Tuesday, May 05, 2015 2:54 PM >> To: Jonathan Gibbons; code-tools-dev at openjdk.java.net; hg-tools-dev at openjdk.java.net >> Subject: Re: RFR(XS): 7901298: jcheck should check that every file ends with exactly one newline >> >> On 2015-05-05 23:35, Jonathan Gibbons wrote: >>> >>> On 05/05/2015 02:31 PM, Magnus Ihse Bursie wrote: >>>> On 2015-02-13 12:01, Volker Simonis wrote: >>>>> Hi, >>>>> >>>>> could somebody please review and sponsor the following small change >>>>> which adds a test for exactly one newline at the and of a file to >>>>> check: >>>>> >>>>> http://cr.openjdk.java.net/~simonis/webrevs/2015/7901298/ >>>>> https://bugs.openjdk.java.net/browse/CODETOOLS-7901298 >>>> >>>> Found this mail again now, when I wondered why it was not already fixed. >>>> >>>> The fix looks good to me, and I wish it was already in place :-). I'm >>>> not a formal jcheck reviewer though. :( >>>> >>>> /Magnus >>> >>> Magnus, >>> >>> Please see the follow-up discussion on hg-tools-dev. >>> http://mail.openjdk.java.net/pipermail/hg-tools-dev/2015-April/thread. >>> html >>> >> >> Quoting that discussion: >>> Do all of the changesets (-r 0:tip) in all existing forests where >>> jcheck is enabled pass with this change? >> >> Is it really the case that there can be no changes to jcheck which do not make all existing changesets in all existing forests pass? How on earth are we then ever going to be able to raise the bar for quality? >> >> /Magnus From magnus.ihse.bursie at oracle.com Thu May 7 12:13:28 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 07 May 2015 14:13:28 +0200 Subject: RFR(XS): 7901298: jcheck should check that every file ends with exactly one newline In-Reply-To: <8FB4AEC6-C515-4E23-BC13-F61CBFE93068@oracle.com> References: <554936C7.1060804@oracle.com> <554937B1.3040803@oracle.com> <55493BDB.9070108@oracle.com> <040387ea-703c-4b7c-82d9-7d40df256506@default> <8FB4AEC6-C515-4E23-BC13-F61CBFE93068@oracle.com> Message-ID: <554B56E8.4050201@oracle.com> On 2015-05-07 11:35, Chris Hegarty wrote: > Volker, > > I cannot answer the questions about the operation of the mercurial server, others better positioned than I should do that, but if jcheck is to ever evolve in a manner like you are suggesting then a repository may need a way to indicate to jcheck what level of checks should be done for certain regions of its history. Say, the .jcheck/conf file in the repo had an entry with a value of a changeset from where jcheck would enable this ?new? stricter checking. It would be opt in by the repo/project and could be configurable to its local history ( i.e. enable from this changeset hash onward ). Previous changsets would be checked as they are today. I still don't understand why jcheck must be able to approve already committed changesets. Are we talking about a technical limitation in the way jcheck is currently implemented? Or a technical limitation on what's possible to run on a mercurial server? Or is this a design choice? Your suggestion might be required if it is a technical limitation in how mercurial server extensions work, but if it is a limitation in the current implementation in jcheck, it seems better to fix it in jcheck than to add special tracking files to the repositories. And if it is a pure design choice, well, I can't see the value of having to keep track exactly what level of jcheck historical commits pasts. /Magnus From volker.simonis at gmail.com Thu May 7 15:12:29 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 7 May 2015 17:12:29 +0200 Subject: RFR(XS): 7901298: jcheck should check that every file ends with exactly one newline In-Reply-To: <8FB4AEC6-C515-4E23-BC13-F61CBFE93068@oracle.com> References: <554936C7.1060804@oracle.com> <554937B1.3040803@oracle.com> <55493BDB.9070108@oracle.com> <040387ea-703c-4b7c-82d9-7d40df256506@default> <8FB4AEC6-C515-4E23-BC13-F61CBFE93068@oracle.com> Message-ID: Thanks Chris, I think now I got it. You are suggesting to configure the new feature in .jcheck/conf right? OK, so what about this new version: http://cr.openjdk.java.net/~simonis/webrevs/2015/7901298.v2/ I've introduced a new attribute 'check_eof' in .jcheck/conf which controls the behaviour of the new feature: # Test if we should check for a correct EOF (i.e. files end with exatly one '\n') # This behaviour is controlled by the 'check_eof' attribute in the conf file. # -1 means to not check for EOF at all. # 0 means to potentially check all the changes for a correct EOF. # any other positive number is interpreted as the revision number or change- # set ID from which on jcheck should start checking for a correct EOF. # If the 'check_eof' attribute is missing, '-1' (i.e. no EOF check) will be assumed. This way we can change jcheck and add the new EOF checking without changing its behaviour on any existing, jcheck-enabled repositories. Afterwards, any single repository can enable the EOF-checking from an arbitrary changeset on-wards. What do you think, Volker On Thu, May 7, 2015 at 11:35 AM, Chris Hegarty wrote: > Volker, > > I cannot answer the questions about the operation of the mercurial server, others better positioned than I should do that, but if jcheck is to ever evolve in a manner like you are suggesting then a repository may need a way to indicate to jcheck what level of checks should be done for certain regions of its history. Say, the .jcheck/conf file in the repo had an entry with a value of a changeset from where jcheck would enable this ?new? stricter checking. It would be opt in by the repo/project and could be configurable to its local history ( i.e. enable from this changeset hash onward ). Previous changsets would be checked as they are today. > > -Chris. > > On 7 May 2015, at 10:25, Volker Simonis wrote: > >> Hi Iris, >> >> can you please explain what you mean with "On push to a server, the >> entire repository is checked for compliance to jcheck, not just the >> pushed changesets". Is this really the case for every push - i.e. if I >> push a change to lets say jdk9/dev/hotspot does this mean that jcheck >> is really run on the revision range 0:tip? And if that's the case, >> what's the reason for it? I don't understand what that should be good >> for, because commited changes can not be changed anyway. >> >> I also doubt that 'hg jcheck --rev 0:tip' is really run on every push >> simply because of performance reasons. When I push a change that's >> usually a matter of seconds. But when I tested 'hg jcheck --rev 0:tip' >> as I wrote in one of my previous mails that took more than 10 minutes >> on the hotspot repository. >> >> So if it would turn out that 'hg jcheck --rev 0:tip' is only used in >> special scenarios, would it be acceptable to use jcheck with a special >> command line switch in these scenarios which turns the test for proper >> EOF format off? I could add such a command line option if that would >> make sense. >> >> But in my opinion, this new check only makes sense if it will be >> enabled by default, otherwise nobody would use it. >> >> Regards, >> Volker >> >> >> On Wed, May 6, 2015 at 11:05 PM, Iris Clark wrote: >>> Hi, Magnus. >>> >>>> Is it really the case that there can be no changes to jcheck which do not make all existing changesets in all existing forests pass? How on earth are we then ever going to be able to raise the bar for quality? >>> >>> Theoretically, I don't think that there's a problem with modifying jcheck to improve the quality of the code. The issue is that as the tool is currently written and used, there is no migration path for a higher bar. The provided patch does not include a solution to this problem. >>> >>> Thanks, >>> iris >>> >>> -----Original Message----- >>> From: Magnus Ihse Bursie >>> Sent: Tuesday, May 05, 2015 2:54 PM >>> To: Jonathan Gibbons; code-tools-dev at openjdk.java.net; hg-tools-dev at openjdk.java.net >>> Subject: Re: RFR(XS): 7901298: jcheck should check that every file ends with exactly one newline >>> >>> On 2015-05-05 23:35, Jonathan Gibbons wrote: >>>> >>>> On 05/05/2015 02:31 PM, Magnus Ihse Bursie wrote: >>>>> On 2015-02-13 12:01, Volker Simonis wrote: >>>>>> Hi, >>>>>> >>>>>> could somebody please review and sponsor the following small change >>>>>> which adds a test for exactly one newline at the and of a file to >>>>>> check: >>>>>> >>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2015/7901298/ >>>>>> https://bugs.openjdk.java.net/browse/CODETOOLS-7901298 >>>>> >>>>> Found this mail again now, when I wondered why it was not already fixed. >>>>> >>>>> The fix looks good to me, and I wish it was already in place :-). I'm >>>>> not a formal jcheck reviewer though. :( >>>>> >>>>> /Magnus >>>> >>>> Magnus, >>>> >>>> Please see the follow-up discussion on hg-tools-dev. >>>> http://mail.openjdk.java.net/pipermail/hg-tools-dev/2015-April/thread. >>>> html >>>> >>> >>> Quoting that discussion: >>>> Do all of the changesets (-r 0:tip) in all existing forests where >>>> jcheck is enabled pass with this change? >>> >>> Is it really the case that there can be no changes to jcheck which do not make all existing changesets in all existing forests pass? How on earth are we then ever going to be able to raise the bar for quality? >>> >>> /Magnus > From volker.simonis at gmail.com Wed May 13 07:35:46 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 13 May 2015 09:35:46 +0200 Subject: RFR(XS): 7901298: jcheck should check that every file ends with exactly one newline In-Reply-To: References: <554936C7.1060804@oracle.com> <554937B1.3040803@oracle.com> <55493BDB.9070108@oracle.com> <040387ea-703c-4b7c-82d9-7d40df256506@default> <8FB4AEC6-C515-4E23-BC13-F61CBFE93068@oracle.com> Message-ID: Ping... Can anybody please have a look at the new webrev? I think the proposed solution is not so bad :) Thanks, Volker On Thu, May 7, 2015 at 5:12 PM, Volker Simonis wrote: > Thanks Chris, > > I think now I got it. You are suggesting to configure the new feature > in .jcheck/conf right? > > OK, so what about this new version: > > http://cr.openjdk.java.net/~simonis/webrevs/2015/7901298.v2/ > > I've introduced a new attribute 'check_eof' in .jcheck/conf which > controls the behaviour of the new feature: > > # Test if we should check for a correct EOF (i.e. files end with > exatly one '\n') > # This behaviour is controlled by the 'check_eof' attribute in the conf file. > # -1 means to not check for EOF at all. > # 0 means to potentially check all the changes for a correct EOF. > # any other positive number is interpreted as the revision number or change- > # set ID from which on jcheck should start checking for a correct EOF. > # If the 'check_eof' attribute is missing, '-1' (i.e. no EOF check) > will be assumed. > > This way we can change jcheck and add the new EOF checking without > changing its behaviour on any existing, jcheck-enabled repositories. > Afterwards, any single repository can enable the EOF-checking from an > arbitrary changeset on-wards. > > What do you think, > Volker > > > On Thu, May 7, 2015 at 11:35 AM, Chris Hegarty wrote: >> Volker, >> >> I cannot answer the questions about the operation of the mercurial server, others better positioned than I should do that, but if jcheck is to ever evolve in a manner like you are suggesting then a repository may need a way to indicate to jcheck what level of checks should be done for certain regions of its history. Say, the .jcheck/conf file in the repo had an entry with a value of a changeset from where jcheck would enable this ?new? stricter checking. It would be opt in by the repo/project and could be configurable to its local history ( i.e. enable from this changeset hash onward ). Previous changsets would be checked as they are today. >> >> -Chris. >> >> On 7 May 2015, at 10:25, Volker Simonis wrote: >> >>> Hi Iris, >>> >>> can you please explain what you mean with "On push to a server, the >>> entire repository is checked for compliance to jcheck, not just the >>> pushed changesets". Is this really the case for every push - i.e. if I >>> push a change to lets say jdk9/dev/hotspot does this mean that jcheck >>> is really run on the revision range 0:tip? And if that's the case, >>> what's the reason for it? I don't understand what that should be good >>> for, because commited changes can not be changed anyway. >>> >>> I also doubt that 'hg jcheck --rev 0:tip' is really run on every push >>> simply because of performance reasons. When I push a change that's >>> usually a matter of seconds. But when I tested 'hg jcheck --rev 0:tip' >>> as I wrote in one of my previous mails that took more than 10 minutes >>> on the hotspot repository. >>> >>> So if it would turn out that 'hg jcheck --rev 0:tip' is only used in >>> special scenarios, would it be acceptable to use jcheck with a special >>> command line switch in these scenarios which turns the test for proper >>> EOF format off? I could add such a command line option if that would >>> make sense. >>> >>> But in my opinion, this new check only makes sense if it will be >>> enabled by default, otherwise nobody would use it. >>> >>> Regards, >>> Volker >>> >>> >>> On Wed, May 6, 2015 at 11:05 PM, Iris Clark wrote: >>>> Hi, Magnus. >>>> >>>>> Is it really the case that there can be no changes to jcheck which do not make all existing changesets in all existing forests pass? How on earth are we then ever going to be able to raise the bar for quality? >>>> >>>> Theoretically, I don't think that there's a problem with modifying jcheck to improve the quality of the code. The issue is that as the tool is currently written and used, there is no migration path for a higher bar. The provided patch does not include a solution to this problem. >>>> >>>> Thanks, >>>> iris >>>> >>>> -----Original Message----- >>>> From: Magnus Ihse Bursie >>>> Sent: Tuesday, May 05, 2015 2:54 PM >>>> To: Jonathan Gibbons; code-tools-dev at openjdk.java.net; hg-tools-dev at openjdk.java.net >>>> Subject: Re: RFR(XS): 7901298: jcheck should check that every file ends with exactly one newline >>>> >>>> On 2015-05-05 23:35, Jonathan Gibbons wrote: >>>>> >>>>> On 05/05/2015 02:31 PM, Magnus Ihse Bursie wrote: >>>>>> On 2015-02-13 12:01, Volker Simonis wrote: >>>>>>> Hi, >>>>>>> >>>>>>> could somebody please review and sponsor the following small change >>>>>>> which adds a test for exactly one newline at the and of a file to >>>>>>> check: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2015/7901298/ >>>>>>> https://bugs.openjdk.java.net/browse/CODETOOLS-7901298 >>>>>> >>>>>> Found this mail again now, when I wondered why it was not already fixed. >>>>>> >>>>>> The fix looks good to me, and I wish it was already in place :-). I'm >>>>>> not a formal jcheck reviewer though. :( >>>>>> >>>>>> /Magnus >>>>> >>>>> Magnus, >>>>> >>>>> Please see the follow-up discussion on hg-tools-dev. >>>>> http://mail.openjdk.java.net/pipermail/hg-tools-dev/2015-April/thread. >>>>> html >>>>> >>>> >>>> Quoting that discussion: >>>>> Do all of the changesets (-r 0:tip) in all existing forests where >>>>> jcheck is enabled pass with this change? >>>> >>>> Is it really the case that there can be no changes to jcheck which do not make all existing changesets in all existing forests pass? How on earth are we then ever going to be able to raise the bar for quality? >>>> >>>> /Magnus >> From chris.hegarty at oracle.com Wed May 13 09:37:18 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 13 May 2015 10:37:18 +0100 Subject: RFR(XS): 7901298: jcheck should check that every file ends with exactly one newline In-Reply-To: References: <554936C7.1060804@oracle.com> <554937B1.3040803@oracle.com> <55493BDB.9070108@oracle.com> <040387ea-703c-4b7c-82d9-7d40df256506@default> <8FB4AEC6-C515-4E23-BC13-F61CBFE93068@oracle.com> Message-ID: <55531B4E.3040406@oracle.com> On 13/05/15 08:35, Volker Simonis wrote: > Ping... > > Can anybody please have a look at the new webrev? I am not a Reviewer on this project, but I quickly skimmed the webrev and it seems ok. > I think the proposed solution is not so bad :) I agree. If we want to evolve jcheck in a manner that enables more strict checking, then such an approach seems reasonable. -Chris. > Thanks, > Volker > > > On Thu, May 7, 2015 at 5:12 PM, Volker Simonis wrote: >> Thanks Chris, >> >> I think now I got it. You are suggesting to configure the new feature >> in .jcheck/conf right? >> >> OK, so what about this new version: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2015/7901298.v2/ >> >> I've introduced a new attribute 'check_eof' in .jcheck/conf which >> controls the behaviour of the new feature: >> >> # Test if we should check for a correct EOF (i.e. files end with >> exatly one '\n') >> # This behaviour is controlled by the 'check_eof' attribute in the conf file. >> # -1 means to not check for EOF at all. >> # 0 means to potentially check all the changes for a correct EOF. >> # any other positive number is interpreted as the revision number or change- >> # set ID from which on jcheck should start checking for a correct EOF. >> # If the 'check_eof' attribute is missing, '-1' (i.e. no EOF check) >> will be assumed. >> >> This way we can change jcheck and add the new EOF checking without >> changing its behaviour on any existing, jcheck-enabled repositories. >> Afterwards, any single repository can enable the EOF-checking from an >> arbitrary changeset on-wards. >> >> What do you think, >> Volker >> >> >> On Thu, May 7, 2015 at 11:35 AM, Chris Hegarty wrote: >>> Volker, >>> >>> I cannot answer the questions about the operation of the mercurial server, others better positioned than I should do that, but if jcheck is to ever evolve in a manner like you are suggesting then a repository may need a way to indicate to jcheck what level of checks should be done for certain regions of its history. Say, the .jcheck/conf file in the repo had an entry with a value of a changeset from where jcheck would enable this ?new? stricter checking. It would be opt in by the repo/project and could be configurable to its local history ( i.e. enable from this changeset hash onward ). Previous changsets would be checked as they are today. >>> >>> -Chris. >>> >>> On 7 May 2015, at 10:25, Volker Simonis wrote: >>> >>>> Hi Iris, >>>> >>>> can you please explain what you mean with "On push to a server, the >>>> entire repository is checked for compliance to jcheck, not just the >>>> pushed changesets". Is this really the case for every push - i.e. if I >>>> push a change to lets say jdk9/dev/hotspot does this mean that jcheck >>>> is really run on the revision range 0:tip? And if that's the case, >>>> what's the reason for it? I don't understand what that should be good >>>> for, because commited changes can not be changed anyway. >>>> >>>> I also doubt that 'hg jcheck --rev 0:tip' is really run on every push >>>> simply because of performance reasons. When I push a change that's >>>> usually a matter of seconds. But when I tested 'hg jcheck --rev 0:tip' >>>> as I wrote in one of my previous mails that took more than 10 minutes >>>> on the hotspot repository. >>>> >>>> So if it would turn out that 'hg jcheck --rev 0:tip' is only used in >>>> special scenarios, would it be acceptable to use jcheck with a special >>>> command line switch in these scenarios which turns the test for proper >>>> EOF format off? I could add such a command line option if that would >>>> make sense. >>>> >>>> But in my opinion, this new check only makes sense if it will be >>>> enabled by default, otherwise nobody would use it. >>>> >>>> Regards, >>>> Volker >>>> >>>> >>>> On Wed, May 6, 2015 at 11:05 PM, Iris Clark wrote: >>>>> Hi, Magnus. >>>>> >>>>>> Is it really the case that there can be no changes to jcheck which do not make all existing changesets in all existing forests pass? How on earth are we then ever going to be able to raise the bar for quality? >>>>> >>>>> Theoretically, I don't think that there's a problem with modifying jcheck to improve the quality of the code. The issue is that as the tool is currently written and used, there is no migration path for a higher bar. The provided patch does not include a solution to this problem. >>>>> >>>>> Thanks, >>>>> iris >>>>> >>>>> -----Original Message----- >>>>> From: Magnus Ihse Bursie >>>>> Sent: Tuesday, May 05, 2015 2:54 PM >>>>> To: Jonathan Gibbons; code-tools-dev at openjdk.java.net; hg-tools-dev at openjdk.java.net >>>>> Subject: Re: RFR(XS): 7901298: jcheck should check that every file ends with exactly one newline >>>>> >>>>> On 2015-05-05 23:35, Jonathan Gibbons wrote: >>>>>> >>>>>> On 05/05/2015 02:31 PM, Magnus Ihse Bursie wrote: >>>>>>> On 2015-02-13 12:01, Volker Simonis wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> could somebody please review and sponsor the following small change >>>>>>>> which adds a test for exactly one newline at the and of a file to >>>>>>>> check: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2015/7901298/ >>>>>>>> https://bugs.openjdk.java.net/browse/CODETOOLS-7901298 >>>>>>> >>>>>>> Found this mail again now, when I wondered why it was not already fixed. >>>>>>> >>>>>>> The fix looks good to me, and I wish it was already in place :-). I'm >>>>>>> not a formal jcheck reviewer though. :( >>>>>>> >>>>>>> /Magnus >>>>>> >>>>>> Magnus, >>>>>> >>>>>> Please see the follow-up discussion on hg-tools-dev. >>>>>> http://mail.openjdk.java.net/pipermail/hg-tools-dev/2015-April/thread. >>>>>> html >>>>>> >>>>> >>>>> Quoting that discussion: >>>>>> Do all of the changesets (-r 0:tip) in all existing forests where >>>>>> jcheck is enabled pass with this change? >>>>> >>>>> Is it really the case that there can be no changes to jcheck which do not make all existing changesets in all existing forests pass? How on earth are we then ever going to be able to raise the bar for quality? >>>>> >>>>> /Magnus >>> From magnus.ihse.bursie at oracle.com Mon May 25 10:13:06 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 25 May 2015 12:13:06 +0200 Subject: RFR(XS): 7901298: jcheck should check that every file ends with exactly one newline In-Reply-To: <55531B4E.3040406@oracle.com> References: <554936C7.1060804@oracle.com> <554937B1.3040803@oracle.com> <55493BDB.9070108@oracle.com> <040387ea-703c-4b7c-82d9-7d40df256506@default> <8FB4AEC6-C515-4E23-BC13-F61CBFE93068@oracle.com> <55531B4E.3040406@oracle.com> Message-ID: <5562F5B2.5000604@oracle.com> On 2015-05-13 11:37, Chris Hegarty wrote: > On 13/05/15 08:35, Volker Simonis wrote: >> Ping... >> >> Can anybody please have a look at the new webrev? > > I am not a Reviewer on this project, but I quickly skimmed the webrev > and it seems ok. > >> I think the proposed solution is not so bad :) > > I agree. If we want to evolve jcheck in a manner that enables more > strict checking, then such an approach seems reasonable. I seems that this approach will lead to each improvement requiring a new line in the configuration. I think that's not ideal. But then again, we need *some* way of being able to evolve jcheck. And if the requirement is to be backward compatible with all previous commits, then this might be the only way. So I'm in favour for Volker's fix, at least until someone finds a better way to evolve jcheck. /Magnus From volker.simonis at gmail.com Mon May 25 14:12:29 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 25 May 2015 16:12:29 +0200 Subject: RFR(XS): 7901298: jcheck should check that every file ends with exactly one newline In-Reply-To: <5562F5B2.5000604@oracle.com> References: <554936C7.1060804@oracle.com> <554937B1.3040803@oracle.com> <55493BDB.9070108@oracle.com> <040387ea-703c-4b7c-82d9-7d40df256506@default> <8FB4AEC6-C515-4E23-BC13-F61CBFE93068@oracle.com> <55531B4E.3040406@oracle.com> <5562F5B2.5000604@oracle.com> Message-ID: Thanks for the review Magnus. Volker On Mon, May 25, 2015 at 12:13 PM, Magnus Ihse Bursie wrote: > On 2015-05-13 11:37, Chris Hegarty wrote: >> >> On 13/05/15 08:35, Volker Simonis wrote: >>> >>> Ping... >>> >>> Can anybody please have a look at the new webrev? >> >> >> I am not a Reviewer on this project, but I quickly skimmed the webrev and >> it seems ok. >> >>> I think the proposed solution is not so bad :) >> >> >> I agree. If we want to evolve jcheck in a manner that enables more strict >> checking, then such an approach seems reasonable. > > > I seems that this approach will lead to each improvement requiring a new > line in the configuration. I think that's not ideal. But then again, we need > *some* way of being able to evolve jcheck. And if the requirement is to be > backward compatible with all previous commits, then this might be the only > way. > > So I'm in favour for Volker's fix, at least until someone finds a better way > to evolve jcheck. > > /Magnus