When doing a "darcs changes" with darcs unstable on the wiki repository
(darcs get http://wiki.darcs.net), it stops on that patch with the
(apparently nested) error:

Wed Oct 28 12:30:29 CET 2009  nomeata <mail@joachim-breitner.de>
  * Idarcs: Char.intToDigit: not a digit 513

On Mon, Feb 08, 2010 at 12:42:09 +0000, gh wrote:
> When doing a "darcs changes" with darcs unstable on the wiki repository
> (darcs get http://wiki.darcs.net), it stops on that patch with the
> (apparently nested) error:
> 
> Wed Oct 28 12:30:29 CET 2009  nomeata <mail@joachim-breitner.de>
>   * Idarcs: Char.intToDigit: not a digit 513

What odd errors you've been submitting lately!

I can't reproduce this.  I've (very slowly) done full fetches both
to my local hard-disk an to NFS

Hmm... I wonder what we could do to track down this problem.

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9

I've tried on another machine, using tcsh, and "darcs changes" outputs
everything, including the problematic patch:

Wed Oct 28 12:30:29 CET 2009  nomeata <mail@joachim-breitner.de>
  * I\e2\80\99m arriving on saturday

The first machine used bash. But doing "darcs changes" in bash in the
second machine does not recreate the bug neither.

The bug happens in gnome-terminal 2.28.1, moreover the part "darcs:
Char.intToDigit: not a digit 513" is suddenly written in red.
In gnome-terminal, I have set the option "execute a command instead of
my shell" to "bash".

It also happens when I want to run darcs-graph in the repository.

In rxvt on the same machine, there is no bug in tcsh but the bug happens
inside of bash.

On Mon, Feb 08, 2010 at 15:17:37 +0000, gh wrote:
> The bug happens in gnome-terminal 2.28.1, moreover the part "darcs:
> Char.intToDigit: not a digit 513" is suddenly written in red.
> In gnome-terminal, I have set the option "execute a command instead of
> my shell" to "bash".

Could you experiment with the highlighting and character escaping
environment variables mentioned in
http://www.darcs.net/manual/node4.html#SECTION00420000000000000000
?

Try turning things (escaping) off and seeing what happens.

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9

works:
DARCS_DONT_ESCAPE_8BIT=1
DARCS_DONT_ESCAPE_ANYTHING=1
DARCS_DONT_ESCAPE_ISPRINT=1

no effect:

DARCS_DONT_COLOR=1
DARCS_DONT_ESCAPE_TRAILING_CR=1
DARCS_DONT_ESCAPE_TRAILING_SPACES=1
DARCS_DONT_ESCAPE_EXTRA=1

same problem in a different color:
DARCS_ALTERNATIVE_COLOR=1

I can reproduce this by doing darcs changes --match "author nomeata" in
the darcs-wiki repo.

It looks like the ColorPrinter (search for intToDigit) is at least
partly involved in this.  I wonder if the UTF-8 work is too.

Guillaume, is this with HEAD darcs or a stable release?  Could you try
with the 2.4 beta?

This is happening with HEAD ( 2.3.1 (+ 455 patches) ), but NOT with the
static binary of the wiki ( 2.3.1 (+ 5 patches)). 
Not with the rc1 neither ( 2.3.99.1 (+ 1 patch) ).

OK, then I think it's some kind of interaction between the utf-8 stuff
and the escaping code.  Assigning to Reinier to investigate when he has
a moment.

The patch in question had "I'm arriving on Saturday", presumably using a
proper apostrophe character rather than the simple tick mark I just used.

Op maandag 08 februari 2010 16:55 schreef gh:
> 
> gh <guillaumh@gmail.com> added the comment:
> 
> This is happening with HEAD ( 2.3.1 (+ 455 patches) ), but NOT with the
> static binary of the wiki ( 2.3.1 (+ 5 patches)). 
> Not with the rc1 neither ( 2.3.99.1 (+ 1 patch) ).

This makes it look very much like my UTF-8 work is involved :-(.

First guess on the train: the escaping code assumes that a Char has a value 0 
<= value < 256.

Reinier

Op maandag 08 februari 2010 15:35 schreef gh:
> gh <guillaumh@gmail.com> added the comment:
> I've tried on another machine, using tcsh, and "darcs changes" outputs
> everything, including the problematic patch:
> 
> Wed Oct 28 12:30:29 CET 2009  nomeata <mail@joachim-breitner.de>
>   * I\e2\80\99m arriving on saturday
> 
> The first machine used bash. But doing "darcs changes" in bash in the
> second machine does not recreate the bug neither.

I think whether the bug occurs or not has to do with the locale. The exact 
behavior depends on it:

# locale nl_NL with ISO-8859-15 encoding
reinier@adim:~/Sources/testrepos/unicodecrash$ LC_ALL=nl_NL@euro 
../../darcsdev/dist/build/darcs/darcs log
Wed Feb 10 08:30:19 CET 2010  Reinier Lamers <tux_rocker@reinier.de>
  * \e2\80\9eJe Moeder\e2\80\9d

# locale nl_NL with ISO-8859-1 encoding
reinier@adim:~/Sources/testrepos/unicodecrash$ LC_ALL=nl_NL 
../../darcsdev/dist/build/darcs/darcs log
Wed Feb 10 08:30:19 CET 2010  Reinier Lamers <tux_rocker@reinier.de>
  * ???Je Moeder???

# locale nl_NL with UTF-8 encoding
reinier@adim:~/Sources/testrepos/unicodecrash$ 
../../darcsdev/dist/build/darcs/darcs log
Wed Feb 10 08:30:19 CET 2010  Reinier Lamers <tux_rocker@reinier.de>
  * darcs: Char.intToDigit: not a digit 513

Regards,
Reinier

The following patch updated the status of issue1739 to be resolved:

* resolve issue1739: make ColorPrinter handle characters > 255 
Ignore-this: ff06ddd7ef801f92cbf66cfd9ba4e467

The following patch updated the status of issue1739 to be resolved-in-stable:

* resolve issue1739: make ColorPrinter handle characters > 255 
Ignore-this: ff06ddd7ef801f92cbf66cfd9ba4e467