unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Tassilo Horn <thorn+news@fastmail.fm>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-pretest-bug@gnu.org, Tassilo Horn <thorn+news@fastmail.fm>
Subject: Re: 23.0.60; Coding system troubles since two days
Date: Thu, 27 Mar 2008 16:01:15 +0100	[thread overview]
Message-ID: <87fxucp5xg.fsf@fastmail.fm> (raw)
In-Reply-To: <jwvtzisnupx.fsf-monnier+emacsbugreports@gnu.org> (Stefan Monnier's message of "Thu, 27 Mar 2008 10:34:35 -0400")

[-- Attachment #1: Type: text/plain, Size: 2315 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Since I updated my emacs CVS checkout on march, 26th in the morning
>> (EST) I have some very frustrating coding system issues.  They
>> appeared first when using Gnus (I couldn't read mails of one of my
>> colleagues), then I got some errors with rcirc (which I cannot
>> reproduce).
> [...]
>> Maybe the following change causes the troubles?
>
> Have you tried to revert the change to see if that's indeed the
> culprit?

Yes, please see my followup to my original bug report on emacs-devel.

http://lists.gnu.org/archive/html/emacs-devel/2008-03/msg02677.html

cvs up -D "2008-03-25 06:00" fixes the problem for me.

> Also, would you be able to make up a reproducible test case?

I don't know how.  I'll attach one of the mails that triggered the
problem.  After reverting my emacs to ""2008-03-25 06:00" I can view
them normally with Gnus, but if I try to save the mail to a file (`O f'
in the *Summary* buffer), I get this:

,----
| These default coding systems were tried to encode text
| in the buffer ` *temp*':
|   (utf-8-unix (403 . 4194294) (749 . 4194300) (788 . 4194276) (840 . 4194276)
|   (853 . 4194276) (892 . 4194271) (1701 . 4194300) (1937 . 4194300) (1938
|   . 4194271))
| However, each of them encountered characters it couldn't encode:
|   utf-8-unix cannot encode these: \366 \374 \344 \344 \344 \337 \374
|                                   \374 \337
| 
| Click on a character (or switch to this window by `C-x o'
| and select the characters by RET) to jump to the place it appears,
| where `C-u C-x =' will give information about it.
| 
| Select one of the safe coding systems listed below,
| or cancel the writing with C-g and edit the buffer
|    to remove or modify the problematic characters,
| or specify any other coding system (and risk losing
|    the problematic characters).
| 
|   utf-8-emacs
`----

I saved it as raw-text and utf-8-emacs, both files are attached.

One interesting thing: I marked the text above with the mouse and
inserted it into another emacs window with a middle mouse click.  There,
instead of \NNN I get: ö ü ä ä ä ß ü ü ß

This other emacs window I pasted into is a current CVS emacs from today
which includes your change, if that matters.


[-- Attachment #2: broken-mail.raw-text --]
[-- Type: application/octet-stream, Size: 2007 bytes --]

X-Gnus-Coding-System: -*- coding: raw-text; -*-

From: Claudia Obermaier <obermaie@uni-koblenz.de>
Subject: Re: Frage zur Dissolution
To: Tassilo Horn <heimdall@uni-koblenz.de>
Date: Wed, 26 Mar 2008 08:13:20 +0100

Hallo,

ich bin auch etwas verwirrt von dem Beispiel. Irgendwas ist da faul.
Der Subgraph relativ zu {C,~A} sollte eigentlich

         ~A
C  v    &
           C

sein. Aber auch wenn der Subgraph so aussieht und nicht wie in deiner 
Lösung, ist das ganz kein c-Block. Denn wie du richtig bemerkt hast, 
macht der c-Pfad {~A,D} Probleme. Der schneidet den Subgraphen zwar, 
aber ist kein Cpfad. Also ist der obige Subgraph noch nicht einmal ein 
C-Block.

Ich vermute, dass sich hier ein kleiner Fehler eingeschlichen hat.
Wenn man das rechte C durch ein anderes Literal ersetzen würde, dann 
klappt das Beispiel. Dann wäre C v ~A der Subgraph relativ zu {C,~A} und 
das wäre dann tatsächlich auch ein "strong c-block".

Gruß
  Claudia

Tassilo Horn schrieb:
> Hi Claudia,
>
> ich hab mal eine Frage zum Dissolutions-Paper.  Auf Seite 508 unten
> geht's um "strong blocks".  Demnach ist ein Subgraph ein c-block, wenn
> alle c-paths, die mindestens einen Knoten von H beinhalten, "durch H
> durchgehen" (pass through H).  Das ist der Fall, wenn die Knoten des
> c-path, welche in H liegen, wiederum einen c-path in H bilden.
>
> So weit, so gut.  Jetzt soll ein starker c-Block ein solcher sein, durch
> den alle c-paths des Graphen laufen.  Als Beispiel wird der Subgraph
> relativ zu {C, ~A} angegeben.
>
> Wenn ich alles korrekt verstanden habe, so ist dieser Graph folgender
> (~ = nicht, & = and):
>
>                   ~A
>                    &
>                    C
>
> Wenn man jetzt aber den c-path {~A, D} betrachtet, so würde ich meinen,
> dass das ein Gegenbeispiel ist.  ~A ist in dem vermeintlichen Block
> enthalten, ist aber nur ein partieller c-path darin, denn er ist im
> c-path {~A, C} komplett enthalten.
>
> Wo liegt mein Denkfehler?
>
> Viele Grüße,
> Tassilo
>   



[-- Attachment #3: broken-mail.utf8-emacs --]
[-- Type: application/octet-stream, Size: 2010 bytes --]

X-Gnus-Coding-System: -*- coding: utf-8-emacs; -*-

From: Claudia Obermaier <obermaie@uni-koblenz.de>
Subject: Re: Frage zur Dissolution
To: Tassilo Horn <heimdall@uni-koblenz.de>
Date: Wed, 26 Mar 2008 08:13:20 +0100

Hallo,

ich bin auch etwas verwirrt von dem Beispiel. Irgendwas ist da faul.
Der Subgraph relativ zu {C,~A} sollte eigentlich

         ~A
C  v    &
           C

sein. Aber auch wenn der Subgraph so aussieht und nicht wie in deiner 
Lösung, ist das ganz kein c-Block. Denn wie du richtig bemerkt hast, 
macht der c-Pfad {~A,D} Probleme. Der schneidet den Subgraphen zwar, 
aber ist kein Cpfad. Also ist der obige Subgraph noch nicht einmal ein 
C-Block.

Ich vermute, dass sich hier ein kleiner Fehler eingeschlichen hat.
Wenn man das rechte C durch ein anderes Literal ersetzen würde, dann 
klappt das Beispiel. Dann wäre C v ~A der Subgraph relativ zu {C,~A} und 
das wäre dann tatsächlich auch ein "strong c-block".

Gruß
  Claudia

Tassilo Horn schrieb:
> Hi Claudia,
>
> ich hab mal eine Frage zum Dissolutions-Paper.  Auf Seite 508 unten
> geht's um "strong blocks".  Demnach ist ein Subgraph ein c-block, wenn
> alle c-paths, die mindestens einen Knoten von H beinhalten, "durch H
> durchgehen" (pass through H).  Das ist der Fall, wenn die Knoten des
> c-path, welche in H liegen, wiederum einen c-path in H bilden.
>
> So weit, so gut.  Jetzt soll ein starker c-Block ein solcher sein, durch
> den alle c-paths des Graphen laufen.  Als Beispiel wird der Subgraph
> relativ zu {C, ~A} angegeben.
>
> Wenn ich alles korrekt verstanden habe, so ist dieser Graph folgender
> (~ = nicht, & = and):
>
>                   ~A
>                    &
>                    C
>
> Wenn man jetzt aber den c-path {~A, D} betrachtet, so würde ich meinen,
> dass das ein Gegenbeispiel ist.  ~A ist in dem vermeintlichen Block
> enthalten, ist aber nur ein partieller c-path darin, denn er ist im
> c-path {~A, C} komplett enthalten.
>
> Wo liegt mein Denkfehler?
>
> Viele Grüße,
> Tassilo
>   



[-- Attachment #4: Type: text/plain, Size: 14 bytes --]


Bye,
Tassilo

      reply	other threads:[~2008-03-27 15:01 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-27  9:25 23.0.60; Coding system troubles since two days Tassilo Horn
2008-03-27 10:17 ` Tassilo Horn
2008-03-27 14:34 ` Tom Rauchenwald
2008-03-27 14:34 ` Stefan Monnier
2008-03-27 15:01   ` Tassilo Horn [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87fxucp5xg.fsf@fastmail.fm \
    --to=thorn+news@fastmail.fm \
    --cc=emacs-pretest-bug@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).