Re: 4 week-old pretest bugs
> On Mon, 15 Jan 2007 00:01:49 +0100, Chris Moore <[EMAIL PROTECTED]> said:
> If not, I'm more than happy to run any test cases you would like me
> to try. I've tried debugging it in various ways myself, but the
> timing seems to be so touchy that any attempt to observe what's
> going on changes things.
Could you test if the following patch affects the stability?
YAMAMOTO Mitsuharu
[EMAIL PROTECTED]
Index: src/alloc.c
===
RCS file: /sources/emacs/emacs/src/alloc.c,v
retrieving revision 1.407
diff -c -p -r1.407 alloc.c
*** src/alloc.c 21 Jan 2007 04:18:17 - 1.407
--- src/alloc.c 23 Jan 2007 07:43:15 -
*** static pthread_mutex_t alloc_mutex;
*** 131,137
do\
{ \
if (pthread_equal (pthread_self (), main_thread)) \
! sigblock (sigmask (SIGIO)); \
pthread_mutex_lock (&alloc_mutex);\
} \
while (0)
--- 131,137
do\
{ \
if (pthread_equal (pthread_self (), main_thread)) \
! BLOCK_INPUT; \
pthread_mutex_lock (&alloc_mutex);\
} \
while (0)
*** static pthread_mutex_t alloc_mutex;
*** 140,146
{ \
pthread_mutex_unlock (&alloc_mutex); \
if (pthread_equal (pthread_self (), main_thread)) \
! sigunblock (sigmask (SIGIO)); \
} \
while (0)
--- 140,146
{ \
pthread_mutex_unlock (&alloc_mutex); \
if (pthread_equal (pthread_self (), main_thread)) \
! UNBLOCK_INPUT;\
} \
while (0)
Index: src/blockinput.h
===
RCS file: /sources/emacs/emacs/src/blockinput.h,v
retrieving revision 1.21
diff -c -p -r1.21 blockinput.h
*** src/blockinput.h14 Jan 2007 03:24:37 - 1.21
--- src/blockinput.h23 Jan 2007 07:43:15 -
*** Boston, MA 02110-1301, USA. */
*** 49,55
interrupt_input_pending to a non-zero value. If that flag is set
when input becomes unblocked, UNBLOCK_INPUT will send a new SIGIO. */
! extern int interrupt_input_blocked;
/* Nonzero means an input interrupt has arrived
during the current critical section. */
--- 49,55
interrupt_input_pending to a non-zero value. If that flag is set
when input becomes unblocked, UNBLOCK_INPUT will send a new SIGIO. */
! extern volatile int interrupt_input_blocked;
/* Nonzero means an input interrupt has arrived
during the current critical section. */
Index: src/keyboard.c
===
RCS file: /sources/emacs/emacs/src/keyboard.c,v
retrieving revision 1.890
diff -c -p -r1.890 keyboard.c
*** src/keyboard.c 21 Jan 2007 04:18:15 - 1.890
--- src/keyboard.c 23 Jan 2007 07:43:16 -
*** extern int errno;
*** 90,96
/* Variables for blockinput.h: */
/* Non-zero if interrupt input is blocked right now. */
! int interrupt_input_blocked;
/* Nonzero means an input interrupt has arrived
during the current critical section. */
--- 90,96
/* Variables for blockinput.h: */
/* Non-zero if interrupt input is blocked right now. */
! volatile int interrupt_input_blocked;
/* Nonzero means an input interrupt has arrived
during the current critical section. */
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: woman doesn't work if current buffer's directory doesn't exist
> From: Richard Stallman <[EMAIL PROTECTED]> > Date: Mon, 22 Jan 2007 21:07:03 -0500 > Cc: emacs-pretest-bug@gnu.org > Reply-To: [EMAIL PROTECTED] > > This should probably be fixed in call-process (I can't use > shell-command-on-region to pipe a region of a buffer through a shell > command if default-directory doesn't exist, for example, and I'd like > to be able to). Perhaps default-directory could default to the value > of temporary-file-directory if it doesn't exist. > > It would be easy to change what call-process does when > default-directory does not exist. What is the best thing for it to do > in that case? There's no ``best way'', it depends on what code calls call-process. In some cases, you could bind default-directory to something sensible (e.g., invocation-directory), in others you _must_ fail, because the command arguments could use something like "./foo/bar" which precludes us from changing directories. So I think this problem cannot be solved inside call-process, but instead an application (WoMan in this case) should cater to such situations, where it indeed doesn't matter what is the value of default-directory. Another possibility would be to add an optional argument to call-process, which, when non-nil, will bind default-directory to some value that is guaranteed to be an existing directory, if default-directory is nil. Applications like WoMan could then use that optional argument. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: woman doesn't work if current buffer's directory doesn't exist
Richard Stallman wrote: This should probably be fixed in call-process (I can't use shell-command-on-region to pipe a region of a buffer through a shell command if default-directory doesn't exist, for example, and I'd like to be able to). Perhaps default-directory could default to the value of temporary-file-directory if it doesn't exist. It would be easy to change what call-process does when default-directory does not exist. What is the best thing for it to do in that case? It should signal an error, that the directory doesn't exist. How does one create a buffer whose default-directory doesn't exist? -- Kevin Rodgers Denver, Colorado, USA ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Should let symbols be interned?
"Lennart Borgman (gmail)" <[EMAIL PROTECTED]> writes:
> So #:my-uninterned-var could be #:dummy? The name given is never used, or?
If you print the code, the name you use is what's printed (that's really
the only thing variable names are ever used for once the reader has read
the code).
-miles
--
/\ /\
(^.^)
(")")
*This is the cute kitty virus, please copy this into your sig so it can spread.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: woman doesn't work if current buffer's directory doesn't exist
This should probably be fixed in call-process (I can't use shell-command-on-region to pipe a region of a buffer through a shell command if default-directory doesn't exist, for example, and I'd like to be able to). Perhaps default-directory could default to the value of temporary-file-directory if it doesn't exist. It would be easy to change what call-process does when default-directory does not exist. What is the best thing for it to do in that case? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Should let symbols be interned?
Miles Bader wrote: "Lennart Borgman (gmail)" <[EMAIL PROTECTED]> writes: (let ((#1=#:my-uninterned-var 5)) (+ #1# 3)) Thanks. I have never seent that syntax. I guess it is "unofficial"? I'm not really sure what you mean; it's real reader syntax, and it's perfectly fine to use it... It will also be output by the lisp printer if `print-gensym' is non-nil. See `(elisp)Output Variables' and `(elisp)Circular Objects' in the info manual. Basically #:SYMBOL is read like SYMBOL, except that it's not interned. So a further occurance of #:SYMBOL will be a _different_ symbol. When is my-uninterned-var used in the elisp code? Only in the #:? The #1# is actually #:my-uninterned-var (the same one as before, not a different one with the same name). Thanks. Let see if I understand now ;-) So #:my-uninterned-var could be #:dummy? The name given is never used, or? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Should let symbols be interned?
> Date: Mon, 22 Jan 2007 11:26:44 +0100 > From: "Lennart Borgman (gmail)" <[EMAIL PROTECTED]> > Cc: emacs-pretest-bug@gnu.org > > > >(intern-soft "my-uninterned-var") > > => nil > >(let ((#1=#:my-uninterned-var 5)) > > (+ #1# 3)) > > => 8 > >(intern-soft "my-uninterned-var") > > => nil > > > > -Miles > > > Thanks. I have never seent that syntax. I guess it is "unofficial"? It's entirely official; see `(elisp)Symbol Type', near the end. (I found that place by typing "i # RET" in the ELisp manual, then hitting `,' a few times.) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: (that binding is currently shadowed ...)
"Lennart Borgman (gmail)" <[EMAIL PROTECTED]> writes:
> If cua-mode is enabled and you define a minor mode using C-c as a
> prefix key you describe-bindings wrongly says that C-c is
> shadowed. This is quite disturbing since C-c by some of the
> punctuation characters is what a minor mode is supposed to use (my
> example uses C-c RET which is a bit bad). Here is how the output can
> look:
>
> key binding
> --- ---
>
> C-c Prefix Command
> (that binding is currently shadowed by another mode)
>
Here is a patch which fixes this problem. I'm not sure whether it
has any bad effects in other cases. Stefan?
*** keymap.c21 Jan 2007 21:53:58 +0100 1.344
--- keymap.c22 Jan 2007 20:57:29 +0100
***
*** 3456,3464
if (!NILP (tem))
{
/* Avoid generating duplicate entries if the
!shadowed binding has the same definition. */
if (mention_shadow && !EQ (tem, definition))
! this_shadowed = 1;
else
continue;
}
--- 3456,3467
if (!NILP (tem))
{
/* Avoid generating duplicate entries if the
!shadowed binding has the same definition.
!*/
if (mention_shadow && !EQ (tem, definition))
! /* If both bindings are keymaps, it's a prefix key, so
! don't say it is shadowed. */
! this_shadowed = !(KEYMAPP (definition) && KEYMAPP (tem));
else
continue;
}
> C-c RET Prefix Command
>
>
> Here is an example to use to reproduce it. Start with
>
>emacs -Q
>M-x cua-mode
>
> Then eval the code below and do
>
>M-x mlinks-mode
>C-h f mlinks-mode RET
>
> (defvar mlinks-mode-map
> (let ((m (make-sparse-keymap)))
> (define-key m [(control ?c) ?\r ?\r] 'mlinks-goto)
> (define-key m [(control ?c) ?\r ?n] 'mlinks-next)
> (define-key m [(control ?c) ?\r ?p] 'mlinks-prev)
> (define-key m [(control ?c) ?\r ?h] 'mlinks-toggle-highlighter)
> m))
>
> (define-minor-mode mlinks-mode
> "
> \\{mlinks-mode-map}
> "
> nil
> " ML"
> nil
> :global t
> :keymap mlinks-mode-map
> :group 'mlinks)
>
>
> In GNU Emacs 22.0.92.1 (i386-mingw-nt5.1.2600)
> of 2007-01-20
--
Kim F. Storm <[EMAIL PROTECTED]> http://www.cua.dk
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Should let symbols be interned?
>> I rest my case: you're confusing variables and symbols. >> Symbols are fundamentally nothing more than hash-consed strings. >> >> Symbols are created by the lexer, not by the evaluator, so insertion into >> a big obarray only affects the performance of the lexer/parser. >> >> >> Stefan > Thanks, I guess I understand a bit more. Just out of curiosity: Does the > lexer/parser know that it is a let variable at the time the symbol is > inserted or is that information only available later to the evaluator? The lexer/parser doesn't even know if it's parsing code or data. That's the meaning of "syntax" as opposed to "semantics". Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: typo in hexl.el
On 1/22/07, Chris Moore <[EMAIL PROTECTED]> wrote: I sent this 11 days ago, but it appears not to have reached the list. Committed, thanks. /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
typo in hexl.el
I sent this 11 days ago, but it appears not to have reached the list. From: Chris Moore <[EMAIL PROTECTED]> To: emacs-pretest-bug@gnu.org, Chris Moore <[EMAIL PROTECTED]> Subject: typo in hexl.el --- lisp/hexl.el2006-12-01 00:30:52.0 +0100 +++ /tmp/hexl.el2007-01-11 15:05:53.0 +0100 @@ -400,7 +400,7 @@ (hl-line-mode 0)) (when (boundp 'hexl-mode-old-hl-line-range-function) (setq hl-line-range-function hexl-mode-old-hl-line-range-function)) - (when (boundp hexl-mode-old-hl-line-face) + (when (boundp 'hexl-mode-old-hl-line-face) (setq hl-line-face hexl-mode-old-hl-line-face)) (setq require-final-newline hexl-mode-old-require-final-newline) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
woman doesn't work if current buffer's directory doesn't exist
In GNU Emacs 22.0.92.24 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2007-01-21 on trpaslik X server distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--with-gtk' '--prefix' '/usr/local' '--with-xpm' '--with-jpeg' '--with-png' '--with-gif'' $ mkdir /tmp/foo $ cd /tmp/foo $ emacs -Q# current directory is /tmp/foo M-x delete-directory RET RET # remove the current directory M-x woman RET ls RET # woman fails * File /usr/share/man/man1/ls.1.gz not found! * The error message is misleading, since the file does exist, and is readable. The cause of the problem is that call-process doesn't work if default-directory doesn't exist, and jka-compr.el uses call-process in a few places. This should probably be fixed in call-process (I can't use shell-command-on-region to pipe a region of a buffer through a shell command if default-directory doesn't exist, for example, and I'd like to be able to). Perhaps default-directory could default to the value of temporary-file-directory if it doesn't exist. Alternatively, a less far-ranging fix is to modify just jka-compr.el to bind default-directory while call-process is running: --- lisp/old/jka-compr.el 2006-12-05 07:15:38.0 +0100 +++ lisp/jka-compr.el 2007-01-22 04:50:57.0 +0100 @@ -166,6 +166,7 @@ ;; to discard the part we don't want. (let ((skip (/ beg jka-compr-dd-blocksize)) (err-file (jka-compr-make-temp-name)) + (default-directory (file-name-directory infile)) count) ;; Update PREFIX based on the text that we won't read in. (setq prefix (- beg (* skip jka-compr-dd-blocksize)) @@ -204,6 +205,7 @@ (defun jka-compr-call-process (prog message infile output temp args) + (let ((default-directory (file-name-directory infile))) (if jka-compr-use-shell (let ((err-file (jka-compr-make-temp-name)) @@ -243,6 +245,7 @@ (with-current-buffer temp (write-region (point-min) (point-max) output) (erase-buffer) + ) ;; Support for temp files. Much of this was inspired if not lifted Chris. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Should let symbols be interned?
"Lennart Borgman (gmail)" <[EMAIL PROTECTED]> writes: >>(let ((#1=#:my-uninterned-var 5)) >> (+ #1# 3)) > > Thanks. I have never seent that syntax. I guess it is "unofficial"? I'm not really sure what you mean; it's real reader syntax, and it's perfectly fine to use it... It will also be output by the lisp printer if `print-gensym' is non-nil. See `(elisp)Output Variables' and `(elisp)Circular Objects' in the info manual. Basically #:SYMBOL is read like SYMBOL, except that it's not interned. So a further occurance of #:SYMBOL will be a _different_ symbol. > When is my-uninterned-var used in the elisp code? Only in the #:? The #1# is actually #:my-uninterned-var (the same one as before, not a different one with the same name). It uses the "reference" feature of the reader, which allows you to specify multiple references to the same lisp object in a form read by the reader. Here #N=FORM (where N is an integer) is read just like FORM, except that it also associates N with FORM. #N# is then read as the same FORM which was read earlier. This is useful for printing/reading circular data structures (so the variable `print-circle' enables printing of it), but it's also good for reading multiple references to uninterned symbols. -Miles -- [|nurgle|] ddt- demonic? so quake will have an evil kinda setting? one that will make every christian in the world foamm at the mouth? [iddt] nurg, that's the goal ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: ps-print-buffer-with-faces doesn't use selected frame's background
On 2007-01-22, Richard Stallman said: > I just tested it. With ps-use-face-background set to t, it seems to > print correctly. > > Should that be the default setting of ps-use-face-background? Since I print to .ps file I don't mind setting it to t. But for others using the REAL printer, that would be quite a waste to print something almost completely black. Would it look good to stay with white background and using reverse-video color for the rest faces? Just a wild guess. -- Leo (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Should let symbols be interned?
Eli Zaretskii wrote: Date: Mon, 22 Jan 2007 02:07:12 +0100 From: "Lennart Borgman (gmail)" <[EMAIL PROTECTED]> Cc: emacs-pretest-bug@gnu.org I believe however that it takes more time to insert a symbol in big obarray than in a small. But that depends on how the internal structure of an obarray looks and how it is handled. I assume it is some kind of tree structure. Why assume? the ELisp manual describes that for you; when in the manual, type "i obarray RET" and read there. You will see that Emacs uses hashing, like all other implementations of symbol tables (which is what obarray really is), so adding a new symbol is more or less independent of the obarray size. The same goes for searches and other types of access. Thanks. That explains it well. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Should let symbols be interned?
Miles Bader wrote: "Lennart Borgman (gmail)" <[EMAIL PROTECTED]> writes: However the real question was of course if the same obarray is used for symbols created by let variable declarations (did I get everything right now?;-) as for symbols created by "defvar" variables. I was surprised by that and a bit curious. Interning is done by the reader, it has absolutely no connection to the interpretation of what is being read. If you want to use an uninterned variable name in a let statement, you can use the "#:" reader syntax, along with the #n= and #n# syntaxes to allow using the uninterned variable: (intern-soft "my-uninterned-var") => nil (let ((#1=#:my-uninterned-var 5)) (+ #1# 3)) => 8 (intern-soft "my-uninterned-var") => nil -Miles Thanks. I have never seent that syntax. I guess it is "unofficial"? When is my-uninterned-var used in the elisp code? Only in the #:? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Should let symbols be interned?
Stefan Monnier wrote: I rest my case: you're confusing variables and symbols. Symbols are fundamentally nothing more than hash-consed strings. Symbols are created by the lexer, not by the evaluator, so insertion into a big obarray only affects the performance of the lexer/parser. Stefan Thanks, I guess I understand a bit more. Just out of curiosity: Does the lexer/parser know that it is a let variable at the time the symbol is inserted or is that information only available later to the evaluator? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Should let symbols be interned?
On 1/22/07, Lennart Borgman (gmail) <[EMAIL PROTECTED]> wrote: Looks like I am waisting time by not beeing clear enough, but since I am rather sure that you understand what I mean I do not express things that explicit. I was originally answering to this: However the real question was of course if the same obarray is used for symbols created by let variable declarations (did I get everything right now?;-) as for symbols created by "defvar" variables. which is a yes/no question, and wondering why, and then you started talking about "relative time consumption". So it seems like the problem (for me) is that you mean different things at different point of the conversation. Is hard to track. /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
