From jonathan.gibbons at oracle.com Fri May 1 00:26:20 2015 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 30 Apr 2015 17:26:20 -0700 Subject: RFR(S): 7901304: IDPREFIX should be configurable from the environment much like BUGURL already is In-Reply-To: References: <5541514C.6090604@oracle.com> Message-ID: <5542C82C.5070102@oracle.com> On 04/30/2015 03:07 AM, Volker Simonis wrote: > On Wed, Apr 29, 2015 at 11:46 PM, Jonathan Gibbons > wrote: >> On 02/13/2015 10:01 AM, Volker Simonis wrote: >>> Hi, >>> >>> could somebody please review and sponsor the following small change: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/2015/7901304/ >>> https://bugs.openjdk.java.net/browse/CODETOOLS-7901304 >>> >>> It is possible to configure the bug url for links to the corresponding >>> OpenJDK bugs by setting the environment variable WEBREV_BUGURL. >>> >>> Unfortunately it is not possible to configure the IDPREFIX which is >>> hard-wired to "JDK-". This makes it impossible to create links to the >>> bug systems for projects like CODETOOLS. >>> >>> The fix is easy - just read IDPREFIX from the environment if there >>> exists an environment variable called WEBREV_IDPREFIX (by the way, the >>> result can be seen in the webrev which correctly links to the >>> corresponding codetools bug :). >>> >>> I've also slightly reordered the place where WEBREV_BUGURL and >>> WEBREV_IDPREFIX are initialized to make it possible to print their >>> default values in the webrev usage text. >>> >>> Regards, >>> Volker >> >> Volker, >> >> This looks like a useful patch. >> > Thanks! > >> Note that round about line 30, there is a variable WEBREV_UPDATED >> which we have been inconsistent in updated, but have been more >> consistent of late. The number gets updated; the additional string >> after the "-" looks a bit moire cryptic. >> > Not sure if I understand you right. Do you want me to bump the version > number in WEBREV_UPDATED in my change? > > I need a sponsor anyway as I can't commit to the code-tools repo. Will > you sponsor this change? > > Thank you and best regards, > Volker > >> -- Jon I'll sponsor it; I'll update the WEBREV_UPDATED unless you send me a new patch before I get round to it. -- Jon From sbaiduzh at redhat.com Mon May 4 12:56:53 2015 From: sbaiduzh at redhat.com (Stanislav Baiduzhyi) Date: Mon, 04 May 2015 14:56:53 +0200 Subject: Webrev: "arithmetic syntax error" when working with non-commited changes Message-ID: <1952342.tG88LHOKTp@thinkpad.hell> Hi All, I'm getting multiple "arithmetic syntax error" when working with non-commited changes. I've made a small fix, could anyone please take a look, and incorporate those changes into upstream if you like the fix? https://e5decb045a719fb58df46fd7e03c2f98cddc1ac6.googledrive.com/host/0B5Kp-cB1sXJrfk9NQTVHMTJTdWpYX3dWaExreWN0V0hQZ3d0eGIyZDltdHBCbmhYcXpzRFk/fix-arithmetic/ -- Regards, Stas From magnus.ihse.bursie at oracle.com Tue May 5 21:31:51 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 05 May 2015 23:31:51 +0200 Subject: RFR(XS): 7901298: jcheck should check that every file ends with exactly one newline In-Reply-To: References: Message-ID: <554936C7.1060804@oracle.com> 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 From jonathan.gibbons at oracle.com Tue May 5 21:35:45 2015 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 05 May 2015 14:35:45 -0700 Subject: RFR(XS): 7901298: jcheck should check that every file ends with exactly one newline In-Reply-To: <554936C7.1060804@oracle.com> References: <554936C7.1060804@oracle.com> Message-ID: <554937B1.3040803@oracle.com> 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 -- Jon From magnus.ihse.bursie at oracle.com Tue May 5 21:36:56 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 05 May 2015 23:36:56 +0200 Subject: Webrev: "arithmetic syntax error" when working with non-commited changes In-Reply-To: <1952342.tG88LHOKTp@thinkpad.hell> References: <1952342.tG88LHOKTp@thinkpad.hell> Message-ID: <554937F8.9080906@oracle.com> On 2015-05-04 14:56, Stanislav Baiduzhyi wrote: > Hi All, > > I'm getting multiple "arithmetic syntax error" when working with non-commited > changes. I've made a small fix, could anyone please take a look, and > incorporate those changes into upstream if you like the fix? > > https://e5decb045a719fb58df46fd7e03c2f98cddc1ac6.googledrive.com/host/0B5Kp-cB1sXJrfk9NQTVHMTJTdWpYX3dWaExreWN0V0hQZ3d0eGIyZDltdHBCbmhYcXpzRFk/fix-arithmetic/ > Hi Stanislav, While the changes look reasonable, I'm curious why this hasn't surfaced as a problem before. The missing $ just looks plain broken, but why is the extra -n test needed? What do you do to trigger the problem? What version of ksh are you using? /Magnus 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 jonathan.gibbons at oracle.com Tue May 5 23:50:13 2015 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 05 May 2015 16:50:13 -0700 Subject: RFR(S): 7901304: IDPREFIX should be configurable from the environment much like BUGURL already is In-Reply-To: <5542C82C.5070102@oracle.com> References: <5541514C.6090604@oracle.com> <5542C82C.5070102@oracle.com> Message-ID: <55495735.4010104@oracle.com> Done. http://hg.openjdk.java.net/code-tools/webrev/rev/48291a35a740 -- Jon On 04/30/2015 05:26 PM, Jonathan Gibbons wrote: > > On 04/30/2015 03:07 AM, Volker Simonis wrote: >> On Wed, Apr 29, 2015 at 11:46 PM, Jonathan Gibbons >> wrote: >>> On 02/13/2015 10:01 AM, Volker Simonis wrote: >>>> Hi, >>>> >>>> could somebody please review and sponsor the following small change: >>>> >>>> http://cr.openjdk.java.net/~simonis/webrevs/2015/7901304/ >>>> https://bugs.openjdk.java.net/browse/CODETOOLS-7901304 >>>> >>>> It is possible to configure the bug url for links to the corresponding >>>> OpenJDK bugs by setting the environment variable WEBREV_BUGURL. >>>> >>>> Unfortunately it is not possible to configure the IDPREFIX which is >>>> hard-wired to "JDK-". This makes it impossible to create links to the >>>> bug systems for projects like CODETOOLS. >>>> >>>> The fix is easy - just read IDPREFIX from the environment if there >>>> exists an environment variable called WEBREV_IDPREFIX (by the way, the >>>> result can be seen in the webrev which correctly links to the >>>> corresponding codetools bug :). >>>> >>>> I've also slightly reordered the place where WEBREV_BUGURL and >>>> WEBREV_IDPREFIX are initialized to make it possible to print their >>>> default values in the webrev usage text. >>>> >>>> Regards, >>>> Volker >>> >>> Volker, >>> >>> This looks like a useful patch. >>> >> Thanks! >> >>> Note that round about line 30, there is a variable WEBREV_UPDATED >>> which we have been inconsistent in updated, but have been more >>> consistent of late. The number gets updated; the additional string >>> after the "-" looks a bit moire cryptic. >>> >> Not sure if I understand you right. Do you want me to bump the version >> number in WEBREV_UPDATED in my change? >> >> I need a sponsor anyway as I can't commit to the code-tools repo. Will >> you sponsor this change? >> >> Thank you and best regards, >> Volker >> >>> -- Jon > > I'll sponsor it; I'll update the WEBREV_UPDATED unless you send me a > new patch before I get round to it. > > -- Jon From sbaiduzh at redhat.com Wed May 6 09:15:30 2015 From: sbaiduzh at redhat.com (Stanislav Baiduzhyi) Date: Wed, 06 May 2015 11:15:30 +0200 Subject: Webrev: "arithmetic syntax error" when working with non-commited changes In-Reply-To: <554937F8.9080906@oracle.com> References: <1952342.tG88LHOKTp@thinkpad.hell> <554937F8.9080906@oracle.com> Message-ID: <2055994.FkmW1OYQrd@thinkpad.hell> On Tuesday 05 May 2015 23:36:56 Magnus Ihse Bursie wrote: > On 2015-05-04 14:56, Stanislav Baiduzhyi wrote: > > Hi All, > > > > I'm getting multiple "arithmetic syntax error" when working with > > non-commited changes. I've made a small fix, could anyone please take a > > look, and incorporate those changes into upstream if you like the fix? > > > > https://e5decb045a719fb58df46fd7e03c2f98cddc1ac6.googledrive.com/host/0B5K > > p-cB1sXJrfk9NQTVHMTJTdWpYX3dWaExreWN0V0hQZ3d0eGIyZDltdHBCbmhYcXpzRFk/fix-a > > rithmetic/ > Hi Stanislav, > > While the changes look reasonable, I'm curious why this hasn't surfaced > as a problem before. The missing $ just looks plain broken, but why is > the extra -n test needed? > > What do you do to trigger the problem? What version of ksh are you using? Hi Magnus, Thanx for your reply. I was wondering myself how is this possible. I'm using the tip from http://hg.openjdk.java.net/code-tools/webrev/ . I think it works fine without that -n check, error only goes to output and as in any shell the failing command means 'false'. So that check only affects the output. Distribution is openSUSE 13.2. Reproducing the issue like this: $ ksh --version version sh (AT&T Research) 93v- 2014-06-25 $ hg clone http://hg.openjdk.java.net/code-tools/webrev/ $ cd webrev # changing anything: $ echo 'echo "the quick brown fox"' >>webrev.ksh # launching webrev: $ ksh webrev.ksh -N -m -u 'Stanislav Baiduzhyi' SCM detected: mercurial No outgoing, perhaps you haven't commited. Workspace: /home/user/work/src/jdk-dev/showroom/webrev Output to: /home/user/work/src/jdk-dev/showroom/webrev/webrev Output Files: webrev.ksh: line 2282: i: arithmetic syntax error # fixing the missing $ error: $ sed -i 's;\[\[ i -lt;\[\[ $i -lt;' webrev.ksh # trying once again: $ ksh webrev.ksh -N -m -u 'Stanislav Baiduzhyi' SCM detected: mercurial No outgoing, perhaps you haven't commited. Workspace: /home/user/work/src/jdk-dev/showroom/webrev Output to: /home/user/work/src/jdk-dev/showroom/webrev/webrev Output Files: webrev.ksh webrev.ksh[2366]: build_old_new[1792]: build_old_new_mercurial[1744]: [: : arithmetic syntax error patch cdiffs udiffs sdiffs frames old new index.html: Done. Output to: /home/user/work/src/jdk-dev/showroom/webrev/webrev the quick brown fox -- Regards, Stas 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 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 sbaiduzh at redhat.com Tue May 12 09:29:15 2015 From: sbaiduzh at redhat.com (Stanislav Baiduzhyi) Date: Tue, 12 May 2015 11:29:15 +0200 Subject: Webrev: "arithmetic syntax error" when working with non-commited changes In-Reply-To: <2055994.FkmW1OYQrd@thinkpad.hell> References: <1952342.tG88LHOKTp@thinkpad.hell> <554937F8.9080906@oracle.com> <2055994.FkmW1OYQrd@thinkpad.hell> Message-ID: <3979298.oDf0PLx1Pc@thinkpad.hell> On Wednesday 06 May 2015 11:15:30 Stanislav Baiduzhyi wrote: > On Tuesday 05 May 2015 23:36:56 Magnus Ihse Bursie wrote: > > On 2015-05-04 14:56, Stanislav Baiduzhyi wrote: > > > Hi All, > > > > > > I'm getting multiple "arithmetic syntax error" when working with > > > non-commited changes. I've made a small fix, could anyone please take a > > > look, and incorporate those changes into upstream if you like the fix? > > > > > > https://e5decb045a719fb58df46fd7e03c2f98cddc1ac6.googledrive.com/host/0B > > > 5K > > > p-cB1sXJrfk9NQTVHMTJTdWpYX3dWaExreWN0V0hQZ3d0eGIyZDltdHBCbmhYcXpzRFk/fix > > > -a > > > rithmetic/ > > > > Hi Stanislav, > > > > While the changes look reasonable, I'm curious why this hasn't surfaced > > as a problem before. The missing $ just looks plain broken, but why is > > the extra -n test needed? > > > > What do you do to trigger the problem? What version of ksh are you using? > > Hi Magnus, > > Thanx for your reply. I was wondering myself how is this possible. I'm using > the tip from http://hg.openjdk.java.net/code-tools/webrev/ . I think it > works fine without that -n check, error only goes to output and as in any > shell the failing command means 'false'. So that check only affects the > output. > > Distribution is openSUSE 13.2. > > Reproducing the issue like this: > $ ksh --version > version sh (AT&T Research) 93v- 2014-06-25 > $ hg clone http://hg.openjdk.java.net/code-tools/webrev/ > $ cd webrev > # changing anything: > $ echo 'echo "the quick brown fox"' >>webrev.ksh > # launching webrev: > $ ksh webrev.ksh -N -m -u 'Stanislav Baiduzhyi' > SCM detected: mercurial > > No outgoing, perhaps you haven't commited. > Workspace: /home/user/work/src/jdk-dev/showroom/webrev > Output to: /home/user/work/src/jdk-dev/showroom/webrev/webrev > Output Files: > webrev.ksh: line 2282: i: arithmetic syntax error > # fixing the missing $ error: > $ sed -i 's;\[\[ i -lt;\[\[ $i -lt;' webrev.ksh > # trying once again: > $ ksh webrev.ksh -N -m -u 'Stanislav Baiduzhyi' > SCM detected: mercurial > > No outgoing, perhaps you haven't commited. > Workspace: /home/user/work/src/jdk-dev/showroom/webrev > Output to: /home/user/work/src/jdk-dev/showroom/webrev/webrev > Output Files: > webrev.ksh > webrev.ksh[2366]: build_old_new[1792]: > build_old_new_mercurial[1744]: [: : arithmetic syntax error > patch cdiffs udiffs sdiffs frames old new > index.html: Done. > Output to: /home/user/work/src/jdk-dev/showroom/webrev/webrev > the quick brown fox Any news on this issue? Am I using the webrev in a way it was intended to or am I encountering those issues because I'm doing something wrong? -- Regards, Stas From jonathan.gibbons at oracle.com Wed May 13 00:06:37 2015 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 12 May 2015 17:06:37 -0700 Subject: Webrev: "arithmetic syntax error" when working with non-commited changes In-Reply-To: <3979298.oDf0PLx1Pc@thinkpad.hell> References: <1952342.tG88LHOKTp@thinkpad.hell> <554937F8.9080906@oracle.com> <2055994.FkmW1OYQrd@thinkpad.hell> <3979298.oDf0PLx1Pc@thinkpad.hell> Message-ID: <5552958D.2090805@oracle.com> There has been some churn recently with respect to the variable HG_LIST_FROM_COMMIT. See http://hg.openjdk.java.net/code-tools/webrev/rev/935f1eaa4691 http://hg.openjdk.java.net/code-tools/webrev/rev/09eb35524f9a Therefore, I would suggest whether this needs to be re-investigated in the light of those recent changes. In particular, the tip has changed since this thread started. -- Jon On 05/12/2015 02:29 AM, Stanislav Baiduzhyi wrote: > On Wednesday 06 May 2015 11:15:30 Stanislav Baiduzhyi wrote: >> On Tuesday 05 May 2015 23:36:56 Magnus Ihse Bursie wrote: >>> On 2015-05-04 14:56, Stanislav Baiduzhyi wrote: >>>> Hi All, >>>> >>>> I'm getting multiple "arithmetic syntax error" when working with >>>> non-commited changes. I've made a small fix, could anyone please take a >>>> look, and incorporate those changes into upstream if you like the fix? >>>> >>>> https://e5decb045a719fb58df46fd7e03c2f98cddc1ac6.googledrive.com/host/0B >>>> 5K >>>> p-cB1sXJrfk9NQTVHMTJTdWpYX3dWaExreWN0V0hQZ3d0eGIyZDltdHBCbmhYcXpzRFk/fix >>>> -a >>>> rithmetic/ >>> Hi Stanislav, >>> >>> While the changes look reasonable, I'm curious why this hasn't surfaced >>> as a problem before. The missing $ just looks plain broken, but why is >>> the extra -n test needed? >>> >>> What do you do to trigger the problem? What version of ksh are you using? >> Hi Magnus, >> >> Thanx for your reply. I was wondering myself how is this possible. I'm using >> the tip from http://hg.openjdk.java.net/code-tools/webrev/ . I think it >> works fine without that -n check, error only goes to output and as in any >> shell the failing command means 'false'. So that check only affects the >> output. >> >> Distribution is openSUSE 13.2. >> >> Reproducing the issue like this: >> $ ksh --version >> version sh (AT&T Research) 93v- 2014-06-25 >> $ hg clone http://hg.openjdk.java.net/code-tools/webrev/ >> $ cd webrev >> # changing anything: >> $ echo 'echo "the quick brown fox"' >>webrev.ksh >> # launching webrev: >> $ ksh webrev.ksh -N -m -u 'Stanislav Baiduzhyi' >> SCM detected: mercurial >> >> No outgoing, perhaps you haven't commited. >> Workspace: /home/user/work/src/jdk-dev/showroom/webrev >> Output to: /home/user/work/src/jdk-dev/showroom/webrev/webrev >> Output Files: >> webrev.ksh: line 2282: i: arithmetic syntax error >> # fixing the missing $ error: >> $ sed -i 's;\[\[ i -lt;\[\[ $i -lt;' webrev.ksh >> # trying once again: >> $ ksh webrev.ksh -N -m -u 'Stanislav Baiduzhyi' >> SCM detected: mercurial >> >> No outgoing, perhaps you haven't commited. >> Workspace: /home/user/work/src/jdk-dev/showroom/webrev >> Output to: /home/user/work/src/jdk-dev/showroom/webrev/webrev >> Output Files: >> webrev.ksh >> webrev.ksh[2366]: build_old_new[1792]: >> build_old_new_mercurial[1744]: [: : arithmetic syntax error >> patch cdiffs udiffs sdiffs frames old new >> index.html: Done. >> Output to: /home/user/work/src/jdk-dev/showroom/webrev/webrev >> the quick brown fox > Any news on this issue? Am I using the webrev in a way it was intended to or > am I encountering those issues because I'm doing something wrong? > 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 sbaiduzh at redhat.com Wed May 13 08:01:39 2015 From: sbaiduzh at redhat.com (Stanislav Baiduzhyi) Date: Wed, 13 May 2015 10:01:39 +0200 Subject: Webrev: "arithmetic syntax error" when working with non-commited changes In-Reply-To: <5552958D.2090805@oracle.com> References: <1952342.tG88LHOKTp@thinkpad.hell> <3979298.oDf0PLx1Pc@thinkpad.hell> <5552958D.2090805@oracle.com> Message-ID: <8626727.vX7Ee776rh@thinkpad.hell> On Tuesday 12 May 2015 17:06:37 Jonathan Gibbons wrote: > There has been some churn recently with respect to the variable > HG_LIST_FROM_COMMIT. > > See > http://hg.openjdk.java.net/code-tools/webrev/rev/935f1eaa4691 > http://hg.openjdk.java.net/code-tools/webrev/rev/09eb35524f9a > > Therefore, I would suggest whether this needs to be re-investigated in > the light of those recent changes. In particular, the tip has changed > since this thread started. Issue still exists in current tip. I've updated the webrev, link is the same: https://e5decb045a719fb58df46fd7e03c2f98cddc1ac6.googledrive.com/host/0B5Kp-cB1sXJrfk9NQTVHMTJTdWpYX3dWaExreWN0V0hQZ3d0eGIyZDltdHBCbmhYcXpzRFk/fix-arithmetic/ > > -- Jon > > On 05/12/2015 02:29 AM, Stanislav Baiduzhyi wrote: > > On Wednesday 06 May 2015 11:15:30 Stanislav Baiduzhyi wrote: > >> On Tuesday 05 May 2015 23:36:56 Magnus Ihse Bursie wrote: > >>> On 2015-05-04 14:56, Stanislav Baiduzhyi wrote: > >>>> Hi All, > >>>> > >>>> I'm getting multiple "arithmetic syntax error" when working with > >>>> non-commited changes. I've made a small fix, could anyone please take a > >>>> look, and incorporate those changes into upstream if you like the fix? > >>>> > >>>> https://e5decb045a719fb58df46fd7e03c2f98cddc1ac6.googledrive.com/host/0 > >>>> B > >>>> 5K > >>>> p-cB1sXJrfk9NQTVHMTJTdWpYX3dWaExreWN0V0hQZ3d0eGIyZDltdHBCbmhYcXpzRFk/fi > >>>> x > >>>> -a > >>>> rithmetic/ > >>> > >>> Hi Stanislav, > >>> > >>> While the changes look reasonable, I'm curious why this hasn't surfaced > >>> as a problem before. The missing $ just looks plain broken, but why is > >>> the extra -n test needed? > >>> > >>> What do you do to trigger the problem? What version of ksh are you > >>> using? > >> > >> Hi Magnus, > >> > >> Thanx for your reply. I was wondering myself how is this possible. I'm > >> using the tip from http://hg.openjdk.java.net/code-tools/webrev/ . I > >> think it works fine without that -n check, error only goes to output and > >> as in any shell the failing command means 'false'. So that check only > >> affects the output. > >> > >> Distribution is openSUSE 13.2. > >> > >> Reproducing the issue like this: > >> $ ksh --version > >> > >> version sh (AT&T Research) 93v- 2014-06-25 > >> > >> $ hg clone http://hg.openjdk.java.net/code-tools/webrev/ > >> $ cd webrev > >> # changing anything: > >> $ echo 'echo "the quick brown fox"' >>webrev.ksh > >> # launching webrev: > >> $ ksh webrev.ksh -N -m -u 'Stanislav Baiduzhyi' > >> > >> SCM detected: mercurial > >> > >> No outgoing, perhaps you haven't commited. > >> > >> Workspace: /home/user/work/src/jdk-dev/showroom/webrev > >> Output to: /home/user/work/src/jdk-dev/showroom/webrev/webrev > >> > >> Output Files: > >> webrev.ksh: line 2282: i: arithmetic syntax error > >> # fixing the missing $ error: > >> $ sed -i 's;\[\[ i -lt;\[\[ $i -lt;' webrev.ksh > >> # trying once again: > >> $ ksh webrev.ksh -N -m -u 'Stanislav Baiduzhyi' > >> > >> SCM detected: mercurial > >> > >> No outgoing, perhaps you haven't commited. > >> > >> Workspace: /home/user/work/src/jdk-dev/showroom/webrev > >> Output to: /home/user/work/src/jdk-dev/showroom/webrev/webrev > >> > >> Output Files: > >> webrev.ksh > >> > >> webrev.ksh[2366]: build_old_new[1792]: > >> build_old_new_mercurial[1744]: [: : arithmetic syntax error > >> > >> patch cdiffs udiffs sdiffs frames old new > >> > >> index.html: Done. > >> > >> Output to: /home/user/work/src/jdk-dev/showroom/webrev/webrev > >> the quick brown fox > > > > Any news on this issue? Am I using the webrev in a way it was intended to > > or am I encountering those issues because I'm doing something wrong? -- Regards, Stas From sbaiduzh at redhat.com Wed May 20 08:26:02 2015 From: sbaiduzh at redhat.com (Stanislav Baiduzhyi) Date: Wed, 20 May 2015 10:26:02 +0200 Subject: Webrev: "arithmetic syntax error" when working with non-commited changes In-Reply-To: <8626727.vX7Ee776rh@thinkpad.hell> References: <1952342.tG88LHOKTp@thinkpad.hell> <5552958D.2090805@oracle.com> <8626727.vX7Ee776rh@thinkpad.hell> Message-ID: <4106910.qMKm2oGpkj@thinkpad.hell> On Wednesday 13 May 2015 10:01:39 Stanislav Baiduzhyi wrote: > On Tuesday 12 May 2015 17:06:37 Jonathan Gibbons wrote: > > There has been some churn recently with respect to the variable > > HG_LIST_FROM_COMMIT. > > > > See > > http://hg.openjdk.java.net/code-tools/webrev/rev/935f1eaa4691 > > http://hg.openjdk.java.net/code-tools/webrev/rev/09eb35524f9a > > > > Therefore, I would suggest whether this needs to be re-investigated in > > the light of those recent changes. In particular, the tip has changed > > since this thread started. > > Issue still exists in current tip. I've updated the webrev, link is the > same: > https://e5decb045a719fb58df46fd7e03c2f98cddc1ac6.googledrive.com/host/0B5Kp > -cB1sXJrfk9NQTVHMTJTdWpYX3dWaExreWN0V0hQZ3d0eGIyZDltdHBCbmhYcXpzRFk/fix-arit > hmetic/ I've experimented more with that empty value check because I still had a feeling that it was not logical. Looks like changing from classical shell braces [ to double braces [[ solves the issue already, no need for additional check. So now it's literally 3 bytes change. Please apply it before any other changes are going upstream. -- Regards, Stas From jonathan.gibbons at oracle.com Thu May 21 01:35:23 2015 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 20 May 2015 18:35:23 -0700 Subject: Webrev: "arithmetic syntax error" when working with non-commited changes In-Reply-To: <4106910.qMKm2oGpkj@thinkpad.hell> References: <1952342.tG88LHOKTp@thinkpad.hell> <5552958D.2090805@oracle.com> <8626727.vX7Ee776rh@thinkpad.hell> <4106910.qMKm2oGpkj@thinkpad.hell> Message-ID: <555D365B.2000105@oracle.com> On 05/20/2015 01:26 AM, Stanislav Baiduzhyi wrote: > On Wednesday 13 May 2015 10:01:39 Stanislav Baiduzhyi wrote: >> On Tuesday 12 May 2015 17:06:37 Jonathan Gibbons wrote: >>> There has been some churn recently with respect to the variable >>> HG_LIST_FROM_COMMIT. >>> >>> See >>> http://hg.openjdk.java.net/code-tools/webrev/rev/935f1eaa4691 >>> http://hg.openjdk.java.net/code-tools/webrev/rev/09eb35524f9a >>> >>> Therefore, I would suggest whether this needs to be re-investigated in >>> the light of those recent changes. In particular, the tip has changed >>> since this thread started. >> Issue still exists in current tip. I've updated the webrev, link is the >> same: >> https://e5decb045a719fb58df46fd7e03c2f98cddc1ac6.googledrive.com/host/0B5Kp >> -cB1sXJrfk9NQTVHMTJTdWpYX3dWaExreWN0V0hQZ3d0eGIyZDltdHBCbmhYcXpzRFk/fix-arit >> hmetic/ > I've experimented more with that empty value check because I still had a > feeling that it was not logical. Looks like changing from classical shell > braces [ to double braces [[ solves the issue already, no need for additional > check. So now it's literally 3 bytes change. Please apply it before any other > changes are going upstream. > Interesting. I see the webrev man page specifies the use of [[ ]] (e.g. here http://www2.research.att.com/sw/download/man/man1/ksh.html) and I see the webrev script already has other instances of [[ ]]. So, the change certainly looks reasonable. Does anyone wish to confirm this behavior? If no one objects, I'll push the change. -- Jon From magnus.ihse.bursie at oracle.com Mon May 25 09:57:51 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 25 May 2015 11:57:51 +0200 Subject: Webrev: "arithmetic syntax error" when working with non-commited changes In-Reply-To: <555D365B.2000105@oracle.com> References: <1952342.tG88LHOKTp@thinkpad.hell> <5552958D.2090805@oracle.com> <8626727.vX7Ee776rh@thinkpad.hell> <4106910.qMKm2oGpkj@thinkpad.hell> <555D365B.2000105@oracle.com> Message-ID: <5562F21F.4090201@oracle.com> On 2015-05-21 03:35, Jonathan Gibbons wrote: > > On 05/20/2015 01:26 AM, Stanislav Baiduzhyi wrote: >> On Wednesday 13 May 2015 10:01:39 Stanislav Baiduzhyi wrote: >>> On Tuesday 12 May 2015 17:06:37 Jonathan Gibbons wrote: >>>> There has been some churn recently with respect to the variable >>>> HG_LIST_FROM_COMMIT. >>>> >>>> See >>>> http://hg.openjdk.java.net/code-tools/webrev/rev/935f1eaa4691 >>>> http://hg.openjdk.java.net/code-tools/webrev/rev/09eb35524f9a >>>> >>>> Therefore, I would suggest whether this needs to be re-investigated in >>>> the light of those recent changes. In particular, the tip has changed >>>> since this thread started. >>> Issue still exists in current tip. I've updated the webrev, link is the >>> same: >>> https://e5decb045a719fb58df46fd7e03c2f98cddc1ac6.googledrive.com/host/0B5Kp >>> >>> -cB1sXJrfk9NQTVHMTJTdWpYX3dWaExreWN0V0hQZ3d0eGIyZDltdHBCbmhYcXpzRFk/fix-arit >>> >>> hmetic/ >> I've experimented more with that empty value check because I still had a >> feeling that it was not logical. Looks like changing from classical >> shell >> braces [ to double braces [[ solves the issue already, no need for >> additional >> check. So now it's literally 3 bytes change. Please apply it before >> any other >> changes are going upstream. >> > > Interesting. I see the webrev man page specifies the use of [[ ]] > (e.g. here http://www2.research.att.com/sw/download/man/man1/ksh.html) > and I see the webrev script already has other instances of [[ ]]. > > So, the change certainly looks reasonable. Does anyone wish to confirm > this behavior? If no one objects, I'll push the change. Fix looks good to me. /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 From chris.hegarty at oracle.com Thu May 7 09:35:49 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 07 May 2015 09:35:49 -0000 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 chris.hegarty at oracle.com Wed May 13 09:37:23 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 13 May 2015 09:37:23 -0000 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 >>>