[PATCH] test-convert-cvs: change TZ=US/Hawaii to TZ=Pacific/Johnston
# HG changeset patch # User Elmar Bartel # Date 1514821711 -3600 # Mon Jan 01 16:48:31 2018 +0100 # Node ID 5206245f023fbf64abe6c99bc93a0ac7d451f588 # Parent eac82bbc886901b154516afe3e742eb5aa96c917 test-convert-cvs: change TZ=US/Hawaii to TZ=Pacific/Johnston The former was limited to be known on Linux and the test failed on FreeBSD and Solaris platforms. The newer is known on Linux, FreeBSD and Solaris. diff -r eac82bbc8869 -r 5206245f023f tests/test-convert-cvs.t --- a/tests/test-convert-cvs.t Sun Dec 31 18:04:26 2017 +0100 +++ b/tests/test-convert-cvs.t Mon Jan 01 16:48:31 2018 +0100 @@ -80,7 +80,12 @@ An arbitrary (U.S.) time zone is used he since it does not use DST (unlike other U.S. time zones) and is always a fixed difference from UTC. - $ TZ=US/Hawaii hg convert --config convert.localtimezone=True src src-hg +This choice is limited to work on Linux environments. At least on +FreeBSD 11 this timezone is not known. A better choice is +TZ=Pacific/Johnston. On Linux "US/Hawaii" is just a symlink to this +name and also it is known on FreeBSD and on Solaris. + + $ TZ=Pacific/Johnston hg convert --config convert.localtimezone=True src src-hg initializing destination src-hg repository connecting to $TESTTMP/cvsrepo scanning source... @@ -170,7 +175,7 @@ commit new file revisions convert again - $ TZ=US/Hawaii hg convert --config convert.localtimezone=True src src-hg + $ TZ=Pacific/Johnston hg convert --config convert.localtimezone=True src src-hg connecting to $TESTTMP/cvsrepo scanning source... collecting CVS rlog @@ -231,7 +236,7 @@ commit branch convert again - $ TZ=US/Hawaii hg convert --config convert.localtimezone=True src src-hg + $ TZ=Pacific/Johnston hg convert --config convert.localtimezone=True src src-hg connecting to $TESTTMP/cvsrepo scanning source... collecting CVS rlog @@ -249,7 +254,7 @@ convert again convert again with --filemap - $ TZ=US/Hawaii hg convert --config convert.localtimezone=True --filemap filemap src src-filemap + $ TZ=Pacific/Johnston hg convert --config convert.localtimezone=True --filemap filemap src src-filemap connecting to $TESTTMP/cvsrepo scanning source... collecting CVS rlog @@ -296,7 +301,7 @@ commit new file revisions with some fuzz convert again - $ TZ=US/Hawaii hg convert --config convert.cvsps.fuzz=2 --config convert.localtimezone=True src src-hg + $ TZ=Pacific/Johnston hg convert --config convert.cvsps.fuzz=2 --config convert.localtimezone=True src src-hg connecting to $TESTTMP/cvsrepo scanning source... collecting CVS rlog ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
[PATCH] crecord: honor "ui.color = no" config option
mercurial/crecord.py | 21 -
1 files changed, 16 insertions(+), 5 deletions(-)
# HG changeset patch
# User Elmar Bartel
# Date 1515064327 -3600
# Thu Jan 04 12:12:07 2018 +0100
# Node ID 04fe74a8269a68c78a57a9f3698f1c87eff09e74
# Parent 31fe397f2bdab5fea4752947e70549e7a7d04f75
crecord: honor "ui.color = no" config option
The current implementation of crecord ignores the ui.color setting.
This patch checks the ui.color config option and does the curses setup
without colors when the option was set to "no". With other (or missing)
setting of ui.color, curses setup is done as before and uses colors.
diff -r 31fe397f2bda -r 04fe74a8269a mercurial/crecord.py
--- a/mercurial/crecord.py Wed Dec 27 00:24:53 2017 +0530
+++ b/mercurial/crecord.py Thu Jan 04 12:12:07 2018 +0100
@@ -581,6 +581,8 @@ class curseschunkselector(object):
# maps custom nicknames of color-pairs to curses color-pair values
self.colorpairnames = {}
+self.usecolor = self.ui.config('ui', 'color') != 'no'
+
# the currently selected header, hunk, or hunk-line
self.currentselecteditem = self.headerlist[0]
@@ -1371,11 +1373,20 @@ class curseschunkselector(object):
colorpair = self.colorpairs[(fgcolor, bgcolor)]
else:
pairindex = len(self.colorpairs) + 1
-curses.init_pair(pairindex, fgcolor, bgcolor)
-colorpair = self.colorpairs[(fgcolor, bgcolor)] = (
-curses.color_pair(pairindex))
-if name is not None:
-self.colorpairnames[name] = curses.color_pair(pairindex)
+if self.usecolor:
+curses.init_pair(pairindex, fgcolor, bgcolor)
+colorpair = self.colorpairs[(fgcolor, bgcolor)] = (
+curses.color_pair(pairindex))
+if name is not None:
+self.colorpairnames[name] = curses.color_pair(
+ pairindex)
+else:
+cval = 0
+if name is not None:
+if name == 'selected':
+cval = curses.A_REVERSE
+self.colorpairnames[name] = cval
+colorpair = self.colorpairs[(fgcolor, bgcolor)] = cval
# add attributes if possible
if attrlist is None:
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
[PATCH] crecord: fallback to color = no when curses.use_default_colors() fails
mercurial/crecord.py | 5 - 1 files changed, 4 insertions(+), 1 deletions(-) # HG changeset patch # User Elmar Bartel # Date 1515065680 -3600 # Thu Jan 04 12:34:40 2018 +0100 # Node ID 528873b321141114df5dcb8327d86ed691e2964b # Parent 04fe74a8269a68c78a57a9f3698f1c87eff09e74 crecord: fallback to color = no when curses.use_default_colors() fails Even when python was setup/compiled with curses, curses.use_default_colors() may raise a curses exception when the TERM environment variable specifies a value where no propper color configuration is possible. This patch falls back to non-color mode to let the user continue instead of failing with an unhandled exception. diff -r 04fe74a8269a -r 528873b32114 mercurial/crecord.py --- a/mercurial/crecord.py Thu Jan 04 12:12:07 2018 +0100 +++ b/mercurial/crecord.py Thu Jan 04 12:34:40 2018 +0100 @@ -1715,7 +1715,10 @@ are you sure you want to review/edit and self.yscreensize, self.xscreensize = self.stdscr.getmaxyx() curses.start_color() -curses.use_default_colors() +try: +curses.use_default_colors() +except curses.error: +self.usecolor = False # available colors: black, blue, cyan, green, magenta, white, yellow # init_pair(color_id, foreground_color, background_color) ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
[PATCH V2] crecord: honor "ui.color = no" config option
mercurial/crecord.py | 26 +-
1 files changed, 21 insertions(+), 5 deletions(-)
# HG changeset patch
# User Elmar Bartel
# Date 1515064327 -3600
# Thu Jan 04 12:12:07 2018 +0100
# Node ID cf99164fad24d96b7508d86085377faf4494a18f
# Parent 31fe397f2bdab5fea4752947e70549e7a7d04f75
crecord: honor "ui.color = no" config option
The current implementation of crecord ignores the ui.color setting.
This patch checks the ui.color config option and does the curses setup
without colors when the option is set to a falsy value. For other (or
missing) setting of ui.color, curses setup is done as before and uses
colors.
diff -r 31fe397f2bda -r cf99164fad24 mercurial/crecord.py
--- a/mercurial/crecord.py Wed Dec 27 00:24:53 2017 +0530
+++ b/mercurial/crecord.py Thu Jan 04 12:12:07 2018 +0100
@@ -581,6 +581,13 @@ class curseschunkselector(object):
# maps custom nicknames of color-pairs to curses color-pair values
self.colorpairnames = {}
+# Honor color setting of ui section. Keep colored setup as
+# long as not explicitly set to a falsy value - especially,
+# when not set at all. This is to stay most compatible with
+# previous (color only) behaviour.
+uicolor= util.parsebool(self.ui.config('ui', 'color'))
+self.usecolor = uicolor is not False
+
# the currently selected header, hunk, or hunk-line
self.currentselecteditem = self.headerlist[0]
@@ -1371,11 +1378,20 @@ class curseschunkselector(object):
colorpair = self.colorpairs[(fgcolor, bgcolor)]
else:
pairindex = len(self.colorpairs) + 1
-curses.init_pair(pairindex, fgcolor, bgcolor)
-colorpair = self.colorpairs[(fgcolor, bgcolor)] = (
-curses.color_pair(pairindex))
-if name is not None:
-self.colorpairnames[name] = curses.color_pair(pairindex)
+if self.usecolor:
+curses.init_pair(pairindex, fgcolor, bgcolor)
+colorpair = self.colorpairs[(fgcolor, bgcolor)] = (
+curses.color_pair(pairindex))
+if name is not None:
+self.colorpairnames[name] = curses.color_pair(
+ pairindex)
+else:
+cval = 0
+if name is not None:
+if name == 'selected':
+cval = curses.A_REVERSE
+self.colorpairnames[name] = cval
+colorpair = self.colorpairs[(fgcolor, bgcolor)] = cval
# add attributes if possible
if attrlist is None:
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH] crecord: honor "ui.color = no" config option
On Fri, Jan 05, 2018 at 03:15:40PM +0900, Yuya Nishihara wrote:
> On Thu, 04 Jan 2018 12:40:39 +0100, Elmar Bartel wrote:
> > mercurial/crecord.py | 21 -
> > 1 files changed, 16 insertions(+), 5 deletions(-)
> >
> >
> > # HG changeset patch
> > # User Elmar Bartel
> > # Date 1515064327 -3600
> > # Thu Jan 04 12:12:07 2018 +0100
> > # Node ID 04fe74a8269a68c78a57a9f3698f1c87eff09e74
> > # Parent 31fe397f2bdab5fea4752947e70549e7a7d04f75
> > crecord: honor "ui.color = no" config option
>
> Looks good, but I'm not a curses user so I'm not sure if there's anyone
> wanting
> to disable text color, but not curses'.
At least me: I do not like color everywhere but like the curses interface.
But the more serious reason for this patch was to have the ground layed
for my second patch to crecord: when curses is not able to setup
colors, it fails badly (try "TERM=vt100 hg commit -i"). The user is
then (whether he likes color or not) left with a Python stacktrace and
cannot continue. I think it's better to let the user continue his work
without color instead of throwing a stack trace at him.
> > The current implementation of crecord ignores the ui.color setting.
> > This patch checks the ui.color config option and does the curses setup
> > without colors when the option was set to "no". With other (or missing)
> > setting of ui.color, curses setup is done as before and uses colors.
> >
> > diff -r 31fe397f2bda -r 04fe74a8269a mercurial/crecord.py
> > --- a/mercurial/crecord.py Wed Dec 27 00:24:53 2017 +0530
> > +++ b/mercurial/crecord.py Thu Jan 04 12:12:07 2018 +0100
> > @@ -581,6 +581,8 @@ class curseschunkselector(object):
> > # maps custom nicknames of color-pairs to curses color-pair values
> > self.colorpairnames = {}
> >
> > +self.usecolor = self.ui.config('ui', 'color') != 'no'
>
> Nit: "util.parsebool() is not False" can be used to support more falsy values.
Definitily better!
(sorry I'am not yet fully familiar with mercurial internals).
I'll make a second version of the patch.
--
LEO GmbH | Elmar Bartel |
Mühlweg 2b| Phone: +49 (0)8104-90950141 | No signature here.
D-82054 Sauerlach | Fax: +49 (0)8104-90950290 |
Germany | Email: el...@leo.org |
Register Gericht: Amtsgericht München, HRB161107
Geschäftsführer: Hans Riethmayer, Elmar Bartel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
[PATCH] diff performance: re-establish linear runtime performance
# HG changeset patch # User Elmar Bartel # Date 1588252205 -7200 # Thu Apr 30 15:10:05 2020 +0200 # Node ID fd68848f8d5515f9a1afe288787f27fcdb130d42 # Parent 5c1f356b108e07782e07b824c206a87d3a9abcff diff performance: re-establish linear runtime performance The previous method with sum() and list() creates a new list object for every hunk. Then sum() is used to flatten out this sequence of lists. The sum() function is not "lazy", but creates a new list object for every "+" operation and so this code had quadratic runtime behaviour. diff -r 5c1f356b108e -r fd68848f8d55 mercurial/patch.py --- a/mercurial/patch.pyFri Apr 24 12:37:43 2020 -0700 +++ b/mercurial/patch.pyThu Apr 30 15:10:05 2020 +0200 @@ -2558,7 +2558,7 @@ def diff( fctx2 is not None ), b'fctx2 unexpectly None in diff hunks filtering' hunks = hunksfilterfn(fctx2, hunks) -text = b''.join(sum((list(hlines) for hrange, hlines in hunks), [])) +text = b''.join((b''.join(hlines) for hrange, hlines in hunks)) if hdr and (text or len(hdr) > 1): yield b'\n'.join(hdr) + b'\n' if text: ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH] diff performance: re-establish linear runtime performance
Hello Pierre, > Interresting, did you run performance benchmark on some specific > diff for comparison ? Yes. ;-) A little bit of history why this line got my attention: I have to maintain a repo with a very large (800.000 lines) file where a specific changeset touched one third of all lines. So this created a long list if hunks and the diff on this specific changeset did not return in a reasonable time (it took several minutes), so I inverstigated what the problem was. The funny thing is: this behaviour did not show up in a very old version of hg which is used on the machine with the central repository. But it did show up on cloned repos where newer versions of hg where used. This specific line was introduced with the change 92714858dd3e. I've written a small shell/python script (attached) to reproduce this kind of performance problem. > I would like to integrat this in our benchmark > suite. When the attached script helps to do so, I'd be glad. Yours, Elmar. -- LEO GmbH | Elmar Bartel | Mühlweg 2b| Phone: +49 (0)8104-90950141 | No signature here. D-82054 Sauerlach | Fax: +49 (0)8104-90950290 | Germany | Email: el...@leo.org | Register Gericht: Amtsgericht München, HRB161107 Geschäftsführer: Hans Riethmayer, Elmar Bartel hg-diff-profile.sh Description: Bourne shell script ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH] diff performance: re-establish linear runtime performance
Hello Yuya, > If the number of intermediate objects matters, creating a list of > bytes might be slightly faster. > > lines = [] > for hr, hl in hunks: > lines.extend(hl) > b''.join(lines) Might be! I've not investigated this variant. But I've taken a look at this variant: text = b''.join(line for hrange, hlines in hunks for line in hlines) The runtime did not show any significant change. And I'd assume the same for the variant with the explicit loop. So its more a question of taste - and then I'd prefer one of the two one-liners. Yours, Elmar. -- LEO GmbH | Elmar Bartel | Mühlweg 2b| Phone: +49 (0)8104-90950141 | No signature here. D-82054 Sauerlach | Fax: +49 (0)8104-90950290 | Germany | Email: el...@leo.org | Register Gericht: Amtsgericht München, HRB161107 Geschäftsführer: Hans Riethmayer, Elmar Bartel ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
[PATCH] hg: copy buffer state to remote ui
# HG changeset patch # User Elmar Bartel # Date 1591826940 -7200 # Thu Jun 11 00:09:00 2020 +0200 # Node ID 563268fce8e7502e17812fea7b90325a37c854f4 # Parent 83e41b73d115e3717943c2e5a83d36d05670384c hg: copy buffer state to remote ui When remoteui() creates a new ui, the buffer state of the source ui should also be copied to the newly created ui. Otherwise, when pushbuffer() was called on the source ui, this "push" gets lost for the remote ui and output from the remote side will go to default stdout but not to the pushed buffer as is expected by the caller of pushbuffer(). diff -r 83e41b73d115 -r 563268fce8e7 mercurial/hg.py --- a/mercurial/hg.py Tue Jun 09 17:13:26 2020 -0400 +++ b/mercurial/hg.py Thu Jun 11 00:09:00 2020 +0200 @@ -1362,6 +1362,12 @@ def remoteui(src, opts): if v: dst.setconfig(b'web', b'cacerts', util.expandpath(v), b'copied') +# copy buffer state to the remote ui +if src._buffers: +dst._buffers = src._buffers +dst._bufferstates = src._bufferstates +dst._bufferapplylabels = src._bufferstates[-1][2] + return dst ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH] hg: copy buffer state to remote ui
Hello Yuya, > > +# copy buffer state to the remote ui > > +if src._buffers: > > +dst._buffers = src._buffers > > +dst._bufferstates = src._bufferstates > > +dst._bufferapplylabels = src._bufferstates[-1][2] > > The state would become inconsistent if you do popbuffer() later on. Which state: the state of the original ui or the state of the remote-ui? Anyway, as long as the ui-buffer interface is correctly used (properly matching pushpuffer() and popbuffer()) I cannot see any state becoming inconsistent. Furthermore the remote-ui is not accessible from the user calling pushbuffer() on the original ui. This fact brought me to the solution which my patch implements. > [...] > And this touches the internal of the ui, we'll need some tests so > the change wouldn't regress. Is see two things here, which could be tested: - the original ui is not changed, beside the desired effect of having additional content in the buffer. - the buffer does contain the content from the actions on the remoute-ui Is this the test you suggest? > It might be even better to add a function to copy ui with > buffer e.g. ui.copy_sharing_buffer() or ui.copy(share_buffer=True). I completly agree here. This is the place where copying things should happen. And then, remoteui() would just call ui.copy(share_buffer=True). Nevertheless: the problems you anticipate (and I do not yet see) are then moved to the ui.copy() function. Since what can really be done by ui.copy(share_buffer==True)? I see two posibilities: 1) ui.copy(share_buffer==True) merely does the same, as my patch. 2) or, deep-copy the buffer structure to the destination ui. With 1) we'd run into the problems you anticipate. With 2) the problem arises when/where to copy back the buffered content to the buffers of the original ui. Sorry for the many questions. Yours, Elmar. -- LEO GmbH | Elmar Bartel | Mühlweg 2b| Phone: +49 (0)8104-90950141 | No signature here. D-82054 Sauerlach | Fax: +49 (0)8104-90950290 | Germany | Email: el...@leo.org | Register Gericht: Amtsgericht München, HRB161107 Geschäftsführer: Hans Riethmayer, Elmar Bartel ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH] hg: copy buffer state to remote ui
Hallo Yuya, > ui._bufferapplylabels of the ui which buffer has been popped by the other. Ah, thanks! It is pretty clear now: The use of ui._bufferapplylabels as "cache" for ui._bufferstates[-1][2] shows a fundamental problem (with shared bufferrs). The condition ui._bufferstates[-1][2] == ui._bufferapplylabels is not neccessarily True for all ui created with ui.copy(share_buffer==True). As soon as pushbuffer() or popbuffer() is called on any of these ui, the ui._bufferapplylabels value get updated only on the ui where the *buffer() method was called on. All other ui will see the change in the (shared) ui._bufferstates[-1][2], but not on their ui._bufferapplylabels. > Perhaps, the simplest workaround is to insert a sentinel entry to > ui._bufferstates by default, and remove ui._bufferapplylabels. Yep. Removing ui._bufferapplylabels and checking ui._bufferstates[-1][2] directly will resolve the consistency problem. The performance penalty is minimal: an addtional check if there is a buffer and if so an index operation. This effort is not prohibitive. > I think remote-ui instance can be obtained from peer.ui. True! > > Is see two things here, which could be tested: > > - the original ui is not changed, beside the desired effect of > > having additional content in the buffer. > > - the buffer does contain the content from the actions on the > > remoute-ui > > Is this the test you suggest? > > Something like that. Maybe you can add the scenario which you're > trying to fix. Ok, I'll try to setup something. > [...] > ui0.pushbuffer() > ui1 = ui0.copy(share_buffer=True) > ... > ui0.popbuffer() > # ui1 may outlive and its buffer would be popped implicitly, which might > # not always be what we want, but that's unavoidable. What could be done about this: We record in ui._bufferstates[] (as fourth element) the ui which did the push and allow/do the pop only when it is done by the same ui. But this also would not fix all possible calling-sequence-scenrios and then its debatable whether this effort is worth it. > So let's implement (1) and document the caveats. I'll do that and come back then. Thank's for your feedback! Yours, Elmar. -- LEO GmbH | Elmar Bartel | Mühlweg 2b| Phone: +49 (0)8104-90950141 | No signature here. D-82054 Sauerlach | Fax: +49 (0)8104-90950290 | Germany | Email: el...@leo.org | Register Gericht: Amtsgericht München, HRB161107 Geschäftsführer: Hans Riethmayer, Elmar Bartel ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
