June 2006 - XEmacs-Beta - XEmacs Mailing List Archives

Re: setup_ccl_program in ccl_init_coding_stream 18 years, 5 months

Aidan Kehoe

Ar an chéad lá is fiche de mí Meitheamh, scríobh Stephen J. Turnbull: > >>>>> "Aidan" == Aidan Kehoe <kehoea(a)parhasard.net> writes: > > Aidan> The test case I gave didn’t involve Gnus, just > Aidan> latin-unity, which is why I asked you in particular. > > Ah, sorry! What's even more sorry is I can't reproduce. :-( At least > if I understand you correctly; the designed result is to end up with a > buffer containing a bunch of ISO 646-IRV characters, with U+00F6, > U+0192, and U+5357 mixed in, and the form returns nil, right? That's > what I get. Well, that’s encouraging, it works for someone :-) . > Japanese language environment (probably not directly relevant). > > Coding system of buffer 5wDxDXtyU is Mule/ISO7. I would think this > doesn't matter since the internal encoding is a UCS, but.... Maybe > you can update your test case to set an appropriate > buffer-file-coding-system to force the problem? To reproduce it here, XEmacs 21.5-b27 "fiddleheads" (+CVS-20060521) configured for `i686-pc-linux'., 1. Download the latest latin-euro-standards and latin-unity packages, extract them to /tmp/aidan/ 2. LANG=C xemacs -vanilla 3. Evaluate the following; (push "/tmp/aidan/lisp/latin-euro-standards/" load-path) (push "/tmp/aidan/lisp/latin-unity/" load-path) 4. Evaluate the test case; (let* ((temp-buffer (generate-new-buffer "5wDxDXtyU")) begin end csets psets) (require 'latin-unity) (set-buffer temp-buffer) (insert (decode-coding-string " >> [...] m\xc3\xb6glich \xc6\x92 \xe5\x8d\x97" 'utf-8)) (setq begin (point-min) end (point-max) csets (latin-unity-representations-feasible-region begin end) psets (latin-unity-representations-present-region begin end)) (latin-unity-maybe-remap begin end 'iso-8859-1 csets psets)) That gives me a long list of warnings on “Obsolete key binding technique”, and a result of iso-8859-1. It shouldn’t give me that result, because U+0192 cannot be, and was not, remapped to ISO 8859/1, and ditto for U+5357. The coding system of the buffer is binary, but that shouldn’t be relevant, as I understand it. -- Santa Maradona, priez pour moi!

2 participants
5 comments

Re: Comments on patch 18 years, 5 months

Surendra Singhi

Hello, "Stephen J. Turnbull" <stephen(a)xemacs.org> wrote: >>>>>> "Surendra" == Surendra Singhi <efuzzyone(a)netscape.net> writes: > > Surendra> Are there any chances of this patch being included: > >In which version? I suppose you mean 21.4, since join-line is already >in 21.5 (I don't know why delete-trailing-whitespace is not), but >please confirm. > Next release of 21.4, I don't care much about join-line, but need 'delete-trailing-whitespace'. Also, won't mind it in 21.5. Thanks. -- Surendra Singhi http://ssinghi.kreeti.com/, http://www.kreeti.com __________________________________________________________________ Switch to Netscape Internet Service. As low as $9.95 a month -- Sign up today at http://isp.netscape.com/register Netscape. Just the Net You Need. New! Netscape Toolbar for Internet Explorer Search from anywhere on the Web and block those annoying pop-ups. Download now at http://channels.netscape.com/ns/search/install.jsp

3 participants
2 comments

Dangerous strcpy 18 years, 5 months

Jerry James

I tried out a "security checker" today that supposedly looks for security-related properties of code. It mostly produced nonsense, but it did find this: in sound.c, line 645, we do a strcpy. We are copying into a stack buffer of fixed size (255 bytes). We are copying from h->h_name, where h is a struct hostent * returned by gethostbyname(). Do we actually know that h->h_name must be 254 (+ 1 null terminator) characters long or less? I don't see anything on the gethostbyname man page that so indicates. -- Jerry James, Assistant Professor james(a)xemacs.org Computer Science Department http://www.cs.usu.edu/~jerry/ Utah State University

4 participants
10 comments

Re: Unicodification of sources, part 1 18 years, 5 months

Sebastian Freundt

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jerry James <james(a)xemacs.org> writes: > Aidan Kehoe <kehoea(a)parhasard.net> wrote: [snip] >> (From the SXEmacs Unix-only perspective, one alternative _might_ be to find >> an ISO-2022 compatible coding system supported by GNU iconv that does what >> my recent changes to the escape-quoted coding system does; that is, >> represent Unicode code points that don’t have a known ISO 2022 mapping using >> UTF-8 escapes. Then one could replace the guts of the Unicode coding systems >> with iconv() calls. But I couldn’t find such an iconv coding system easily; >> maybe one does exist, still.) > > I don't understand why we need to worry about SXEmacs. Let the SXEmacs > developers worry about it, if they feel the need. We've got our hands > full with our own project. (Don't interpret this as antipathy for > SXEmacs; I wish the SXEmacs developers well. I'm just being pragmatic.) Absolutely right, Jerry. :) And thanks to Aidan for this wonderful proposal. We are currently checking/discussing the pros and cons of libiconv and friends, from what I understood so far it is a very promising approach. However, our decision for or against one of the alternatives is not something you should bother with or count on, especially as we do not have: 1. enough insight to foresee consequences 2. enough man-power and competence to migrate faster than you 3. very limited interest in unicode at all (from the developers point) We would like to see us in an reactive role, that is our final decision may depend on yours, but conversely you should not necessarily consider us in your decision. If all your changes are transparent enough at lisp level, we will surely implement the necessary compatibility layer at the C level. Sebastian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEmcNNlMmhrILJOQ4RAt9rAJwPtKb3BsMoExWRmkC9Tfapny5g3ACdG4G0 GWJnQUH0OTMmgQaQy7NltdA= =3sFO -----END PGP SIGNATURE-----

2 participants
1 comments

Yet another Dynarr leak in redisplay 18 years, 5 months

Jerry James

I just sent a patch to xemacs-patches to fix a Dynarr leak in redisplay. Here's another one, but I'm not sure what to do with it. This leak affects both 21.4 and 21.5. In redisplay.c, look at the macro ADD_NEXT_OCTAL_RUNE_CHAR. Note that, if prop is NULL, it is set to a freshly created Dynarr by this macro. The macro is used in the function add_octal_runes, which is just below it. At the end of that function, nothing is done with prop. It is not returned and, more to the point, it is not freed. It looks like the callers of add_octal_runes expected prop to be returned to them. However, I don't understand this code at all, so I'm afraid to touch it. Does anybody know what's going on here? -- Jerry James, Assistant Professor james(a)xemacs.org Computer Science Department http://www.cs.usu.edu/~jerry/ Utah State University

2 participants
1 comments

Comments on patch 18 years, 5 months

Surendra Singhi

Hello, Are there any chances of this patch being included: http://list-archive.xemacs.org/xemacs-patches/200204/msg00188.html it adds join-line and delete-trailing-whitespace to simple.el If there are any issues/problems with it, then I will try to help. Thanks. -- Surendra Singhi http://ssinghi.kreeti.com, http://www.kreeti.com Read my blog at: http://cuttingtheredtape.blogspot.com/ ,---- | "All animals are equal, but some animals are more equal than others." | -- Orwell, Animal Farm, 1945 `----

3 participants
2 comments

Crash in Carbon XEmacs 21.5.26-carbon-b5 18 years, 5 months

Glen Whitney

================================================================ Dear Bug Team! I am running Mac OS X 10.4.6 on a PowerPC G4. I downloaded xemacs-21.5.26.tar.gz from a standard XEmacs site, and xemacs-21.5.26-carbon-b5.diff.bz2 from Andrew Choi's Carbon XEmacs page (as linked by www.xemacs.org). I followed the build instructions in the carbon/README file with no modifications, everything went smoothly and as described. With no init file xemacs seems to come up OK and seems to behave generally as expected. However, if I create an .xemacs directory with just an init.el containing the following text: ----cut here---- (setq minibuffer-frame-plist '(top -1 left 1 height 3)) (setq initial-frame-plist '(minibuffer nil [default font] "Courier:13")) ----cut here---- and then start xemacs, I get the following behavior: An initial window comes up that looks the same as with no init file. If I type any key to this window, the app crashes, creating a window with the following information: ----cut here---- EXC_BAD_ACCESS (0x0001) KERN_INVALID_ADDRESS (0x0001) at 0x0591a010 Thread 0 Crashed: 0 vecCGSBlendXXXX8888 + 420 1 ripd_Mark + 324 2 ripl_BltImage + 908 3 ripc_RenderImage + 256 4 ripc_DrawImage + 3532 5 CGContextDelegateDrawImage + 76 6 CGContextDrawImage + 340 7 HIViewDrawCGImage + 284 8 main_view_handler + 604 (frame-carbon.c:150) 9 DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 692 ----cut here---- (The window asks if I want to close, report, or attach debugger. I tried the debugger, but it seemed to hang, i.e., no debugger prompt for about 10 minutes.) Note I have no .emacs file. On a separate note, this Carbon XEmacs seems palpably slower than the Carbon (Gnu) Emacs package available at http://homepage.mac.com/ zenitani/emacs-e.html for almost every task. For one simple example, I can easily type ahead of Carbon XEmacs's response on my machine in just the ordinary *scratch* buffer, whereas I can only do so with great effort in Carbon Emacs. Is this speed difference to be expected? Is there any hope of XEmacs's speed being significantly improved? I like the feature set in XEmacs better (although specifiers can be byzantine) but right now the speed issue is making me stick with Carbon Emacs, since I find myself often making erroneous edits when I type ahead of Carbon XEmacs but don't realize it. Thanks for any information/advice on the topic of XEmacs's speed, I would prefer to use XEmacs but can't if the speed makes it impractical. Finally, I wasn't sure where best to send this bug. Mr. Choi's website suggests comp.emacs.xemacs, report-xemacs-bug suggests this email address. If the bug report needs to be forwarded so that it will be visible both to Mr. Choi and the main-line XEmacs maintainers, I'd appreciate your doing so. Thanks, Glen Whitney ================================================================ System Info to help track down your bug: --------------------------------------- uname -a: Darwin chickadee.local 8.6.0 Darwin Kernel Version 8.6.0: Tue Mar 7 16:58:48 PST 2006; root:xnu-792.6.70.obj~1/RELEASE_PPC Power Macintosh powerpc PowerBook3,5 Darwin ./configure '--without-kkcc' '--without-mc-alloc' '--with-carbon' '-- with-mule' '--without-ldap' '--enable-error-checking=none' '--with- optimization' '--with-cflags-optimization=-O2' '--prefix=/sw/src/ xemacs-21.5.26/carbon/XEmacs.app/Contents/Resources' XEmacs 21.5-b26 "endive" configured for `powerpc-apple-darwin8.6.0'. Compilation Environment and Installation Defaults: Source code location: /sw/src/xemacs-21.5.26 Installation prefix: /sw/src/xemacs-21.5.26/carbon/ XEmacs.app/Contents/Resources Operating system description file: `s/darwin.h' Machine description file: `m/powerpc.h' Compiler version: powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5341) - GCC specs file: specs. - Compiler command: gcc -I/sw/src/xemacs-21.5.26/ carbon/xpm -Wall -Wno-switch -Wundef -Wsign-compare -Wno-char- subscripts -Wpacked -Wpointer-arith -Wunused-parameter -g -O2 libc version: Relocating allocator for buffers: no GNU version of malloc: no - The GNU allocators don't work with this system configuration. Window System: Compiling in support for Mac OS X Carbon. Using Lucid menubars. Using Lucid scrollbars. Compiling in support for Drag'n'Drop (EXPERIMENTAL). - Drag'n'Drop prototype: Carbon. TTY: Compiling in support for ncurses. Images: Compiling in support for GIF images (builtin). Compiling in support for XPM images. WARNING: ----------------------------------------------------------- WARNING: Compiling without PNG image support. WARNING: You should strongly consider installing the PNG libraries. WARNING: Otherwise certain images and glyphs may not display. WARNING: (a copy may be found in ftp://ftp.xemacs.org/pub/xemacs/aux) WARNING: ----------------------------------------------------------- Sound: Databases: Compiling in support for Berkeley database. Compiling in support for DBM. Internationalization: Compiling in support for Mule (multi-lingual Emacs). Mail: Compiling in support for "file" mail spool file locking method. Other Features: Inhibiting IPv6 canonicalization at startup. Compiling in support for dynamic shared object modules. Using the new portable dumper. Dumping into executable. Compiling in support for extra debugging code. Load-Path Lisp Shadows: nil

2 participants
1 comments

comint + shell still hosed 18 years, 5 months

Ilya N. Golubev

Can not work with recent `.el': `comint.el' as of 2006-06-07, `shell.el' as of 2006-06-01. Can not switch to new `comint.el' without also updating `shell.el'. New `comint.el' does not define `make-comint-1' at all. Debugger entered--Lisp error: (void-function make-comint-1) make-comint-1(#<buffer "*shell*"> "/bin/bash" nil "--noediting" "-i") apply(make-comint-1 #<buffer "*shell*"> "/bin/bash" nil ("--noediting" "-i")) shell() Can not update `shell.el' either. In xemacs 21.4 when loading new `shell.elc' the following error occurs. Lisp error: (invalid-function (macro . #<compiled-function (mode doc &optional init-value lighter keymap &rest body) "...(660)" [lighter group mode-name keymap mode body keywordp nil symbol-name easy-mmode-pretty-mode-name t intern "-map" "-hook" "-on-hook" "-off-hook" :init-value :lighter :global :extra-args :group :require quote replace-regexp-in-string "-mode\\'" "" progn defvar format "Non-nil if %s is enabled. Use the command `%s' to change this variable." make-variable-buffer-local boundp byte-compile-current-file defcustom "Non-nil if %s is enabled. See the command `%s' for a description of this minor-mode. Setting this variable directly does not take effect; use either \\[customize] or the function `%s'." :set (lambda (symbol value) (funcall symbol (or value 0))) :initialize (quote custom-initialize-default) append :type (quote boolean) file-name-nondirectory file-name-sans-extension defun &optional arg "Toggle %s on or off. Interactively, with no prefix argument, toggle the mode. With universal prefix ARG turn mode on. With zero or negative ARG turn mode off. \\{%s}" (interactive (list (or current-prefix-arg (quote toggle)))) let old-mode setq cond (eq arg (quote toggle)) not (arg (or (listp arg) (> (prefix-numeric-value arg) 0))) if null message "Toggling %s off; better pass an explicit argument." (nil) and equal run-hooks init-value keymap-sym G89102 pretty-name require globalp hook hook-on hook-off extra-args curfile load-file-name doc (interactive-p) "%s %%sabled" ("en" "dis") (force-mode-line-update) "Hook run at the end of function `%s'." (:type (quote hook)) "Hook to run when entering %s." (:type (quote hook)) "Hook to run when exiting %s." (:type (quote hook)) m ((keymapp m) m) ((listp m) (easy-mmode-define-keymap m)) error "Invalid keymap %S" "Keymap for `%s'." add-minor-mode symbol-value ((not purify-flag)) eval-after-load (1 -1)] 23 ("/home/gin/xemacs-21.4-nsp/xemacs-packages/lisp/xemacs-base/easy-mmode.elc" . 2635)>)) define-minor-mode(t "Turn directory tracking on and off in a shell buffer." nil nil nil "/home/gin/" (shell-directory-tracker)) byte-code("..." [list-buffers-directory default-directory shell-dirtrack-mode defvaralias shell-dirtrackp define-minor-mode "Turn directory tracking on and off in a shell buffer." nil add-hook comint-input-filter-functions shell-directory-tracker t remove-hook defalias shell-dirtrack-toggle dirtrack-toggle dirtrack-mode] 12) load-internal After that `shell' does not signal errors, and works in an elementary way, but outputs this message. Symbol's function definition is void: shell-dirtrack-mode

2 participants
1 comments

assert, ABORT, and friends 18 years, 5 months

Jerry James

I'm trying to make some static checkers produce usable results on the XEmacs code base. By "usable", I mean, "not producing hundreds and hundreds of false positives." One of the problems I am facing is that the checkers I am using are very, very good at finding code paths that lead through assert_failed(), usually coming in via assert() or ABORT(). The function assert_failed() can return. In normal circumstances, it won't, but it can. It starts like this: /* If we're already crashing, let's not crash again. This might be critical to getting auto-saving working properly. */ if (fatal_error_in_progress) return; for example. Our code base is riddled with code that calls assert() and assumes that execution will not continue if the assertion fails, or calls ABORT() and assumes that execution will not continue under any circumstances. Again, normally that is true, but it is not guaranteed. The code in assert_failed() is trying to be paranoid. It wants to (1) make sure the user's files are auto-saved, and (2) that some kind of "I'm dying!" message gets printed on the way out, with helpful information such as a Lisp backtrace. It wants to make sure that, if (1) or (2) trigger another assertion failure, ABORT(), or fatal signal that we don't get trapped in an infinite loop. My opinion is that this is misdirected paranoia. I think we would be better served by having an assert_failed() that we know for certain will not return, without unduly jeopardizing the user's data. I can see a couple of ways of accomplishing that. We could have assert_failed() do a setjmp and, if assert_failed is entered a second time, longjmp() back to the first invocation. This option makes me nervous. We could have a second invocation of assert_failed() print some kind of apologetic message ("Dave, my mind is going. I can feel it. I can feel it.") and exit(). Since assert_failed() tries to auto-save the user's files first and print second, a second invocation of assert_failed() means either that: (1) the files were already auto-saved and we're recrashing while trying to tell the user about it; or (2) the attempt to auto-save triggered another failure. In case (1), either approach above is fine. In case (2), I'm afraid that the user is just going to lose data no matter what we do, so either approach above is fine. For a little contrast, I just went through the Emacs code base to see how they handle this situation. Their assertion macro (xassert) just calls the system abort() if the expression is false. Their SIGABRT handler unhandles SIGABRT before doing anything else. That way, if a second abort() happens, it uses the system default handler: dump core and die. I think this approach makes a lot of sense and is much better than the error-prone way we are doing it. -- Jerry James, Assistant Professor james(a)xemacs.org Computer Science Department http://www.cs.usu.edu/~jerry/ Utah State University

4 participants
6 comments

setup_ccl_program in ccl_init_coding_stream 18 years, 5 months

Jerry James

Today I played with a very clever static checker that noticed that the return value of setup_ccl_program is checked everywhere, except for the call in ccl_init_coding_stream (mule-coding.c). So, to those who understand this code, should the return value be checked there as well? -- Jerry James, Assistant Professor james(a)xemacs.org Computer Science Department http://www.cs.usu.edu/~jerry/ Utah State University

3 participants
6 comments

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta June 2006