* process output has become a bit random...
@ 2004-07-28 16:44 David Kastrup
2004-07-28 22:43 ` Peter Heslin
2004-07-29 10:55 ` Lars Hansen
0 siblings, 2 replies; 29+ messages in thread
From: David Kastrup @ 2004-07-28 16:44 UTC (permalink / raw)
Hi,
I have the problem that recently AUCTeX started producing spurious
repetitions of output on the console. There does not seem to be a
fixed size to the repeated areas: they can be something like 540, 970,
random numbers like that, probably pretty much a single read's worth.
It is not for long that I have been having those problems. I can't
seem to be able to reproduce it in shell mode easily, however. It may
have something to do with the coding system (which the AUCTeX buffer
inherits from the source file, so it would typically be something like
latin1-unix).
Has anybody else experienced anything weird in connection with process
output recently?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: process output has become a bit random...
2004-07-28 16:44 process output has become a bit random David Kastrup
@ 2004-07-28 22:43 ` Peter Heslin
2004-07-28 23:40 ` Kim F. Storm
2004-07-29 10:55 ` Lars Hansen
1 sibling, 1 reply; 29+ messages in thread
From: Peter Heslin @ 2004-07-28 22:43 UTC (permalink / raw)
On 2004-07-28, David Kastrup <dak@gnu.org> wrote:
> Has anybody else experienced anything weird in connection with process
> output recently?
When running M-x grep recently, I got the output duplicated several
times, which happened on a couple of random occasions. At the time I
thought it might have been related to the super-slow grep output bug,
but it sounds pretty close to what you describe.
Peter
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: process output has become a bit random...
2004-07-28 22:43 ` Peter Heslin
@ 2004-07-28 23:40 ` Kim F. Storm
2004-07-29 6:14 ` David Kastrup
0 siblings, 1 reply; 29+ messages in thread
From: Kim F. Storm @ 2004-07-28 23:40 UTC (permalink / raw)
Cc: handa, emacs-devel
Peter Heslin <usenet@heslin.eclipse.co.uk> writes:
> On 2004-07-28, David Kastrup <dak@gnu.org> wrote:
> > Has anybody else experienced anything weird in connection with process
> > output recently?
>
> When running M-x grep recently, I got the output duplicated several
> times, which happened on a couple of random occasions. At the time I
> thought it might have been related to the super-slow grep output bug,
> but it sounds pretty close to what you describe.
I made a change on 2004-06-07 which increased the read buffer from 1k to 4k.
I don't see how that could provoke duplicate buffer output, though.
There have been recent changes specific for the MAC port, but that may be
irrelevant in your case?
Another change which may be relevant is this
2004-06-11 Kenichi Handa <handa@m17n.org>
* coding.c (decode_coding_string): Check CODING_FINISH_INTERRUPT.
Process output handling calls decode_coding_string in such a way that
it may not decode an entire string (leaving further decoding to the
next call). If there is some error in that logic, I think text could
be duplicated.
--
Kim F. Storm <storm@cua.dk> http://www.cua.dk
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: process output has become a bit random...
2004-07-28 23:40 ` Kim F. Storm
@ 2004-07-29 6:14 ` David Kastrup
2004-07-29 8:21 ` Kim F. Storm
0 siblings, 1 reply; 29+ messages in thread
From: David Kastrup @ 2004-07-29 6:14 UTC (permalink / raw)
Cc: Peter Heslin, emacs-devel, handa
storm@cua.dk (Kim F. Storm) writes:
> Peter Heslin <usenet@heslin.eclipse.co.uk> writes:
>
> > On 2004-07-28, David Kastrup <dak@gnu.org> wrote:
> > > Has anybody else experienced anything weird in connection with process
> > > output recently?
> >
> > When running M-x grep recently, I got the output duplicated
> > several times, which happened on a couple of random occasions. At
> > the time I thought it might have been related to the super-slow
> > grep output bug, but it sounds pretty close to what you describe.
>
> I made a change on 2004-06-07 which increased the read buffer from
> 1k to 4k. I don't see how that could provoke duplicate buffer
> output, though.
Well, something's rotten in the state of Denmark, anyway. If you take
a look at the buffer sizes, you'll see that chars is allocated with a
size of carryover+readmax, but it is only ever filled with carryover
old and (readmax-carryover) new characters, for a total of merely
readmax characters. Consequently, I had at one time patched down
either the buffer size or increased the read sizes (don't remember
which it was), but that was later found to cause segmentation faults.
So the change was reverted, but never explained.
I have no clue whether this might be related.
> Another change which may be relevant is this
>
> 2004-06-11 Kenichi Handa <handa@m17n.org>
>
> * coding.c (decode_coding_string): Check CODING_FINISH_INTERRUPT.
>
> Process output handling calls decode_coding_string in such a way that
> it may not decode an entire string (leaving further decoding to the
> next call). If there is some error in that logic, I think text could
> be duplicated.
That's a possibility, yes. Another remote one is that it may coincide
with myself changing from gcc-3.3.x to gcc-3.4.1.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: process output has become a bit random...
2004-07-29 6:14 ` David Kastrup
@ 2004-07-29 8:21 ` Kim F. Storm
2004-07-29 10:29 ` Peter Heslin
0 siblings, 1 reply; 29+ messages in thread
From: Kim F. Storm @ 2004-07-29 8:21 UTC (permalink / raw)
Cc: Peter Heslin, emacs-devel, handa
David Kastrup <dak@gnu.org> writes:
> storm@cua.dk (Kim F. Storm) writes:
>
> > Peter Heslin <usenet@heslin.eclipse.co.uk> writes:
> >
> > > On 2004-07-28, David Kastrup <dak@gnu.org> wrote:
> > > > Has anybody else experienced anything weird in connection with process
> > > > output recently?
> > >
> > > When running M-x grep recently, I got the output duplicated
> > > several times, which happened on a couple of random occasions. At
> > > the time I thought it might have been related to the super-slow
> > > grep output bug, but it sounds pretty close to what you describe.
> >
> > I made a change on 2004-06-07 which increased the read buffer from
> > 1k to 4k. I don't see how that could provoke duplicate buffer
> > output, though.
>
> Well, something's rotten in the state of Denmark, anyway. If you take
> a look at the buffer sizes, you'll see that chars is allocated with a
> size of carryover+readmax, but it is only ever filled with carryover
> old and (readmax-carryover) new characters, for a total of merely
> readmax characters.
That's true. I'll fix that.
> Consequently, I had at one time patched down
> either the buffer size or increased the read sizes (don't remember
> which it was), but that was later found to cause segmentation faults.
> So the change was reverted, but never explained.
Well, I found and fixed a crash related to the way the "carryover"
characters were saved, so that might have been the explanation.
>
> I have no clue whether this might be related.
>
> > Another change which may be relevant is this
> >
> > 2004-06-11 Kenichi Handa <handa@m17n.org>
> >
> > * coding.c (decode_coding_string): Check CODING_FINISH_INTERRUPT.
> >
> > Process output handling calls decode_coding_string in such a way that
> > it may not decode an entire string (leaving further decoding to the
> > next call). If there is some error in that logic, I think text could
> > be duplicated.
>
> That's a possibility, yes. Another remote one is that it may coincide
> with myself changing from gcc-3.3.x to gcc-3.4.1.
Anybody else using that version ??
--
Kim F. Storm <storm@cua.dk> http://www.cua.dk
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: process output has become a bit random...
2004-07-29 8:21 ` Kim F. Storm
@ 2004-07-29 10:29 ` Peter Heslin
2004-07-29 10:45 ` David Kastrup
0 siblings, 1 reply; 29+ messages in thread
From: Peter Heslin @ 2004-07-29 10:29 UTC (permalink / raw)
> storm@cua.dk (Kim F. Storm) writes:
> I made a change on 2004-06-07 which increased the read buffer from
> 1k to 4k. I don't see how that could provoke duplicate buffer
> output, though.
Before you made that change, my auctex latex compiles had gotten
really slow. Not pathological like the grep bug, but noticeably
slower than they should have been -- Emacs was using too much CPU. I
thought your change fixed things, but maybe there was still an
underlying bug.
> Anybody else using that version ??
No. gcc 2.95.4 here.
Peter
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: process output has become a bit random...
2004-07-29 10:29 ` Peter Heslin
@ 2004-07-29 10:45 ` David Kastrup
0 siblings, 0 replies; 29+ messages in thread
From: David Kastrup @ 2004-07-29 10:45 UTC (permalink / raw)
Cc: emacs-devel
Peter Heslin <usenet@heslin.eclipse.co.uk> writes:
> > storm@cua.dk (Kim F. Storm) writes:
> > I made a change on 2004-06-07 which increased the read buffer from
> > 1k to 4k. I don't see how that could provoke duplicate buffer
> > output, though.
>
> Before you made that change, my auctex latex compiles had gotten
> really slow. Not pathological like the grep bug, but noticeably
> slower than they should have been -- Emacs was using too much CPU. I
> thought your change fixed things, but maybe there was still an
> underlying bug.
>
> > Anybody else using that version ??
>
> No. gcc 2.95.4 here.
Well, I also had a few times here recently where the output trickled
in one character at a time, with maybe 3 or 4 characters per second,
for maybe half a minute before things caught up again. But since I
also have the replication problem, and all of this is pretty much
nondeterministic, I was not able to nail this down.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: process output has become a bit random...
2004-07-28 16:44 process output has become a bit random David Kastrup
2004-07-28 22:43 ` Peter Heslin
@ 2004-07-29 10:55 ` Lars Hansen
2004-07-29 11:08 ` David Kastrup
1 sibling, 1 reply; 29+ messages in thread
From: Lars Hansen @ 2004-07-29 10:55 UTC (permalink / raw)
Cc: emacs-devel
David Kastrup wrote:
> Has anybody else experienced anything weird in connection with process
> output recently?
Recently Tramp has begun to fail. It does not happen very often, but
occationally. When I inspect the Tramp buffer (which should contain a
lisp form), I can se the syntax is wrong. It may be possibel that a part
is missing or repeated.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: process output has become a bit random...
2004-07-29 10:55 ` Lars Hansen
@ 2004-07-29 11:08 ` David Kastrup
2004-07-29 12:02 ` Kim F. Storm
0 siblings, 1 reply; 29+ messages in thread
From: David Kastrup @ 2004-07-29 11:08 UTC (permalink / raw)
Cc: emacs-devel
Lars Hansen <larsh@math.ku.dk> writes:
> David Kastrup wrote:
> > Has anybody else experienced anything weird in connection with process
> > output recently?
>
> Recently Tramp has begun to fail. It does not happen very often, but
> occationally. When I inspect the Tramp buffer (which should contain a
> lisp form), I can se the syntax is wrong. It may be possibel that a
> part is missing or repeated.
preview-latex is a pretty good test case, since it complains (with
some detail) when stuff gets replicated unexpectedly.
It has become pretty much unusable now.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: process output has become a bit random...
2004-07-29 11:08 ` David Kastrup
@ 2004-07-29 12:02 ` Kim F. Storm
2004-07-29 12:12 ` David Kastrup
0 siblings, 1 reply; 29+ messages in thread
From: Kim F. Storm @ 2004-07-29 12:02 UTC (permalink / raw)
Cc: Lars Hansen, emacs-devel
David Kastrup <dak@gnu.org> writes:
> Lars Hansen <larsh@math.ku.dk> writes:
>
> > David Kastrup wrote:
> > > Has anybody else experienced anything weird in connection with process
> > > output recently?
> >
> > Recently Tramp has begun to fail. It does not happen very often, but
> > occationally. When I inspect the Tramp buffer (which should contain a
> > lisp form), I can se the syntax is wrong. It may be possibel that a
> > part is missing or repeated.
>
> preview-latex is a pretty good test case, since it complains (with
> some detail) when stuff gets replicated unexpectedly.
>
> It has become pretty much unusable now.
When did "now" begin ?
Can you identify the change that made this fail?
--
Kim F. Storm <storm@cua.dk> http://www.cua.dk
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: process output has become a bit random...
2004-07-29 12:02 ` Kim F. Storm
@ 2004-07-29 12:12 ` David Kastrup
2004-07-29 12:26 ` Ralf Angeli
0 siblings, 1 reply; 29+ messages in thread
From: David Kastrup @ 2004-07-29 12:12 UTC (permalink / raw)
Cc: Lars Hansen, emacs-devel
storm@cua.dk (Kim F. Storm) writes:
> David Kastrup <dak@gnu.org> writes:
>
> > Lars Hansen <larsh@math.ku.dk> writes:
> >
> > > David Kastrup wrote:
> > > > Has anybody else experienced anything weird in connection with process
> > > > output recently?
> > >
> > > Recently Tramp has begun to fail. It does not happen very often, but
> > > occationally. When I inspect the Tramp buffer (which should contain a
> > > lisp form), I can se the syntax is wrong. It may be possibel that a
> > > part is missing or repeated.
> >
> > preview-latex is a pretty good test case, since it complains (with
> > some detail) when stuff gets replicated unexpectedly.
> >
> > It has become pretty much unusable now.
>
> When did "now" begin ?
No idea. It has been some time since I last worked on preview-latex,
and I just took it up last week with some new stuff, being
flabberghasted at how bad I must have bungled matters. Until it
became obvious that something else was going on.
I suppose that maybe two months ago or so this probably did still
work. Also, I have not yet received any third party bug reports, and
there are quite a few people around that tend to use recent Emacs CVS
versions in connection with AUCTeX/preview-latex. So it is my guess
that it might have been just some time in the last month or so.
> Can you identify the change that made this fail?
Not yet. I can try a few things, but stuff is not overly conclusive
by now, and I have not ruled out gcc problems before reporting this,
anyway. That's why I wanted to get some feedback first.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: process output has become a bit random...
2004-07-29 12:12 ` David Kastrup
@ 2004-07-29 12:26 ` Ralf Angeli
2004-07-29 12:31 ` David Kastrup
0 siblings, 1 reply; 29+ messages in thread
From: Ralf Angeli @ 2004-07-29 12:26 UTC (permalink / raw)
* David Kastrup (2004-07-29) writes:
> storm@cua.dk (Kim F. Storm) writes:
>
>> David Kastrup <dak@gnu.org> writes:
>>
>> > preview-latex is a pretty good test case, since it complains (with
>> > some detail) when stuff gets replicated unexpectedly.
>> >
>> > It has become pretty much unusable now.
>>
>> When did "now" begin ?
>
> No idea. It has been some time since I last worked on preview-latex,
> and I just took it up last week with some new stuff, being
> flabberghasted at how bad I must have bungled matters. Until it
> became obvious that something else was going on.
>
> I suppose that maybe two months ago or so this probably did still
> work. Also, I have not yet received any third party bug reports, and
> there are quite a few people around that tend to use recent Emacs CVS
> versions in connection with AUCTeX/preview-latex. So it is my guess
> that it might have been just some time in the last month or so.
>
>> Can you identify the change that made this fail?
>
> Not yet. I can try a few things, but stuff is not overly conclusive
> by now, and I have not ruled out gcc problems before reporting this,
> anyway. That's why I wanted to get some feedback first.
Despite of the randomness of the problem, can you provide a test case?
I have a CVS Emacs here checked out on 2004-07-26 and compiled with
gcc 3.3.4. When I issue `C-c C-p C-d' on a file like
\documentclass{article}
\usepackage[displaymath,footnotes]{preview}
\begin{document}
\begin{equation}
x^2+y^2=z^2
\end{equation}
Text Text Text Text\footnote{foot foot foot foot} Text Text
\end{document}
there aren't any obvious problems. (Tested with `preview-image-type'
set to 'dvi and 'dvipng.)
--
Ralf
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: process output has become a bit random...
2004-07-29 12:26 ` Ralf Angeli
@ 2004-07-29 12:31 ` David Kastrup
2004-07-29 12:43 ` Ralf Angeli
0 siblings, 1 reply; 29+ messages in thread
From: David Kastrup @ 2004-07-29 12:31 UTC (permalink / raw)
Ralf Angeli <angeli@iwi.uni-sb.de> writes:
> Despite of the randomness of the problem, can you provide a test case?
>
> I have a CVS Emacs here checked out on 2004-07-26 and compiled with
> gcc 3.3.4. When I issue `C-c C-p C-d' on a file like
>
> \documentclass{article}
> \usepackage[displaymath,footnotes]{preview}
> \begin{document}
> \begin{equation}
> x^2+y^2=z^2
> \end{equation}
> Text Text Text Text\footnote{foot foot foot foot} Text Text
> \end{document}
>
> there aren't any obvious problems. (Tested with `preview-image-type'
> set to 'dvi and 'dvipng.)
Use circ.tex as delivered. That typically gives 1-2 problems pretty
often. The problem depends on the size of the file. Using really
large documents with hundreds of images is pretty certain to trigger
it.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: process output has become a bit random...
2004-07-29 12:31 ` David Kastrup
@ 2004-07-29 12:43 ` Ralf Angeli
2004-07-29 12:49 ` David Kastrup
0 siblings, 1 reply; 29+ messages in thread
From: Ralf Angeli @ 2004-07-29 12:43 UTC (permalink / raw)
* David Kastrup (2004-07-29) writes:
> Use circ.tex as delivered. That typically gives 1-2 problems pretty
> often. The problem depends on the size of the file. Using really
> large documents with hundreds of images is pretty certain to trigger
> it.
Then I get something like this in the output buffer:
[...]
Preview-LaTeX exited abnormally with code 1 at Thu Jul 29 14:41:04
Running `Preview-DviPNG' with ``dvipng circ.dvi -o circ.prv/tmp11392cK/prev%03d.png --bd 1 -D87 ''
Parser: End of Preview snippet 8 unexpected
Parser: Preview snippet 17 out of sequence
Parser: End of Preview snippet 27 unexpected
Parser: End of Preview snippet 31 unexpected
Parser: End of Preview snippet 48 unexpected
Parser: Preview snippet 57 out of sequence
Parser: Preview snippet 68 out of sequence
Parser: Preview snippet 79 out of sequence
Parser: Preview snippet 97 out of sequence
Parser: Preview snippet 100 out of sequence
[...]
Preview-DviPNG finished at Thu Jul 29 14:41:07
DviPNG sentinel: Wrong type argument: arrayp, nil
--
Ralf
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: process output has become a bit random...
2004-07-29 12:43 ` Ralf Angeli
@ 2004-07-29 12:49 ` David Kastrup
2004-07-29 13:05 ` Kenichi Handa
2004-07-29 14:09 ` David Kastrup
0 siblings, 2 replies; 29+ messages in thread
From: David Kastrup @ 2004-07-29 12:49 UTC (permalink / raw)
Ralf Angeli <angeli@iwi.uni-sb.de> writes:
> * David Kastrup (2004-07-29) writes:
>
> > Use circ.tex as delivered. That typically gives 1-2 problems pretty
> > often. The problem depends on the size of the file. Using really
> > large documents with hundreds of images is pretty certain to trigger
> > it.
>
> Then I get something like this in the output buffer:
>
> [...]
> Preview-LaTeX exited abnormally with code 1 at Thu Jul 29 14:41:04
> Running `Preview-DviPNG' with ``dvipng circ.dvi -o circ.prv/tmp11392cK/prev%03d.png --bd 1 -D87 ''
> Parser: End of Preview snippet 8 unexpected
> Parser: Preview snippet 17 out of sequence
> Parser: End of Preview snippet 27 unexpected
> Parser: End of Preview snippet 31 unexpected
> Parser: End of Preview snippet 48 unexpected
> Parser: Preview snippet 57 out of sequence
> Parser: Preview snippet 68 out of sequence
> Parser: Preview snippet 79 out of sequence
> Parser: Preview snippet 97 out of sequence
> Parser: Preview snippet 100 out of sequence
> [...]
> Preview-DviPNG finished at Thu Jul 29 14:41:07
> DviPNG sentinel: Wrong type argument: arrayp, nil
Yes, that's it. Even though the very last line would appear to be a
preview-latex internal bug. If you take a look at the run buffer (C-c
C-l) and search for, say, "Snippet 8", you will find that some
passages around the matches are replicated.
It is probably some change in process.c or coding.c in the last month
or so. If you use gcc-3.3.4, at least it does not seem to be
gcc-3.4-related like I feared at first.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: process output has become a bit random...
2004-07-29 12:49 ` David Kastrup
@ 2004-07-29 13:05 ` Kenichi Handa
2004-07-29 13:16 ` David Kastrup
2004-07-29 14:09 ` David Kastrup
1 sibling, 1 reply; 29+ messages in thread
From: Kenichi Handa @ 2004-07-29 13:05 UTC (permalink / raw)
Cc: emacs-devel
In article <x5acxjyo4i.fsf@lola.goethe.zz>, David Kastrup <dak@gnu.org> writes:
[...]
> Yes, that's it. Even though the very last line would appear to be a
> preview-latex internal bug. If you take a look at the run buffer (C-c
> C-l) and search for, say, "Snippet 8", you will find that some
> passages around the matches are replicated.
> It is probably some change in process.c or coding.c in the last month
> or so. If you use gcc-3.3.4, at least it does not seem to be
> gcc-3.4-related like I feared at first.
The change below
2004-06-11 Kenichi Handa <handa@m17n.org>
* coding.c (decode_coding_string): Check CODING_FINISH_INTERRUPT.
is just this.
Index: coding.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/coding.c,v
retrieving revision 1.303
retrieving revision 1.304
diff -u -c -r1.303 -r1.304
cvs diff: conflicting specifications of output style
*** coding.c 6 Jun 2004 23:59:19 -0000 1.303
--- coding.c 11 Jun 2004 05:56:44 -0000 1.304
***************
*** 6320,6325 ****
--- 6320,6326 ----
produced += coding->produced;
produced_char += coding->produced_char;
if (result == CODING_FINISH_NORMAL
+ || result == CODING_FINISH_INTERRUPT
|| (result == CODING_FINISH_INSUFFICIENT_SRC
&& coding->consumed == 0))
break;
Could you please try again while canceling this change?
---
Ken'ichi HANDA
handa@m17n.org
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: process output has become a bit random...
2004-07-29 13:05 ` Kenichi Handa
@ 2004-07-29 13:16 ` David Kastrup
0 siblings, 0 replies; 29+ messages in thread
From: David Kastrup @ 2004-07-29 13:16 UTC (permalink / raw)
Cc: emacs-devel
Kenichi Handa <handa@m17n.org> writes:
> In article <x5acxjyo4i.fsf@lola.goethe.zz>, David Kastrup <dak@gnu.org> writes:
> [...]
> > Yes, that's it. Even though the very last line would appear to be a
> > preview-latex internal bug. If you take a look at the run buffer (C-c
> > C-l) and search for, say, "Snippet 8", you will find that some
> > passages around the matches are replicated.
>
> > It is probably some change in process.c or coding.c in the last month
> > or so. If you use gcc-3.3.4, at least it does not seem to be
> > gcc-3.4-related like I feared at first.
>
> The change below
>
> 2004-06-11 Kenichi Handa <handa@m17n.org>
>
> * coding.c (decode_coding_string): Check CODING_FINISH_INTERRUPT.
>
> is just this.
[...]
> Could you please try again while canceling this change?
Doesn't help.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: process output has become a bit random...
2004-07-29 12:49 ` David Kastrup
2004-07-29 13:05 ` Kenichi Handa
@ 2004-07-29 14:09 ` David Kastrup
2004-07-29 14:20 ` Kim F. Storm
1 sibling, 1 reply; 29+ messages in thread
From: David Kastrup @ 2004-07-29 14:09 UTC (permalink / raw)
Cc: Kim F. Storm
David Kastrup <dak@gnu.org> writes:
> Ralf Angeli <angeli@iwi.uni-sb.de> writes:
>
> Yes, that's it. Even though the very last line would appear to be a
> preview-latex internal bug. If you take a look at the run buffer
> (C-c C-l) and search for, say, "Snippet 8", you will find that some
> passages around the matches are replicated.
>
> It is probably some change in process.c or coding.c in the last
> month or so. If you use gcc-3.3.4, at least it does not seem to be
> gcc-3.4-related like I feared at first.
The error first appears with version 1.431 of process.c.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: process output has become a bit random...
2004-07-29 14:09 ` David Kastrup
@ 2004-07-29 14:20 ` Kim F. Storm
2004-07-29 14:57 ` David Kastrup
2004-07-29 14:58 ` Kim F. Storm
0 siblings, 2 replies; 29+ messages in thread
From: Kim F. Storm @ 2004-07-29 14:20 UTC (permalink / raw)
Cc: emacs-devel
David Kastrup <dak@gnu.org> writes:
> David Kastrup <dak@gnu.org> writes:
>
> > Ralf Angeli <angeli@iwi.uni-sb.de> writes:
> >
> > Yes, that's it. Even though the very last line would appear to be a
> > preview-latex internal bug. If you take a look at the run buffer
> > (C-c C-l) and search for, say, "Snippet 8", you will find that some
> > passages around the matches are replicated.
> >
> > It is probably some change in process.c or coding.c in the last
> > month or so. If you use gcc-3.3.4, at least it does not seem to be
> > gcc-3.4-related like I feared at first.
>
> The error first appears with version 1.431 of process.c.
Could you try to set readmax to 1024 ?
That may break UDP packet receive, but it isn't relevant for this case.
--
Kim F. Storm <storm@cua.dk> http://www.cua.dk
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: process output has become a bit random...
2004-07-29 14:20 ` Kim F. Storm
@ 2004-07-29 14:57 ` David Kastrup
2004-07-29 14:58 ` Kim F. Storm
1 sibling, 0 replies; 29+ messages in thread
From: David Kastrup @ 2004-07-29 14:57 UTC (permalink / raw)
Cc: emacs-devel
storm@cua.dk (Kim F. Storm) writes:
> David Kastrup <dak@gnu.org> writes:
>
> > David Kastrup <dak@gnu.org> writes:
> >
> > > Ralf Angeli <angeli@iwi.uni-sb.de> writes:
> > >
> > > Yes, that's it. Even though the very last line would appear to be a
> > > preview-latex internal bug. If you take a look at the run buffer
> > > (C-c C-l) and search for, say, "Snippet 8", you will find that some
> > > passages around the matches are replicated.
> > >
> > > It is probably some change in process.c or coding.c in the last
> > > month or so. If you use gcc-3.3.4, at least it does not seem to be
> > > gcc-3.4-related like I feared at first.
> >
> > The error first appears with version 1.431 of process.c.
>
> Could you try to set readmax to 1024 ?
>
> That may break UDP packet receive, but it isn't relevant for this case.
With an otherwise unchanged 1.433 (head), this appears to do the
trick. Now it would just be nice to find out just what error actually
gets triggered here.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: process output has become a bit random...
2004-07-29 14:20 ` Kim F. Storm
2004-07-29 14:57 ` David Kastrup
@ 2004-07-29 14:58 ` Kim F. Storm
2004-07-29 20:59 ` David Kastrup
1 sibling, 1 reply; 29+ messages in thread
From: Kim F. Storm @ 2004-07-29 14:58 UTC (permalink / raw)
Cc: emacs-devel
storm@cua.dk (Kim F. Storm) writes:
> David Kastrup <dak@gnu.org> writes:
>
> > David Kastrup <dak@gnu.org> writes:
> >
> > > Ralf Angeli <angeli@iwi.uni-sb.de> writes:
> > >
> > > Yes, that's it. Even though the very last line would appear to be a
> > > preview-latex internal bug. If you take a look at the run buffer
> > > (C-c C-l) and search for, say, "Snippet 8", you will find that some
> > > passages around the matches are replicated.
> > >
> > > It is probably some change in process.c or coding.c in the last
> > > month or so. If you use gcc-3.3.4, at least it does not seem to be
> > > gcc-3.4-related like I feared at first.
> >
> > The error first appears with version 1.431 of process.c.
>
> Could you try to set readmax to 1024 ?
>
> That may break UDP packet receive, but it isn't relevant for this case.
Could you also try the following patch (with readmax=4096).
I don't expect it to make a lot of difference, but just to rule out
the obvious...
*** process.c 19 Jul 2004 12:02:56 +0200 1.433
--- process.c 29 Jul 2004 16:46:31 +0200
***************
*** 4762,4777 ****
if (DATAGRAM_CHAN_P (channel))
{
int len = datagram_address[channel].len;
! nbytes = recvfrom (channel, chars + carryover, readmax - carryover,
0, datagram_address[channel].sa, &len);
}
else
#endif
if (proc_buffered_char[channel] < 0)
{
! nbytes = emacs_read (channel, chars + carryover, readmax - carryover);
#ifdef ADAPTIVE_READ_BUFFERING
! if (!NILP (p->adaptive_read_buffering))
{
int delay = XINT (p->read_output_delay);
if (nbytes < 256)
--- 4762,4777 ----
if (DATAGRAM_CHAN_P (channel))
{
int len = datagram_address[channel].len;
! nbytes = recvfrom (channel, chars + carryover, readmax,
0, datagram_address[channel].sa, &len);
}
else
#endif
if (proc_buffered_char[channel] < 0)
{
! nbytes = emacs_read (channel, chars + carryover, readmax);
#ifdef ADAPTIVE_READ_BUFFERING
! if (nbytes > 0 && !NILP (p->adaptive_read_buffering))
{
int delay = XINT (p->read_output_delay);
if (nbytes < 256)
***************
*** 4783,4789 ****
delay += READ_OUTPUT_DELAY_INCREMENT * 2;
}
}
! else if (delay > 0 && (nbytes == readmax - carryover))
{
delay -= READ_OUTPUT_DELAY_INCREMENT;
if (delay == 0)
--- 4783,4789 ----
delay += READ_OUTPUT_DELAY_INCREMENT * 2;
}
}
! else if (delay > 0 && (nbytes == readmax))
{
delay -= READ_OUTPUT_DELAY_INCREMENT;
if (delay == 0)
***************
*** 4802,4808 ****
{
chars[carryover] = proc_buffered_char[channel];
proc_buffered_char[channel] = -1;
! nbytes = emacs_read (channel, chars + carryover + 1, readmax - 1 - carryover);
if (nbytes < 0)
nbytes = 1;
else
--- 4802,4808 ----
{
chars[carryover] = proc_buffered_char[channel];
proc_buffered_char[channel] = -1;
! nbytes = emacs_read (channel, chars + carryover + 1, readmax - 1);
if (nbytes < 0)
nbytes = 1;
else
--
Kim F. Storm <storm@cua.dk> http://www.cua.dk
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: process output has become a bit random...
2004-07-29 14:58 ` Kim F. Storm
@ 2004-07-29 20:59 ` David Kastrup
2004-08-01 0:28 ` David Kastrup
0 siblings, 1 reply; 29+ messages in thread
From: David Kastrup @ 2004-07-29 20:59 UTC (permalink / raw)
Cc: emacs-devel
storm@cua.dk (Kim F. Storm) writes:
> storm@cua.dk (Kim F. Storm) writes:
>
> > Could you try to set readmax to 1024 ?
> >
> > That may break UDP packet receive, but it isn't relevant for this case.
>
>
> Could you also try the following patch (with readmax=4096).
>
> I don't expect it to make a lot of difference, but just to rule out
> the obvious...
[...]
Sorry for the delay, had to go climbing. The patch does not cure the
problem. The problem still occurs with comparable severity.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: process output has become a bit random...
2004-07-29 20:59 ` David Kastrup
@ 2004-08-01 0:28 ` David Kastrup
2004-08-01 23:49 ` Kim F. Storm
2004-08-02 0:03 ` Kenichi Handa
0 siblings, 2 replies; 29+ messages in thread
From: David Kastrup @ 2004-08-01 0:28 UTC (permalink / raw)
Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 625 bytes --]
David Kastrup <dak@gnu.org> writes:
> storm@cua.dk (Kim F. Storm) writes:
>
> > storm@cua.dk (Kim F. Storm) writes:
> >
> > > Could you try to set readmax to 1024 ?
> > >
> > > That may break UDP packet receive, but it isn't relevant for this case.
> >
> >
> > Could you also try the following patch (with readmax=4096).
> >
> > I don't expect it to make a lot of difference, but just to rule out
> > the obvious...
>
> [...]
>
> Sorry for the delay, had to go climbing. The patch does not cure the
> problem. The problem still occurs with comparable severity.
However, the following patch cures everything then:
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 463 bytes --]
--- coding.c 22 Jun 2004 11:22:11 +0200 1.305
+++ coding.c 01 Aug 2004 02:17:32 +0200
@@ -5330,7 +5330,7 @@
/* As shrinking conversion region requires some overhead, we don't try
shrinking if the length of conversion region is less than this
value. */
-static int shrink_conversion_region_threshhold = 1024;
+static int shrink_conversion_region_threshhold = 4100;
#define SHRINK_CONVERSION_REGION(beg, end, coding, str, encodep) \
do { \
[-- Attachment #3: Type: text/plain, Size: 364 bytes --]
This might explain why the changes in buffer size that I did
previously triggered problems: that way the buffer could get larger
than this threshold of 1024 bytes. It would appear that as soon as
shrink_decoding_region is called via SHRINK_CONVERSION_REGION in
decode-coding-string, things start going haywire.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
[-- Attachment #4: Type: text/plain, Size: 142 bytes --]
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: process output has become a bit random...
2004-08-01 0:28 ` David Kastrup
@ 2004-08-01 23:49 ` Kim F. Storm
2004-08-02 0:03 ` Kenichi Handa
1 sibling, 0 replies; 29+ messages in thread
From: Kim F. Storm @ 2004-08-01 23:49 UTC (permalink / raw)
Cc: emacs-devel
David Kastrup <dak@gnu.org> writes:
> However, the following patch cures everything then:
>
> --- coding.c 22 Jun 2004 11:22:11 +0200 1.305
> +++ coding.c 01 Aug 2004 02:17:32 +0200
> @@ -5330,7 +5330,7 @@
> /* As shrinking conversion region requires some overhead, we don't try
> shrinking if the length of conversion region is less than this
> value. */
> -static int shrink_conversion_region_threshhold = 1024;
> +static int shrink_conversion_region_threshhold = 4100;
>
> #define SHRINK_CONVERSION_REGION(beg, end, coding, str, encodep) \
> do { \
>
> It would appear that as soon as
> shrink_decoding_region is called via SHRINK_CONVERSION_REGION in
> decode-coding-string, things start going haywire.
Good catch!! I hope Handa can explain what's going on here.
--
Kim F. Storm <storm@cua.dk> http://www.cua.dk
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: process output has become a bit random...
2004-08-01 0:28 ` David Kastrup
2004-08-01 23:49 ` Kim F. Storm
@ 2004-08-02 0:03 ` Kenichi Handa
2004-08-03 1:44 ` Kenichi Handa
1 sibling, 1 reply; 29+ messages in thread
From: Kenichi Handa @ 2004-08-02 0:03 UTC (permalink / raw)
Cc: emacs-devel, storm
In article <x5d62bn1l5.fsf@lola.goethe.zz>, David Kastrup <dak@gnu.org> writes:
> [2 <text/x-patch (7bit)>]
> --- coding.c 22 Jun 2004 11:22:11 +0200 1.305
> +++ coding.c 01 Aug 2004 02:17:32 +0200
> @@ -5330,7 +5330,7 @@
> /* As shrinking conversion region requires some overhead, we don't try
> shrinking if the length of conversion region is less than this
> value. */
> -static int shrink_conversion_region_threshhold = 1024;
> +static int shrink_conversion_region_threshhold = 4100;
> #define SHRINK_CONVERSION_REGION(beg, end, coding, str, encodep) \
> do { \
> [3 <text/plain (7bit)>]
> This might explain why the changes in buffer size that I did
> previously triggered problems: that way the buffer could get larger
> than this threshold of 1024 bytes. It would appear that as soon as
> shrink_decoding_region is called via SHRINK_CONVERSION_REGION in
> decode-coding-string, things start going haywire.
Thank you for tracking the problem down to here. I'll check
what's wrong with shrink_conversion_region soon.
---
Ken'ichi HANDA
handa@m17n.org
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: process output has become a bit random...
2004-08-02 0:03 ` Kenichi Handa
@ 2004-08-03 1:44 ` Kenichi Handa
2004-08-03 2:07 ` David Kastrup
0 siblings, 1 reply; 29+ messages in thread
From: Kenichi Handa @ 2004-08-03 1:44 UTC (permalink / raw)
Cc: handa, storm
In article <200408020003.JAA21336@etlken.m17n.org>, Kenichi Handa <handa@m17n.org> writes:
>> This might explain why the changes in buffer size that I did
>> previously triggered problems: that way the buffer could get larger
>> than this threshold of 1024 bytes. It would appear that as soon as
>> shrink_decoding_region is called via SHRINK_CONVERSION_REGION in
>> decode-coding-string, things start going haywire.
> Thank you for tracking the problem down to here. I'll check
> what's wrong with shrink_conversion_region soon.
After intalling auctex and preview-latex, I tried C-c C-p
C-d on circ.tex (lang. env. is German), but couldn't
reproduce the problem. Attached is the contents of a buffer
shown by C-c C-l.
Even though it has this line:
Preview-LaTeX exited abnormally with code 1 at Tue Aug 3 10:41:49
the buffer circ.tex is shown with lots of preview images. I
found that C-v doesn't work when a image that is taller than
the window height is shown, but it seems that this is a
different bug.
---
Ken'ichi HANDA
handa@m17n.org
Running `Preview-LaTeX' on `circ' with ``latex "\nonstopmode\PassOptionsToPackage{active,tightpage,auctex}{preview}\AtBeginDocument{\ifx\ifPreview\undefined\RequirePackage[displaymath,floats,graphics,textmath,sections,footnotes]{preview}\fi}\input{circ.tex}"''
This is TeX, Version 3.14159 (Web2C 7.4.5)
LaTeX2e <2001/06/01>
Babel <v3.7h> and hyphenation patterns for american, french, german, ngerman, n
ohyphenation, loaded.
(./circ.tex (/usr/share/texmf/tex/latex/base/article.cls
Document Class: article 2001/04/21 v1.4e Standard LaTeX document class
(/usr/share/texmf/tex/latex/base/size10.clo))
(/usr/share/texmf/tex/generic/babel/babel.sty
(/usr/share/texmf/tex/generic/babel/germanb.ldf
(/usr/share/texmf/tex/generic/babel/babel.def)))
(/usr/share/texmf/tex/latex/base/fontenc.sty
(/usr/share/texmf/tex/latex/base/t1enc.def))
(/usr/share/texmf/tex/latex/base/inputenc.sty
(/usr/share/texmf/tex/latex/base/latin1.def))
(/usr/share/texmf/tex/latex/preview/preview.sty
(/usr/share/texmf/tex/latex/preview/prtightpage.def)
(/usr/share/texmf/tex/latex/preview/prauctex.def
(/usr/share/texmf/tex/latex/preview/prauctex.cfg))
(/usr/share/texmf/tex/latex/preview/prshowlabels.def)
No auxiliary output files.
)
No file circ.aux.
Preview: Fontsize 10pt
! Preview: Snippet 1 started.
<-><->
l.41 \begin{abstract}
Preview: Tightpage -32891 -32891 32891 32891
! Preview: Snippet 1 ended.(651269+183455x14483456).
<-><->
l.41 \begin{abstract}
[1] (/usr/share/texmf/tex/latex/base/t1cmtt.fd)
! Preview: Snippet 2 started.
<-><->
l.48 \section
{Einführung}
! Preview: Snippet 2 ended.(651269+183455x14483456).
<-><->
l.48 \section{Einführung}
[2]
! Preview: Snippet 3 started.
<-><->
l.52 \item Sie lassen sich als Funktion $
y = f(x)$ darstellen.
! Preview: Snippet 3 ended.(491520+163840x2494310).
<-><->
l.52 \item Sie lassen sich als Funktion $y = f(x)$
darstellen.
[3]
! Preview: Snippet 4 started.
<-><->
l.53 \item $
y$ ist im betrachteten Bereich monoton, das heißt, entweder
! Preview: Snippet 4 ended.(282168+127431x344824).
<-><->
l.53 \item $y$
ist im betrachteten Bereich monoton, das heißt, entweder
[4]
! Preview: Snippet 5 started.
<-><->
l.55 \item Wenn $
x$ sich um $1$ ändert, so ändert sich $y$ betragsmäßig
! Preview: Snippet 5 ended.(282168+0x374556).
<-><->
l.55 \item Wenn $x$
sich um $1$ ändert, so ändert sich $y$ betragsmäßig
[5]
! Preview: Snippet 6 started.
<-><->
l.55 \item Wenn $x$ sich um $
1$ ändert, so ändert sich $y$ betragsmäßig
! Preview: Snippet 6 ended.(422343+0x327681).
<-><->
l.55 \item Wenn $x$ sich um $1$
ändert, so ändert sich $y$ betragsmäßig
[6]
! Preview: Snippet 7 started.
<-><->
l.55 ...n $x$ sich um $1$ ändert, so ändert sich $
y$ betragsmäßig
! Preview: Snippet 7 ended.(282168+127431x344824).
<-><->
l.55 ...$x$ sich um $1$ ändert, so ändert sich $y$
betragsmäßig
[7]
! Preview: Snippet 8 started.
<-><->
l.56 höchstens um $
1$
! Preview: Snippet 8 ended.(422343+0x327681).
<-><->
l.56 höchstens um $1$
[8]
! Preview: Snippet 9 started.
<-><->
l.57 ($
\left|\frac{\partial y}{\partial x}\right| \leq 1$).
! Preview: Snippet 9 ended.(753670+425990x2400954).
<-><->
l.57 ...rac{\partial y}{\partial x}\right| \leq 1$
).
[9]
! Preview: Snippet 10 started.
<-><->
l.60 \section
{Die gerade Linie}
! Preview: Snippet 10 ended.(651269+183455x14483456).
<-><->
l.60 \section{Die gerade Linie}
[10]
! Preview: Snippet 11 started.
<-><->
l.62 die durch den Punkt $
0 \choose 0$ geht. Alle anderen Linien lassen
! Preview: Snippet 11 ended.(586443+229380x861985).
<-><->
l.62 die durch den Punkt $0 \choose 0$
geht. Alle anderen Linien lassen
[11]
! Preview: Snippet 12 started.
<-><->
l.63 sich durch Vertauschen von $
x$ und~$y$ sowie Vorzeichenwechsel
! Preview: Snippet 12 ended.(282168+0x374556).
<-><->
l.63 sich durch Vertauschen von $x$
und~$y$ sowie Vorzeichenwechsel
[12]
! Preview: Snippet 13 started.
<-><->
l.63 sich durch Vertauschen von $x$ und~$
y$ sowie Vorzeichenwechsel
! Preview: Snippet 13 ended.(282168+127431x344824).
<-><->
l.63 sich durch Vertauschen von $x$ und~$y$
sowie Vorzeichenwechsel
[13]
! Preview: Snippet 14 started.
<-><->
l.64 erzeugen. Im ersten Oktanten gilt $
x \geq y \geq 0$. Zum Zeichnen
! Preview: Snippet 14 ended.(422343+127431x2794673).
<-><->
l.64 ... Im ersten Oktanten gilt $x \geq y \geq 0$
. Zum Zeichnen
[14]
! Preview: Snippet 15 started.
<-><->
l.65 einer Linie genügt es also, $
x$ durchlaufen zu lassen und für $y$ die
! Preview: Snippet 15 ended.(282168+0x374556).
<-><->
l.65 einer Linie genügt es also, $x$
durchlaufen zu lassen und für $y$ die
[15]
! Preview: Snippet 16 started.
<-><->
l.65 ... also, $x$ durchlaufen zu lassen und für $
y$ die
! Preview: Snippet 16 ended.(282168+127431x344824).
<-><->
l.65 ...lso, $x$ durchlaufen zu lassen und für $y$
die
[16]
! Preview: Snippet 17 started.
<-><->
l.68 Die Gleichung einer Geraden durch $
\Delta x \choose \Delta y$ lautet:
! Preview: Snippet 17 ended.(604284+315196x1328475).
<-><->
l.68 ... Geraden durch $\Delta x \choose \Delta y$
lautet:
[17]
! Preview: Snippet 18 started.
<-><->
l.69 \begin{equation}
! Preview: Snippet 18 ended.(1340729+232964x15661007).
<-><->
l.72 \end{equation}
[18]
! Preview: Snippet 19 started.
<-><->
l.74 Nun stellen wir $
y$ als Summe eines ganzzahligen Wertes $e$ und eines
! Preview: Snippet 19 ended.(282168+127431x344824).
<-><->
l.74 Nun stellen wir $y$
als Summe eines ganzzahligen Wertes $e$ und eines
[19]
! Preview: Snippet 20 started.
<-><->
l.74 ... $y$ als Summe eines ganzzahligen Wertes $
e$ und eines
! Preview: Snippet 20 ended.(282168+0x305153).
<-><->
l.74 ...y$ als Summe eines ganzzahligen Wertes $e$
und eines
[20]
! Preview: Snippet 21 started.
<-><->
l.75 gebrochenen Wertes $
f$ dar, für den gilt: $-0.5 \leq f < 0.5$. Somit
! Preview: Snippet 21 ended.(455111+127431x391398).
<-><->
l.75 gebrochenen Wertes $f$
dar, für den gilt: $-0.5 \leq f < 0.5$. Somit
[21]
! Preview: Snippet 22 started.
<-><->
l.75 gebrochenen Wertes $f$ dar, für den gilt: $
-0.5 \leq f < 0.5$. Somit
! Preview: Snippet 22 ended.(455111+127431x4323550).
<-><->
l.75 ...$f$ dar, für den gilt: $-0.5 \leq f < 0.5$
. Somit
[22]
! Preview: Snippet 23 started.
<-><->
l.76 stellt dann $
e$ den gewünschten, auf die nächste ganze Zahl gerundeten
! Preview: Snippet 23 ended.(282168+0x305153).
<-><->
l.76 stellt dann $e$
den gewünschten, auf die nächste ganze Zahl gerundeten
[23]
! Preview: Snippet 24 started.
<-><->
l.77 $
y$-Wert dar. Jetzt formen wir (\ref{lgi}) um:
! Preview: Snippet 24 ended.(282168+127431x344824).
<-><->
l.77 $y$
-Wert dar. Jetzt formen wir (\ref{lgi}) um:
[24]
LaTeX Warning: Reference `lgi' on page 1 undefined on input line 77.
! Preview: Snippet 25 started.
<-><->
l.78 \begin{eqnarray}
! Preview: Snippet 25 ended.(4020438+232964x15939467).
<-><->
l.83 \end{eqnarray}
[25]
LaTeX Warning: Reference `lgii' on page 1 undefined on input line 85.
! Preview: Snippet 26 started.
<-><->
l.85 ...in (\ref{lgii}) bezeichnen wir jetzt mit $
d$. Für
! Preview: Snippet 26 ended.(455111+0x341106).
<-><->
l.85 ... (\ref{lgii}) bezeichnen wir jetzt mit $d$
. Für
[26]
! Preview: Snippet 27 started.
<-><->
l.86 positive gerade Werte von $
\Delta x$ ist offensichtlich $d < 0$ eine
! Preview: Snippet 27 ended.(447828+0x920691).
<-><->
l.86 positive gerade Werte von $\Delta x$
ist offensichtlich $d < 0$ eine
[27]
! Preview: Snippet 28 started.
<-><->
l.86 ... Werte von $\Delta x$ ist offensichtlich $
d < 0$ eine
! Preview: Snippet 28 ended.(455111+25623x1542593).
<-><->
l.86 ... von $\Delta x$ ist offensichtlich $d < 0$
eine
[28]
! Preview: Snippet 29 started.
<-><->
l.87 zu~$
f < 0.5$ equivalente Bedingung.
! Preview: Snippet 29 ended.(455111+127431x2102611).
<-><->
l.87 zu~$f < 0.5$
equivalente Bedingung.
[29]
! Preview: Snippet 30 started.
<-><->
l.89 Für ungerade Werte von~$
\Delta x$ ist $f < 0.5$ equivalent zu
! Preview: Snippet 30 ended.(447828+0x920691).
<-><->
l.89 Für ungerade Werte von~$\Delta x$
ist $f < 0.5$ equivalent zu
[30]
! Preview: Snippet 31 started.
<-><->
l.89 Für ungerade Werte von~$\Delta x$ ist $
f < 0.5$ equivalent zu
! Preview: Snippet 31 ended.(455111+127431x2102611).
<-><->
l.89 ...ngerade Werte von~$\Delta x$ ist $f < 0.5$
equivalent zu
[31]
! Preview: Snippet 32 started.
<-><->
l.90 $
d + 0.5 < 0$.
! Preview: Snippet 32 ended.(455111+54613x3180990).
<-><->
l.90 $d + 0.5 < 0$
.
[32]
! Preview: Snippet 33 started.
<-><->
l.91 Da $
d$ stets eine ganze Zahl ist, ist dies wieder zu $d < 0$
! Preview: Snippet 33 ended.(455111+0x341106).
<-><->
l.91 Da $d$
stets eine ganze Zahl ist, ist dies wieder zu $d < 0$
[33]
! Preview: Snippet 34 started.
<-><->
l.91 ... eine ganze Zahl ist, ist dies wieder zu $
d < 0$
! Preview: Snippet 34 ended.(455111+25623x1542593).
<-><->
l.91 ...ganze Zahl ist, ist dies wieder zu $d < 0$
[34]
! Preview: Snippet 35 started.
<-><->
l.99 Wird nun $
\ifPreview\special{ps: junk}\fi f \geq 0.5$, wie sich durch
! Preview: Snippet 35 ended.(455111+127431x2102611).
<-><->
l.99 ...ifPreview\special{ps: junk}\fi f \geq 0.5$
, wie sich durch
[35]
! Preview: Snippet 36 started.
<-><->
l.100 den Vergleich $
d \stackrel{?}{<} 0$ feststellen läßt, so muß man
! Preview: Snippet 36 ended.(868487+25623x1542593).
<-><->
l.100 den Vergleich $d \stackrel{?}{<} 0$
feststellen läßt, so muß man
[36]
! Preview: Snippet 37 started.
<-><->
l.101 korrigieren, indem man $
f$ um~1 erniedrigt und $e$ um~$1$ erhöht.
! Preview: Snippet 37 ended.(455111+127431x391398).
<-><->
l.101 korrigieren, indem man $f$
um~1 erniedrigt und $e$ um~$1$ erhöht.
[37]
! Preview: Snippet 38 started.
<-><->
l.101 ...eren, indem man $f$ um~1 erniedrigt und $
e$ um~$1$ erhöht.
! Preview: Snippet 38 ended.(282168+0x305153).
<-><->
l.101 ...en, indem man $f$ um~1 erniedrigt und $e$
um~$1$ erhöht.
[38]
! Preview: Snippet 39 started.
<-><->
l.101 ...ndem man $f$ um~1 erniedrigt und $e$ um~$
1$ erhöht.
! Preview: Snippet 39 ended.(422343+0x327681).
<-><->
l.101 ...em man $f$ um~1 erniedrigt und $e$ um~$1$
erhöht.
[39]
! Preview: Snippet 40 started.
<-><->
l.106 $
\ifPreview\special{ps: quit}\fi d$ muß dann auch entsprechend
! Preview: Snippet 40 ended.(455111+0x341106).
<-><->
l.106 $\ifPreview\special{ps: quit}\fi d$
muß dann auch entsprechend
[40]
! Preview: Snippet 41 started.
<-><->
l.110 Einflüsse von $
x$ und $e$ auf $d$ der in Tabelle~\ref{linalg}
! Preview: Snippet 41 ended.(282168+0x374556).
<-><->
l.110 Einflüsse von $x$
und $e$ auf $d$ der in Tabelle~\ref{linalg}
[41]
! Preview: Snippet 42 started.
<-><->
l.110 Einflüsse von $x$ und $
e$ auf $d$ der in Tabelle~\ref{linalg}
! Preview: Snippet 42 ended.(282168+0x305153).
<-><->
l.110 Einflüsse von $x$ und $e$
auf $d$ der in Tabelle~\ref{linalg}
[42]
! Preview: Snippet 43 started.
<-><->
l.110 Einflüsse von $x$ und $e$ auf $
d$ der in Tabelle~\ref{linalg}
! Preview: Snippet 43 ended.(455111+0x341106).
<-><->
l.110 Einflüsse von $x$ und $e$ auf $d$
der in Tabelle~\ref{linalg}
[43]
LaTeX Warning: Reference `linalg' on page 1 undefined on input line 110.
LaTeX Warning: Reference `linc' on page 1 undefined on input line 112.
LaTeX Warning: Reference `linpict' on page 1 undefined on input line 114.
! Preview: Snippet 44 started.
<-><->
l.115 \begin{table}
! Preview: Snippet 44 ended.(4765618+3793642x16496387).
<-><->
l.133 \end{table}
[44]
! Preview: Snippet 45 started.
<-><->
l.134 \begin{table}
! Preview: Snippet 45 ended.(15886676+15042100x15939467).
<-><->
l.183 \end{table}
[45]
! Preview: Snippet 46 started.
<-><->
l.184 \begin{figure}
! Preview: Snippet 46 ended.(14621882+232964x16774847).
<-><->
l.215 \end{figure}
[46]
! Preview: Snippet 47 started.
<-><->
l.217 \section
{Der Kreis}
! Preview: Snippet 47 ended.(651269+0x14483456).
<-><->
l.217 \section{Der Kreis}
[47]
! Preview: Snippet 48 started.
<-><->
l.219 ($
y \geq x \geq 0$). Hier gelten die oben angegebenen Beziehungen.
! Preview: Snippet 48 ended.(422343+127431x2794673).
<-><->
l.219 ($y \geq x \geq 0$
). Hier gelten die oben angegebenen Beziehungen.
[48]
! Preview: Snippet 49 started.
<-><->
l.224 \begin{equation}
! Preview: Snippet 49 ended.(859893+0x14483456).
<-><->
l.226 \end{equation}
[49]
! Preview: Snippet 50 started.
<-><->
l.228 Der Wert $
y$ läßt sich darstellen als Summe einer ganzen Zahl $e$ und
! Preview: Snippet 50 ended.(282168+127431x344824).
<-><->
l.228 Der Wert $y$
läßt sich darstellen als Summe einer ganzen Zahl $e$ und
[50]
! Preview: Snippet 51 started.
<-><->
l.228 ... darstellen als Summe einer ganzen Zahl $
e$ und
! Preview: Snippet 51 ended.(282168+0x305153).
<-><->
l.228 ...arstellen als Summe einer ganzen Zahl $e$
und
[51]
! Preview: Snippet 52 started.
<-><->
l.229 einem Wert $
f$ mit $-0.5 \leq f < 0.5$. Der Wertebereich von $f$ ist
! Preview: Snippet 52 ended.(455111+127431x391398).
<-><->
l.229 einem Wert $f$
mit $-0.5 \leq f < 0.5$. Der Wertebereich von $f$ ist
[52]
! Preview: Snippet 53 started.
<-><->
l.229 einem Wert $f$ mit $
-0.5 \leq f < 0.5$. Der Wertebereich von $f$ ist
! Preview: Snippet 53 ended.(455111+127431x4323550).
<-><->
l.229 einem Wert $f$ mit $-0.5 \leq f < 0.5$
. Der Wertebereich von $f$ ist
[53]
! Preview: Snippet 54 started.
<-><->
l.229 ...0.5 \leq f < 0.5$. Der Wertebereich von $
f$ ist
! Preview: Snippet 54 ended.(455111+127431x391398).
<-><->
l.229 ...5 \leq f < 0.5$. Der Wertebereich von $f$
ist
[54]
! Preview: Snippet 55 started.
<-><->
l.230 so gewählt worden, damit $
e$ einen auf ganze Zahlen gerundeten Wert
! Preview: Snippet 55 ended.(282168+0x305153).
<-><->
l.230 so gewählt worden, damit $e$
einen auf ganze Zahlen gerundeten Wert
[55]
! Preview: Snippet 56 started.
<-><->
l.231 für $
y$ darstellt.
! Preview: Snippet 56 ended.(282168+127431x344824).
<-><->
l.231 für $y$
darstellt.
[56]
! Preview: Snippet 57 started.
<-><->
l.234 \begin{eqnarray}
! Preview: Snippet 57 ended.(1842933+232964x15661007).
<-><->
l.237 \end{eqnarray}
[57]
LaTeX Warning: Reference `ggg' on page 1 undefined on input line 239.
! Preview: Snippet 58 started.
<-><->
l.239 Die Gleichung (\ref{ggg}) hat für $
x+1$ folgende Form:
! Preview: Snippet 58 ended.(422343+54613x1503227).
<-><->
l.239 Die Gleichung (\ref{ggg}) hat für $x+1$
folgende Form:
[58]
! Preview: Snippet 59 started.
<-><->
l.240 \begin{eqnarray}
! Preview: Snippet 59 ended.(730033+116484x15661007).
<-><->
l.242 \end{eqnarray}
[59]
LaTeX Warning: Reference `ggg' on page 1 undefined on input line 244.
LaTeX Warning: Reference `hhh' on page 1 undefined on input line 244.
! Preview: Snippet 60 started.
<-><->
l.246 \begin{eqnarray*}
! Preview: Snippet 60 ended.(3602007+0x14483456).
<-><->
l.251 \end{eqnarray*}
[60]
! Preview: Snippet 61 started.
<-><->
l.253 Jetzt wird $
2ef + f^2$ mit $m$ getauft. Also:
! Preview: Snippet 61 ended.(533465+127431x2510623).
<-><->
l.253 Jetzt wird $2ef + f^2$
mit $m$ getauft. Also:
[61]
! Preview: Snippet 62 started.
<-><->
l.253 Jetzt wird $2ef + f^2$ mit $
m$ getauft. Also:
! Preview: Snippet 62 ended.(282168+0x575415).
<-><->
l.253 Jetzt wird $2ef + f^2$ mit $m$
getauft. Also:
[62]
! Preview: Snippet 63 started.
<-><->
l.254 \begin{eqnarray*}
! Preview: Snippet 63 ended.(3529189+0x14483456).
<-><->
l.259 \end{eqnarray*}
[63]
! Preview: Snippet 64 started.
<-><->
l.260 Wie groß ist jetzt $
m$? Für $x=0$ ist es sicher $0$. Solange $e$
! Preview: Snippet 64 ended.(282168+0x575415).
<-><->
l.260 Wie groß ist jetzt $m$
? Für $x=0$ ist es sicher $0$. Solange $e$
[64]
! Preview: Snippet 65 started.
<-><->
l.260 Wie groß ist jetzt $m$? Für $
x=0$ ist es sicher $0$. Solange $e$
! Preview: Snippet 65 ended.(422343+0x1576043).
<-><->
l.260 Wie groß ist jetzt $m$? Für $x=0$
ist es sicher $0$. Solange $e$
[65]
! Preview: Snippet 66 started.
<-><->
l.260 ... ist jetzt $m$? Für $x=0$ ist es sicher $
0$. Solange $e$
! Preview: Snippet 66 ended.(422343+0x327681).
<-><->
l.260 ...st jetzt $m$? Für $x=0$ ist es sicher $0$
. Solange $e$
[66]
! Preview: Snippet 67 started.
<-><->
l.260 ...$? Für $x=0$ ist es sicher $0$. Solange $
e$
! Preview: Snippet 67 ended.(282168+0x305153).
<-><->
l.260 ... Für $x=0$ ist es sicher $0$. Solange $e$
[67]
! Preview: Snippet 68 started.
<-><->
l.261 konstant bleibt, schrumpft $
f$ stetig. Fällt $f$ unter $-0.5$, so
! Preview: Snippet 68 ended.(455111+127431x391398).
<-><->
l.261 konstant bleibt, schrumpft $f$
stetig. Fällt $f$ unter $-0.5$, so
[68]
! Preview: Snippet 69 started.
<-><->
l.261 ...ant bleibt, schrumpft $f$ stetig. Fällt $
f$ unter $-0.5$, so
! Preview: Snippet 69 ended.(455111+127431x391398).
<-><->
l.261 ...t bleibt, schrumpft $f$ stetig. Fällt $f$
unter $-0.5$, so
[69]
! Preview: Snippet 70 started.
<-><->
l.261 ..., schrumpft $f$ stetig. Fällt $f$ unter $
-0.5$, so
! Preview: Snippet 70 ended.(422343+54613x1347133).
<-><->
l.261 ...rumpft $f$ stetig. Fällt $f$ unter $-0.5$
, so
[70]
! Preview: Snippet 71 started.
<-><->
l.262 fällt $
m$ (unter Vernachlässigung von $f^2$) unter $-e$. Dies wird
! Preview: Snippet 71 ended.(282168+0x575415).
<-><->
l.262 fällt $m$
(unter Vernachlässigung von $f^2$) unter $-e$. Dies wird
[71]
! Preview: Snippet 72 started.
<-><->
l.262 fällt $m$ (unter Vernachlässigung von $
f^2$) unter $-e$. Dies wird
! Preview: Snippet 72 ended.(533465+127431x685401).
<-><->
l.262 fällt $m$ (unter Vernachlässigung von $f^2$
) unter $-e$. Dies wird
[72]
! Preview: Snippet 73 started.
<-><->
l.262 ...unter Vernachlässigung von $f^2$) unter $
-e$. Dies wird
! Preview: Snippet 73 ended.(382293+54613x814879).
<-><->
l.262 ...er Vernachlässigung von $f^2$) unter $-e$
. Dies wird
[73]
! Preview: Snippet 74 started.
<-><->
l.263 ...t als Kriterium für einen Unterlauf von $
f$ verwendet. Tritt
! Preview: Snippet 74 ended.(455111+127431x391398).
<-><->
l.263 ...als Kriterium für einen Unterlauf von $f$
verwendet. Tritt
[74]
! Preview: Snippet 75 started.
<-><->
l.264 dieser auf, so muß $
f$ um $1$ erhöht und $e$ um $1$ erniedrigt werden.
! Preview: Snippet 75 ended.(455111+127431x391398).
<-><->
l.264 dieser auf, so muß $f$
um $1$ erhöht und $e$ um $1$ erniedrigt werden.
[75]
! Preview: Snippet 76 started.
<-><->
l.264 dieser auf, so muß $f$ um $
1$ erhöht und $e$ um $1$ erniedrigt werden.
! Preview: Snippet 76 ended.(422343+0x327681).
<-><->
l.264 dieser auf, so muß $f$ um $1$
erhöht und $e$ um $1$ erniedrigt werden.
[76]
! Preview: Snippet 77 started.
<-><->
l.264 dieser auf, so muß $f$ um $1$ erhöht und $
e$ um $1$ erniedrigt werden.
! Preview: Snippet 77 ended.(282168+0x305153).
<-><->
l.264 dieser auf, so muß $f$ um $1$ erhöht und $e$
um $1$ erniedrigt werden.
[77]
! Preview: Snippet 78 started.
<-><->
l.264 ...uf, so muß $f$ um $1$ erhöht und $e$ um $
1$ erniedrigt werden.
! Preview: Snippet 78 ended.(422343+0x327681).
<-><->
l.264 ..., so muß $f$ um $1$ erhöht und $e$ um $1$
erniedrigt werden.
[78]
! Preview: Snippet 79 started.
<-><->
l.266 ...ingung zu vereinfachen, setzt man jetzt $
q$ = $m+e$.
! Preview: Snippet 79 ended.(282168+127431x316074).
<-><->
l.266 ...gung zu vereinfachen, setzt man jetzt $q$
= $m+e$.
[79]
! Preview: Snippet 80 started.
<-><->
l.266 ... zu vereinfachen, setzt man jetzt $q$ = $
m+e$.
! Preview: Snippet 80 ended.(382293+54613x1681558).
<-><->
l.266 ...vereinfachen, setzt man jetzt $q$ = $m+e$
.
[80]
LaTeX Warning: Reference `alg' on page 1 undefined on input line 267.
LaTeX Warning: Reference `prog' on page 1 undefined on input line 268.
! Preview: Snippet 81 started.
<-><->
l.269 \begin{table}
! Preview: Snippet 81 ended.(5248012+4276036x15661007).
<-><->
l.287 \end{table}
[81]
! Preview: Snippet 82 started.
<-><->
l.288 \begin{table}
! Preview: Snippet 82 ended.(13851388+12879412x15939467).
<-><->
l.331 \end{table}
[82]
! Preview: Snippet 83 started.
<-><->
l.332 \begin{figure}
! Preview: Snippet 83 ended.(14621882+116484x16217927).
<-><->
l.360 \end{figure}
[83]
! Preview: Snippet 84 started.
<-><->
l.362 \section
{Einfache Hyperbeln}
! Preview: Snippet 84 ended.(651269+183455x14483456).
<-><->
l.362 \section{Einfache Hyperbeln}
[84]
! Preview: Snippet 85 started.
<-><->
l.364 $
y = r^2\!/x$ genügen, und zwar im Bereich~$x \geq r$.
! Preview: Snippet 85 ended.(533465+163840x2419522).
<-><->
l.364 $y = r^2\!/x$
genügen, und zwar im Bereich~$x \geq r$.
[85]
! Preview: Snippet 86 started.
<-><->
l.364 $y = r^2\!/x$ genügen, und zwar im Bereich~$
x \geq r$.
! Preview: Snippet 86 ended.(416790+89110x1562238).
<-><->
l.364 ...$ genügen, und zwar im Bereich~$x \geq r$
.
[86]
! Preview: Snippet 87 started.
<-><->
l.366 Mit dem Ansatz $
y = e + f$ ergibt sich:
! Preview: Snippet 87 ended.(455111+127431x2716171).
<-><->
l.366 Mit dem Ansatz $y = e + f$
ergibt sich:
[87]
! Preview: Snippet 88 started.
<-><->
l.367 \begin{eqnarray}
! Preview: Snippet 88 ended.(2696113+232964x15939467).
<-><->
l.371 \end{eqnarray}
[88]
! Preview: Snippet 89 started.
<-><->
l.373 Für $
x' = x+1$ hat nun (\ref{phyp}) die Form
! Preview: Snippet 89 ended.(492688+54613x2935454).
<-><->
l.373 Für $x' = x+1$
hat nun (\ref{phyp}) die Form
[89]
LaTeX Warning: Reference `phyp' on page 1 undefined on input line 373.
! Preview: Snippet 90 started.
<-><->
l.374 \begin{eqnarray*}
! Preview: Snippet 90 ended.(3602007+0x14483456).
<-><->
l.379 \end{eqnarray*}
[90]
! Preview: Snippet 91 started.
<-><->
l.380 Setzt man jetzt $
d = (2f + 1)x$, so ist $f < -0.5$ mit~$d < 0$
! Preview: Snippet 91 ended.(491520+163840x3946944).
<-><->
l.380 Setzt man jetzt $d = (2f + 1)x$
, so ist $f < -0.5$ mit~$d < 0$
[91]
! Preview: Snippet 92 started.
<-><->
l.380 Setzt man jetzt $d = (2f + 1)x$, so ist $
f < -0.5$ mit~$d < 0$
! Preview: Snippet 92 ended.(455111+127431x2612337).
<-><->
l.380 ... jetzt $d = (2f + 1)x$, so ist $f < -0.5$
mit~$d < 0$
[92]
! Preview: Snippet 93 started.
<-><->
l.380 ... $d = (2f + 1)x$, so ist $f < -0.5$ mit~$
d < 0$
! Preview: Snippet 93 ended.(455111+25623x1542593).
<-><->
l.380 ...(2f + 1)x$, so ist $f < -0.5$ mit~$d < 0$
[93]
! Preview: Snippet 94 started.
<-><->
l.382 $
e' = e$,
! Preview: Snippet 94 ended.(492688+0x1667977).
<-><->
l.382 $e' = e$
,
[94]
! Preview: Snippet 95 started.
<-><->
l.383 dann muß in bekannter Weise $
f$ um~$1$ erhöht und $e$ um~$1$
! Preview: Snippet 95 ended.(455111+127431x391398).
<-><->
l.383 dann muß in bekannter Weise $f$
um~$1$ erhöht und $e$ um~$1$
[95]
! Preview: Snippet 96 started.
<-><->
l.383 dann muß in bekannter Weise $f$ um~$
1$ erhöht und $e$ um~$1$
! Preview: Snippet 96 ended.(422343+0x327681).
<-><->
l.383 dann muß in bekannter Weise $f$ um~$1$
erhöht und $e$ um~$1$
[96]
! Preview: Snippet 97 started.
<-><->
l.383 ...n bekannter Weise $f$ um~$1$ erhöht und $
e$ um~$1$
! Preview: Snippet 97 ended.(282168+0x305153).
<-><->
l.383 ...bekannter Weise $f$ um~$1$ erhöht und $e$
um~$1$
[97]
! Preview: Snippet 98 started.
<-><->
l.383 ...nter Weise $f$ um~$1$ erhöht und $e$ um~$
1$
! Preview: Snippet 98 ended.(422343+0x327681).
<-><->
l.383 ...er Weise $f$ um~$1$ erhöht und $e$ um~$1$
[98]
! Preview: Snippet 99 started.
<-><->
l.387 Für $
d'$ ergeben sich dann die folgenden Werte:
! Preview: Snippet 99 ended.(492688+0x524971).
<-><->
l.387 Für $d'$
ergeben sich dann die folgenden Werte:
[99]
! Preview: Snippet 100 started.
<-><->
l.388 \begin{eqnarray*}
! Preview: Snippet 100 ended.(3529189+0x14483456).
<-><->
l.393 \end{eqnarray*}
[100]
LaTeX Warning: Reference `halg' on page 1 undefined on input line 394.
! Preview: Snippet 101 started.
<-><->
l.396 \begin{table}
! Preview: Snippet 101 ended.(5231703+4259727x15939467).
<-><->
l.414 \end{table}
[101]
! Preview: Snippet 102 started.
<-><->
l.415 \begin{table}
! Preview: Snippet 102 ended.(9526012+8554036x14483456).
<-><->
l.446 \end{table}
[102]
! Preview: Snippet 103 started.
<-><->
l.447 \begin{figure}
! Preview: Snippet 103 ended.(14621882+116484x16496387).
<-><->
l.478 \end{figure}
[103]
LaTeX Warning: There were undefined references.
)
(see the transcript file for additional information)
Output written on circ.dvi (103 pages, 41812 bytes).
Transcript written on circ.log.
Preview-LaTeX exited abnormally with code 1 at Tue Aug 3 10:41:49
Running `Preview-DviPS' with ``dvips -Pwww circ.dvi -o circ.prv/tmp21606y_g/preview.ps''
This is dvips(k) 5.92b Copyright 2002 Radical Eye Software (www.radicaleye.com)
' TeX output 2004.08.03:1041' -> circ.prv/tmp21606y_g/preview.ps
<texc.pro><aae443f0.enc><f7b6d320.enc><bbad153f.enc><texps.pro><special.pro>
. <cmsy7.pfb><lcircle1.pfb><cmr7.pfb><cmsy10.pfb><cmmi7.pfb><cmex10.pfb>
<cmr10.pfb><cmmi10.pfb>[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12]
[13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27]
[28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42]
[43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57]
[58] [59] [60] [61] [62] [63] [64] [65] [66] [67] [68] [69] [70] [71] [72]
[73] [74] [75] [76] [77] [78] [79] [80] [81] [82] [83] [84] [85] [86] [87]
[88] [89] [90] [91] [92] [93] [94] [95] [96] [97] [98] [99] [100] [101] [102]
[103]
Preview-DviPS finished at Tue Aug 3 10:41:49
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: process output has become a bit random...
2004-08-03 1:44 ` Kenichi Handa
@ 2004-08-03 2:07 ` David Kastrup
2004-08-03 5:20 ` Kenichi Handa
0 siblings, 1 reply; 29+ messages in thread
From: David Kastrup @ 2004-08-03 2:07 UTC (permalink / raw)
Cc: storm, emacs-devel
Kenichi Handa <handa@m17n.org> writes:
> In article <200408020003.JAA21336@etlken.m17n.org>, Kenichi Handa <handa@m17n.org> writes:
>
> >> This might explain why the changes in buffer size that I did
> >> previously triggered problems: that way the buffer could get larger
> >> than this threshold of 1024 bytes. It would appear that as soon as
> >> shrink_decoding_region is called via SHRINK_CONVERSION_REGION in
> >> decode-coding-string, things start going haywire.
>
> > Thank you for tracking the problem down to here. I'll check
> > what's wrong with shrink_conversion_region soon.
>
> After intalling auctex and preview-latex, I tried C-c C-p
> C-d on circ.tex (lang. env. is German), but couldn't
> reproduce the problem.
Rats. You have the threshold for the shrinking significantly lower
than readmax in process.c?
> Attached is the contents of a buffer shown by C-c C-l.
>
> Even though it has this line:
>
> Preview-LaTeX exited abnormally with code 1 at Tue Aug 3 10:41:49
Which is normal. I probably should try to weazle around producing
this message since people tend to get surprised by it.
> the buffer circ.tex is shown with lots of preview images. I found
> that C-v doesn't work when a image that is taller than the window
> height is shown, but it seems that this is a different bug.
Quite so.
So let us compare our language environments:
Latin-1 language environment
[...]
Character sets:
ascii: ASCII (ISO646 IRV)
latin-iso8859-1: Right-Hand Part of Latin Alphabet 1 (ISO/IEC 8859-1): ISO-IR-100.
Coding systems:
iso-latin-1 (`1' in mode line):
ISO 2022 based 8-bit encoding for Latin-1 (MIME:ISO-8859-1).
(alias: iso-latin-1 iso-8859-1 latin-1)
[back]
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: process output has become a bit random...
2004-08-03 2:07 ` David Kastrup
@ 2004-08-03 5:20 ` Kenichi Handa
2004-08-03 10:49 ` David Kastrup
0 siblings, 1 reply; 29+ messages in thread
From: Kenichi Handa @ 2004-08-03 5:20 UTC (permalink / raw)
Cc: emacs-devel, storm
In article <x5vfg10ya1.fsf@lola.goethe.zz>, David Kastrup <dak@gnu.org> writes:
>> After intalling auctex and preview-latex, I tried C-c C-p
>> C-d on circ.tex (lang. env. is German), but couldn't
>> reproduce the problem.
> Rats. You have the threshold for the shrinking significantly lower
> than readmax in process.c?
Yes. But, I found that sub-shell runs in en_US.UTF-8 locale
on Fedora even if I invoked Emacs with LANG=de_DE.iso88591.
And, thus, the process coding system is set to utf-8 which
doesn't trigger shrinking.
Anyway, I found a bug in decode_coding_string (incorrect
setting of coding->consumed, and etc), and just installed a
fix. Could you please try with the latest CVS HEAD code?
---
Ken'ichi HANDA
handa@m17n.org
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: process output has become a bit random...
2004-08-03 5:20 ` Kenichi Handa
@ 2004-08-03 10:49 ` David Kastrup
0 siblings, 0 replies; 29+ messages in thread
From: David Kastrup @ 2004-08-03 10:49 UTC (permalink / raw)
Cc: emacs-devel, storm
Kenichi Handa <handa@m17n.org> writes:
> In article <x5vfg10ya1.fsf@lola.goethe.zz>, David Kastrup <dak@gnu.org> writes:
> >> After intalling auctex and preview-latex, I tried C-c C-p
> >> C-d on circ.tex (lang. env. is German), but couldn't
> >> reproduce the problem.
>
> > Rats. You have the threshold for the shrinking significantly lower
> > than readmax in process.c?
>
> Yes. But, I found that sub-shell runs in en_US.UTF-8 locale
> on Fedora even if I invoked Emacs with LANG=de_DE.iso88591.
> And, thus, the process coding system is set to utf-8 which
> doesn't trigger shrinking.
>
> Anyway, I found a bug in decode_coding_string (incorrect
> setting of coding->consumed, and etc), and just installed a
> fix. Could you please try with the latest CVS HEAD code?
Could detect nothing wrong now. However, last time I played with
process.c (and got bitten in the process) it took months until
somebody tracked down an obscure case that actually triggered the bug
(probably the one that you fixed now: I reverted my change without
understanding what could have been wrong).
Let's hope for the best this time.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2004-08-03 10:49 UTC | newest]
Thread overview: 29+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-07-28 16:44 process output has become a bit random David Kastrup
2004-07-28 22:43 ` Peter Heslin
2004-07-28 23:40 ` Kim F. Storm
2004-07-29 6:14 ` David Kastrup
2004-07-29 8:21 ` Kim F. Storm
2004-07-29 10:29 ` Peter Heslin
2004-07-29 10:45 ` David Kastrup
2004-07-29 10:55 ` Lars Hansen
2004-07-29 11:08 ` David Kastrup
2004-07-29 12:02 ` Kim F. Storm
2004-07-29 12:12 ` David Kastrup
2004-07-29 12:26 ` Ralf Angeli
2004-07-29 12:31 ` David Kastrup
2004-07-29 12:43 ` Ralf Angeli
2004-07-29 12:49 ` David Kastrup
2004-07-29 13:05 ` Kenichi Handa
2004-07-29 13:16 ` David Kastrup
2004-07-29 14:09 ` David Kastrup
2004-07-29 14:20 ` Kim F. Storm
2004-07-29 14:57 ` David Kastrup
2004-07-29 14:58 ` Kim F. Storm
2004-07-29 20:59 ` David Kastrup
2004-08-01 0:28 ` David Kastrup
2004-08-01 23:49 ` Kim F. Storm
2004-08-02 0:03 ` Kenichi Handa
2004-08-03 1:44 ` Kenichi Handa
2004-08-03 2:07 ` David Kastrup
2004-08-03 5:20 ` Kenichi Handa
2004-08-03 10:49 ` David Kastrup
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).