* 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).