robert> Just a note, this is exactly where OS X XEmacs 21.5.b9 robert> fails on a number of occasions. The only cure I found was robert> to increase the stack, but it appears when viewed through robert> Apple's Project Developer that re_match_2 routines are robert> being called recursively (I counted 30 nested calls in one robert> instance), and That's right. robert> the failure was always a bad memory access at the robert> expression PUSH_FAILURE_POINT (p1 + mcnt, d, -2); Yup. If you look at the value of this_reg at that point, you'll very likely find that it's equal to fail_stack.size, and entirely absurd given the values of lowest_active_reg and highest_active_reg. So it looks like this has something to do with the implementation of alloca that isn't glibc related, right? robert> Perhaps this would allow me to recompile with a smaller robert> stack. An 8 MB stack prevents the Carbonized program from robert> being debugged in Project Developer. That's what I would expect. However, I think that you still need a bigger than default stack. Let me know how it works and if it does I'll add it to PROBLEMS and INSTALL in the appropriate places. If you get any results about just how small the stack can be, that would be appreciated, too. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Economics of Information Communication and Computation Systems Experimental Economics, Microeconomic Theory, Game Theory

The Carbon version of XEmacs sets the size of the stack explicitly. (see run.c: int stack_size = 0x800000; /* moby */) The Carbon version is two cooperative threads. The main thread fields Carbon events. The second thread is XEmacs. The line of code above sets the stack size of the second thread (XEmacs). I recently set the stack size to 8MB per Royar's suggestion. Carbon XEmacs no longer crashes with a segmentation fault in the regex code when opening a file in shell-mode (my .tcshrc file for example). Rather than crashing with a segmentation fault it fails with a warning. I can ignore the warning and proceed to edit my .tcshrc file, but only in fundamental mode. The warning is: (1) (file-mode-spec/warning) Error in File mode specification: sh-mode Backtrace follows: signal(error ("sh-mode")) # bind (args datum) cerror("%s" sh-mode) apply(cerror "%s" sh-mode) # bind (args datum) error("%s" sh-mode) # bind (name alist mode name keep-going) # (unwind-protect ...) # bind (just-from-file-name) set-auto-mode() #<compiled-function nil "...(5)" [set-auto-mode t] 1>() # (unwind-protect ...) call-with-condition-handler(#<compiled-function (__call_trapping_errors_arg__) "...(17)" [__call_trapping_errors_arg__ errstr error-message-string lwarn file-mode-spec warning "Error in %s: %s\n\nBacktrace follows:\n\n%s" "File mode specification" backtrace-in-condition-handler-eliminating-handler] 8> #<compiled-function nil "...(5)" [set-auto-mode t] 1>) # (condition-case ... . ((error))) # bind (find-file) normal-mode(t) # bind (nomodes after-find-file-from-revert-buffer noauto warn error) after-find-file(nil t) byte-code("..." [buffer-file-number number truename buffer-file-truename buf buffer-file-name set-buffer-major-mode erase-buffer nil (byte-code "´á¬ √\"à™Öƒ √\"à¬á" [rawfile filename insert-file-contents-literally t insert-file-contents] 3) ((file-error (byte-code "√\n!´åƒ\n!¨á≈∆«\nD\"à´Ñ»™á… !¨Ç»√á" [rawfile error filename file-exists-p file-readable-p signal file-error "File is not readable" t run-hook-with-args-until-success find-file-not-found-hooks] 4))) abbreviate-file-name file-name-directory make-local-variable backup-inhibited t after-find-file find-file-use-truenames default-directory backup-enable-predicate rawfile error nowarn] 3) # (condition-case ... . ((t (byte-code "¬!à√ ＠ A\"á" [buf data kill-buffer signal] 3)))) # (unwind-protect ...) # bind (error number truename buf rawfile nowarn filename) find-file-noselect("~/.tcshrc") # bind (codesys filename) find-file("~/.tcshrc" nil) # bind (command-debug-status) call-interactively(find-file) # (condition-case ... . error) # (catch top-level ...) On Monday, December 16, 2002, at 02:58 PM, robert delius royar wrote:

robert> Since package updates do not work under the carbon version, Oops ... do you know why not? -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.

Would you please be more specific? The Carbon version of XEmacs 21.5.9 is functionaly IDENTICAL to the Terminal version. Are there "process control abilities" in the X-Windows version that are not in the Terminal version? I do have a documented intermittent bug that not all grep output reaches the *grep* buffer; however, all other process related stuff (dired, ediff, shell, &tc.) functions properly. There are four Carbon specific portions of the implementation. Carbon/Apple events, a thin veneer for Unix access from Carbon, lisp access to the Macintosh tool box (Carbon), and TTY style display. Which parts don't you like? What packages are you having trouble with? The packages that I use every day include: c-support cc-mode calendar debug dired ediff edit-utils efs os-utils prog-modes psgml xemacs-base xemacs-devel From time to time I find problems with package code that makes incorrect assumptions about GUI issues. For example accessing non-existent menus and other missing UI elements not present on a raw TTY system. Are your issues similar? On Wed, 18 Dec 2002, robert delius royar <royar(a)adelphia.net&gt; wrote: > On Wed, 18 Dec 2002, Stephen J. Turnbull wrote: > >>>>>>> "robert" == robert delius royar <royar(a)adelphia.net&gt; writes: >> >> >> Oops ... do you know why not? > > The Carbon (semi-native) version is still alpha--very alpha. XEmacs > under > XFree-86 on OS X does run package update reliably. The Carbon version > doesn't have all the process control abilities yet. It is more like > the old > 19.4 (?) XEmacs that was ported to Mac years ago than it is like a > current > XEmacs. It's run through a wrapper of what looks to be ancient > converted > PASCAL (like the old MS C of the mid 1980s). > > X11 on my machine requires reboots about every four days, so I am > trying to > find a way not to use it--memory usage problems that are not XEmacs > related. > XEmacs is my only reason for running X11. > > r. royar > > -- > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > =- > Dr. Robert D. Royar Morehead State University > royar(a)adelphia.net > T r a f f i c expands to exceed the available > roadway. > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > =-= >