Re: Emacs build does not finish
Kenichi Handa skrev: In article [EMAIL PROTECTED], Miles Bader [EMAIL PROTECTED] writes: Ralf Angeli [EMAIL PROTECTED] writes: The build process, however, now is really slow. Probably twice the time it took before. Is the slowness restricted to the abnormally large files in the leim subdirectory, such as ZIRANMA.el and ja-dic.el, or is it all lisp files? As the outout of make messages are not shown, I'm not sure which files are re-created, but I suspect that the slowness is because of regeneration of those Lisp files from big dictionary files under CXTERM-DIC and MISC-IDC that is caused by my recent update. The process of byte compiling them is, I think, not that slow; for instance, I can byte-compile ZIRANMA.el in 1.5 second. This takes a very long time for me ( 20 minutes, previously under 30 seconds): sed -n '/^[^;]/ p' /home/jhd/src/emacs/leim/leim-ext.el leim-list.el EMACSLOADPATH=/home/jhd/src/emacs/leim/../lisp LC_ALL=C ../src/emacs -batch --no-init-file --no-site-file --multibyte -f batch-byte-compile /home/jhd/src/emacs/leim/ja-dic/ja-dic.el 1 entries 2 entries 3 entries 4 entries It goes to 4 in about the same time as before, but then is seems to hang. As, those dictionary files are updated very very rarely, I don't think it's a big problem. And a tarball contains generated *.el files. It is a huge problem when you develop in Emacs. Jan D. ___ 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
Chris Moore wrote: Kevin Rodgers [EMAIL PROTECTED] writes: It should signal an error, that the directory doesn't exist. How does one create a buffer whose default-directory doesn't exist? One finds a file or creates a buffer which isn't associated with a file, but has default-directory set anyway, and then has someone else: rename the directory containing the file or rename one of the directories higher up the tree or umount the filesystem holding the file or ... I don't find those scenarios compelling, but I did find out that it's even easier: C-x C-f /this/directory/doesn't/exist/and_neither_does_this_file RET I don't see why I shouldn't be allowed to pipe the contents of a buffer through 'wc -w' for example to count the words in the buffer just because the buffer's default-directory doesn't exist. Now _that_ is a compelling argument. In the case where I first saw this bug, the buffer in question wasn't associated with a file at all. I had simply typed C-x b tmp RET to create a temporary buffer. I was in a '*shell*' buffer at the time, which was in the ~/tmp/foo directory. The 'tmp' buffer which I created therefore had a default-directory of ~/tmp/foo - a directory which I then deleted before attempting to run a shell command on the contents of the tmp buffer. Hmmm. So what is the appropriate directory to use in that situation? As someone else pointed out, that will affect how relative pathnames are interpreted: usefully and safely, or not. Note that when checking for the existance of default-directory, we need to take the filename handlers into account. /ssh:[EMAIL PROTECTED]:/tmp might look like a bad pathname, but it makes sense to Tramp. That is a whole other can of worms. In that case, Tramp is responsible for ensuring that file-directory-p returns the correct result (which is noncontroversial) and also for ensuring that shell-command, call-process, etc. Do The Right Thing i.e. run the command on the remote host in the specified directory (which may or may not be implemented yet). -- 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: Cursor placement with mouse in long lines with wrapped tab
Klaus Zeitler [EMAIL PROTECTED] writes: Sorry for the late response, I have been on vacation. I think we're talking about the following patch: *** emacs/src/xdisp.c.~1.1130.~ 2006-11-26 16:47:55.0 -0500 --- emacs/src/xdisp.c 2006-11-30 14:03:33.0 -0500 *** *** 6828,6834 break; case MOVE_LINE_CONTINUED: ! it-continuation_lines_width += it-current_x; break; default: --- 6828,6835 break; case MOVE_LINE_CONTINUED: ! it-continuation_lines_width += ! (it-c == '\t') ? it-last_visible_x : it-current_x; break; default: Yesterday I fetched the newest CVS version and for me it doesn't work without this patch. Thanks. Chong, will you install your patch? -- 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: Emacs build does not finish
Kenichi Handa [EMAIL PROTECTED] writes: The process of byte compiling them is, I think, not that slow; for instance, I can byte-compile ZIRANMA.el in 1.5 second. Does your Emacs binary include the byte-compiler change mentioned earlier in this thread? Thanks, -- Romain Francoise [EMAIL PROTECTED] | The sea! the sea! the open it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the | ever free! --Bryan W. Procter ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs build does not finish
The build process, however, now is really slow. Probably twice the time it took before. Handa, did you edit one of the dictionary source files and not check in the updated compiled dictionary file made from it? ___ 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
To see jka-compr failing, evaluate this: (let ((default-directory /a/b/c)) (insert-file-contents /usr/share/man/man1/ls.1.gz)) Can someone please fix jka-compr? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
So, in order for BLOCK_INPUT to work reliably, it seems that interrupt_input_blocked should be declared as volatile (or maybe `volatile sig_atomic_t' instead of `volatile int') because it is accessed from a signal handler. Isn't it the case that the C spec calls for this to be volatile? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
Richard Stallman skrev: So, in order for BLOCK_INPUT to work reliably, it seems that interrupt_input_blocked should be declared as volatile (or maybe `volatile sig_atomic_t' instead of `volatile int') because it is accessed from a signal handler. Isn't it the case that the C spec calls for this to be volatile? Quote form the C standard: The type defined is sig_atomic_t which is the (possibly volatile-qualified) integer type of an object that can be accessed as an atomic entity, even in the presence of asynchronous interrupts. However, Neither glibc or Solaris has volatile in the definition. I think the thing guaranteed is accessed, not modified. Jan D. ___ 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
On 1/25/07, Richard Stallman [EMAIL PROTECTED] wrote: To see jka-compr failing, evaluate this: (let ((default-directory /a/b/c)) (insert-file-contents /usr/share/man/man1/ls.1.gz)) Can someone please fix jka-compr? It's at a lower level than jka-compr: (let ((default-directory a/b/c)) (call-process gzip c:/emacs/otros/quack.el.gz t nil -d)) = *** Eval error *** Setting current directory: no such file or directory, a/b/c /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs build does not finish
In article [EMAIL PROTECTED], Romain Francoise [EMAIL PROTECTED] writes: Kenichi Handa [EMAIL PROTECTED] writes: The process of byte compiling them is, I think, not that slow; for instance, I can byte-compile ZIRANMA.el in 1.5 second. Does your Emacs binary include the byte-compiler change mentioned earlier in this thread? Ah, no! I've just updated my working directory and faced with that extreme slowness in byte compiling leim/ja-dic/ja-dic.el. Miles Bader [EMAIL PROTECTED] writes: If the former, perhaps we should add a variable to control whether the byte compiler tries to correctly dump circular data structures or not (`byte-compile-circle'?), and bind it to nil when compiling those large files as we know they contain no circular data. It seems that we need such a hack. How about something like the attached patch and add: -*- byte-compile-disable-print-circle:t; -*- at the head of all generated quail files and ja-dic.el? --- Kenichi Handa [EMAIL PROTECTED] *** bytecomp.el 25 Jan 2007 17:11:39 +0900 2.192 --- bytecomp.el 25 Jan 2007 21:22:12 +0900 *** *** 296,301 --- 296,305 the functions you loaded will not be able to run.) ;;;###autoload(put 'byte-compile-dynamic 'safe-local-variable 'booleanp) + (defvar byte-compile-disable-print-circle nil + If non-nil, disable `print-circle' on printing a byte-compiled code.) + ;;;###autoload(put 'byte-compile-disable-print-circle 'safe-local-variable 'booleanp) + (defcustom byte-compile-dynamic-docstrings t *If non-nil, compile doc strings for lazy access. We bury the doc strings of functions and variables *** *** 2003,2009 (print-level nil) (print-quoted t) (print-gensym t) ! (print-circle t)); handle circular data structures (princ \n outbuffer) (prin1 form outbuffer) nil))) --- 2007,2014 (print-level nil) (print-quoted t) (print-gensym t) ! (print-circle ; handle circular data structures ! (not byte-compile-disable-print-circle))) (princ \n outbuffer) (prin1 form outbuffer) nil))) *** *** 2060,2066 ;; print-gensym-alist not to be cleared ;; between calls to print functions. (print-gensym '(t)) ! (print-circle t); handle circular data structures print-gensym-alist; was used before print-circle existed. (print-continuous-numbering t) print-number-table --- 2065,2072 ;; print-gensym-alist not to be cleared ;; between calls to print functions. (print-gensym '(t)) ! (print-circle ; handle circular data structures ! (not byte-compile-disable-print-circle)) print-gensym-alist; was used before print-circle existed. (print-continuous-numbering t) print-number-table ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs build does not finish
In article [EMAIL PROTECTED], Richard Stallman [EMAIL PROTECTED] writes: The build process, however, now is really slow. Probably twice the time it took before. Handa, did you edit one of the dictionary source files and not check in the updated compiled dictionary file made from it? I do edited several dicstionary source files and updated the generated *.el files, but *.elc are not in the repository. They are byte-compiled at the time of building emacs. --- Kenichi Handa [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: fix for parallel make failure
making finder-data and custom-deps depend on loaddefs.el should avoid this issue. Is this patch correct? It looks OK. But maybe a better approach would be to change the way those two targets work so that they don't read loaddefs.el. After all, they won't find anything useful in there. They just happen to read it because they read every file. Stefan who's hacked his autoload.el so as to generate the custom-dep info as well ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
I think volatile int is OK, I'm sure some systems don't define sig_atomic_t. We could have configure determine whether sig_atomic_t exists, but first let's try `volatile int' and see if that is enough. ___ 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
On 1/25/07, Eli Zaretskii [EMAIL PROTECTED] wrote: What do you mean by ``take into account''? File primitives already do take that into account, in a way, so I'm unsure what you meant here. I'm sorry. I guess all I mean is that we need to fix Tramp (and other file handlers) as well as jka-compr, because this also causes an error: $ emacs -Q (require 'shell) (let ((default-directory /a/b/c)) (insert-file-contents /scp:lukhas:/home/dooglus/.BASH_PROFILE nil)) and so does this: $ emacs -Q (let ((default-directory /a/b/c)) (require 'shell)) Both of these errors are caused by call-process not working when the current directory doesn't exist. ___ 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
It's at a lower level than jka-compr: (let ((default-directory a/b/c)) (call-process gzip c:/emacs/otros/quack.el.gz t nil -d)) Let's not go around in circles. We've already seen why this can't be fixed in a natural way. So jka-compr needs to be fixed to avoid doing this. Would someone please fix jka-compr? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs build does not finish
It seems that we need such a hack. How about something like the attached patch and add: -*- byte-compile-disable-print-circle:t; -*- at the head of all generated quail files and ja-dic.el? For now, we need to either do something like this, or revert the patch that bound print-circle to t. I think it is better to use your patch, because binding print-circle to t does fix a bug. However, after the release it would be good to speed up the implementation of print-circle. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
