Bug in tooltip handling
Hi all, I'm not quite sure if this is a bug or a intended change in tooltip handling, but here I go. Supporting own tooltips in Emacs 21 was basically a matter of: , | (defun my-tooltip-mode (&optional arg) | ;; [snip] | (tooltip-mode 1) | (add-hook 'tooltip-hook 'my-tooltip-function) | (make-local-variable 'track-mouse) | (setq track-mouse on)) | | (defun my-tooltip-function (event) | (interactive "e") | ;; process event... | (tooltip-show "Huzzah!")) ` This convenient approach (used for example by dictionary-el) doesn't work anymore in Emacs 22. If I set `track-mouse' to a non-nil value, even the standard tooltips which worked before (e.g. the modeline help tooltips) don't work anymore. I use the CVS HEAD of yesterday. Bye, Tassilo -- [Emacs] is written in Lisp, which is the only computer language that is beautiful. -- Neal Stephenson, _In the Beginning was the Command Line_ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Bug in tooltip handling
Nick Roberts <[EMAIL PROTECTED]> writes: Hi Nick, > > | (setq track-mouse on)) >^^^ t? Just a typo. > > | (defun my-tooltip-function (event) > > | (interactive "e") > > | ;; process event... > > | (tooltip-show "Huzzah!")) > > ` > > This didn't seem to work very well on Emacs 21 when I tried it. Also > there's no mechanism to remove my-tooltip-function from tooltip-hook. > > You can get it to work as before by using: > > (defun my-tooltip-mode (&optional arg) >;; [snip] >(gud-tooltip-mode 1) > ^^^ Indeed, this works. > > This convenient approach (used for example by dictionary-el) > > doesn't work anymore in Emacs 22. > > dictionary-el isn't part of Emacs 22. I have split GUD tooltips > (which use track-mouse from ordinary ones (which don't). dictionary-el and my own mode display tooltips based on the word under the mouse pointer. The event based approach makes it easy to extract the word. If there's a better way, please let me know. Currently I use an own timer an lots of ugly code to work arround this. > This means that they can be toggled independently. At some stage, if > other packages want to use tooltips in the way GUD does, that part > could be split out of gud.el. That would be really nice. Bye, Tassilo -- A child of five could understand this! Fetch me a child of five! ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Bug in tooltip handling
Nick Roberts <[EMAIL PROTECTED]> writes: Hi Nick, > I don't know what dictionary-el or your mode do but, if possible, its > best to add tooltips through the `help-echo' text property. My mode [1] opens a tooltip with translations of the word you're pointing at. The translation is done by an external Ruby script. Of course the translation process should only run if the user points at the word for a given amount of time (e.g. `tooltip-delay'). The problem with `help-echo' is that I would have to propertize every word in the buffer before tooltips would be available, thus I would have to call that external script on every word. This would take a lot of time and memory consumtion would increase dramatically, because every word would hold a set of possible translations in its `help-echo' property. Most of this work would be superfluous anyway, because normally the user knows most words and only needs translations of a handfull new words. Another thing with `help-echo' is that I would need to propertize newly typed words on the fly. (Ok, this should be possible somehow, flyspell does this, too.) > If dictionary-el is generally useful and it needs GUD-type tooltips > then the best way to do this might be to make it part of Emacs. dictionary-el is quite similar, but instead querying an external Ruby script it queries a dict server, so it's more general than simple word-translation, but IMHO most dict dictionaries are quite outdated (at least the translation dicts), which was the reason to write my own tool. To make it short: I would not include it, but the author may think different. Currently I'm fine with (require 'gud) (gud-tooltip-mode 1) [...] The only drawback of this is that I load too much (the whole GUD stuff instead of only the tooltip functionality), thus consuming a little more memory than necessary. Another drawback is that on every mouse event `gud-tooltip-tips' is executed (returning nil). If this is all, that's no big problem for me. Anyway, I think those event-based tooltips are useful for a lot of tasks where calculation of the tooltip contents is time-intensive and should not be performed beforehand. So splitting it out into an own library `event-tooltip' or so would be a good idea. Bye, Tassilo Footnotes: [1] http://www.uni-koblenz.de/%7Eheimdall/apps.php -- A child of five could understand this! Fetch me a child of five! ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Bug in tooltip handling
Nick Roberts <[EMAIL PROTECTED]> writes: > It returns nil in buffers where GUD tooltips are not meant to work i.e > when the major-mode is not a member of gud-tooltip-modes. > > I think thats the problem of just adding to tooltip-hook. You have a > list of functions and the last non-nil one wins. Yeah, so I'm fine with appending my function (locally) to the hook like this: (add-hook 'tooltip-hook 'rdictcc-translate-word-open-tooltip t t) > > Anyway, I think those event-based tooltips are useful for a lot of > > tasks where calculation of the tooltip contents is time-intensive > > and should not be performed beforehand. So splitting it out into an > > own library `event-tooltip' or so would be a good idea. > > Well, it's part of the answer. ??? I don't get you here. Part of which answer? Bye, Tassilo ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Bug in tooltip handling
Nick Roberts <[EMAIL PROTECTED]> writes: Hi Nick, > It might be fine for personalising Emacs but not a general package. > Your construction above adds the function to the hook at the end. So, > for example, if that's in a buffer that I'm using for debugging, the > tooltips will display translations of my variable names rather than > their values, which might not be what I want. Sure, but my rdictcc-tooltip-mode as well as dictionary-el's tooltip mode are buffer local. If a user enables one of them in a debugging buffer he might really want translations. After toggling the mode off, the GUD-tooltips will be back again. I mean, there are always minor modes which can conflict, so the user has to decide what he needs at a time. Enabling flyspell-mode in a buffer with elisp code will overwrite the normal font-locking, which might be exactly what the user wants. Bye, Tassilo -- VI VI VI - The Roman Number Of The Beast ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Bug in tooltip handling
Nick Roberts <[EMAIL PROTECTED]> writes: > The example that you gave at the start didn't toggle anything: it just > added a function to tooltip-hook. Right, sorry. It would have been better to poste the complete minor mode function. --8<---cut here---start->8--- (defun rdictcc-tooltip-mode (&optional arg) "Display tooltips with the translations of the word under the mouse pointer." (interactive "P") (require 'tooltip) (require 'gud) ;; The tooltips are currently part of GUD (let ((val (if arg (> (prefix-numeric-value arg) 0) (not rdictcc-tooltip-mode (if val ;; Switch tooltip mode on (progn (make-local-variable 'rdictcc-tooltip-mode) (setq rdictcc-tooltip-mode val) (make-local-variable 'tooltip-delay) (setq tooltip-delay rdictcc-tooltip-delay) (gud-tooltip-mode 1) (add-hook 'tooltip-hook 'rdictcc-translate-word-open-tooltip t t) (make-local-variable 'track-mouse) (setq track-mouse val)) ;; Switch tooltip mode off (kill-local-variable 'rdictcc-tooltip-mode) (kill-local-variable 'tooltip-delay) (kill-local-variable 'track-mouse) (remove-hook 'tooltip-hook 'rdictcc-translate-word-open-tooltip t --8<---cut here---end--->8--- > Anyway, I'll look at splitting out the functionality after the > release. Thanks a lot. > The pretest is meant to be imminent, but the last one for Emacs 21 > took about a year, so I wouldn't hold your breath. No problem. I'll be patient. Bye, Tassilo -- My opinions may have changed, but not the fact that I am right. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Emacs uses 100% cpu time
>From time to time emacs starts utilizing 100% of cpu time. Sometimes it falls back to normal usage for some seconds, but it always catches up again. Emacs stays responsible and the only indication is that my fan is running all the time, thus I'm not sure since when I have this problem. And I don't find a way to reproduce the bug. The only thing I would say is that it subjectively happens earlier, if network apps like gnus and circe are running. I ran emacs from gdb and got this backtrace: , | Program received signal SIGTSTP, Stopped (user). | 0x08145f5d in Fgarbage_collect () | (gdb) bt | #0 0x08145f5d in Fgarbage_collect () | #1 0x0815a11d in Ffuncall () | #2 0x08184baa in Fbyte_code () | #3 0x081598d8 in Feval () | #4 0x08158f1c in internal_catch () | #5 0x08183e2f in Fbyte_code () | #6 0x08159e24 in funcall_lambda () | #7 0x0815a23b in Ffuncall () | #8 0x08184baa in Fbyte_code () | #9 0x081598d8 in Feval () | #10 0x0815bf11 in internal_lisp_condition_case () | #11 0x08183ea9 in Fbyte_code () | #12 0x08159e24 in funcall_lambda () | #13 0x0815a23b in Ffuncall () | #14 0x0815bb1e in Fapply () | #15 0x0815a553 in Ffuncall () | #16 0x08184baa in Fbyte_code () | #17 0x081598d8 in Feval () | #18 0x0815bf11 in internal_lisp_condition_case () | #19 0x08183ea9 in Fbyte_code () | #20 0x08159e24 in funcall_lambda () | #21 0x0815a23b in Ffuncall () | #22 0x0815b6e9 in call1 () | #23 0x080fb7f7 in timer_check () | #24 0x0818b2e8 in wait_reading_process_output () | ---Type to continue, or q to quit--- | #25 0x08056488 in sit_for () | #26 0x080ff846 in read_char () | #27 0x081016e2 in read_key_sequence () | #28 0x08103195 in command_loop_1 () | #29 0x08158e5b in internal_condition_case () | #30 0x080fce2e in command_loop_2 () | #31 0x08158f1c in internal_catch () | #32 0x080fd89e in command_loop () | #33 0x080fdc28 in recursive_edit_1 () | #34 0x080fdd16 in Frecursive_edit () | #35 0x080f3dd2 in main () | (gdb) continue | Continuing. ` Two interesting observation: - When emacs uses 100% and I press `M-x' and the mini buffer is focused it instantly uses a normal cpu percentage again. After the mini buffer activity finished it starts going crazy again. But when I press `M-x' and jump back to my editing buffer with `C-x o' it works fine, too, e.g. no high cpu utilization. - Whenever I provide keyboard input to emacs the cpu usage goes down, too. In GNU Emacs 22.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2006-09-29 on baldur X server distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--prefix=/usr' '--host=i686-pc-linux-gnu' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--datadir=/usr/share' '--sysconfdir=/etc' '--localstatedir=/var/lib' '--program-suffix=.emacs-22.0.50' '--without-carbon' '--with-x' '--with-xpm' '--with-toolkit-scroll-bars' '--with-jpeg' '--with-tiff' '--with-gif' '--with-png' '--with-x-toolkit=gtk' '--build=i686-pc-linux-gnu' 'CFLAGS=-O2' 'build_alias=i686-pc-linux-gnu' 'host_alias=i686-pc-linux-gnu'' Important settings: value of $LC_ALL: de_DE.utf8 value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: de_DE.utf8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: Emacs-Lisp Minor modes in effect: shell-dirtrack-mode: t eldoc-mode: t tracking-mode: t recentf-mode: t desktop-save-mode: t show-paren-mode: t semantic-idle-scheduler-mode: t tooltip-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t abbrev-mode: t Recent input: C-x b C-gC-x C-s C-g C-g C-g M-x e m b u g s u b e m a C-g M-x r e p o r Recent messages: Wrote /home/heimdall/uni/repos/heimdall-uni/programs/elisp/th-abbrev.el Loading /home/heimdall/uni/repos/heimdall-uni/programs/elisp/th-abbrev.el (source)...done th-abbrev.el reloaded. Quit (No changes need to be saved) Quit [3 times] Making completion list... [2 times] Quit Making completion list... [2 times] Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs uses 100% cpu time
Nick Roberts <[EMAIL PROTECTED]> writes:
Hi Nick,
> Maybe someone can interpret your observations, but generally you need
> to compile Emacs with -g so that the backtrace gives argument values
Ok, I did a fesh checkout 1 hour ago and compiled it with -g. Here's
gdb's `bt full'.
(gdb) run
Starting program: /usr/bin/emacs
[Thread debugging using libthread_db enabled]
[New Thread -1220720976 (LWP 27396)]
Program received signal SIGTSTP, Stopped (user).
[Switching to Thread -1220720976 (LWP 27396)]
0x0814b8be in swap_in_symval_forwarding (symbol=137550897,
valcontents=) at data.c:1026
1026data.c: Datei oder Verzeichnis nicht gefunden.
in data.c
(gdb) bt full
#0 0x0814b8be in swap_in_symval_forwarding (symbol=137550897,
valcontents=) at data.c:1026
tem1 =
#1 0x0814ba65 in find_symbol_value (symbol=137550897) at data.c:1073
valcontents = 137551970
val =
#2 0x0814bcd2 in Fsymbol_value (symbol=137550897) at data.c:1109
val =
#3 0x0811214c in set_buffer_internal_1 (b=0x955a8b8) at buffer.c:1899
tail =
valcontents =
tem = 137551970
#4 0x08113306 in Fset_buffer (buffer=156608700) at buffer.c:1980
buf = 156608700
#5 0x081839dc in Fbyte_code (bytestr=142606907, vector=142886428, maxdepth=64)
at bytecode.c:1350
v1 =
v2 =
op = 137551968
vectorp = (Lisp_Object *) 0x8844620
stack = {pc = 0x880a28b "\210\016\031\f=\203\206", top = 0xbfdc37a0,
bottom = 0xbfdc37a0, byte_string = 142606907,
byte_string_start = 0x880a230 "�030\"\"\"\031�211\032\033�034\r\203�,
constants = 142886428, next = 0xbfdc39d0}
top = (Lisp_Object *) 0xbfdc37a0
result =
#6 0x081598d8 in Feval (form=142547469) at eval.c:2330
numargs =
argvals = {142606907, 142886428, 64, 135805346, 137504257, 148840957,
157559280, 0}
args_left = 137459913
i = 3
fun =
val =
original_fun = 137554113
original_args = 142547461
funcar =
backtrace = {next = 0xbfdc3a78, function = 0xbfdc3888,
args = 0xbfdc3850, nargs = 3, evalargs = 1 '\001', debug_on_exit = 0 '\0'}
#7 0x08158f1c in internal_catch (tag=141382977, func=0x8159510 ,
arg=142547469) at eval.c:1218
c = {tag = 141382977, val = 137459913, next = 0xbfdc3bb8, gcpro = 0x0,
jmp = {{__jmpbuf = {135632144, -1076086384, 142647784, -1076086408,
1165093982, -222798863}, __mask_was_saved = 0, __saved_mask = {
__val = {135468231, 2, 3218880752, 24, 3218880916, 0, 56,
137459913 , backlist = 0xbfdc3a78,
handlerlist = 0xbfdc3c80, lisp_eval_depth = 6, pdlcount = 12,
poll_suppress_count = 1, interrupt_input_blocked = 0,
byte_stack = 0xbfdc39d0}
#8 0x08183e2f in Fbyte_code (bytestr=142606955, vector=142323308, maxdepth=24)
at bytecode.c:854
v1 =
op = 137551968
vectorp = (Lisp_Object *) 0x87bae70
stack = {pc = 0x880a1f5 "\210)\b\205\026", top = 0xbfdc3994,
bottom = 0xbfdc3990, byte_string = 142606955,
---Type to continue, or q to quit---
byte_string_start = 0x880a1e8 "\b\203\b", constants = 142323308,
next = 0xbfdc3af0}
top = (Lisp_Object *) 0xbfdc3990
result =
#9 0x08159e24 in funcall_lambda (fun=142323444, nargs=0,
arg_vector=0xbfdc3ab4) at eval.c:3180
val =
syms_left =
next =
i = 0
optional = 158258125
rest = 137459913
#10 0x0815a23b in Ffuncall (nargs=1, args=0xbfdc3ab0) at eval.c:3050
fun = 142323444
original_fun = 141382953
funcar =
numargs = 0
val =
backtrace = {next = 0xbfdc3b70, function = 0xbfdc3ab0,
args = 0xbfdc3ab4, nargs = 0, evalargs = 0 '\0', debug_on_exit = 0 '\0'}
internal_args = (Lisp_Object *) 0xbfdc3ab4
i =
#11 0x08184baa in Fbyte_code (bytestr=141386203, vector=142323572, maxdepth=8)
at bytecode.c:679
v1 =
v2 =
op = 137551970
vectorp = (Lisp_Object *) 0x87baf78
stack = {pc = 0x880a4de "*\207", top = 0xbfdc3ab0,
bottom = 0xbfdc3ab0, byte_string = 141386203,
byte_string_start = 0x880a4d4 "�\210�\030�216�*\207",
constants = 142323572, next = 0xbfdc3cf0}
top =
result =
#12 0x081598d8 in Feval (form=142547141) at eval.c:2330
numargs =
argvals = {141386203, 142323572, 8, 135634493, 128, 157990044, 32,
-1076085840}
args_left = 137459913
i = 3
fun =
val =
original_fun = 137554113
original_args = 142547117
funcar =
backtrace = {next = 0xbfdc3d98, function = 0xbfdc3b88,
args = 0xbfdc3b50, nargs = 3, evalargs = 1 '\001', debug_on_exit = 0 '\0'}
#13 0x0815bf11 in internal_lisp_condition_case (var=137791249,
bodyform=142547141, handlers=142991069) at eval.c:1422
val =
c = {tag = 137459913, val = 137459913, next = 0xbfdc3f68, gcpro = 0x0,
jmp = {{__jmpbuf = {1374
Re: Emacs uses 100% cpu time
Tassilo Horn <[EMAIL PROTECTED]> writes: >> This happens automatically if you attach to emacs in the directory in >> which it was built i.e using .gdbinit (also needed for xbacktrace). Ok, now I've run gdb from emacs src build directory and made a new backtrace. It's too large to post here (1.2 MB), so get it from http://www.uni-koblenz.de/~heimdall/emacs-bt-full.gz Bye, Tassilo -- My opinions may have changed, but not the fact that I am right. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs uses 100% cpu time
Hi all, I made some more backtraces [1], which are much shorter now (no clue why...). And I found a way to enforce the problem to occur. Whenever I open a lisp file (elisp or CL) emacs goes crazy nearly instantly. With normal text files without highlighting the problem never occurs that fast, if at all. Other modes / files don't trigger the bug, too, or at least not that fast. I opened some haskell (with haskell-mode from haskell.org) and ruby (with ruby-mode which comes with the ruby tarball) files, scrolled, edited, marked, killed, but nothing happened. Bye, Tassilo Footnotes: [1] http://www.uni-koblenz.de/~heimdall/emacs-bt.tar.gz ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs uses 100% cpu time
Stefan Monnier <[EMAIL PROTECTED]> writes: Hello Stefan, > Does (setq jit-lock-stealth-time nil) fix it? No. If it has already started looping it has no effect at all, and if I set in in my ~/.emacs and restart it, I can reproduce the bug again, but it seems to happen not that fast. If it's set to the default of 16 I just have to open my ~/.emacs, and bam, 100% cpu utilization. If it's set to nil I had to jump arround the buffer for some time. Now I'll do what Richard suggested: Making normal backtraces and looking for a common pattern... Bye, Tassilo ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs uses 100% cpu time
Richard Stallman <[EMAIL PROTECTED]> writes:
Hello Richard,
> The way to find out where a program is running during a long operation
> is to stop the program several times, making a backtrace each time.
> When you see a pattern start to emerge, then please report it.
Ok, all backtraces have this bottom part, although the arguments may
vary a bit:
#32 0x0818b2e8 in wait_reading_process_output (time_limit=30, microsecs=0,
read_kbd=-1, do_display=1, wait_for_cell=137459913, wait_proc=0x0,
just_wait_proc=0) at process.c:4343
#33 0x08056488 in sit_for (timeout=240, reading=1, do_display=1)
at dispnew.c:6548
#34 0x080ff846 in read_char (commandflag=1, nmaps=4, maps=0xbf806180,
prev_event=137459913, used_mouse_menu=0xbf806228, end_time=0x0)
---Type to continue, or q to quit---
at keyboard.c:2865
#35 0x081016e2 in read_key_sequence (keybuf=0xbf8062d4, bufsize=30,
prompt=137459913, dont_downcase_last=0, can_return_switch_frame=1,
fix_current_buffer=1) at keyboard.c:8956
#36 0x08103195 in command_loop_1 () at keyboard.c:1601
#37 0x08158e5b in internal_condition_case (bfun=0x8103000 ,
handlers=137504617, hfun=0x80fda50 ) at eval.c:1477
#38 0x080fce2e in command_loop_2 () at keyboard.c:1326
#39 0x08158f1c in internal_catch (tag=137500825,
func=0x80fce00 , arg=137459913) at eval.c:1218
#40 0x080fd89e in command_loop () at keyboard.c:1305
#41 0x080fdc28 in recursive_edit_1 () at keyboard.c:1003
#42 0x080fdd16 in Frecursive_edit () at keyboard.c:1064
#43 0x080f3dd2 in main (argc=Cannot access memory at address 0x4
) at emacs.c:1794
Above this part, there's nothing all backtraces have in common.
> If the pattern you see involves lots of calls to Ffuncall, that means
> it is running Lisp code. In that case only, you need to use
> `xbacktrace' in order to look at the Lisp-level backtrace.
I have made several backtraces without calls to Ffuncall at all.
> Once you see the pattern, you should follow the instructions in
> etc/DEBUG to figure out which of the frames is actually looping.
According point "** If the symptom of the bug is that Emacs fails to
respond" I stopped emacs with C-z in the terminal GDB is running in and
typed finish till the call didn't return anymore. That was in
wait_reading_process_output. So I pressed C-z again and stepped through
that frame with next:
(gdb) finish
Run till exit from #0 0x0818b2e8 in wait_reading_process_output (
time_limit=30, microsecs=0, read_kbd=-1, do_display=1,
wait_for_cell=137459913, wait_proc=0x0, just_wait_proc=0) at process.c:4343
Program received signal SIGTSTP, Stopped (user).
0x08141c3c in mark_object (arg=151918113) at alloc.c:5447
5447{
(gdb) next
Program received signal SIGTSTP, Stopped (user).
0x08141c3c in mark_object (arg=151918113) at alloc.c:5447
5447{
(gdb) next
5457 if (PURE_POINTER_P (XPNTR (obj)))
(gdb) next
5460 last_marked[last_marked_index++] = obj;
(gdb) next
5461 if (last_marked_index == LAST_MARKED_SIZE)
(gdb) next
5460 last_marked[last_marked_index++] = obj;
(gdb) next
5461 if (last_marked_index == LAST_MARKED_SIZE)
(gdb) next
5503 switch (SWITCH_ENUM_CAST (XGCTYPE (obj)))
(gdb) next
5700register struct Lisp_Symbol *ptr = XSYMBOL (obj);
(gdb) next
5703if (ptr->gcmarkbit) break;
(gdb) next
5842}
(gdb) next
mark_object (arg=153342668) at alloc.c:5693
5693 for (i = 0; i < size; i++) /* and then mark its elements */
(gdb) next
5694mark_object (ptr->contents[i]);
(gdb) next
5693 for (i = 0; i < size; i++) /* and then mark its elements */
(gdb) next
5694mark_object (ptr->contents[i]);
[...]
It seems I could do this ad infimum...
Then I continued and stopped emacs again. It didn't finish the same
frame as before, but seemes to be stuck in another loop:
(gdb)
5964 if (!CONS_MARKED_P (&cblk->conses[i]))
(gdb)
5976 CONS_UNMARK (&cblk->conses[i]);
(gdb)
5963for (i = 0; i < lim; i++)
(gdb)
5976 CONS_UNMARK (&cblk->conses[i]);
(gdb)
5975 num_used++;
(gdb)
5963for (i = 0; i < lim; i++)
(gdb)
5976 CONS_UNMARK (&cblk->conses[i]);
(gdb)
5963for (i = 0; i < lim; i++)
(gdb)
5964 if (!CONS_MARKED_P (&cblk->conses[i]))
(gdb)
5976 CONS_UNMARK (&cblk->conses[i]);
(gdb)
5963for (i = 0; i < lim; i++)
(gdb)
5976 CONS_UNMARK (&cblk->conses[i]);
(gdb)
5975 num_used++;
(gdb)
> Of course, if people think this is a bug that is already fixed, it is
> worth checking that first before you spend the time to do the
> debugging described above.
My checkout is one day old now, so it may be related but definitely not
fixed.
Bye,
Tassilo
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs uses 100% cpu time
Stefan Monnier <[EMAIL PROTECTED]> writes:
Hello Stefan,
> What about your .emacs file? Have you tried to empty it (or partly)
> to see if something in it triggers the problem?
I cannot reproduce the bug with --no-site-file or -Q. If I start emacs
with -q the bug occurs. So it seems to have something to do with the
code in my site-file. I tried commenting out each block of external
mode's init code, but that didn't help. Is it possible that there is a
weird combination or order of how external modes are loaded?
,[ /usr/share/emacs/site-lisp/site-start.el ]
| (load "/usr/share/emacs/site-lisp/site-gentoo")
`
,[ /usr/share/emacs/site-lisp/site-gentoo.el ]
| ;;; DO NOT EDIT THIS FILE -- IT IS GENERATED AUTOMATICALLY BY PORTAGE
| ;;; -
|
|
| ;;; ispell-aspell site-lisp configuration
|
| (setq ispell-program-name "aspell")
|
| ;;; boxquote site-lisp configuration
|
| (setq load-path (cons "/usr/share/emacs/site-lisp/boxquote" load-path))
| (require 'boxquote)
|
|
| ;;; circe site-lisp configuration
|
| (add-to-list 'load-path "/usr/share/emacs/site-lisp/circe-cvs")
| (require 'circe-auto)
|
| ;;; elib site-lisp configuration
|
| (setq load-path (cons "/usr/share/emacs/site-lisp/elib" load-path))
|
| ;;; site-lisp configuration for emms-cvs
|
| (add-to-list 'load-path "/usr/share/emacs/site-lisp/emms")
| (require 'emms)
| ;;; Gnuplot site-lisp configuration
|
| (add-to-list 'load-path "/usr/share/emacs/site-lisp/gnuplot")
|
| ;;
| ;; Lines enabling gnuplot-mode
|
| (autoload 'gnuplot-mode "gnuplot" "gnuplot major mode" t)
| (autoload 'gnuplot-make-buffer "gnuplot" "open a buffer in gnuplot mode" t)
|
| ;; this line automatically causes all files with the .gp extension to
| ;; be loaded into gnuplot mode
| (setq auto-mode-alist (append '(("\\.gp$" . gnuplot-mode)) auto-mode-alist))
|
| ;; This line binds the function-9 key so that it opens a buffer into
| ;; gnuplot mode
| (global-set-key [(f9)] 'gnuplot-make-buffer)
|
| ;; end of line for gnuplot-mode
| ;;
|
| ;;; haskell-mode site-lisp configuration
|
| (add-to-list 'load-path "/usr/share/emacs/site-lisp/haskell-mode")
| (setq auto-mode-alist
| (append auto-mode-alist
| '(("\\.[hg]s$" . haskell-mode)
| ("\\.hi$" . haskell-mode)
| ("\\.l[hg]s$" . literate-haskell-mode
| (autoload 'haskell-mode "haskell-mode"
| "Major mode for editing Haskell scripts." t)
| (autoload 'literate-haskell-mode "haskell-mode"
| "Major mode for editing literate Haskell scripts." t)
|
| ;;; htmlize site-lisp configuration
|
| (add-to-list 'load-path "/usr/share/emacs/site-lisp/htmlize")
| (require 'htmlize)
|
| ;;; mailcrypt site-lisp configuration
|
| (setq load-path (cons "/usr/share/emacs/site-lisp/mailcrypt" load-path))
| ;; maxima mode
| (setq load-path (cons "/usr/shar/maxima/5.9.3/emacs" load-path))
| (autoload 'maxima-mode "maxima" "Maxima mode" t)
| (autoload 'maxima "maxima" "Maxima interactive" t)
| (setq auto-mode-alist (cons '("\\.max" . maxima-mode) auto-mode-alist))
| (autoload 'dbl "dbl" "Make a debugger to run lisp, maxima and or gdb in" t)
| (autoload 'gcl-mode "gcl" "Major mode for editing maxima code and interacting
with debugger" t)
| (setq auto-mode-alist (cons '("\\.ma?[cx]\\'" . maxima-mode) auto-mode-alist))
|
| ;; emaxima mode
| (autoload 'emaxima-mode "emaxima" "EMaxima" t)
| (add-hook 'emaxima-mode-hook 'emaxima-mark-file-as-emaxima)
|
|
| ;; site-file configuration for po-mode
|
| (autoload 'po-mode "po-mode" "Major mode for translators to edit PO files" t)
| (autoload 'po-find-file-coding-system "po-compat")
|
| (add-to-list 'auto-mode-alist '("\\.po\\'\\|\\.po\\." . po-mode))
| (modify-coding-system-alist 'file "\\.po\\'\\|\\.po\\."
'po-find-file-coding-system)
|
| ;;; ruby-mode site-lisp configuration
|
| (add-to-list 'load-path "/usr/share/emacs/site-lisp/ruby-mode")
|
| (autoload 'ruby-mode "ruby-mode" "Major mode to edit ruby files." t)
|
| (add-to-list 'auto-mode-alist '("\\.rb\\'" . ruby-mode))
| (add-to-list 'interpreter-mode-alist '("ruby" . ruby-mode))
|
| (autoload 'run-ruby "inf-ruby" "Run an inferior Ruby process" t)
| (autoload 'inf-ruby-keys "inf-ruby" "Set local key defs for inf-ruby in
ruby-mode")
|
| (add-hook 'ruby-mode-hook 'inf-ruby-keys)
|
| ;;; auctex site-lisp configuration
|
| (load "auctex.el" nil t t)
|
| ;;; auctex site-lisp configuration, activating preview-latex
|
| (load "preview-latex.el" nil t t)
|
| ;;; cedet site-lisp configuration
|
| (load "/usr/share/emacs/site-lisp/cedet/common/cedet")
|
| ;; If you wish to customize CEDET, you will need to follow the
| ;; directions in the INSTALL (installed in the documentation) file and
| ;; customize your ~/.emacs /before/ site-gentoo is loaded.
|
Re: Emacs uses 100% cpu time
Eugene Vlasov <[EMAIL PROTECTED]> writes: Hi Eugene, >> | (load "/usr/share/emacs/site-lisp/cedet/common/cedet") > > Try to update CEDET to latest CVS snapshot. Or just update > semantic-idle.el (and may be semantic-analyze.el) files. IT WORKS! I updated semantic-idle.el, where one line was changed compared to my cedet-1.0_pre3. The semantic-analyze.el from HEAD is the same as the one in my version. Thanks a lot, Tassilo ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs uses 100% cpu time
Stefan Monnier <[EMAIL PROTECTED]> writes: Hello Stefan, >> | (load "/usr/share/emacs/site-lisp/cedet/common/cedet") > > Doesn't CEDET include Semantic which was known to have some bad > interaction with the new sit-for code? Yep, see Eugene's mail <[EMAIL PROTECTED]>. I updated semantic-idle.el and now the problem seems to have gone. Raman, could you verify this? > Admittedly, it would be good if Emacs could behave better with the > "old" Semantic code. Maybe just detect the problematic behavior and > output a useful warning? The change in semantic-idle.el is trivial, so that should be no problem. See http://xrl.us/rztp Bye, Tassilo ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs uses 100% cpu time
"T. V. Raman" <[EMAIL PROTECTED]> writes: Hi, > did you update semantic out of CVS? the last release on the > sourceforge site appears to be from 2005 Yes, but only semantic-idle.el. Bye, Tassilo ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Weird article scrolling in Gnus with customized face
Ok, I start up Gnus. Now, if I view an article by hitting RET (`gnus-summary-scroll-up') on it in *Summary*, I get the following behavior: - as long as there are visible headers (Subject, From, etc.) on top of the buffer, pressing RET scrolls exactly one line as it should be. - when the last visible header scrolled out of the visible buffer part pressing RET results in scrolling one entire page like SPACE (`gnus-summary-next-page') does. - the same applies to M-RET I tried it on a test account, and all worked fine. But I was able to locate the source of the problem: One customized face is causing the trouble! (custom-set-faces '(mode-line class color) (min-colors 88)) (:background "darkred" :foreground "grey" :box (:line-width 1 :style released-button) :height 0.8 :family "helvetica") If I commend out this line, scrolling works as it should. With this line I can reproduce the bug in both No Gnus and 5-11. In GNU Emacs 22.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.10.6) of 2006-10-24 on baldur X server distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--prefix=/usr' '--host=i686-pc-linux-gnu' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--datadir=/usr/share' '--sysconfdir=/etc' '--localstatedir=/var/lib' '--program-suffix=.emacs-22.0.50' '--without-carbon' '--with-x' '--with-xpm' '--with-toolkit-scroll-bars' '--with-jpeg' '--with-tiff' '--with-gif' '--with-png' '--with-x-toolkit=gtk' '--build=i686-pc-linux-gnu' 'CFLAGS=-O2' 'build_alias=i686-pc-linux-gnu' 'host_alias=i686-pc-linux-gnu'' Important settings: value of $LC_ALL: de_DE.utf8 value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: de_DE.utf8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: Emacs-Lisp Minor modes in effect: eldoc-mode: t recentf-mode: t desktop-save-mode: t show-paren-mode: t semantic-idle-scheduler-mode: t tooltip-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t abbrev-mode: t Recent input: y n y w a y s . C-x 1 C-c C-c y q l s C-x 1 C-x b C-x C-s M-x e mb u g r e p p o r b Recent messages: Deleting article /home/heimdall/News/drafts/drafts/3 in drafts... No more unread newsgroups Wrote /home/heimdall/.newsrc Saving /home/heimdall/.newsrc.eld... Saving file /home/heimdall/.newsrc.eld... Wrote /home/heimdall/.newsrc.eld Saving /home/heimdall/.newsrc.eld...done (No changes need to be saved) Making completion list... [4 times] Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Customizing how windows are split by display-buffer
Hi Fredrik, Hey, I had the same idea about a week ago and implemented it in elisp. --8<---cut here---start->8--- (defun th-display-buffer (buffer force-other-window) "If BUFFER is visible, select it. If it's not visible and there's only one window, split the current window and select BUFFER in the new window. If the current window (before the split) is more than 165 columns wide, split horizontally, else split vertically. If the current buffer contains more than one window, select BUFFER in the least recently used window. This function returns the window which holds BUFFER. FORCE-OTHER-WINDOW is ignored." (or (get-buffer-window buffer) (if (one-window-p) (let ((new-win (if (> (window-width) 165) (split-window-horizontally) (split-window-vertically (set-window-buffer new-win buffer) new-win) (let ((new-win (get-lru-window))) (set-window-buffer new-win buffer) new-win (setq display-buffer-function 'th-display-buffer) --8<---cut here---end--->8--- But my function doesn't behave exactly like a "horizontalized" `display-buffer', because it will always split if there's only one window and never reuse the current window. That makes a difference for e.g. `M-x info'. I like this difference, but I was very surprised that there is no standard way to tell emacs that I prefer horizontal splitting. In times where most new computers have wide-screen displays your patch should really be considered for inclusion, best before the release of Emacs 22. Bye, Tassilo -- The glass is neither half-full nor half-empty: it's twice as big as it needs to be. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Tumme fails with default custom settings
Mathias Dahl <[EMAIL PROTECTED]> writes: Hi Matthias, > Could someone else test as well? Here, the thumbs are displayed properly, and RET opens a *tumme-display-image* buffer with a scaled image. (The original icon is 64x64, and the buffer shows about a 350x350 version) When I type `f' a small, empty square is displayed -- not the image. `s' gets me back to the scaled image. However, the fix of Stephen doesn't help here. I removed the +profile "*" option and set the changes for the current session, killed the *tumme-display-image* buffer and typed RET on a thumb to open a new image buffer. Still the image transforms to an empty box with `f'. Bye, Tassilo -- The easiest way to determine Chuck Norris' age is to cut him in half and count the rings. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
(recentf-mode 1) aborts emacs
Please write in English if possible, because the Emacs maintainers usually do not have translators to read other languages for them. Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list. Please describe exactly what actions triggered the bug and the precise symptoms of the bug: Hi, since I updated my emacs checkout (head, not a branch) this morning my emacs shuts down immediately after starting. This was due to a SIGABRT. I commented out things in my ~/.emacs and found out that the line (recentf-mode 1) causes this bug. I made a backtrace with a ~/.emacs only containing the line (recentf-mode 1) and did `gdb --args /usr/bin/emacs-22-cvs -Q -l .emacs'. The backtrace is pasted here: http://paste.lisp.org/display/43790 The checkout I compiled yesterday morning (CEST) worked just fine. If Emacs crashed, and you have the Emacs process in the gdb debugger, please include the output from the following gdb commands: `bt full' and `xbacktrace'. If you would like to further debug the crash, please read the file /usr/share/emacs/22.1.50/etc/DEBUG for instructions. In GNU Emacs 22.1.50.1 (i686-pc-linux-gnu, GTK+ Version 2.10.13) of 2007-07-02 on baldur Windowing system distributor `The X.Org Foundation', version 11.0.1030 configured using `configure '--prefix=/usr' '--host=i686-pc-linux-gnu' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--datadir=/usr/share' '--sysconfdir=/etc' '--localstatedir=/var/lib' '--program-suffix=-emacs-22-cvs' '--infodir=/usr/share/info/emacs-22-cvs' '--without-carbon' '--with-sound' '--with-x' '--with-xpm' '--with-toolkit-scroll-bars' '--with-jpeg' '--with-tiff' '--with-gif' '--with-png' '--with-x-toolkit=gtk' '--without-hesiod' '--with-gpm' '--build=i686-pc-linux-gnu' 'build_alias=i686-pc-linux-gnu' 'host_alias=i686-pc-linux-gnu' 'CFLAGS=-march=i386 -O0 -pipe -g'' Important settings: value of $LC_ALL: en_US.UTF-8 value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_US.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: Group Minor modes in effect: gnus-topic-mode: t gnus-undo-mode: t desktop-save-mode: t window-number-meta-mode: t window-number-mode: t show-paren-mode: t which-function-mode: t tooltip-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t Recent input: y M-1 M-2 M-3 C-x 0 M-x t h - s e r s t C-x 0 C-x 0 M-x g n u s y M-x r e p e m a C-g C-g C-h a b u g $ M-x r e p o r b Recent messages: Desktop lazily opening .gnus.el (8 remaining)...done Desktop lazily opening main.org (7 remaining)...done Desktop lazily opening private.org (6 remaining)...done Desktop lazily opening remember-notes.org (5 remaining)...done Desktop lazily opening uni.org (4 remaining)...done Desktop lazily opening work.org (3 remaining)...done Desktop lazily opening diary (2 remaining)...done Desktop lazily opening diplomarbeit.org (1 remaining)...done Lazy desktop load complete Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Emacs crashes with SIGABRT (was: (recentf-mode 1) aborts emacs)
Hi all, I just wanted to mention that this bug seems not to be strictly related to (recentf-mode 1), but that triggers the bug immediately. But although I commented out this line (and all of recentf settings), emacs crashed with SIGABRT after about 10 hours uptime. Unfortunately it didn't run in the debugger this time... My observations are that the bug occurs much more often when I run emacs with its GTK interface than the terminal version. Bye, Tassilo ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
vc-register doesn't recognize subversion repository
Please write in English if possible, because the Emacs maintainers usually do not have translators to read other languages for them. Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list. Please describe exactly what actions triggered the bug and the precise symptoms of the bug: If I find a new file in a directory that's under subversion version control and say `M-x vc-register' I'm prompted if a rcs directory should be created. It seems emacs doesn't recognize that there's a .svn directory already. I cannot say since when emacs has this bug, but about one month ago it worked as expected. Emacs recognized that this file is in a svn In GNU Emacs 22.1.50.1 (i686-pc-linux-gnu, GTK+ Version 2.10.13) of 2007-07-11 on baldur Windowing system distributor `The X.Org Foundation', version 11.0.1030 configured using `configure '--prefix=/usr' '--host=i686-pc-linux-gnu' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--datadir=/usr/share' '--sysconfdir=/etc' '--localstatedir=/var/lib' '--program-suffix=-emacs-22-cvs' '--infodir=/usr/share/info/emacs-22-cvs' '--without-carbon' '--with-sound' '--with-x' '--with-xpm' '--with-toolkit-scroll-bars' '--with-jpeg' '--with-tiff' '--with-gif' '--with-png' '--with-x-toolkit=gtk' '--without-hesiod' '--with-gpm' '--build=i686-pc-linux-gnu' 'build_alias=i686-pc-linux-gnu' 'host_alias=i686-pc-linux-gnu' 'CFLAGS=-march=i686 -mtune=prescott -O2 -pipe'' Important settings: value of $LC_ALL: en_US.UTF-8 value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_US.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: Text Minor modes in effect: shell-dirtrack-mode: t tracking-mode: t desktop-save-mode: t recentf-mode: t window-number-meta-mode: t window-number-mode: t savehist-mode: t show-paren-mode: t global-hl-line-mode: t which-function-mode: t tooltip-mode: t mouse-wheel-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t Recent input: i i s SPC i n SPC a SPC s v n SPC r e p o s i t a r y o r f y SPC a s n d SPC a d d e d SPC i t SPC t o SPC v e r s i o n SPC t c o n r t r o l . C-k C-k C-k C-k C-k C-k C-k C-k C-k C-k C-k C-k C-SPC M-w C-x k y C-x k C-x b M-x v c - r e g n M-x r e p o r t e m a b u Recent messages: Auto-saving...done Auto-saving...done Mark set Buffer *mail to [EMAIL PROTECTED] modified; kill anyway? (y or n) Mark set Press C-c C-c when you are done editing. Registering /home/heimdall/uni/repos/st-ss07/victor/comments/blatt08.txt... Create RCS subdirectory? (y or n) apply: Searching for program: no such file or directory, rcs Making completion list... ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [2007-07-24] Unicode2 -- Building Emacs overflowed pure space
Katsumi Yamaoka <[EMAIL PROTECTED]> writes: Hi Katsumi, > It has been solved by this change: > > --- puresize.h~ 2007-01-14 03:24:37 + > +++ puresize.h2007-07-25 23:58:10 + > @@ -46 +46 @@ > -#define BASE_PURESIZE (112 + SYSTEM_PURESIZE_EXTRA + > SITELOAD_PURESIZE_EXTRA) > +#define BASE_PURESIZE (1121000 + SYSTEM_PURESIZE_EXTRA + > SITELOAD_PURESIZE_EXTRA) I updated my working copy one minute ago (22.1.50), but this patch has not been applied so far. Bye, Tassilo -- Writing a newsreader isn't hard, any dwep can do it. And, unfortunately, a lot of them does. Even worse, some of them works for Microsoft or Netscape. Writing a *good* newsreader is hard, and writing the perfect newsreader is Lars Magne Ingebrigtsen. (Per Abrahamsen) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Make bootstrap fails because of missing cl-loaddefs.el
Please write in English if possible, because the Emacs maintainers usually do not have translators to read other languages for them. Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list. Please describe exactly what actions triggered the bug and the precise symptoms of the bug: Here's the compile output. --8<---cut here---start->8--- (cd lisp; make -w --jobserver-fds=3,4 - --jobserver-fds=3,4 -j bootstrap-prepare) make[2]: Entering directory `/var/tmp/portage/app-editors/emacs-cvs-22.1.50/work/emacs/man' cd /var/tmp/portage/app-editors/emacs-cvs-22.1.50/work/emacs/man; makeinfo --force emacs.texi cd /var/tmp/portage/app-editors/emacs-cvs-22.1.50/work/emacs/man; makeinfo --force cc-mode.texi make[2]: Entering directory `/var/tmp/portage/app-editors/emacs-cvs-22.1.50/work/emacs/lisp' if test -x ../src/emacs; then \ make -w --jobserver-fds=3,4 - --jobserver-fds=3,4 - --jobserver-fds=3,4 - --jobserver-fds=3,4 -j autoloads; \ else\ cp /var/tmp/portage/app-editors/emacs-cvs-22.1.50/work/emacs/lisp/ldefs-boot.el /var/tmp/portage/app-editors/emacs-cvs-22.1.50/work/emacs/lisp/loaddefs.el; \ fi chmod +w /var/tmp/portage/app-editors/emacs-cvs-22.1.50/work/emacs/lisp/loaddefs.el \ /var/tmp/portage/app-editors/emacs-cvs-22.1.50/work/emacs/lisp/ps-print.el \ /var/tmp/portage/app-editors/emacs-cvs-22.1.50/work/emacs/lisp/emacs-lisp/cl-loaddefs.el chmod: cannot access `/var/tmp/portage/app-editors/emacs-cvs-22.1.50/work/emacs/lisp/emacs-lisp/cl-loaddefs.el': No such file or directory make[2]: *** [bootstrap-prepare] Error 1 make[2]: Leaving directory `/var/tmp/portage/app-editors/emacs-cvs-22.1.50/work/emacs/lisp' make[1]: *** [bootstrap-build] Error 2 make[1]: *** Waiting for unfinished jobs --8<---cut here---end--->8--- In GNU Emacs 22.1.50.1 (i686-pc-linux-gnu, GTK+ Version 2.10.14) of 2007-07-30 on baldur configured using `configure '--prefix=/usr' '--host=i686-pc-linux-gnu' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--datadir=/usr/share' '--sysconfdir=/etc' '--localstatedir=/var/lib' '--program-suffix=-emacs-22-cvs' '--infodir=/usr/share/info/emacs-22-cvs' '--without-carbon' '--with-sound' '--with-x' '--with-xpm' '--with-toolkit-scroll-bars' '--with-jpeg' '--with-tiff' '--with-gif' '--with-png' '--with-x-toolkit=gtk' '--without-hesiod' '--with-gpm' '--build=i686-pc-linux-gnu' 'build_alias=i686-pc-linux-gnu' 'host_alias=i686-pc-linux-gnu' 'CFLAGS=-march=i686 -mtune=prescott -O2 -pipe'' Important settings: value of $LC_ALL: en_US.UTF-8 value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_US.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: Group Minor modes in effect: gnus-topic-mode: t gnus-undo-mode: t desktop-save-mode: t recentf-mode: t window-number-meta-mode: t window-number-mode: t savehist-mode: t exec-abbrev-cmd-mode: t show-paren-mode: t global-hl-line-mode: t encoded-kbd-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t Recent input: ESC x g n u s RET RET SPC RET RET RET RET RET RET RET RET RET RET RET RET RET RET RET RET RET c RET SPC c ESC x r e p o r TAB b u TAB RET Recent messages: 20070730T090056.690> Opening nntp server on Uni... 20070730T090056.691> Opening nntp server on Uni...done 20070730T090056.715> Fetching headers for nntp+Uni:gnu.emacs.help... 20070730T090056.947> Fetching headers for nntp+Uni:gnu.emacs.help...done 20070730T090057.068> Scoring... 20070730T090057.077> Scoring...done 20070730T090057.078> Generating summary... 20070730T090057.078> Generating summary...done 20070730T090059.611> No more unread articles Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs trunk needs to increase PURESIZE
Katsumi Yamaoka <[EMAIL PROTECTED]> writes: > The value of PURESIZE needs to be increased for at least the > Fedora 7 system: > > [...] > Dumping under names emacs and emacs-22.1.50.1 > emacs:0:Pure Lisp storage overflow (approx. 1120140 bytes needed) > 144 pure bytes used > [...] It's the same for my Gentoo GNU/Linux box. Bye, Tassilo ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
